メインコンテンツへスキップ
リフレッシュトークンのローテーションはリフレッシュトークンを使って新しいアクセストークンを取得する方法で、サイレント認証よりも優れています。リフレッシュトークンは一般的に寿命が長いため、より寿命の短いアクセストークンの期限が切れた後、新しいアクセストークンを要求するのに利用できます。リフレッシュトークンは、寿命が短いアクセストークンと共に、モバイルデバイスのネイティブアプリケーションで広く使用されています。寿命の長いアクセストークンを発行することなく、シームレスなUXを提供できるようにします。 でリフレッシュトークンのローテーションを有効にすると、アプリケーションがリフレッシュトークンを交換して新しいアクセストークンを取得するたびに、新しいリフレッシュトークンが返されます。このため、侵入を受けると永久にリソースへのアクセスを許してしまうような、寿命の長いリフレッシュトークンはなくなりました。リフレッシュトークンは交換され続け、失効し続けるため、脅威の軽減に繋がっています。 リフレッシュトークンのローテーションについて、Auth0の仕組みはOAuth 2.0 BCPに準拠しており、以下のフローで動作します。

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

ごく最近まで、SPAは、PKCEを使った認可コードフローとサイレント認証を併せて使用することによって、ユーザーのセッションを維持していました。Intelligent Tracking Prevention（ITP）など、ブラウザーのプライバシー技術における最近の発展により、Auth0のセッションCookieへのアクセスが妨げられるため、ユーザーの再認証が必要になっています。
リフレッシュトークンローテーションでSPAのユーザーセッション維持の図
残念ながら、意図されたアプリケーションのみにアクセスを保証できるような永続ストレージのメカニズムがブラウザーにはないため、寿命の長いリフレッシュトークンはSPAには適していません。これら高価値のアーティファクトを手に入れるためや、悪意ある行為者に保護されたリソースへのアクセス権を付与させるために悪用され得る脆弱性があるため、SPAでリフレッシュトークンを使用することは断固としてお勧めできません。 リフレッシュトークンのローテーションは、ブラウザーのプライバシー保護メカニズムが原因で、エンドユーザーのセッションが失われてしまうという不都合を改善します。リフレッシュトークンのローテーションはAuth0のセッションCookieにアクセスしないため、ITPやそれに類似した保護メカニズムの影響を受けません。 以下の図は、リフレッシュトークンのローテーションがどのようにして、PKCEを使った認可コードフローと併せて使用されるのかを表していますが、交換時に新しいリフレッシュトークンの取得に適用される一般原則は、すべての対応するフローに適用されます。
リフレッシュトークンローテーションでSPAのユーザーセッション維持の状態図
つまり、ブラウザーのプライバシー保護ツールがもたらす副作用を軽減するために、リフレッシュトークンを安全に使用して、ユーザーエクスペリエンスを損なうことなく、エンドユーザーに継続してアクセスできるということになります。

​
再利用の自動検出

クライアントは、新しいアクセストークンが必要になると、新しいトークンのペアを取得するために、Auth0へ要求を添えてリフレッシュトークンを送信します。Auth0が新しいトークンのペアを発行すると、要求に使用されたリフレッシュトークンが即座に失効します。こうすることで、トークンの侵害によって起きるリプレイ攻撃からアプリを保護します。 sender-constraintを実現させないのであれば、リプレイ攻撃の際に、認可サーバーが正当な行為者と悪意のある行為者を区別することは不可能です。そのため、以前に使用されたリフレッシュトークン（すでに失効済み）が認可サーバーへ送信されるたら、発行されたばかりの最新のリフレッシュトークンでさえ即座に失効させることが重要です。これによって、同じトークンファミリー（クライアントに対して発行されたオリジナルのリフレッシュトークンから派生したすべてのリフレッシュトークン）のあらゆるリフレッシュトークンが、新しいアクセストークンの取得に使用されることを防ぎます。 たとえば、以下のシナリオを考えてみてください。
リフレッシュトークンローテーションの再利用検出状態の図
  1. 正当なクライアントにリフレッシュトークン1 があり、それが漏洩したか、悪意のあるクライアントに盗まれました。
  2. 正当なクライアントがリフレッシュトークン1 を使用して、新しいリフレッシュトークンとアクセストークンのペアを取得します。
  3. Auth0がリフレッシュトークン2とアクセストークン2 を返します。
  4. 悪意のあるクライアントがリフレッシュトークン1 を使用してアクセストークンを取得しようとします。Auth0はリフレッシュトークン1が再利用されたことを認識し、即座にリフレッシュトークン2 を含む関連のリフレッシュトークンを無効にします。
  5. Auth0が悪意のあるクライアントにアクセス拒否の応答を返します。
  6. アクセストークン2 が失効したため、正当なクライアントがリフレッシュトークン2 を使用して新しいトークンのペアを要求します。Auth0が正当なクライアントにアクセス拒否の応答を返します。
  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ライブラリーのページをご覧ください。 トークンの保管場所は、ローカルストレージまたはブラウザーのメモリーを選択することができます。デフォルトはブラウザーのメモリーです。トークンのストレージに関する推奨については、「トークンのベストプラクティス」を参照してください。オフラインアクセスを有効にして、クライアントSDKでオフラインアクセスのスコープを要求しなければなりません。

​
もっと詳しく

⌘I