ユースケース
AI agentは、長時間かかる処理や後で実行される処理、機密性の高いオペレーションを伴う処理を行う必要があることがよくあります。たとえば、次のような場合です。- 取引の承認：出張を手配するエージェントは、航空券とホテルを見つけることはできても、購入を完了するにはユーザーの最終承認が必要です。
- 機密データへのアクセス：エージェントが問い合わせに回答するために、保護されたユーザーの健康記録にアクセスしなければならない場合があります。
- 高い権限を要するタスクの実行：DevOpsエージェントが、アプリケーションの新しいバージョンを本番環境に導入する権限を必要とする場合があります。
仕組み
Auth0は、クライアント起点のバックチャネル認証 (CIBA) とリッチ認可リクエスト (RAR) を組み合わせて非同期認可を実現しています。- CIBAはOpenID Foundationの仕様で、クライアントアプリケーション (AI agentのバックエンドなど) が、同じデバイス上でのユーザーの直接操作なしに認証リクエストを開始できる分離型のフローを定義しています。ユーザーは、別の信頼できる認証デバイス (携帯電話など) で、通常はAuthenticatorアプリへのプッシュ通知、SMS、またはメールを通じてリクエストを承認または拒否します。
- RARはOAuth 2.0の拡張仕様で、クライアントアプリケーションが認可リクエストの中で、標準的なOAuth 2.0のスコープでは表現できない、より複雑な権限を要求できるようにします。これにより、エージェントは取引内容を正確に記述した、詳細で構造化されたペイロードを送信できます。その結果、ユーザーには汎用的なプロンプトではなく、「ExampleCorpへの$50.00の支払いを承認する」といった具体的で検証可能なコンテキストが提示されます。これは、ユーザーの信頼とセキュリティを確保するうえで欠かせません。なお、CIBAフローでRARを使用するかどうかは任意です。
1
開始
エージェントのバックエンドは、ユーザーの承認が必要だと判断すると、Auth0の
/bc-authorize
エンドポイントにCIBAリクエストを送信します。このリクエストには、ユーザー
識別子と、 (authorization_details) パラメーターで指定する任意のRARペイロードが
含まれます。2
受領確認
Auth0は一意の
auth_req_idを返し、リクエストを受け付けたことを
直ちに通知します。3
ポーリング
エージェントのバックエンドは
auth_req_idを使ってAuth0の/token
エンドポイントへのポーリングを開始し、処理が完了したかどうかを確認します。4
ユーザーの同意
これと並行して、Auth0はユーザーの認証デバイスに通知 (プッシュ、SMS、メールなど) を送信し、
RARペイロードに含まれる詳細なコンテキストを表示します。ユーザーは
リクエストを承認または拒否します。
5
トークンの発行
ユーザーが承認すると、エージェントのバックエンドから
/tokenエンドポイントへの
次のポーリングリクエストが成功します。Auth0は必要なアクセストークンとIDトークンを
返し、エージェントは認可されたアクションを実行できるようになります。ユーザーの同意と通知チャネルの選択
Auth0はバックチャネルリクエストを受け取ると、ユーザーに承認を求める際にどの通知チャネルを使用するかを決定する必要があります。現在利用できるオプションは次のとおりです (優先度の高い順) ：- Auth0 Guardianのモバイルプッシュ通知：ユーザーの登録済みモバイルデバイスにモバイルプッシュ通知を送信します。認証と認可は、通知を受信したデバイス上で行われます。
- メール：ユーザーの検証済みアドレスにメールを送信します。メールにはリンクが記載されており、ユーザーがそのリンクを選択すると、ブラウザー上で認証と認可が行われます。
非同期認可のメール通知は有料のアドオン機能で、現在、Essentials、Professional、Enterpriseのすべてのプランで利用できます。詳細については、価格ページをご覧ください。
