> ## Documentation Index
> Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> リフレッシュトークンを使用するクライアントが新しいアクセストークンを取得するために Auth0 にリクエストするたびに、新しいリフレッシュトークンを発行することで、リフレッシュトークンローテーションがどのようにセキュリティを強化するかを説明します。

# リフレッシュトークンローテーション

<Tooltip tip="リフレッシュトークン: ユーザーに再ログインを求めることなく、新しいアクセストークンを取得するために使用するトークン。" cta="用語集を見る" href="/ja/docs/glossary?term=Refresh+token">リフレッシュトークン</Tooltip>ローテーションは、リフレッシュトークンを使用して新しい<Tooltip tip="リフレッシュトークン: ユーザーに再ログインを求めることなく、新しいアクセストークンを取得するために使用するトークン。" cta="用語集を見る" href="/ja/docs/glossary?term=access+tokens">アクセストークン</Tooltip>を取得する手法で、[サイレント認証](/ja/docs/authenticate/login/configure-silent-authentication)を補完するものです。リフレッシュトークンは通常、より長期間有効であり、有効期間の短いアクセストークンの有効期限が切れた後に、新しいアクセストークンを要求するために使用できます。リフレッシュトークンは、長期間有効なアクセストークンを発行しなくてもシームレスな UX を実現できるよう、モバイルデバイス上のネイティブアプリケーションで有効期間の短いアクセストークンと組み合わせて使われることがよくあります。

<Tooltip tip="リフレッシュトークンローテーション: 脆弱性を最小限に抑えるために、リフレッシュトークンを頻繁に置き換える戦略です。リフレッシュトークンローテーションでは、アプリケーションが新しいアクセストークンを取得するためにリフレッシュトークンを交換するたびに、Auth0 から新しいリフレッシュトークンも返されます。" cta="用語集を見る" href="/ja/docs/glossary?term=refresh+token+rotation">リフレッシュトークンローテーション</Tooltip>を<Tooltip tip="リフレッシュトークンローテーション: 脆弱性を最小限に抑えるために、リフレッシュトークンを頻繁に置き換える戦略です。リフレッシュトークンローテーションでは、アプリケーションが新しいアクセストークンを取得するためにリフレッシュトークンを交換するたびに、Auth0 から新しいリフレッシュトークンも返されます。" cta="用語集を見る" href="/ja/docs/glossary?term=Auth0+Dashboard">Auth0 Dashboard</Tooltip>で有効にすると、アプリケーションが新しいアクセストークンを取得するためにリフレッシュトークンを交換するたびに、新しいリフレッシュトークンも返されます。そのため、侵害された場合にリソースへの不正アクセスを許す可能性がある、長期間有効なリフレッシュトークンを保持し続ける必要がなくなります。リフレッシュトークンは継続的に交換されて無効化されるため、脅威は軽減されます。

Auth0 におけるリフレッシュトークンローテーションの仕組みは [OAuth 2.0 BCP](https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4.12) に準拠しており、次のフローで機能します。

* [Authorization Code Flow](/ja/docs/get-started/authentication-and-authorization-flow/authorization-code-flow)
* [Proof Key for Code Exchange を使用する Authorization Code Flow](/ja/docs/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce)
* [デバイス認可フロー](/ja/docs/get-started/authentication-and-authorization-flow/device-authorization-flow)
* [Resource Owner Password Flow](/ja/docs/get-started/authentication-and-authorization-flow/resource-owner-password-flow)

<div id="maintain-user-sessions-in-spas">
  ## SPA でユーザーセッションを維持する
</div>

ごく最近まで、SPA では PKCE を使用する認可コードフローとサイレント認証を組み合わせて、ユーザーセッションを維持していました。しかし、Intelligent Tracking Prevention (ITP) など、ブラウザーのプライバシー保護技術の進展により、Auth0 の <Tooltip tip="セッションクッキー: 存在すると、ユーザーが認証済みと見なされるようにするエンティティ。" cta="用語集を表示" href="/ja/docs/glossary?term=session+cookie">セッションクッキー</Tooltip> にアクセスできなくなり、ユーザーは再認証を求められるようになりました。

