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

> 1 つのリフレッシュトークンで複数の API にアクセスできるようにする Auth0 マルチリソース リフレッシュトークンについて学ぶ。

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

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

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

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

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

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

* 複数の API へのアクセスを制御する場合でも、アプリケーションごとに 1 つのリフレッシュトークンで管理できます。
* アプリケーションが新しい API へアクセスする必要が生じるたびに、完全な <Tooltip tip="認可フロー: OAuth 2.0 フレームワークで規定された認可グラント（またはワークフロー）。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=authorization+flow">認可フロー</Tooltip> をやり直す必要がありません。
* パフォーマンスが向上し、<Tooltip tip="認可サーバー: ユーザーのアクセス範囲の境界を定義するのに関与する集中管理サーバー。たとえば、認可サーバーはユーザーが利用できるデータ、タスク、機能を制御できます。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=authorization+server">認可サーバー</Tooltip> への負荷を軽減できます。
* 完全な認可コードフローを繰り返すことによる [レート制限](/docs/ja-jp/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">
  たとえば、Native アプリケーションがユーザーを認証し、`https://api.example.com` の audience へのアクセスを要求するとします。その後、アプリケーションは `https://billing.example.com` の audience へのアクセスも必要になります。両方の API がそのアプリケーションの MRRT ポリシーに含まれていれば、アプリケーションはリフレッシュトークンを交換して、いずれかの API 用のアクセストークンを取得できます。
</Callout>

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

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

* MRRT を通じて発行される各アクセストークンは、単一の API のみに対して有効です。アプリケーションで複数の API へのアクセスが必要な場合は、API ごとに個別のアクセストークンをリクエストする必要があります。
* MRRT は [ファーストパーティアプリケーション](/docs/ja-jp/get-started/applications/first-party-and-third-party-applications#first-party-applications) のみをサポートします。
* MRRT は、[ユーザーの同意を省略できる](/docs/ja-jp/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="/docs/ja-jp/glossary?term=Management+API">Management API</Tooltip> は、MRRT ポリシーに含めることはできません。