![](https://cdn-ak-scissors.b.st-hatena.com/image/square/a1fae406bee4090b9fc3d8ebaf92b7facbcc924d/height=288;version=1;width=512/https%3A%2F%2Fres.cloudinary.com%2Fzenn%2Fimage%2Fupload%2Fs--dSDgMppg--%2Fc_fit%252Cg_north_west%252Cl_text%3Anotosansjp-medium.otf_55%3A%252522JWT%25253D%2525E3%252582%2525B9%2525E3%252583%252586%2525E3%252583%2525BC%2525E3%252583%252588%2525E3%252583%2525AC%2525E3%252582%2525B9%252522%2525E3%252581%25258B%2525E3%252582%252589%2525E4%2525B8%252580%2525E6%2525AD%2525A9%2525E8%2525B8%25258F%2525E3%252581%2525BF%2525E5%252587%2525BA%2525E3%252581%252599%2525E3%252581%25259F%2525E3%252582%252581%2525E3%252581%2525AE%2525E8%252580%252583%2525E3%252581%252588%2525E6%252596%2525B9%252Cw_1010%252Cx_90%252Cy_100%2Fg_south_west%252Cl_text%3Anotosansjp-medium.otf_37%3Aritou%252Cx_203%252Cy_121%2Fg_south_west%252Ch_90%252Cl_fetch%3AaHR0cHM6Ly9saDMuZ29vZ2xldXNlcmNvbnRlbnQuY29tL2EtL0FPaDE0R2pRX2Zjd3NJUms2TGFsYm5qQ0hXeldmazdCa1l2WDlYQWtaUDhiOFE9czI1MC1j%252Cr_max%252Cw_90%252Cx_87%252Cy_95%2Fv1627283836%2Fdefault%2Fog-base-w1200-v2.png)
エントリーの編集
![loading...](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/common/loading@2x.gif)
エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。
記事へのコメント17件
- 注目コメント
- 新着コメント
![odz odz](https://cdn.profile-image.st-hatena.com/users/odz/profile.png)
odz
JWTにsession id埋め込むくらいなら、単に定期的にsession idをregenerateすれば良いのでは。あと少数の不正トークンに対するバックエンドアクセスコストと、多数の正当トークンに対する署名検証コストの比較はちと微妙。
![y-kawaz y-kawaz](https://cdn.profile-image.st-hatena.com/users/y-kawaz/profile.png)
y-kawaz
スケールするメリットと即時失効の間をとった実装として機密情報の取得や更新系APIの時だけ失効リストをチェックするって実装ならした事ある。こんな感じに> https://twitter.com/kawaz/status/1436724705377980419?s=21
![metatrading metatrading](https://cdn.profile-image.st-hatena.com/users/metatrading/profile.png)
metatrading
改ざん耐性を持つJWTにSessionID入れて事前検証で弾ければ、サーバリソースを過剰に使わんよね。それを冒頭のログアウトの機構と合わせて入れればお得でしょう。という意味と理解。
![metatrading metatrading](https://cdn.profile-image.st-hatena.com/users/metatrading/profile.png)
metatrading
改ざん耐性を持つJWTにSessionID入れて事前検証で弾ければ、サーバリソースを過剰に使わんよね。それを冒頭のログアウトの機構と合わせて入れればお得でしょう。という意味と理解。
![y-kawaz y-kawaz](https://cdn.profile-image.st-hatena.com/users/y-kawaz/profile.png)
y-kawaz
スケールするメリットと即時失効の間をとった実装として機密情報の取得や更新系APIの時だけ失効リストをチェックするって実装ならした事ある。こんな感じに> https://twitter.com/kawaz/status/1436724705377980419?s=21
![odz odz](https://cdn.profile-image.st-hatena.com/users/odz/profile.png)
odz
JWTにsession id埋め込むくらいなら、単に定期的にsession idをregenerateすれば良いのでは。あと少数の不正トークンに対するバックエンドアクセスコストと、多数の正当トークンに対する署名検証コストの比較はちと微妙。
注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています
![アプリのスクリーンショット](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/entry/app-screenshot.png)
いまの話題をアプリでチェック!
- バナー広告なし
- ミュート機能あり
- ダークモード搭載
関連記事
"JWT=ステートレス"から一歩踏み出すための考え方
おはようございます、ritouです。 この話に乗っかっていきます。3行で ログアウト時にJWTを無効化でき...
おはようございます、ritouです。 この話に乗っかっていきます。3行で ログアウト時にJWTを無効化できない実装は今後脆弱性診断で﹁OWASP Top 10 2021違反﹂と指摘されるようになりそう(今も個別にされてるかもしれないけど) JWTは単純なフォーマットなので、ステートレスなセッション管理においてログアウトしたときに文字列自体を無効化できない件は独自エンコード方式(一般的にフレームワークのCookieストアと呼ばれているもの)でも起こり得る ﹁セッションID vs JWTで内包﹂ 以外にも ﹁セッションIDをJWTに内包﹂もあり得る。既存の機能を残しつつ﹁JWTで武装﹂する選択肢も考えてみてはどうか。 ステートレスなセッション管理でログアウトの際に文字列自体を無効化できない問題 これは前から言われていますし、駆け出し何とか勢のQiita記事に書かれるぐらいには一般的です。2
2021/09/12 リンク