<Frame>
  <img src="https://mintcdn.com/translations/3nS3prIggmJG9TUI/docs/images/cdy7uua7fh8z/3sf7RRsy81bt3zcXMnHUSe/2171fdab4ffeb0987c329aa897038abc/rt-and-at.png?fit=max&auto=format&n=3nS3prIggmJG9TUI&q=85&s=e9ad75d7fab9abc686e06dba4d38324c" alt="SPA でユーザーセッションを維持するためのリフレッシュトークンローテーションの図" width="900" height="764" data-path="docs/images/cdy7uua7fh8z/3sf7RRsy81bt3zcXMnHUSe/2171fdab4ffeb0987c329aa897038abc/rt-and-at.png" />
</Frame>

一方で、長期間有効なリフレッシュトークンは SPA には適していません。ブラウザーには、意図したアプリケーションだけがアクセスできることを保証できる永続的な保存メカニズムがないためです。こうした価値の高いアーティファクトは、脆弱性を悪用して取得され、悪意のある第三者に保護されたリソースへのアクセスを許してしまうおそれがあるため、SPA でリフレッシュトークンを使用することは強く非推奨とされてきました。

リフレッシュトークンローテーションは、ブラウザーのプライバシー保護メカニズムの副作用によってエンドユーザーのセッションが失われる問題への対策となります。リフレッシュトークンローテーションは Auth0 のセッションクッキーへのアクセスに依存しないため、ITP や同様のメカニズムの影響を受けません。

次の状態図は、リフレッシュトークンローテーションを PKCE を使用する認可コードフローと組み合わせて使用する方法を示しています。ただし、交換のたびに新しいリフレッシュトークンを取得するという基本原則は、サポートされているすべてのフローに当てはまります。

<Frame>
  <img src="https://mintcdn.com/translations/pvjQqAy3EB2TK6NP/docs/images/cdy7uua7fh8z/41avsR2u0B4fSP3Bwh0WZz/d803a9057ea6e606d602c7c97d99fc3a/rtr-state-diagram.png?fit=max&auto=format&n=pvjQqAy3EB2TK6NP&q=85&s=1391833b00321c0e5c2b671652c70070" alt="SPA でユーザーセッションを維持するためのリフレッシュトークンローテーションの状態図" width="1500" height="1567" data-path="docs/images/cdy7uua7fh8z/41avsR2u0B4fSP3Bwh0WZz/d803a9057ea6e606d602c7c97d99fc3a/rtr-state-diagram.png" />
</Frame>

つまり、ブラウザーのプライバシーツールによる悪影響を軽減し、ユーザー体験を損なうことなくエンドユーザーへの継続的なアクセスを実現するために、リフレッシュトークンを安全に使用できます。

<div id="automatic-reuse-detection">
  ## 自動再利用検出
</div>

クライアントが新しいアクセストークンを必要とする場合、リフレッシュトークンを添えて Auth0 にリクエストを送信し、新しいトークンペアを取得します。Auth0 が新しいペアを発行すると、そのリクエストで使用されたリフレッシュトークンは直ちに無効化されます。これにより、侵害されたトークンに起因するリプレイ攻撃からアプリを保護できます。

送信者制約を適用していない場合、リプレイ攻撃が発生した際に、どのアクターが正当でどれが悪意のあるものかを <Tooltip tip="Authorization Server: ユーザーのアクセス境界の定義に寄与する集中型サーバーです。たとえば、認可サーバーは、ユーザーが利用できるデータ、タスク、機能を制御できます。" cta="用語集を表示" href="/ja/docs/glossary?term=authorization+server">認可サーバー</Tooltip> が判断することはできません。そのため、以前使用されたリフレッシュトークン (すでに無効化済み) が認可サーバーに送信された場合は、直近に発行されたリフレッシュトークンも直ちに無効化されることが重要です。これにより、同じトークンファミリー内のリフレッシュトークン (クライアント向けに発行された元のリフレッシュトークンから派生したすべてのリフレッシュトークン) が、新しいアクセストークンの取得に使われるのを防ぎます。

