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

<Tooltip tip="リフレッシュトークンローテーション: 脆弱性を最小限に抑えるためにリフレッシュトークンを頻繁に置き換える戦略です。リフレッシュトークンローテーションでは、アプリケーションがリフレッシュトークンを新しいアクセストークンと交換するたびに、Auth0 は新しいリフレッシュトークンも返します。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=refresh+token+rotation">リフレッシュトークンローテーション</Tooltip>を<Tooltip tip="リフレッシュトークンローテーション: 脆弱性を最小限に抑えるためにリフレッシュトークンを頻繁に置き換える戦略です。リフレッシュトークンローテーションでは、アプリケーションがリフレッシュトークンを新しいアクセストークンと交換するたびに、Auth0 は新しいリフレッシュトークンも返します。" cta="用語集を見る" href="/docs/ja-jp/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) に準拠しており、次のフローで利用できます。

* [認可コードフロー](/docs/ja-jp/get-started/authentication-and-authorization-flow/authorization-code-flow)
* [Proof Key for Code Exchange を使用する認可コードフロー](/docs/ja-jp/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce)
* [デバイス認可フロー](/docs/ja-jp/get-started/authentication-and-authorization-flow/device-authorization-flow)
* [リソース所有者パスワードフロー](/docs/ja-jp/get-started/authentication-and-authorization-flow/resource-owner-password-flow)

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

ごく最近まで、SPA では、サイレント認証と組み合わせて PKCE を使用した Authorization Code フローを用いることで、ユーザーのセッションを維持していました。ところが、Intelligent Tracking Prevention (ITP) などのブラウザーのプライバシー技術の進展により、Auth0 の <Tooltip tip="セッション Cookie: 存在する場合、ユーザーが認証済みと見なされるようにする要素。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=session+cookie">セッション 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="Refresh Token Rotation Maintain User Sessions in SPAs diagram" width="900" height="764" data-path="docs/images/cdy7uua7fh8z/3sf7RRsy81bt3zcXMnHUSe/2171fdab4ffeb0987c329aa897038abc/rt-and-at.png" />
</Frame>

残念ながら、有効期間の長いリフレッシュトークンは SPA には適していません。というのも、ブラウザーには、想定されたアプリケーションだけがアクセスできることを保証できる永続的な保存の仕組みがないためです。このような価値の高い成果物を取得し、悪意のある攻撃者に保護されたリソースへのアクセスを許してしまう脆弱性が悪用される可能性があることから、SPA でリフレッシュトークンを使用することは強く非推奨とされてきました。

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

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

<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="Refresh Token Rotation Maintain User Sessions in SPAs State diagram" 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="/docs/ja-jp/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. 正規のクライアントは **リフレッシュトークン 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 は検出された再利用 [イベント](/docs/ja-jp/deploy-monitor/logs/log-event-type-codes) (交換の失敗を示す `ferrt` など) をログに記録します。これは、不審なアクティビティを検出するうえで、Auth0 の [ログストリーミング](/docs/ja-jp/customize/log-streams) 機能と組み合わせると特に有用です。

別の例として、悪意のあるクライアントが **リフレッシュトークン 1** を盗み、正規のクライアントが **リフレッシュトークン 1** を使おうとする前に、それを使ってアクセストークンの取得に成功するケースがあります。この場合、悪意のあるクライアントのアクセスは短期間にとどまります。これは、次の図に示すように、正規のクライアントが **リフレッシュトークン 1** を使おうとした時点で **リフレッシュトークン 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](/docs/ja-jp/libraries) ページを参照してください。

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

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

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