2025/12/10

Auth0機能

スマホに通知、タップで承認。次世代の認証フロー「CIBA」をAuth0で実現する方法

概要

ECサイトで決済ボタンを押したら、手元のスマートフォンに「承認しますか？」と通知が届く。パスワードを入力することなく、タップひとつで安全に支払いが完了する──。そんなスマートな購買体験を、あなたのサービスでも実現できるとしたらどうでしょうか。

あるいは、コールセンターに問い合わせをした際、本人確認のためにオペレーターへ口頭で個人情報を伝える代わりに、手元のスマホを一度タップするだけで認証が済む。これは、顧客にとっても企業にとっても、より安全でスムーズなやり取りです。

このような「スマホに通知、タップで承認」という体験を実現するのが、今回ご紹介する次世代の認証フロー「CIBA（Client Initiated Backchannel Authentication）」です。

本記事では、このCIBAがどのような仕組みで、従来の認証方式と何が違うのかを解説します。さらに、主要なCIAMソリューションであるAuth0を用いて、この先進的な認証フローを実装するための具体的な設定手順やAPIリクエストの流れをステップバイステップでご紹介します。この記事を読めば、CIBAの基本を理解し、自社サービスへの応用を検討するための具体的な知識を得ることができるでしょう。

CIBAとは？「スマホで承認」を実現する仕組み

CIBAは、OpenID Foundationによって標準化された「クライアント主導のバックチャネル認証フロー（Client Initiated Backchannel Authentication）」の略称です。その技術的な特徴は、ユーザーのブラウザを介さずに認証を開始できる点にありますが、本質的な価値はユーザー体験の向上にあります。

「消費デバイス」と「認証デバイス」の分離

CIBAを理解する鍵は、「デカップルド（decoupled）認証」という考え方です。これは、ユーザーがサービスを利用する「消費デバイス」と、本人が認証操作を行う「認証デバイス」を分離することを指します。

消費デバイス (Consumption Device): サービス要求を開始するデバイス。コールセンターのオペレーターが使うPC、店舗のPOS端末、スマートスピーカーなどが該当します。
認証デバイス (Authentication Device): ユーザーが本人であることを証明するために操作するデバイス。通常はユーザーが所有するスマートフォンやタブレットが使われます。

図１：消費デバイスと認証デバイス

この仕組みこそが、「スマホに通知、タップで承認」という次世代の体験を支える核となります。ユーザーは目の前の端末（消費デバイス）から意識を離すことなく、普段から使い慣れた自分のスマホ（認証デバイス）で、きわめて自然に認証を完了できるのです。

なぜCIBAが必要なのか？具体的な利用シーン

この「スマホで承認」の仕組みは、特に従来のリダイレクト型認証が不向きな、以下のようなシナリオで真価を発揮します。

コールセンター：口頭確認から「スマホでタップ承認」へ
オペレーターが顧客のIDを入力し、顧客のスマートフォンへ認証要求を送信。顧客が手元で承認することで、パスワードなどを口頭で伝える必要なく、安全かつ迅速に本人確認が完了します。

CIBAの認証フロー概要

「スマホで承認」が、裏側でどのように動いているのか、その流れを見ていきましょう。

クライアントから認証要求を送信（①）
クライアントアプリケーション（例：コールセンターシステム）は、認証サーバーのバックチャネル認証エンドポイント（/bc-authorize）に対し、エンドユーザーを特定する情報（メールアドレスなど）を含んだリクエストを送信します。
認証サーバーが受付IDを返却（②）
認証サーバーはリクエストを受け付け、即座に auth_req_id（認証リクエストID）をクライアントアプリケーションに返却します。これは「受付番号」のような役割を果たし、以降の処理を追跡するために使われます
クライアントアプリケーションがトークンエンドポイントをポーリング（③）
クライアントアプリケーションはすぐにユーザー認証が終わるわけではないため、/token エンドポイントを一定間隔で呼び出し（ポーリング）、認証が完了したかどうかを確認し続けます。
ユーザー認証プロセス（スマホ通知）（④⑤⑥⑦）
認証サーバーはエンドユーザーの認証デバイス（スマホなど）に通知を送信します。エンドユーザーはモバイルアプリで同意内容を確認し、「承認」または「拒否」を選択します。
クライアントアプリケーションがトークンを取得（⑧⑨）
エンドユーザーが承認すると、認証サーバーは IDトークンやアクセストークンを生成します。クライアントアプリケーションはポーリングの結果としてこのトークンを取得し、ログイン処理や後続の業務フローを進めます。

Auth0で「スマホに通知、タップで承認」を実装する手順

前提条件

CIBA機能はAuth0 Enterpriseプランでのみ有効です。Professionalプランでは利用できませんが、22日間の無料トライアルで検証可能です。

CIBAをAuth0で利用するには、対象ユーザーが Auth0 Guardian アプリで多要素認証（MFA）のセットアップを完了していることが前提となります。

GuardianはAuth0公式のMFAアプリで、スマートフォンにインストールして利用します。
ユーザーが初回ログインする際、MFA登録のトリガーが走り、QRコードスキャンなどでセットアップを行います。
この登録が済んでいないユーザーには、CIBAによる「スマホに通知、タップで承認」が届きません。

