クライアントが開始するバックチャネル認証フロー

クライアントが開始するバックチャネル認証（CIBA）フローは、分離型認証フローに関するOpenID Foundationの標準です。ソリューション開発でこの標準を使用することにより、IDやアクセストークンを受け取るデバイス、または消費デバイス上で直接ログインするのではなく、別の認証デバイス上でログインする認証フローを構築できます。

以下のユースケースにCIBAフローを使用できます。

• あるユーザーがコールセンターに電話をかけてきた際に、それに対応するエージェントが、そのユーザーのコンピューターにある個人情報にアクセスできるようにする場合。電話をかけてきたユーザーは、携帯電話でプッシュ通知を承認することで、この操作に同意できます。

• ユーザーが、街中でレンタルする自転車や小売店のキオスクなど、入力機能が限られているデバイスにアクセスしたい場合。

• ユーザーが、比較的セキュリティの低いデバイスで機密性の高いトランザクションを開始し、それよりもセキュリティの高いデバイスでそのトランザクションを承認する場合。例えば、個人の携帯電話にプッシュ通知が届いた後で、機密性の高いトランザクションを承認するなどということが考えられます。

CIBAフローはログインや認証の処理について、クライアントアプリケーションがブラウザーでユーザーをリダイレクトすることに依存しません。その代わりに、クライアントアプリケーションがバックチャネル要求を通して直接OpenIDプロバイダーを呼び出し、認証フローを開始します。

CIBAフローは付与を作成または更新しません。そのため、クライアントアプリケーションがCIBAフロー経由で特定のスコープを要求した場合、ユーザーが同意すれば、そのスコープは付与として保存されません。つまり、設定されている場合、同じスコープを要求する別の認証フロー（付与タイプ）では、ユーザーにOAuthの同意を再度求める必要があります。

CIBAフローにはセッション（ブラウザークッキー）がないため、CIBAチャレンジの前にユーザーが認証を受ける必要はありません。CIBAチャレンジの前にすでにユーザーが認証を受けている場合、既存のセッションには影響しません。

下の図はCIBAフローを示しています。

1. クライアントアプリケーションまたは消費デバイスがユーザー認証を要求します。

2. クライアントアプリケーションのバックエンドが/bc-authorizeエンドポイントにPOST要求を送信します。

3. Auth0がこのPOST要求を受信し、認証デバイスにプッシュ通知を送信します。

4. 認証デバイスはAuth0から同意の詳細を取得し、エンドユーザーに提示します。

5. エンドユーザーは認証デバイス上で応答を入力し、認証デバイスからAuth0にユーザーの応答が送信されます。

6. クライアントアプリケーションのバックエンドが/tokenエンドポイントをポーリングし、CIBAフローが完了すると適切なトークンを受け取ります。