クライアント起点バックチャネル認証 Flow

クライアント起点バックチャネル認証 Flow の仕組みを説明します。

クライアント起点バックチャネル認証 (CIBA) 機能を使用するには、Enterprise Plan または適切なアドオンが必要です。詳しくは、Auth0 Pricing を参照してください。

クライアント起点バックチャネル認証 (CIBA) Flow は、安全なバックチャネルリクエストを使用して、認証と認可を分離した形で実行できるようにする OpenID Foundation の標準です。CIBA フローは、リクエストを開始するデバイス (利用デバイス) と、ユーザーが認証に使用するデバイス (認証デバイス) が異なるユースケース向けに設計されています。

CIBA フローには、2 つのアクターが存在します。

• 開始ユーザー: 利用デバイスで認証または認可を開始する主体です。バックエンドアプリケーション、人間のユーザー (たとえば、カスタマーサービスアプリケーションのカスタマーサービス担当者) 、またはエンドユーザーに代わってタスクを実行する AI エージェントが該当します。
• 認可ユーザー: 認証デバイスで認証または認可のリクエストを受け取り、同意を行うエンドユーザーです。

認証と認可を利用デバイスから切り離すことで、クライアントアプリケーションはバックチャネルリクエストを使用して OpenID プロバイダーを直接呼び出せます。これにより、CIBA フローではクライアント認証に mTLS や Private Key JWT など、より安全な方法を使用できるため、セキュリティが向上します。

​

ユースケース

CIBA フローの一般的なユースケースには、次のようなものがあります。

• AI エージェントが human-in-the-loop 承認を利用して、ユーザーが依頼したアクションを完了するための許可をユーザーに求める。
• ユーザーがコールセンターに電話をかけ、対応中のオペレーターが自身のコンピューターで発信者の個人情報にアクセスしたい場合。発信者は、たとえば自分のスマートフォンに届くプッシュ通知を承認することで、これに同意できます。
• ユーザーが、街中で借りる自転車や小売店のキオスクなど、入力機能が限られたデバイスにアクセスしたい場合。
• ユーザーが比較的安全性の低いデバイスで機微なトランザクションを開始し、より安全なデバイスでそのトランザクションを承認したい場合。たとえば、個人用の携帯電話に届くプッシュ通知を承認して、支払いや個人情報の変更を承認することがあります。

​

通知チャネル

Auth0 は、CIBA で次の通知チャネルをサポートしています。

• Auth0 Guardian モバイルプッシュ通知: すべての Enterprise プラン で利用できます。ユーザーは登録済みのモバイルデバイスでプッシュ通知を受信し、認証またはトランザクションの詳細の確認を行います。認証と認可は、そのプッシュ通知を受信した認証デバイス上で実行されます。CIBA でモバイルプッシュ通知を有効にする方法は次のとおりです。
  • Auth0 Guardian アプリ
  • Auth0 Guardian SDK と統合されたカスタムアプリ
• メール通知: 有料プラン のアドオンとして利用できます。ユーザーは、確認済みのメールアドレス宛てにメールを受信します。メールにはリンクが含まれており、認証と認可はブラウザー経由で行われます。

デフォルトでは、Auth0 は CIBA フローで Guardian プッシュ通知を使用し、これを推奨しています。Guardian プッシュ通知は、フィッシング攻撃の影響を受けやすいメールなどの他のチャネルよりも安全です。CIBA フローでメール通知を使用するには、明示的に有効にする必要があります。

​

仕組み

次の図は、CIBA フローのエンドツーエンドの流れを示しています。

1. クライアントアプリケーションまたは利用デバイスが、ユーザーの認証または認可を要求します。
2. クライアントアプリケーションのバックエンドが、/bc-authorize エンドポイントに POST リクエストを送信します。
3. Auth0 は POST リクエストを受信し、認証デバイスに通知を送信します。
4. 認証デバイスは Auth0 から認可の詳細を取得し、エンドユーザーに表示します。
5. エンドユーザーは、リクエストに関するコンテキスト情報を含む認可の詳細を確認します。
6. エンドユーザーが認証デバイス上で応答すると、認証デバイスはその応答を Auth0 に送信します。
7. クライアントアプリケーションのバックエンドが /token エンドポイントをポーリングし、CIBA フローの完了後に適切なトークンを受け取ります。

CIBA フローは 1 回限りの非同期ユーザー認証および認可に使用されるため、アプリケーションによる API リソースへのアクセスに対するユーザーの同意を含むグラントは、CIBA では作成も保存もされません。後でユーザーが別の認証フローを使用して認証し、そのフローで、以前 CIBA で同意したものと同じスコープを要求した場合、Auth0 にはその同意の記録がありません。そのため、ユーザーは再度同意を求められます。

​

エンティティの制限

CIBA フローには、次の制限があります。

• テナントごとに、1 分あたり最大 500 件の CIBA リクエストを作成できます。
• テナントごとに、同時に保留できる CIBA リクエストは最大 5000 件です。保留中の CIBA リクエストとは、開始されているものの、まだユーザーからの応答を受け取っていないリクエストを指します。ユーザーからの応答がないまま CIBA リクエストの有効期限が切れた場合でも、最大 24 時間はこの 5000 件の上限に引き続きカウントされることがあります。

​

はじめに

読む項目…	学べること…
クライアント起点バックチャネル認証を設定する	アプリケーションの CIBA グラントタイプと通知チャネルを設定する方法。
CIBA でモバイルプッシュ通知を使用する	モバイルプッシュ通知を使用して、CIBA フローでユーザーを認証する方法。
CIBA でメール通知を使用する	メール通知を使用して、CIBA フローでユーザーを認証する方法。
CIBA を使用したユーザー認可	Rich Authorization Requests (RAR) を伴う CIBA フローを使用して、ユーザーを認可する方法。