それでは、実際にAuth0を利用してこのフローを実装する手順を見ていきましょう。

1. アプリケーションの設定

まず、Auth0のダッシュボードでCIBAを利用するアプリケーションを設定します。

Auth0ダッシュボードにログインし、「Applications」メニューから対象のアプリケーション（通常は "Regular Web Application" または "Machine to Machine Application"）を選択します。
「Settings」タブの下部にある「Advanced Settings」を開き、「Grant Types」タブに移動します。
「Client Initiated Backchannel Authentication (CIBA)」のチェックボックスをオンにして、CIBAを有効化します。

[図２：Auth0ダッシュボードのApplication設定画面、「Advanced Settings」 > 「Grant Types」セクション]

2.認証要求の送信

クライアントアプリケーションのサーバーサイドから、Auth0（認証サーバー）のバックチャネル認証エンドポイント（/bc-authorize）に認証要求（POSTリクエスト）を送信します。

[コードスニペット1：認証要求のcurlコマンド例]

curl --request POST \
  --url 'https://YOUR_DOMAIN/bc-authorize' \
  --header 'content-type: application/x-www-form-urlencoded' \
  --data-urlencode 'client_id=YOUR_CLIENT_ID' \
  --data-urlencode 'client_secret=YOUR_CLIENT_SECRET' \
  --data-urlencode 'scope=openid profile email' \
  --data-urlencode 'login_hint={ "format": "iss_sub", "iss": "https://YOUR_DOMAIN/", "sub": "auth0|USER_ID" }' \
  -- data-urlencode 'binding_message=Login request from Curl'

※binding_messageには英数字と + - _ . , : # のみ使用可能で、64文字までという制約があります。

成功すると、Auth0からauth_req_idを含むJSONレスポンスが返ってきます。

レスポンス例：

{
  "auth_req_id": "JlPUfyyTHcKEGoPfb5L5Ax...",
  "expires_in": 300,
  "interval": 5
}

3.エンドユーザーへの通知と承認

上記のリクエストが成功すると、Auth0はlogin_hintで指定されたエンドユーザーに対し、Auth0 Guardian（多要素認証アプリ）などを通じてプッシュ通知を送信します。エンドユーザーは内容を確認し、「承認」をタップします。

[図３：Auth0 Guardianの承認画面

注意: 2025年9月１日時点では、Auth0 Guardianのプッシュ通知には binding_message の内容は表示されません。

4.トークンの取得

クライアントアプリケーションはトークンエンドポイント（/oauth/token）を定期的にポーリングし、認証結果を確認します。

[コードスニペット2：トークンエンドポイントへのポーリングリクエスト例]

curl --request POST \
  --url 'https://YOUR_DOMAIN/oauth/token' \
  --header 'content-type: application/x-www-form-urlencoded' \
  --data-urlencode 'grant_type=urn:openid:params:grant-type:ciba' \
  --data-urlencode 'client_id=YOUR_CLIENT_ID' \
  --data-urlencode 'client_secret=YOUR_CLIENT_SECRET' \
  --data-urlencode 'auth_req_id=【ステップ2で取得したauth_req_id】'

エンドユーザーが認証を完了するまでは、以下のレスポンスが返ってきます。

{
    "error": "authorization_pending",
    "error_description": "The end-user authorization is pending"
}

認証が成功すると、IDトークンとアクセストークンを含むJSONが返却されます。

認証完了時のレスポンス例

{
  "access_token": "eyJz93a...k4laUWw",
  "id_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...",
  "expires_in": 86400,
  "scope": "openid profile email",
  "token_type": "Bearer"
}

実際のシステムでは、この IDトークンの署名を検証して正しいことを確認します。

結論・まとめ

本記事では、「スマホに通知、タップで承認」という次世代の認証フローを実現するCIBAについて、その仕組みからAuth0での具体的な実装方法までを解説しました。

CIBAは、サービスを利用する「消費デバイス」と、エンドユーザー本人が持つ「認証デバイス」を分離することで、従来は困難だったコールセンターやPOS端末、IoT機器など多様な環境で、極めてスムーズかつセキュアな認証体験を提供します。

ご紹介したように、Auth0を使えば、いくつかの設定とAPIリクエストによってこの強力なフローを実装することが可能です。この先進的な認証フローを正しく活用することで、顧客体験を損なうことなく、サービスの信頼性とセキュリティを一段上のレベルに引き上げることができるでしょう。

おわりに

「スマホに通知、タップで承認」という体験は、ユーザーにとって非常に魅力的です。Auth0を利用すれば、このCIBAフローをSDKの実装だけで比較的容易に組み込むことができる点も大きなメリットです。一方で、実運用においては堅牢なエラーハンドリングやユーザー通知のUXデザインといった観点で、ビジネス要件に沿った設計を行うことが不可欠です。

私たちのCIAM導入支援の経験上、こうした細部の設計がプロジェクトの成否を分けることも少なくありません。

もし、貴社が本記事で取り上げたような先進的な認証フローの導入をご検討されていたり、CIAM戦略全般に関する課題をお持ちであったりする場合には、私たちNTTコムオンラインの専門家がその道のりを支援し、ビジネス目標の達成をお手伝いします。どうぞお気軽にご相談ください。