トークン内のエージェントアイデンティティ

クライアントに関連付けると、そのクライアントに発行されるトークンには、帰属の明確化と追跡可能性のためにエージェントのアイデンティティが含まれます。トークン内でエージェントのアイデンティティがどのように表されるかは、グラントタイプによって異なります。

クライアント認証情報フロー：エージェントがサブジェクトです。そのアイデンティティは最上位レベルの sub クレームに含まれます。
標準ログインフロー：ユーザーがサブジェクトです。エージェントのアイデンティティは、単一レベルの act クレームに含まれます。
On-Behalf-Of (OBO) トークン交換：ユーザーは引き続きサブジェクトです。エージェントのアイデンティティは act クレームに含まれ、その中にネストされた act として元のクライアントが示されます。

Auth0は、エージェントにリンクされたクライアントでのjwt_bearer グラントをサポートしていません。

Auth0はOAuth Actor Profile for Delegationドラフトも採用しており、トークン内の各位置にあるエンティティの種類を明示的に識別するために、sub_profile と client_profile のクレームを導入しています。

エージェントの subject クレーム

sub_profile および client_profile クレームは、エージェントにリンクされたクライアントが発行するトークン内のエンティティタイプを指定します。

クレーム	説明
`sub_profile`	subject のエンティティタイプ。値: `user`、`ai_agent`、`service`、`browser_app`、`native_app`。
`client_profile`	リクエストを行うクライアントのエンティティタイプ。値: `user`、`ai_agent`、`service`、`browser_app`、`native_app`。スペース区切りで複数の値を指定できます (例: `service ai_agent`) 。
`act`	OBO トークン交換の actor クレーム。エージェントにリンクされたクライアントが関与する場合は常に含まれます。`sub`、`iss`、`sub_profile`、`client_id`、`client_profile`、必要に応じて `cnf` (DPoP バインディング) 、およびマルチホップチェーン用にネストされた `act` が含まれます。

発行されたトークンで sub_profile および client_profile クレームを受け取るには、リソースサーバーを設定する必要があります。クレーム内 (最上位レベルの sub または act.sub) にエージェントの ID が含まれる場合、作成時に設定されていればそのエージェントの external_agent_id、設定されていなければ agent_id です。

エージェントのsubjectクレームを受信するようリソースサーバーを設定する

sub_profile および client_profile クレームを受信するには、対象のリソースサーバーに agent_subject_claims: 'auth0-v1' を設定します。これはリソースサーバーごとに明示的な有効化が必要です。

PATCH /api/v2/resource-servers/{id}
Content-Type: application/json

{
  "agent_subject_claims": "auth0-v1"
}

sub_profile クレームにより、トークンに正式なエンティティタイプが導入されます。トークンを受け取るサービスでは、sub_profile が常にユーザーであるとは想定しないでください。sub_profile がない場合 (リソースサーバーのオプトインが有効になっていない場合) 、既存の動作は変わりません。有効にする前に、ダウンストリームサービスでの sub の解析を確認してください。sub クレームの形式を検証または解析するサービスでは、クライアント認証情報グラントで ai_agent を有効なエンティティタイプとして処理できるよう、更新が必要になる場合があります。

エージェントにリンクされたクライアントは、認可コード、Implicit、CIBA、device、MFA、パスワード、パスキー、またはリフレッシュトークンのグラントを使用して、標準ログインフローを実行できます。subject は引き続きユーザーです。エージェントのアイデンティティは最上位の sub クレームには含まれません。代わりに、トークン内でエージェントを識別できるよう、単一レベルの act クレームが追加されます。次の例では、エージェントにリンクされたクライアントが標準ログインフローを実行し、次のエージェントの subject クレームを含むトークンを発行します。

sub: ユーザー ID
sub_profile: user
client_profile: ai_agent。クライアントがエージェントにリンクされていることを示します
act: エージェントを識別する単一レベルの actor クレーム ("sub": "agt_1a2b3c", "sub_profile": "ai_agent")

{
  "iss": "https://YOUR_AUTH0_DOMAIN/",
  "sub": "auth0|user123",
  "sub_profile": "user",
  "client_id": "agent-linked-client-id",
  "client_profile": "ai_agent",
  "aud": "https://resource-api.example.com",
  "scope": "read:data",
  "exp": 1711820400,
  "iat": 1711816800,
  "act": {
    "sub": "agt_1a2b3c",
    "sub_profile": "ai_agent",
    "client_id": "agent-linked-client-id"
  }
}

クライアント認証情報フロー

