どうして JWT をセッションに使っちゃうわけ？ - co3k.org

備考 2018/09/21 22:15 追記 2018/09/20 12:10 に公開した「どうして JWT をセッションに使っちゃうわけ？」というタイトルが不適切だとご指摘をいただいています。 その意見はもっともだと思いますので、現在、適切となるようにタイトルを調整しています。 ご迷惑およびお騒がせをして大変申し訳ございません。 本文の表現についても改善の余地は大いにありそうですが、こちらは (すでにご意見を頂戴している関係で、) 主張が変わってしまわないように配慮しつつ慎重に調整させていただくかもしれません。 はあああ〜〜〜〜頼むからこちらも忙しいのでこんなエントリを書かせないでほしい (挨拶)。もしくは僕を暇にしてこういうエントリを書かせるためのプログラマーを募集しています (挨拶)。 JWT (JSON Web Token; RFC 7519) を充分なリスクの見積もりをせずセッシ

[auth0]

ちょっと反論気味の記事書いた。　https://auth0.hatenablog.com/entry/2018/09/21/004131

[kwhrtsk]

マイクロサービス化しないとメリットは実感できないと思う。簡単に単一のセッションDBを運用できるような規模のうちは、JWTをセッションに使うのは牛刀。

[suginoy]

Railsユーザーとしては「Ruby on Rails の "デフォルトの" セッション管理機構」と書いてほしいかな。細かいけど。

[co3k]

※タイトルについて調整中です。お騒がせして申し訳ありません/ id:suginoy そのように修正しました/ id:nakag0711 対策してみました/ id:iktakahiro それらはOIDCですね。罠を踏みやすいという点を除きJWTは問題視してません

[knjname]

（自分でも）普通にここらへんのことは考えるかなあ。トークンのrevokeについては要件次第。むしろ通信に自動でくっついちゃうcookieが厄介ということも言えるわけで。

[snowcrush]

なんで全体で鍵を共有する前提なんだろう？ユーザー毎に鍵生成じゃダメなんだっけ。

[n314]

うーん…結局JWTは何が利点なんだろう。

[esodov]

「cookie の HttpOnly フラグの保護を受けない」はjwtだからじゃなくてwebストレージだからではないの？/ドメイン跨いで認可するならcookie使えない以上jwtをwebストレージで使うしかないよね。跨がないならセッションでもいい。

[ifttt]

高菜食べちゃったら怒りそう

[iktakahiro]

Firebase も Auth0 も Refresh Token + JWT ですけど見解が聞きたい。認証はともかく認可のステップまでまじめに考えるとどっかしらで DB 参照せざるを得なく 'ステートレス' にはならないんですよね。

[ksss9]

セキュリティ難しい……。

[kazkun]

社内でJWT使えば便利だし手間もコストも減るよ、という提案があってこの記事を思い出した。これ見てリスクに気づいてもらえれば良いんだが。

[k12u]

“TLS におけるダウングレード攻撃”

[akatakun]

サーバ側でのセッション無効化ができない (鍵を無効化し、発行済セッション全体を無効化することはできる)

[ono_matope]

ようやく読んだ

[mkusunok]

ID Tokenをセッション管理に使っちゃダメよという話。最近そんな変な実装が増えてるんですかね

[luccafort]

何故使うのか？に対しては多分便利だからが答えなんだと思うんすよね。ただ問題はここで書かれているセキュリティー的な問題とか鍵の管理の問題とかはあるよね？ということなんだけどそれはJWTに限らないからなあ。

[naari_3]

「罠があるからそんなに詳しくない人は使わないほうがいいよ」っていう記事だった、タイトルが過激なだけ

[infobloga]

「そんなこと知らないで使う奴いたのか？」レベルのことしか書いてなくてゲンナリ。JWTでトークンのリフレッシュ対策できない奴は、CookieのCSRF対策もできないだろうから、どっちも使わず寝てたほうが良い

[ry_mizuki]

“そこまでしてステートレスに JWT を使わなくてはいけないか？ というのは熟考しまくったほうがいい”

[taguch1]

その発想がない。

[braitom]

“ (ステートレスな) JWT をセッションに使うことは、セッション ID を用いる伝統的なセッション機構に比べて、あらゆるセキュリティ上のリスクを負うことになります。”

[mi_kattun]

この問題は参照先の記事も含めて考えたことあるけどCookieとWeb Storageの比較は妥当なのかな？任意のJSを実行可能ならトークンを盗む必要性は薄いのでは。参考: https://postd.cc/web-storage-the-lesser-evil-for-session-tokens/

[love0hate]

署名による認証の問題・セッションストアとして使うことの問題・JWT固有の問題・現実の実装時の問題は分けた方が議論しやすいと思う。／セッションストアとしては使いたくないのには同意

[tekitekitou]

(apiで)user_idしかセッションに保存する情報のないシステムの場合、わざわざjwtをログイン認証に使ったあとuser_idをセッションから引くよりuser_idを直接jwtに入れたらセッションサーバいらなくね？そういう話でない？

[PEEE]

flaskのデフォルトのセッション管理もこれなので自前で実装したんだよなあ

[KoshianX]

お、JWT 知らんかった。Firebase とかにも使われてるのかな。今時はバックエンド作らないこともあるだろうし cookie でのセッション管理が難しくなってるのかなあ……。

[chintaro3]

　GJ

[zetta1985]

DBが高負荷になりがちで一日に一回必ずセッション切る要件のシステムでJWTによるセッション管理を採用したことがある

[nakag0711]

なんなんだこのどや顔オーバーレイは。変わったページを作るときはスマホで必ず動作確認すべし／消えた

[iakio]

なるほど。JWKってそういう風に使うものだったのか

[xlc]

JWTでググると「セッションデータに使えるぜ！」というQiitaの記事がヒットするからでは？

[ledsun]

「JWTをセッションストアとして使うと、サーバー側にセッションストアを用意しなく良い。が、cookie storeと比べてメリットはないので、（使えるなら）枯れた既存実装があるcookie store使えばよくね？」という話でいい？

[onesplat]

Cookieというストレージ&デリバリの問題と、その値の問題は分けて考えた方が良い。クッキーにJWSを詰めるという手もあるので。ちなみにrevokeはブラックリストなのでJWTだとサイズを小さくできるというメリットはある

[tohokuaiki]

最初しか読んでないけど「初カキコ…ども…」のコピペを思い出しました。

[mole-studio]

メール認証で送りつけるURLに付けるくらいしか使い道が思いつかない