WebアプリケーションでJWTをセッションに使う際の保存先は（自分なりに説明できれば）どちらでもよいと思います - 日々量産

以下のツイートを読んで気持ちが昂ったので。 みんな、もうSNSでいがみ合うのはやめよう。 平和に好きなJWTの話でもしようよ。 JWTの格納場所はlocalStorageとCookieのどっちが好き？— 徳丸 浩 (@ockeghem) 2022年2月11日 というのも、JWTをセッションに使うときに保存先含めて一時期悩んでいたので、その時の自分の解。 ただ、考えるたびに変化しているので、変わるのかもしれない。 要約 タイトル。 あとは優秀な方々が既に色々考えておられるのでそちらを読むとよいでしょう。 SPAセキュリティ入門～PHP Conference Japan 2021 JWT カテゴリーの記事一覧 - r-weblife どうしてリスクアセスメントせずに JWT をセッションに使っちゃうわけ？ - co3k.org JWT形式を採用したChatWorkのアクセストークンについて -

[aukusoe]

“まぁ、頑張って考えてもユーザや会社からは何の評価もされないと思いますけど。” ふええ……

[taguch1]

毎度議題に上がるが基本XSSやられてる時点で誤差っていうことに収束する。結局やられた時に任意のログインを無効にできればいいと思ってる。

[yuu-yuiken]

“CookieだろうがlocalstorageだろうがどっちもXSSの前には無力”

[yarumato]

“どちらでもよいと思います。CookieだろうがlocalstorageだろうがどっちもXSSの前には無力です”

[efcl]

JWTはCookieかlocalStorageかという話。

[letsspeak]

全部同意しかない

[tettekete37564]

普通にハッシュ値 + Cookie で使った方が良いと思うけどね

[sigeharucom]

全部の画面を一つのSPAにしてブラウザのメモリ上に保存すれば、CookieもlocalStorageも使わなくて済む。

[forest1040]

“まぁ、頑張って考えてもユーザや会社からは何の評価もされないと思いますけど。” 辛辣コメント。あわあわ。

[ed_v3]

結局リフレッシュトークンはどこに保存するんだ…ってなりそう。

[yoshikidz]

わかりみが深すぎてやばい“最近はウェブサイト作ったら作っただけ脆弱性になるんじゃないかとヒヤヒヤしながら作ってます”

[kkobayashi]

XSSがあってもセキュアに、という要件が矛盾しているんだけどね。デファクトスタンダードというかベストプラクティスみたいなのないのかな

[mohno]

要約すると「もう格納場所でいがみ合うのはやめよう」（←たぶん違う）/「まぁ、頑張って考えてもユーザや会社からは何の評価もされないと思いますけど」

[kijtra]

どっちで作ってもいいなら、個人的には GDPR を考えて localStorage かな。

[pascal256]

素晴らしい整理。この記事にも書かれてるけどリフレッシュトークンをどう管理するのかがずっと大事だし。

[strawberryhunter]

「Chatwork...期限を30分と短くしてその期限内の悪用は許容」変更の反映に最大30分かかるのを許容できるかどうかによる。結局、自前でセッション管理しているのと変わらなかったり、JWT自体が人類にはほんの少しだけ早い。

[jaguarsan]

身も蓋もないこと言うと、フレームワークに含まれるか、ライブラリ化するかして今月ジョインしたメンバーが安全に扱えるならどちらでも良い

[uva]

「まぁ、頑張って考えてもユーザや会社からは何の評価もされないと思いますけど」つらいよね

[sin20xx]

脆弱性を埋め込まない可能性の高い技術で実現すればよいかと。そもそも設計の自由度が高い局面であればリードエンジニアの判断に従うだけで、その人の技術スタックや好き嫌いに左右されるし、自由度がないならば（ry

[onesplat]

内容はともかく同僚にいたら面倒臭そう。感情が安定してなさそう

[hasiduki]

無限に続くセキュリティ道！

[Shinwiki]

ほんとこれ揺れる

[rmanzoku]

素晴らしいまとめだ。

[zentarou]

HttpOnly属性ついていれば多少マシ程度だよね。XSSあるなら他に色々被害出る。