Q&A
YouTube動画のURLを追記してください。
ググッても解決しなかったので質問させていただきます。
JsonWebTokenには
- access
- refresh
の二種類があり、両方をcookieに保存するとした場合、意味がわからなくなりました。
再生回数の多い海外のYoutube動画でそうしていました。
JWTは、
永久に使えるtokenが危険だから期限があり、
期限の短いものをリフレッシュさせるトークンもあり、
改ざんしづらいように署名もある
というのはわかりますが、
だからといって二種類のTokenが必要なのでしょうか？
accessのみを利用して、期限を長期間（一ヶ月）にすればいいと思ってしまいました。
ただ、そうしたときにJWTではaccessのみで期限を伸ばすリフレッシュができないため、refreshも用意し、それならばaccessは期限を短くして使おう、ということでしょうか？
https://www.youtube.com/watch?v=7C3rPbXmm44
再生回数多くなかったです。勘違いでしたが念の為お送りします。
Accessのタグは、Microsoft Officeに含まれるデータベースAccess用です。
この質問とは関係ないと思われますので、Accessタグの削除をお願いいたします。
回答2件
0
ベストアンサー
accessのみを利用して、期限を長期間（一ヶ月）にすればいいと思ってしまいました。
ただ、そうしたときにJWTではaccessのみで期限を伸ばすリフレッシュができないため、refreshも用意し、それならばaccessは期限を短くして使おう、ということでしょうか？
勘違いがあると思いますが、jwtとアクセストークン・リフレッシュトークンは無関係です
jwtはユーザー端末に情報を保存する為に保存する情報を暗号化しつつ期限など様々な値を含めて保存する事を目的としたもの
様々な値についてはwikiでもみてください
アクセストークン・リフレッシュトークンはOAuth2.0の仕様
簡単に喩えると
一ヶ月間入り放題のテーマパークに入場する為に免許証を提示（ID/PWの入力）をして、一ヶ月間有効の入場券発行用パスポート（リフレッシュトークン）と当日限り有効の入場券（アクセストークン）を取り、テーマパーク内のアトラクションを利用する際は入場券（アクセストークン）を提示する
翌日に遊ぶ為には最初に貰った入場券は使えない（アクセストークンの有効期限切れ）ので、パスポートを提示して新しい入場券を貰う（リフレッシュトークンを元にアクセストークンを更新）
だからといって二種類のTokenが必要なのでしょうか？
jwtとか関係無しに必要かどうかだについて言うと、絶対に盗聴・漏洩しないのなら不要です。
だけど普通は絶対漏洩しないシステム作りより、万が一漏洩しても被害を最小限に抑えるシステム作りをするので。
投稿2021/02/18 03:03
総合スコア6415
回答していただきありがとうございます。
wikiを確認したことろ、仕様など把握できました。
## 例え以下について
おっしゃることはわかります。
ただ、django-rest-framework-simplejwtというモジュールを使用しているのですが、
refreshTokenを使って、ユーザーの情報を含んだJWT(access,resfresh)を更新することになります。
そこでの返り値はaccess,refreshの両方ともです。
例えに当てはめると現実味がないですが、もしも他人の一ヶ月有効期限のパスポートを拾った場合、refreshをし続けることで永久に有効状態が続くのではないでしょうか。
そうなると、漏洩しても期限が無限になり、被害が収束しないように感じます。
その仕様はdjangoのモジュールの仕様かどうかはわかりません。
ただ、その返り値を返す関数をオーバーライドして、accessのみ返せばいいのではないかと思われますが、refreshしたと同時に、そのrefreshTokenはブラックリストに入ります。
どのように処理するのが最適でしょうか？
djangoの説明を見る気はないけど
> 例えに当てはめると現実味がないですが、もしも他人の一ヶ月有効期限のパスポートを拾った場合
その拾チャンスは減らせますよね？ID/PWは月に一度だけ、リフレッシュトークンは日に一度だけ、アクセストークンは使う都度
> refreshをし続けることで永久に有効状態が続くのではないでしょうか。
当然そういう作りにすればそうなります。
> どのように処理するのが最適でしょうか？
サービスが取り扱う情報の重要度に合わせて決めてください。
sns、ヨドバシみたいな物販サイト、銀行サイト、それぞれに盗用された時のリスクを考えて設計するものです。
それにjwtに認証を一任せずに使う機能によって必要な認証のレベルを変えれば良いだけです。SNSの投稿ならアクセストークンで良いし、ID/PWの変更はトークンが有効でもそれだけで処理をせずID/PWを入力させるなど。
お返事いただきありがとうございます。
となると、
Access,RefreshTokenの両方をローテーションさせないべきだとわかりました。永久に使われてしまうので。
また、たとえ話のように
仮にAccessが一日、Refreshが一ヶ月の有効期限とし、
RefreshToken自体のRefreshができなければ、
おおよそ月に一回ログインをするだけで、AccessTokenによる認証ができるはずです。
しかし、RefreshTokenの有効期限が伸びないのは普通なのでしょうか？
つまり、確実に月一回はログインをし直す必要があるということです。
> つまり、確実に月一回はログインをし直す必要があるということです。
既に書いたけどサービスの重要度に合わせて好きにしてください。
毎月ログインしなきゃいけない事に違和感を感じるならリフレッシュトークンだけでログイン維持できるようにすれば良いし、リフレッシュトークンが盗まれたら終わりなのにログイン状態が続けられる事がおかしいと思うなら一ヶ月後には必ずログイン処理からやり直す作りにすれば良いだけです。
普通がどうだから、で決めるもんじゃありません。
ありがとうございます。
承知しました
0
JWTのアクセストークンは、認証サーバーに問い合わせることなく、トークンのみで認証状態を把握できます。これがJWTの特徴・メリットですが、その裏返しのデメリットとして、仮に特定ユーザーをサイト側で認証拒絶したい事態になった際にも、アクセストークンが有効である期間中は認証を拒否できません。また、サーバー側でログアウトの実装もできません。攻撃者がアクセストークンを持っていればログイン状態になってしまうからです（見かけ上のログアウト処理はできます）。
これに対する改善策の一つは、リクエスト毎にサーバーに認証状態を確認することですが、これだとJWTのメリットが薄れ、通常のセッションでよいということになります。
このため、JWTのアクセストークンの期限を短くして、期限内はJWTのみで認証を確認する一方、アクセストークンの期限切れによるリフレッシュの際にはサーバー側でログアウトや認証拒否の状態でないかを調べる方法が一般的に行われます。これは、JWTのメリットとデメリットをバランス良く実装するためです。
両者がどちらもcookieに保存されることは問題にはなりません。cookieよりも安全なストレージはブラウザにはないからです。仮に、たとえばアクセストークンをsessionStorage、リフレッシュトークンをcookieに保存しても、セキュリティ上安全にはなりません。なので、「どちらもCookieに保存する意味は何か」と考えても、あまり得るものはないでしょう。
投稿2021/02/17 23:59
総合スコア11701
> このため、JWTのアクセストークンの期限を短くして、期限内はJWTのみで認証を確認する一方、アクセストークンの期限切れによるリフレッシュの際にはサーバー側でログアウトや認証拒否の状態でないかを調べる方法が一般的に行われます。これは、JWTのメリットとデメリットをバランス良く実装するためです。
この点についてですが、cookieにてaccess,refreshの両方を保存して実装した経験はあります。個人的に趣味でやりました。もちろん、httpOnly,Secure,SameSiteなどの設定も知っています。
別の回答者様にも質問したのですが、djangoのモジュール
https://django-rest-framework-simplejwt.readthedocs.io/en/latest/settings.html
では、リフレッシュした際に、用いたrefreshTokenをブラックリストに入れ、新たなaccessToken,RefreshTokenを得るのが無難なやり方です。
つまり、リフレッシュするたびに直前のaccessToken,RefreshTokenを使えないようにし、新たなaccessToken,RefreshTokenを手に入れるということです
この点はおかしいでしょうか？
これだと、万が一RefreshTokenが漏洩した場合、永続的にTokenを発行されてしまいます。
よって、一番いいのは、ログイン後に手に入れたAccessToken（１）とRefreshToken（２）を使ってAccessToken（１）をリフレッシュし、そのときに用いたRefreshToken（２）はそのまま持ち続け、新たなAccessToken（４）を手に入れる。
（２）の有効期限が切れたら、再度リフレッシュできないので、ログインさせる
ということになるでしょうか。
> これだと、万が一RefreshTokenが漏洩した場合、永続的にTokenを発行されてしまいます。
これは「そういうもの」というしかないので、これが心配なのであれば、refreshトークンを使うのをやめてたらどうかと思います。RefreshTokenの寿命をつけるのはありかと思います。
ただ、トークンやセッションIDの漏洩は致命的なことなので、それに対する緩和策はかなり難易度が高いです。まずは、「漏洩しないように脆弱性対処を頑張る」のが一般的なセキュリティ水準です。
お返事いただきありがとうございます。
そのとおりです。
もうひとりの回答者様にも書いた内容ですが、
AccessTokenが一日、RefreshTokenが一ヶ月の有効期限を持つものとする。
また、RefreshTokenの有効期限は伸びない。
これが、自分の不安に思う
> 万が一RefreshTokenが漏洩した場合、永続的にTokenを発行されてしまいます。
の解決策となるのでしょうか？
自分の持っていたTokenを用いた認証処理とは違いました。つまり、週に一回ほどそのサービスを開いているにも関わらず、月に一回のログインが必要となってしまうということです。
> また、RefreshTokenの有効期限は伸びない
リフレッシュトークンの有効期限は伸びないというか、使用済みのリフレッシュトークンは無効化されます（無効化されない場合もあり）が、あらたにリフレッシュトークンも再発行されますので、ユーザーから見ると、ログインしないでサービスを使い続けることは可能です。
言い方に語弊がありました。
RefreshTokenをリフレッシュするというのは、直前のRefreshTokenを使えないようにして、新たなRefreshTokenを発行するということです。
回答、ありがとうございました。
あなたの回答
tips
プレビュー
