なぜ我々はsession.cookieを変更しなければならなかったのか - BASEプロダクトチームブログ
はじめに こんにちは。バックエンドエンジニアの小笠原です。 今回は、2022年2月18日から2022年3月4日にかけて発生していたこちらの障害に対し私達開発チームが実施した、session.cookieで定義しているCookieのkey名を変更するという影響範囲の大きい対応について、実施に至るまでの経緯や対応過程についてご紹介したいと思います。 ショップオーナー向けに掲載していたお知らせの内容 背景 全ては iOS14.5から端末識別子の取得に同意が必要になったことから始まった ことの発端は、iOS14.5以降からIDFA（端末ごとに持つ固有識別子）の取得に端末所有者の許可が必要になったことでした。 この変更は、端末所有者側から見ると情報の活用範囲を自身で管理できることでよりプライバシーに配慮されるようになった良い変更と言えるでしょう。 一方で、広告出稿側から見た場合は拒否をしたユーザーの
"JWT=ステートレス"から一歩踏み出すための考え方
おはようございます、ritouです。 この話に乗っかっていきます。 3行で ログアウト時にJWTを無効化できない実装は今後脆弱性診断で「OWASP Top 10 2021違反」と指摘されるようになりそう(今も個別にされてるかもしれないけど) JWTは単純なフォーマットなので、ステートレスなセッション管理においてログアウトしたときに文字列自体を無効化できない件は独自エンコード方式(一般的にフレームワークのCookieストアと呼ばれているもの)でも起こり得る 「セッションID vs JWTで内包」 以外にも 「セッションIDをJWTに内包」もあり得る。既存の機能を残しつつ「JWTで武装」する選択肢も考えてみてはどうか。 ステートレスなセッション管理でログアウトの際に文字列自体を無効化できない問題 これは前から言われていますし、駆け出し何とか勢のQiita記事に書かれるぐらいには一般的です。 2
マイクロサービス時代のセッション管理 - Retty Tech Blog
この記事はRetty Advent Calendar 2019 21日目の記事です。エンジニアの 神@pikatenor がお送りします。11日目の記事に書かれた「弊社エンジニアの神（注・人名であり実名です）」とは私のことです。 qiita.com さて世はまさにマイクロサービス大航海時代、大規模化した組織・肥大化したコードベースのメンテナンスを継続的に行っていくべく、アプリケーションを機能別に分割する同手法が注目を集めていることは皆さんもご存知でしょう。 マイクロサービスアーキテクチャ特有の設計課題はいくつかありますが、今回は認証情報のような、サービス間でグローバルに共有されるセッション情報の管理のパターンについて調べたことをまとめてみたいと思います。 背景 HTTP は本質的にステートレスなプロトコルですが、実際の Web サービス上では複数リクエストをまたがって状態を保持するために、
オープンソースかつ自サーバー上でホスト可能な認証プラットフォーム「SuperTokens」が登場
ウェブサイトにログイン機能を実装できるサービスとしてはAuth0やAmazon Cognito、Firebaseがありますが、いずれもオープンソースではありません。ニュースサイト・Hacker Newsを運営するYコンビネータの支援のもと、オープンソースとして開発された「SuperTokens」は、Auth0やAmazon Cognitoなどの代替を目指すソフトウェアです。 SuperTokens, Open Source Alternative to Auth0 https://supertokens.io/ アクセス可能なリソースをアプリケーションに柔軟に割り当てることができる「OAuth」は、多くのウェブサイトが準拠している「権限の認可」を行うための標準規格です。OAuthはAuth0やAmazon Cognito、Firebaseといった認証プラットフォームを利用することでソフトウ
JWT・Cookieそれぞれの認証方式のメリデメ比較 - Qiita
JWTとは JSON Web Tokenの略。ジョットと読むらしい。 ざっくりいうとJsonに電子署名を加え、URL-Safeな文字列にしたTokenのこと 正確にいうと、電子署名を使用する方式はJWS（JSON Web Signature）と呼ばれ、別途暗号化を使用するJWE（JSON Web Encryption）も存在する。よく見かける説明はJWS方式のほう。 JWS方式の場合、電子署名であり暗号化ではないため、中身を見ることは可能。但し改ざんはできない、という仕組み。 実際のユースケースで言うと、サーバ側で認証情報が入ったJsonを加工（電子署名を加える等）し、JWTにしたのち、それを認証Tokenとしてクライアントに渡す。クライアントはそのTokenを認証Tokenとして使用する。 仕組みについては調べればたくさん出てくるのでそちらを参照したほうが良いかと思います。 この記事では
【決定版】Django認証方法まとめ〜カスタム方法詳細解説〜 | ひつじCloud
ここで作成したユーザーの、認証の仕方は以下のコードを利用します。 from django.contrib.auth import authenticate user = authenticate(username='john', password='secret') if user is not None: # A backend authenticated the credentials else: # No backend authenticated the credentials django.contrib.auth.authenticate()メソッドの部分が認証を行う機能になります。 引数の情報から認証バックエンドに処理を依頼し、結果はUserオブジェクトとして返却されます。 認証バックエンドとは、settings.pyでAUTHENTICATION_BACKENDSで設定した
認証機能を独自実装する代わりにIDaaSのREST APIを使うアプローチ - r-weblife
こんにちは、ritou です。 最近のあれこれでIDaaSと呼ばれる機能に注目が集まっているような気がしますが、どうしてもフロントエンドでの導入部分が目に付きます。 「新規サービスで使っていこう」ならまだしも「既存のを何とかしたい」みたいな場合にフロントエンドまでごっそり変えるのなんて腰が重くなって仕方ない感じでしょう。 そこで今回は、REST APIを用いた新規導入、移行というアプローチもあるのかなという話を書いておきます。 SPAとなると当然フロントエンドの振る舞いに注目されるけど、Deviseからの...を考える人たちはこの辺りから攻めるのもアリかと思う。ちゃんと整理して考えよう。https://t.co/fwhoA6wtjx— 👹秋田の猫🐱 (@ritou) 2020年8月19日 IDaaS の REST API この辺りをみてみてはどうでしょう。 Firebase Authe
Firebase AuthなどJavaScriptでAPIセッション用のトークンを得ることについて - Qiita
ちょっとでもセキュリティに自信がないなら、 Firebase Authentication を検討しよう （※ こちらの参照記事の内容自体に不備があるとか甘いとか指摘するものではないんですが、勝手に枕として使わせてもらいます） 上記記事は、Firebase Authenticationが提供するJavaScript APIを使ってJWTのトークンを取得し、自前のサーバにHTTPのヘッダで送りつけて検証をさせることで、認証の仕組みをセキュアかつかんたんに実現しよう、という内容です。 このようにJavaScriptのAPIでトークンを発行して自前バックエンドのAPI認証につかう方法はAuth0のSDKなどでも行われていますので、IDaaSをつかってSPAを開発する場合には一般的なのかもしれません。 話は変わりますが、SPAの開発に携わっている方は「localStorageにはセッション用のトー
ちょっとでもセキュリティに自信がないなら、 Firebase Authentication を検討しよう
note のやらかしのあのへんについて。 認証自作、 Rails 、 Devise - Diary パーフェクト Rails 著者が解説する devise の現代的なユーザー認証のモデル構成について - joker1007’s diary 認証サーバーの実装は本質的に難しいです。セキュリティが絡むものは「簡単な実装」などなく、プロアマ個人法人問わず、個人情報を守るという点で、同じ水準を要求されます。悪意あるハッカーは常にカモを探していて、もし認証が破られた場合、自分だけではなく大多数に迷惑が掛かります。初心者だから免責されるといったこともありません。全員が同じ土俵に立たされています。 とはいえ、認証基盤を作らないといろんなサービスが成立しません。そういうときにどうするか。 Firebase Authentication で、タイトルの件なんですが、 Firebase Authenticat
next.js + vercel + firebase authentication で JWT の検証を行う + Graphql
今個人で作ってるアプリの 認証 + Graphql の部分を抜き出して GitHub に公開した。 mizchi/next-boilerplate-20200727 next.js + vercel + firebase は (パーツを良く選べば) 最高 next.js はルーティングを持つページを作るには最高で、サーバー、静的サイト、JAM スタック、AMP と必要に応じて選択できる。React ベースならこれ一択。 認証サーバーの実装は毎度疲れるし、Firebase Athunetication はこの点においては OAuth Secret を置くだけ + Custom Provider も作れるので、最高。 それと比べて firestore は、ちょっと前に firestore べったりでアプリを試作したことがあったのだが、型がないためにかなり扱いづらく、また読み書きの速度が遅くパフ
2020年版 チーム内勉強会資料その1 : JSON Web Token - r-weblife
おはようございます。ritou です。 5月下旬ぐらいにチーム内勉強会としてJSON Web Token(JWT)についてわいわいやりました。 その際に作成した資料に簡単な説明を添えつつ紹介します。 このブログではJWTについて色々と記事を書いてきましたが、その範囲を超えるものではありません。 ちょっとだけ長いですが、ちょっとだけです。お付き合いください。それでは始めましょう。 JSON Web Token boot camp 2020 今回の勉強会では、JWTについて概要、仕様紹介という基本的なところから、業務で使っていくにあたって気をつけるべき点といったあたりまでカバーできると良いなと思っています。 JSON Web Token 概要 まずは概要から紹介していきます。 JSON Web Tokenの定義とはということで、RFC7519のAbstractの文章を引用します。 JSON W
JWT+RDBを用いたOAuth 2.0 ハイブリッド型トークンの実装例 - r-weblife
おはようございます、ritouです。 (⚠️認可イベントの識別子のあたり、ちょっと見直しました！最初に見ていただいた方はもう一回どうぞ！) 前回、ハイブリッド型と呼ばれる OAuth 2.0 のトークン実装について書きました。 ritou.hatenablog.com その続きとして JWT(JWS) + RDBでできる実装例を紹介します。 理解するにはそれなりの OAuth 2.0 に関する知識が必要になるかもしれませんが、よかったら参考にしてみてください。 何を考えたのか OAuth 2.0のRefresh Token, Access Tokenを考えます。 要件から整理しましょう。 要件 結構ありますが、最低限の OAuth 2.0 の Authorization Server を実装しようと思ったらこれぐらいはやらないといけないでしょう。 RFC6750 で定義されている Bear
SPAのログイン認証のベストプラクティスがわからなかったのでわりと網羅的に研究してみた〜JWT or Session どっち？〜 - Qiita
SPAのログイン認証のベストプラクティスがわからなかったのでわりと網羅的に研究してみた〜JWT or Session どっち？〜JavaScriptRailsJWT認証React SPAのログイン周りについて、「これがベストプラクティスだ！」という情報があまり見当たらないので、様々な可能性を模索してみました。 いろいろな状況が想定され、今回記載する内容に考慮の漏れや不備などがありましたら是非コメントでご指摘いただきたいです！特に「おすすめ度：○」と記載しているものに対しての批判をどしどしお待ちしております！ この記事でおすすめしているものであっても、ご自身の責任で十分な検討・検証の上で選択されてください。 前提 想定しているAPIは、 ログイン外のAPIにはPOST/PUT/DELETEのものがなく、GETのみ GETのAPIにはDBを更新するなどの操作がない とし、そのためログイン外では
全く知らない人のためのSign in with Apple
Mercari Advent Calendar 2019 の10日目担当は メルカリ iOS チームの @HideakiTouhara です。 はじめに 2019年のWWDCで新しいSign in, Sign up方法であるSign in with Appleが発表されました。 今回は主にクライアントの実装を起点に、その流れを説明していきたいと思います。 Sign in with Appleの説明や特徴 まず、そもそもどういうものなのでしょうか？ 2019年9月に更新されたガイドラインを引用します。 Make it easy for users to sign in to your apps and websites using the Apple ID they already have. With privacy and security features built-in, Sign
Webアプリケーションのセッション管理にJWT導入を検討する際の考え方 - r-weblife
おはようございます、ritou です。 qiita.com これの初日です。 なんの話か 皆さんは今まで、こんな記事を目にしたことがありませんか？ Cookie vs JWT 認証に JWT を利用するのってどうなの？ JWT をセッション管理に使うべきではない！ リンク貼るのは省略しますが、年に何度か見かける記事です。 個人的にこの話題の原点は最近 IDaaS(Identity as a Service) として注目を集めている Auth0 が Cookie vs Token とか言う比較記事を書いたことだと思っていますが、今探したところ記事は削除されたのか最近の記事にリダイレクトされてるようなのでもうよくわからん。 なのでそれはおいといて、この話題を扱う記事は クライアントでのセッション管理 : HTTP Cookie vs WebStorage(LocalStorage / Sess
アプリで「ログインしっぱなし」はどのように実現されているか？ - Qiita
このツイートを見て、「アプリで再ログインを頻繁要求されるってユーザビリティ良くないな。」と思ったのですが、普段裏側の仕組みは意識していなかったりテックリードの方に任せきりだったりしていたので、これを機に調べてみました。 そもそもスマホアプリ の時代、もはやauthenticationですらないと思うのよね。（何を言ってるかわからねえだろうと思うが。） — Hiromitsu Takagi (@HiromitsuTakagi) 2019年7月8日 この記事は「アプリでログインしっぱなしは、どのように実現されるの？」という疑問と調べた結果を共有するために書いていきます。 間違いや「もっとこんな仕組みが使われてるよ！」等のツッコミがあれば、どしどし貰えると助かります！ 疑問1. アクセストークンという仕組みとは？ 「なぜアクセストークンという概念が必要なのか？」 モバイルアプリでユーザー認証をし
TechCrunch | Startup and Technology News
An Indian court has dismissed Twitter’s lawsuit against the Indian government that sought to challenge New Delhi’s block orders on tweets and accounts. The Karnataka High Court dismissed t Seoul-based e-commerce company Levit, an operator of the shopping app Alwayz, wants to make the shopping experience more entertaining and affordable. The two-year-old startup has recently raised $46 m
ユーザーをログアウトから守れ！―シーケンス図から読み解くログイン状態維持【Webアプリ編】 | DevelopersIO
認証というのは面倒なもので、利用者に余計な手間を掛けさせてアクティブ率を下げたくないと日夜工夫を凝らす我々にとっては、やり玉に上がりやすいテーマであると思います。要するに、ユーザーをログアウトさせたくないわけです。さて、どうしましょう？ 生魚おじさん、都元です。今月の魚はアジです！アジを食べましょう。 さて、認証というのは面倒なもので、利用者に余計な手間を掛けさせてアクティブ率を下げたくないと日夜工夫を凝らす我々にとっては、やり玉に上がりやすいテーマであると思います。要するに、ユーザーをログアウトさせたくないわけです。 例えば Facebook や Twitter のページはいつ訪問しても自分のアカウントでログイン状態になっています。 最後にログインしたのはいつでしたっけ？ 覚えていませんよね？ これがおそらく皆さんの理想です。 セッションによるログイン ログインには通常、Cookie を
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
DjangoでLoginRequiredMixinとUserPassesTestMixinの併用 - Qiita
http://python.zombie-hunting-club.com/entry/2017/11/06/222409
