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

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

ごく最近まで、SPA では PKCE を使用する認可コードフローとサイレント認証を組み合わせて、ユーザーセッションを維持していました。しかし、Intelligent Tracking Prevention (ITP) など、ブラウザーのプライバシー保護技術の進展により、Auth0 の にアクセスできなくなり、ユーザーは再認証を求められるようになりました。
SPA でユーザーセッションを維持するためのリフレッシュトークンローテーションの図
一方で、長期間有効なリフレッシュトークンは SPA には適していません。ブラウザーには、意図したアプリケーションだけがアクセスできることを保証できる永続的な保存メカニズムがないためです。こうした価値の高いアーティファクトは、脆弱性を悪用して取得され、悪意のある第三者に保護されたリソースへのアクセスを許してしまうおそれがあるため、SPA でリフレッシュトークンを使用することは強く非推奨とされてきました。 リフレッシュトークンローテーションは、ブラウザーのプライバシー保護メカニズムの副作用によってエンドユーザーのセッションが失われる問題への対策となります。リフレッシュトークンローテーションは Auth0 のセッションクッキーへのアクセスに依存しないため、ITP や同様のメカニズムの影響を受けません。 次の状態図は、リフレッシュトークンローテーションを PKCE を使用する認可コードフローと組み合わせて使用する方法を示しています。ただし、交換のたびに新しいリフレッシュトークンを取得するという基本原則は、サポートされているすべてのフローに当てはまります。
SPA でユーザーセッションを維持するためのリフレッシュトークンローテーションの状態図
つまり、ブラウザーのプライバシーツールによる悪影響を軽減し、ユーザー体験を損なうことなくエンドユーザーへの継続的なアクセスを実現するために、リフレッシュトークンを安全に使用できます。

​
自動再利用検出

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

​
SDK のサポート

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

​
詳細情報