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

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

マルチリソース リフレッシュトークン (MRRT) を使用すると、1 つの リフレッシュトークン で、複数の API に対する アクセストークン を取得できます。各 API には、それぞれ独自のスコープと権限を設定できます。MRRT は、リフレッシュトークンで複数の認可ポリシーを保持できるようにすることで、標準的な OAuth 2.0 の動作を拡張します。

アプリケーションがリフレッシュトークンを アクセストークン と交換する際は、設定済みの audience とスコープのセットから選択できます。これにより、API ごとに新しいリフレッシュトークンを取得する必要がなくなり、MRRT は認証フローを簡素化します。 MRRT を使用すると、Auth0 はリフレッシュトークン交換で発行するアクセストークンを決定するために、2 つの認可ソースを統合します。

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

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

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

• 複数の API へのアクセスを制御する場合でも、アプリケーションごとに 1 つのリフレッシュトークンで管理できます。
• アプリケーションが新しい API へアクセスする必要が生じるたびに、完全な 認可フロー をやり直す必要がありません。
• パフォーマンスが向上し、認可サーバー への負荷を軽減できます。
• 完全な認可コードフローを繰り返すことによる レート制限 のリスクを低減できます。

​

仕組み

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

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

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

4. アプリケーションはマルチリソース リフレッシュトークンを使用して、API 2 用のアクセスと引き換えます。

5. Auth0 は API 2 を対象とする新しいアクセストークンを返します。

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

たとえば、Native アプリケーションがユーザーを認証し、https://api.example.com の audience へのアクセスを要求するとします。その後、アプリケーションは https://billing.example.com の audience へのアクセスも必要になります。両方の API がそのアプリケーションの MRRT ポリシーに含まれていれば、アプリケーションはリフレッシュトークンを交換して、いずれかの API 用のアクセストークンを取得できます。

マルチリソース リフレッシュトークンの構成と実装 の方法をご覧ください。

​

制限事項

• MRRT を通じて発行される各アクセストークンは、単一の API のみに対して有効です。アプリケーションで複数の API へのアクセスが必要な場合は、API ごとに個別のアクセストークンをリクエストする必要があります。
• MRRT は ファーストパーティアプリケーション のみをサポートします。
• MRRT は、ユーザーの同意を省略できる ように設定された API をサポートします。
• Auth0 の Management API は、MRRT ポリシーに含めることはできません。