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

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

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

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

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

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

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

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

​

仕組み

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

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

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

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

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

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

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

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

​

制限事項

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