> ## 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.

> マルチリソース リフレッシュトークンについて学びます

# マルチリソース リフレッシュトークン

マルチリソース <Tooltip tip="Refresh Token: ユーザーに再度ログインを求めることなく、新しいアクセストークンを取得するために使用されるトークン。" cta="用語集を表示" href="/ja/docs/glossary?term=Refresh+Tokens">リフレッシュトークン</Tooltip> (MRRT) を使用すると、1 つの[リフレッシュトークン](/ja/docs/secure/tokens/refresh-tokens)で、複数の[API](/ja/docs/get-started/apis)それぞれに対して、個別のスコープと権限を持つ[アクセストークン](/ja/docs/secure/tokens/access-tokens)を取得できます。MRRT は、リフレッシュトークンで複数の認可ポリシーを維持できるようにすることで、標準的な [OAuth 2.0](/ja/docs/authenticate/protocols/oauth) の動作を拡張します。

アプリケーションがリフレッシュトークンを <Tooltip tip="Access Token: API へのアクセスに使用される、不透明な文字列または JWT 形式の認可資格情報。" cta="用語集を表示" href="/ja/docs/glossary?term=access+token">アクセストークン</Tooltip> に交換する際は、設定済みの <Tooltip tip="Audience: 発行されたトークンの対象者を一意に識別する値です。トークン内では aud という名前で表され、その値には IDトークンの場合はアプリケーション（クライアントID）、アクセストークンの場合は API（API Identifier）の ID が含まれます。" cta="用語集を表示" href="/ja/docs/glossary?term=audience">オーディエンス</Tooltip> とスコープのセットから選択できます。これにより、MRRT は API ごとに新しいリフレッシュトークンを取得する必要をなくし、認証フローを簡素化します。
MRRT を使用する場合、Auth0 は 2 つの認可ソースを組み合わせて、リフレッシュトークン交換時に発行するアクセストークンを決定します。

1. 元の認証フローで付与されたオーディエンスとスコープ。
2. アプリケーションの MRRT ポリシーで設定されたオーディエンスとスコープ。

これにより、アプリケーションはログイン時にリクエストした API だけでなく、MRRT ポリシーで許可された追加の API に対してもリフレッシュトークンを再利用できます。

**MRRT の主な利点は次のとおりです**：

* 複数の API へのアクセスを制御する場合でも、アプリケーションごとに 1 つのリフレッシュトークンで管理できます。
* アプリケーションが新しい API にアクセスする必要が生じるたびに、完全な <Tooltip tip="Authorization Flow: OAuth 2.0 フレームワークで規定された認可グラント（またはワークフロー）。" cta="用語集を表示" href="/ja/docs/glossary?term=authorization+flow">認可フロー</Tooltip> を毎回実行する必要がありません。
* <Tooltip tip="Authorization Server: ユーザーのアクセス境界の定義に関与する集中型サーバーです。たとえば、認可サーバーはユーザーが利用できるデータ、タスク、機能を制御できます。" cta="用語集を表示" href="/ja/docs/glossary?term=authorization+server">認可サーバー</Tooltip> の負荷を軽減し、パフォーマンスを向上させます。
* 完全な認可コードフローを繰り返し実行することによる[レート制限](/ja/docs/troubleshoot/customer-support/operational-policies/rate-limit-policy)のリスクを低減します。

<div id="how-it-works">
  ## 仕組み
</div>

<Frame>
  <img src="https://mintcdn.com/translations/eVsQcTnbClN-oB7d/docs/images/cdy7uua7fh8z/1V12Rzfm8mafMTaxlcEr25/a9ab2a335a835f0c2ae61eb1d767c9fa/Docs_Diagram_Toolkit_-_Carlos__1_.png?fit=max&auto=format&n=eVsQcTnbClN-oB7d&q=85&s=b8d95753dc3b63ab0d807f9ee96b2547" alt="" width="1400" height="943" data-path="docs/images/cdy7uua7fh8z/1V12Rzfm8mafMTaxlcEr25/a9ab2a335a835f0c2ae61eb1d767c9fa/Docs_Diagram_Toolkit_-_Carlos__1_.png" />
</Frame>

1. アプリケーションが Auth0 で認証を行います。

2. Auth0 はアクセストークンとマルチリソース リフレッシュトークンを返します。

3. アプリケーションはアクセストークンを使用して API 1 を呼び出します。

4. アプリケーションはマルチリソース リフレッシュトークンを交換して、API 2 へのアクセスを取得します。

5. Auth0 は API 2 向けのスコープを持つ新しいアクセストークンを返します。

6. アプリケーションは新しいアクセストークンを使用して API 2 を呼び出します。

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  たとえば、ネイティブアプリケーションがユーザーを認証し、オーディエンスとして `https://api.example.com` を指定してアクセスを要求するとします。次に、そのアプリケーションはオーディエンス `https://billing.example.com` へのアクセスを必要とします。両方の API がアプリケーションの MRRT ポリシーに含まれている場合、アプリケーションはリフレッシュトークンを交換して、いずれかの API 用のアクセストークンを取得できます。
</Callout>

[マルチリソース リフレッシュトークンの構成と実装](/ja/docs/secure/tokens/refresh-tokens/multi-resource-refresh-token/configure-and-implement-multi-resource-refresh-token)方法をご覧ください。

<div id="limitations">
  ## 制限事項
</div>

* MRRT を通じて発行される各アクセストークンのスコープは、単一の API に限定されます。アプリケーションで複数の API へのアクセスが必要な場合は、API ごとに個別のアクセストークンをリクエストする必要があります。
* MRRT でサポートされるのは、[ファーストパーティアプリケーション](/ja/docs/get-started/applications/first-party-and-third-party-applications#first-party-applications) のみです。
* MRRT は、[ユーザーの同意のスキップを許可する](/ja/docs/get-started/applications/third-party-applications/user-consent-and-third-party-applications#skip-consent-for-first-party-applications) ように設定された API をサポートします。
* Auth0 の <Tooltip tip="Management API: お客様が管理タスクを実行できるようにする製品です。" cta="用語集を表示" href="/ja/docs/glossary?term=Management+API">Management API</Tooltip> は、MRRT ポリシーに含めることはできません。