Skip to main content
ローテーションは、リフレッシュトークンを使って新しいを取得する手法であり、サイレント認証にとどまらないアプローチです。リフレッシュトークンは通常、アクセストークンよりも有効期間が長く、有効期間の短いアクセストークンの期限が切れた後に新しいアクセストークンをリクエストするために使用できます。リフレッシュトークンは、長期間有効なアクセストークンを発行しなくてもシームレスな UX を実現できるため、モバイルデバイス上のネイティブアプリケーションで有効期間の短いアクセストークンと組み合わせて使われることがよくあります。 をで有効にすると、アプリケーションがリフレッシュトークンを新しいアクセストークンと交換するたびに、新しいリフレッシュトークンも返されます。これにより、侵害された場合にリソースへの不正アクセスを許してしまうおそれのある、長期間有効なリフレッシュトークンを保持し続ける必要がなくなります。リフレッシュトークンは継続的に交換されて無効化されるため、脅威を軽減できます。 Auth0 におけるリフレッシュトークンローテーションの仕組みは OAuth 2.0 BCP に準拠しており、次のフローで利用できます。

​
SPA でユーザーセッションを維持する

ごく最近まで、SPA では、サイレント認証と組み合わせて PKCE を使用した Authorization Code フローを用いることで、ユーザーのセッションを維持していました。ところが、Intelligent Tracking Prevention (ITP) などのブラウザーのプライバシー技術の進展により、Auth0 の にアクセスできなくなり、その結果、ユーザーは再認証を求められるようになりました。
Refresh Token Rotation Maintain User Sessions in SPAs diagram
残念ながら、有効期間の長いリフレッシュトークンは SPA には適していません。というのも、ブラウザーには、想定されたアプリケーションだけがアクセスできることを保証できる永続的な保存の仕組みがないためです。このような価値の高い成果物を取得し、悪意のある攻撃者に保護されたリソースへのアクセスを許してしまう脆弱性が悪用される可能性があることから、SPA でリフレッシュトークンを使用することは強く非推奨とされてきました。 リフレッシュトークンローテーションは、ブラウザーのプライバシー機構の副作用によってエンドユーザーのセッションが失われる問題への対策になります。リフレッシュトークンローテーションは Auth0 のセッション Cookie へのアクセスに依存しないため、ITP や同様の仕組みの影響を受けません。 次の状態図は、リフレッシュトークンローテーションが PKCE を使用した Authorization Code フローと組み合わせてどのように使用されるかを示していますが、交換のたびに新しいリフレッシュトークンを取得するという基本原則は、サポートされているすべてのフローに当てはまります。
Refresh Token Rotation Maintain User Sessions in SPAs State diagram
つまり、ブラウザーのプライバシーツールによる悪影響を軽減し、ユーザー体験を損なうことなくエンドユーザーに継続的なアクセスを提供するために、リフレッシュトークンを安全に使用できます。

​
自動再利用検出

クライアントが新しいアクセストークンを必要とする場合、リフレッシュトークンをリクエストとともに Auth0 に送信して、新しいトークンペアを取得します。Auth0 が新しいペアを発行すると、そのリクエストで使用されたリフレッシュトークンはただちに無効化されます。これにより、漏えいしたトークンによるリプレイ攻撃からアプリを保護できます。 送信者制約を強制しない場合、リプレイ攻撃が発生した際に、どのアクターが正当でどれが悪意あるものかを が判断することはできません。したがって、以前に使用されたリフレッシュトークン (すでに無効化済み) が認可サーバーに送信された場合は、直近に発行されたリフレッシュトークンもただちに無効化されることが重要です。これにより、同じトークンファミリー内のリフレッシュトークン (クライアントに対して最初に発行された元のリフレッシュトークンから派生した、すべてのリフレッシュトークン) を使って新しいアクセストークンを取得することを防ぎます。 たとえば、次のシナリオを考えてみましょう。
リフレッシュトークンローテーションの再利用検出の状態図
  1. 正規のクライアントは リフレッシュトークン 1 を保持しており、それが悪意のあるクライアントに漏えいまたは盗まれます。
  2. 正規のクライアントは リフレッシュトークン 1 を使用して、新しいリフレッシュトークン / アクセストークンのペアを取得します。
  3. Auth0 は リフレッシュトークン 2 / アクセストークン 2 を返します。
  4. その後、悪意のあるクライアントが リフレッシュトークン 1 を使ってアクセストークンを取得しようとします。Auth0 はリフレッシュトークン 1 が再利用されていることを検知し、リフレッシュトークン 2 を含むトークンファミリー全体をただちに無効化します。
  5. Auth0 は悪意のあるクライアントに access denied レスポンスを返します。
  6. アクセストークン 2 の有効期限が切れ、正規のクライアントが リフレッシュトークン 2 を使って新しいトークンペアをリクエストしようとします。Auth0 は正規のクライアントに access denied レスポンスを返します。
  7. 再認証が必要になります。
この保護の仕組みは、正規のクライアントと悪意のあるクライアントのどちらが先に リフレッシュトークン 1 を新しいトークンペアと交換できたかに関係なく機能します。再利用が検出されると、ユーザーが再認証するまで、その後のすべてのリクエストは拒否されます。再利用が検出されると、Auth0 は検出された再利用 イベント (交換の失敗を示す ferrt など) をログに記録します。これは、不審なアクティビティを検出するうえで、Auth0 の ログストリーミング 機能と組み合わせると特に有用です。 別の例として、悪意のあるクライアントが リフレッシュトークン 1 を盗み、正規のクライアントが リフレッシュトークン 1 を使おうとする前に、それを使ってアクセストークンの取得に成功するケースがあります。この場合、悪意のあるクライアントのアクセスは短期間にとどまります。これは、次の図に示すように、正規のクライアントが リフレッシュトークン 1 を使おうとした時点で リフレッシュトークン 2 (またはその後に発行された任意のリフレッシュトークン) が自動的に失効するためです。
リフレッシュトークンローテーションの再利用検出の状態図

​
SDK サポート

以下の SDK は、リフレッシュトークンローテーションと自動再利用検出をサポートしています。
  • Auth0 SPA SDK
  • Flutter (Web)
  • Swift (iOS) SDK
  • Android SDK
  • Flutter
  • React Native SDK
  • WPF / Winforms
  • Xamarin
これらの SDK に関するドキュメントは、Auth0 SDK Libraries ページを参照してください。 トークンは、ローカルストレージまたはブラウザーメモリのいずれかに保存できます。デフォルトではブラウザーメモリに保存されます。トークンの保存に関する推奨事項については、Token Best Practices を参照してください。クライアント SDK では、オフラインアクセスを有効にし、offline_access スコープをリクエストする必要があります。

​
詳細