エージェントにリンクされたマシンツーマシン (M2M) クライアントは、クライアント認証情報フローを実行します。エージェントがsubjectとなり、自身として認証されるため、ユーザーは関与しません。次の例では、エージェントにリンクされたM2Mクライアントがクライアント認証情報フローを実行し、以下のエージェント subjectクレームを含むtokenを発行します。

sub: 作成時に設定されている場合はエージェントのexternal_agent_id、それ以外の場合はagent_id
sub_profile: ai_agent
client_profile: エージェントにリンクされたM2Mクライアントを表すservice ai_agent

{
  "iss": "https://YOUR_AUTH0_DOMAIN/",
  "sub": "agt_1a2b3c",
  "sub_profile": "ai_agent",
  "client_id": "YOUR_CLIENT_ID",
  "client_profile": "service ai_agent",
  "aud": "https://your-resource-api.example.com",
  "scope": "read:data",
  "exp": 1711820400,
  "iat": 1711816800
}

On-Behalf-Of (OBO) トークン交換

OBO トークン交換では、ユーザーが認証を行い、エージェントのリソースサーバーを audience とするアクセストークンを受け取ります。次に、エージェントにリンクされたクライアントは、On-Behalf-Of Token Exchangeを使用して、このトークンを委任トークンに交換します。ユーザーは一貫して subject のままです。エージェントは act クレーム内で actor として識別されます。トークン交換の前に、ユーザーはブラウザーアプリで認証を行い、アクセストークンを受け取ります。

sub: ユーザー ID
sub_profile: user
client_profile: 送信元クライアントが browser_app であることを示します
aud: エージェントリソースサーバー

{
  "iss": "https://YOUR_AUTH0_DOMAIN/",
  "sub": "auth0|user123",
  "sub_profile": "user",
  "client_id": "spa-client-id",
  "client_profile": "browser_app",
  "aud": "https://ai-agent-resource-server.example.com",
  "scope": "read:data",
  "exp": 1711820300,
  "iat": 1711816700
}

エージェントにリンクされたクライアントは、OBO トークン交換を使用してユーザートークンを交換します。

sub: ユーザー ID (変更なし)
sub_profile: user (変更なし)
client_profile: エージェントにリンクされたクライアントを表す service ai_agent
aud: 新しいリソースサーバー
act: 直近の actor はエージェントであり、ネストされた act にはフローを開始した元のクライアントが示されます。委譲の最大深度は 5 ホップ、またはネストされた act の最大 4 レベルです。

{
  "iss": "https://YOUR_AUTH0_DOMAIN/",
  "sub": "auth0|user123",
  "sub_profile": "user",
  "client_id": "agent-client-id",
  "client_profile": "service ai_agent",
  "aud": "https://resource-api.example.com",
  "scope": "read:data",
  "cnf": { "jkt": "NzbLsXh8uDCcd7MNwrnNZpX0ak8ACQ" },
  "exp": 1711820400,
  "iat": 1711816800,
  "act": {
    "sub": "agt_1a2b3c",
    "sub_profile": "ai_agent",
    "client_id": "agent-client-id",
    "act": {
      "sub": "spa-client-id",
      "sub_profile": "browser_app",
      "client_id": "spa-client-id"
    }
  }
}

トークン交換で現在 OBO がサポートされるのは、受信トークンのサブジェクトがユーザーである場合のみです。エージェントまたはクライアント自体が OBO 交換における最上位のサブジェクトとなるトークンの発行は、まだサポートされていません。

OBO トークン交換ではリフレッシュトークンはサポートされていません。設定と制限事項の詳細については、On-Behalf-Of Token Exchangeを参照してください。

次のステップ

Actions を使用してアクセストークンにエージェントコンテキストを追加する
エージェントのアイデンティティの帰属と追跡に使用するため、テナントログでエージェント ID をクエリする

Quickstarts

Auth0 Overview

Configure Auth0

Applications

トークン内のエージェントアイデンティティ

エージェントの subject クレーム

エージェントのsubjectクレームを受信するようリソースサーバーを設定する

クライアント認証情報フロー

On-Behalf-Of (OBO) トークン交換

次のステップ

​エージェントの subject クレーム

​エージェントのsubjectクレームを受信するようリソースサーバーを設定する

​標準ログインフロー

​クライアント認証情報フロー

​On-Behalf-Of (OBO) トークン交換

​次のステップ

エージェントの subject クレーム

エージェントのsubjectクレームを受信するようリソースサーバーを設定する

標準ログインフロー

クライアント認証情報フロー

On-Behalf-Of (OBO) トークン交換

次のステップ