JWTをlocalStorageに置くなと言われる理由を、2005〜Cookie回帰まで年表で解説しBFFやHttpOnly Cookieも整理する
ガラケーの時も個体識別番号を送ってしまう問題とかあったのを思い出した。
徳丸氏もOWASP v5になった際にブラウザストレージへのセッショントークンの保存が容認されたと言及している様に、昨今のSSRの主流化により、Ajaxの呼び出しが不要になったから、またcookie認証が広がりだしただけ。
ついこのあいだ、仕事で議論したとこなので、参加になるわ。
まとめてもらって感謝。歴史の話と今の話があったので理解が進みました
JWTからCookie回帰の流れ、歴史のサイクルを感じて面白いな
輪廻 /ブラウザに持たされていた認証情報をBFFやサーバ側に押し返した
歴史
SSRが出始めたあたりからフロントエンドが「一周回ってPHP」と言われ出した所以。そして今これ
セッション管理がステートレスであることをまるでメリットかのように騒いでた人たち、何も学んでいないんだなと当時から苦々しく思っていた
主にウェブアプリ（SPA）の話です
人の手で書かれた良いまとめ。
HotwireやHTMXみたいなJavaScriptをなるべく書かない昔ながらのシンプルなアプローチまで遡ったら面白いな(追記：「昔ながら」ではないと某所で怒られました)。このところ支持者も増えてきてるそうですが。
君のゆく道は果てしなく遠いなあ……。なので、ずっと手前で止まっている（←オイ）
よくまとまっていてわかりやすい
一周すれば最先端
ちゃんと実装すると、Cookieが署名されているくらいの意味しか残らない。クライアントサイドでは署名も活用できないからマジで無駄なんだわ。
長年1人で設計・実装・環境構築・運用しているLAMPおじさんとしては、jQueryすらめんどくせー、SPAとか言われだした時点ですでについて行けてなかったけど、シンプルになって戻ってきてくれるなら何よりｗｗｗ
ウェブのトレンドは当てにならんね。
.netでAがSのPでWebするみたいなオールドなスタイルで生活してると一生ｸｯｷｰ🍪なのでいつのまにか世界が一巡してるのぼけーっと見てるだけ～。連携システムがJWTだとほえーって思いながら付き従うくらいで。
BFF等がありサーバサイドに処理があるならCookie一択、SPAならLocalStrage一択(expireの間隔やペイロードに何を含めるかは注意する)。
“BFF を立てるなら、クライアント ↔ BFF 間で JWT を使う理由はもはや無くなり、伝統的な Cookie セッションに戻る”
"BFF を立てるなら、クライアント ↔ BFF 間で JWT を使う理由はもはや無くなり、伝統的な Cookie セッションに戻る、と徳丸氏は述べています。"
私のポストをマクラに詳しい解説をいただきありがとうございます
ひどい切り取り。JWTをlocalStorageに置くことがセキュリティ的に問題ないということを言っている流れで一歩引いて最近のトレンドを解説した部分。
本題とは関係ないのに、途中では業界でも色々なパターンがある話をしてたのに、現在業界全体的でマイクロサービスが当たり前であるかのように話してるのが残念。
長すぎてみんなちゃんと読んでるのかな。
単純にSSRするとき認証状況がサーバーから見えないからクッキーの方が自然ってずーーーっと前から思ってた
つか、クロスドメイン的に厳しいよね？localStorageだと
なるほど わかりやすい
amplifyがlocalstorage使ってるせいもあると思ってる。AWSなら使わざるを得ないがあれは最低のクソ。
前提としてBFFを使うウェブサイトでの話。BFFないなら別
後半後で読む
localStorage に置くのは XSS 見つかったときに読まれるからダメというのはわかるが、結局2023年の App Router 登場で BFF に JWT 置くのが普及してうまく回るようになったって感じか。
非常に，非常に学びのある記事だった
この辺、仕事で扱うことがなくて、ぼんやりと「JWT で即時無効化ができないから、適材適所で」という話を、事故りそうな話だなぁ、と思ってたけど、今はその一歩先に行っているのを知ってスッキリした。
「JWT を localStorage に置くな」はなぜ言われるのか、Cookie 回帰までの時系列整理
JWTをlocalStorageに置くなと言われる理由を、2005〜Cookie回帰まで年表で解説しBFFやHttpOnly Cookieも整理する
ガラケーの時も個体識別番号を送ってしまう問題とかあったのを思い出した。
徳丸氏もOWASP v5になった際にブラウザストレージへのセッショントークンの保存が容認されたと言及している様に、昨今のSSRの主流化により、Ajaxの呼び出しが不要になったから、またcookie認証が広がりだしただけ。
ついこのあいだ、仕事で議論したとこなので、参加になるわ。
まとめてもらって感謝。歴史の話と今の話があったので理解が進みました
JWTからCookie回帰の流れ、歴史のサイクルを感じて面白いな
輪廻 /ブラウザに持たされていた認証情報をBFFやサーバ側に押し返した
歴史
SSRが出始めたあたりからフロントエンドが「一周回ってPHP」と言われ出した所以。そして今これ
セッション管理がステートレスであることをまるでメリットかのように騒いでた人たち、何も学んでいないんだなと当時から苦々しく思っていた
主にウェブアプリ（SPA）の話です
人の手で書かれた良いまとめ。
HotwireやHTMXみたいなJavaScriptをなるべく書かない昔ながらのシンプルなアプローチまで遡ったら面白いな(追記：「昔ながら」ではないと某所で怒られました)。このところ支持者も増えてきてるそうですが。
君のゆく道は果てしなく遠いなあ……。なので、ずっと手前で止まっている（←オイ）
よくまとまっていてわかりやすい
一周すれば最先端
ちゃんと実装すると、Cookieが署名されているくらいの意味しか残らない。クライアントサイドでは署名も活用できないからマジで無駄なんだわ。
長年1人で設計・実装・環境構築・運用しているLAMPおじさんとしては、jQueryすらめんどくせー、SPAとか言われだした時点ですでについて行けてなかったけど、シンプルになって戻ってきてくれるなら何よりｗｗｗ
ウェブのトレンドは当てにならんね。
.netでAがSのPでWebするみたいなオールドなスタイルで生活してると一生ｸｯｷｰ🍪なのでいつのまにか世界が一巡してるのぼけーっと見てるだけ～。連携システムがJWTだとほえーって思いながら付き従うくらいで。
BFF等がありサーバサイドに処理があるならCookie一択、SPAならLocalStrage一択(expireの間隔やペイロードに何を含めるかは注意する)。
“BFF を立てるなら、クライアント ↔ BFF 間で JWT を使う理由はもはや無くなり、伝統的な Cookie セッションに戻る”
"BFF を立てるなら、クライアント ↔ BFF 間で JWT を使う理由はもはや無くなり、伝統的な Cookie セッションに戻る、と徳丸氏は述べています。"
私のポストをマクラに詳しい解説をいただきありがとうございます
ひどい切り取り。JWTをlocalStorageに置くことがセキュリティ的に問題ないということを言っている流れで一歩引いて最近のトレンドを解説した部分。
本題とは関係ないのに、途中では業界でも色々なパターンがある話をしてたのに、現在業界全体的でマイクロサービスが当たり前であるかのように話してるのが残念。
長すぎてみんなちゃんと読んでるのかな。
単純にSSRするとき認証状況がサーバーから見えないからクッキーの方が自然ってずーーーっと前から思ってた
つか、クロスドメイン的に厳しいよね？localStorageだと
なるほど わかりやすい
amplifyがlocalstorage使ってるせいもあると思ってる。AWSなら使わざるを得ないがあれは最低のクソ。
前提としてBFFを使うウェブサイトでの話。BFFないなら別
後半後で読む
localStorage に置くのは XSS 見つかったときに読まれるからダメというのはわかるが、結局2023年の App Router 登場で BFF に JWT 置くのが普及してうまく回るようになったって感じか。
非常に，非常に学びのある記事だった
この辺、仕事で扱うことがなくて、ぼんやりと「JWT で即時無効化ができないから、適材適所で」という話を、事故りそうな話だなぁ、と思ってたけど、今はその一歩先に行っているのを知ってスッキリした。