マルチリソース リフレッシュトークンの設定と実装

マルチリソース リフレッシュトークンの設定と実装の方法を学びます

​

MRRT 用にアプリケーションを設定する

Multi-Resource リフレッシュトークン (MRRT) を使用するには、Auth0 の Management API を使用して、アプリケーションのリフレッシュトークンポリシーを設定します。これらのポリシーでは、リフレッシュトークンの交換時に、アプリケーションがリクエストを許可される API とスコープを指定します。

MRRT ポリシーは、アプリケーションの refresh_token.policies プロパティで定義できます。

Property	Type	Description
audience	string	リフレッシュトークンの使用を許可するアプリケーションの Auth0 API identifier。
scope	Array of strings	指定した audience に対するアクセストークンをリクエストする際に許可されるスコープの一覧。scope は、API で定義されているスコープと同じか、それより限定的である必要があります。

audience プロパティと scope プロパティは、テナント内の既存のアプリケーションに対応している必要があります。そうでない場合、リフレッシュトークン交換時にそれらは通知なく無視されます。

既存のアプリケーションの場合は、Update a Client エンドポイントに PATCH リクエストを送信します。新しいアプリケーションを作成するには、Create a Client エンドポイントに POST リクエストを送信します。

レスポンス例:

{
  "client_id": "abc123xyz",
  "name": "My Native App",
  "refresh_token": {
    "rotation_type": "rotating",
    "policies": [
      {
        "audience": "https://api.example.com",
        "scope": ["read:data"]
      },
      {
        "audience": "https://billing.example.com",
        "scope": ["read:billing"]
      }
    ]
  }
}

​

マルチリソース リフレッシュトークンを実装する

アプリケーションのリフレッシュトークンを MRRT ポリシーで設定すると、1 つのリフレッシュトークンを使って、複数の API 向けの アクセストークン を取得できるようになります。 これを行うには、アプリケーションで Authorization Code Flow または Resource Owner Password Grant のいずれかを使用してログインフローを開始する必要があります。

​

ステップ 1: 認証し、リフレッシュトークンをリクエストする

リフレッシュトークンを受け取るには、認証リクエストを開始する際に offline_access スコープを含めます。詳細については、リフレッシュトークンを取得するを参照してください。

リフレッシュトークンを受け取れない場合は、次の点を確認してください。

• API の設定で Allow Offline Access が有効になっていること。
• offline_access がスコープに含まれていること。
• リクエストで使用した audience が、テナントで設定済みの API と一致していること。

​

ステップ 2: リフレッシュトークンを別の API 用に交換する

リフレッシュトークンが発行されると、初回の認証時と MRRT ポリシーの両方で定義された任意の API およびスコープに対して、アクセストークンをリクエストできます。例:

 詳しくは、リフレッシュトークンの使用を参照してください。

Auth0 Swift SDK を使用している場合は、次のコードを使用してリフレッシュトークンを交換できます。

credentialsManager.apiCredentials(forAudience: "https://example.com/me",
                                  scope: "create:me:authentication_methods") { result in
    switch result {
    case .success(let apiCredentials):
        print("Obtained API credentials: \(apiCredentials)")
    case .failure(let error):
        print("Failed with: \(error)")
    }
}

詳しくは、Auth0 Swift SDKを参照してください。

Auth0 Android SDK を使用している場合は、次のコードでリフレッシュトークンを交換できます。

credentialsManager.getApiCredentials(
    audience = "https://example.com/me", scope = " create:me:authentication_methods",
    callback = object : Callback<APICredentials, CredentialsManagerException> {
        override fun onSuccess(result: APICredentials) {
            print("Obtained API credentials: $result")
        }
        override fun onFailure(error: CredentialsManagerException) {
            print("Failed with: $error")
        }
    })

詳しくは、Auth0 Android SDKを参照してください。

​

ステップ 3: アクセストークンを使用して API を呼び出す

Bearer HTTP 認証スキームを使用して、アクセストークンで保護された API を呼び出します。詳細については、アクセストークンの使用を参照してください。

jwt.io でアクセストークンをデコードして、次の内容を確認できます。

• aud クレームが、要求した API と一致していること (例: https://billing.example.com) 。
• scope クレームに、許可された値のみが含まれていること。

​

Actions でマルチリソース リフレッシュトークンを使用する

MRRT を Actions で使用すると、アプリケーションの MRRT ポリシーに基づく動的な判定を構成できます。これを可能にするため、post-login Actions には event.client.refresh_token.policies オブジェクトが用意されており、オーディエンス やスコープなどの関連情報が含まれます。

event.client.refresh_token.policies オブジェクトを使用すると、リフレッシュトークンの発行時または交換時にアプリケーションのオーディエンスとスコープを評価し、API へのアクセスとスコープを正確に制御できます。

exports.onExecutePostLogin = async (event, api) => {
  // クライアントで許可されているAPIのリストを取得する
  const allowedAPIsInTheClient = event.client.refresh_token?.policies;

  if(allowedAPIsInTheClient?.some(policy => policy?.audience?.includes('https://myapi'))){
    // カスタムロジック
  }
};

​

評価ロジック

MRRT は元の認証を置き換えるものではなく、その拡張として機能します。リフレッシュトークンを交換する際、Auth0 は次のロジックに基づいて交換リクエストを評価します。

• audience パラメーターが省略されている場合、Auth0 は元のオーディエンスと、MRRT ポリシーで設定された追加のスコープを含むアクセストークンを返します。
• 新しい audience パラメーターが指定されている場合、Auth0 はそのオーディエンスが MRRT ポリシーに含まれていることを確認し、設定されたスコープを持つ、その新しいオーディエンス向けのアクセストークンを返します。
• scope パラメーターが省略されている場合、Auth0 は元のリクエストと MRRT ポリシーで許可されているすべてのスコープを組み合わせます。
• 新しい scope パラメーターが指定されている場合、Auth0 は要求されたスコープを検証し、MRRT ポリシーに含まれるスコープを持つアクセストークンを返します。無効なスコープや許可されていないスコープは、要求されても暗黙的に無視されます。
• audience パラメーターが元のリクエストと同じ場合、Auth0 は MRRT ポリシーを適用し、MRRT で設定されたすべてのスコープと元の認証時のスコープを持つ、そのオーディエンス向けのアクセストークンを返します。

MRRT を使用すると、新しいリフレッシュトークンを発行したり、ユーザーに再度ログインを求めたりすることなく、新しい API へのユーザーアクセスを拡張できます。

​

例

ユーザーは、次のオーディエンスとスコープを指定してログインします。

{
"audience": "https://api.example.com",  
"scope": "openid profile read:messages"
}

アプリケーションのMRRTポリシーでは、追加のスコープを付与するように設定されています。

{
  "audience": "https://api.example.com",
  "scope": ["write:messages"]
}

同じ audience を使用し、スコープを指定せずにリフレッシュトークン交換を行うと、設定済みのすべてのスコープを含むアクセストークンが取得されます。

{
  "aud": "https://api.example.com",
  "scope": "openid profile read:messages write:messages"
}