たとえば、次のシナリオを考えてみましょう。

<Frame>
  <img src="https://mintcdn.com/translations/Dcx0M11uuptU53TX/docs/images/cdy7uua7fh8z/33fe73R81Cpm6eTmOWfAnm/e7d168edc27861507a121910b32f1ee2/reuse-detection1.png?fit=max&auto=format&n=Dcx0M11uuptU53TX&q=85&s=f38db99d1301278466def0e78d33cb85" alt="リフレッシュトークンローテーションの再利用検出状態図" width="1500" height="1105" data-path="docs/images/cdy7uua7fh8z/33fe73R81Cpm6eTmOWfAnm/e7d168edc27861507a121910b32f1ee2/reuse-detection1.png" />
</Frame>

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 は検出された再利用の[イベント](/ja/docs/deploy-monitor/logs/log-event-type-codes) (交換の失敗を示す `ferrt` など) をログに記録します。これは、不審なアクティビティを検出するうえで、Auth0 の[ログストリーミング](/ja/docs/customize/log-streams)機能と組み合わせると特に有効です。

別の例として、悪意のあるクライアントが **refresh token 1** を盗み、正当なクライアントが **refresh token 1** を使用しようとする前に、それを使ってアクセストークンの取得に成功するケースがあります。この場合、次の図に示すように、正当なクライアントが **refresh token 1** を使用しようとした時点で **refresh token 2** (またはその後に発行されたリフレッシュトークン) は自動的に失効されるため、悪意のあるクライアントのアクセスは短期間しか続きません。

<Frame>
  <img src="https://mintcdn.com/translations/3nS3prIggmJG9TUI/docs/images/cdy7uua7fh8z/36rAUgLOAqW7k7Fdl1eRN1/c1a57be5093416b50d42ec41a1e3a233/reuse-detection2.png?fit=max&auto=format&n=3nS3prIggmJG9TUI&q=85&s=b89ad8a6b2462ef5d0a443d5cdca40d0" alt="リフレッシュトークンローテーションの再利用検出状態図" width="1500" height="1189" data-path="docs/images/cdy7uua7fh8z/36rAUgLOAqW7k7Fdl1eRN1/c1a57be5093416b50d42ec41a1e3a233/reuse-detection2.png" />
</Frame>

<div id="sdk-support">
  ## SDK のサポート
</div>

次の SDK は、リフレッシュトークンローテーションと自動再利用検出をサポートしています。

* Auth0 SPA SDK
* Flutter (Web)
* Swift (iOS) SDK
* Android SDK
* Flutter
* React Native SDK
* WPF / Winforms
* Xamarin

これらの SDK に固有のドキュメントは、[Auth0 SDK Libraries](/ja/docs/libraries) ページを参照してください。

トークンは、ローカルストレージまたはブラウザーメモリのいずれかに保存できます。デフォルトではブラウザーメモリに保存されます。トークンの保存に関する推奨事項については、[トークンのベストプラクティス](/ja/docs/secure/tokens/token-best-practices) を参照してください。クライアント SDK では、オフラインアクセスを有効にし、offline\_access スコープを要求する必要があります。

<div id="learn-more">
  ## 詳細情報
</div>

* [リフレッシュトークンローテーションの設定](/ja/docs/secure/tokens/refresh-tokens/configure-refresh-token-rotation)
* [リフレッシュトークンローテーションの無効化](/ja/docs/secure/tokens/refresh-tokens/disable-refresh-token-rotation)
* [リフレッシュトークンの有効期限の設定](/ja/docs/secure/tokens/refresh-tokens/configure-refresh-token-expiration)
* [トークンのベストプラクティス](/ja/docs/secure/tokens/token-best-practices)