Skip to content

MS_CIBA

Jump to bottom
nishi_74322014 edited this page Sep 11, 2026 · 2 revisions

CIBA(Client Initiated Backchannel Authentication)

概要

CIBA は、シーバと読み「新たなユーザ認証体験」のベースとなりうるものらしい。

  • デバイスを「サービス利用」と「ユーザー認証」に分離することにより
    ユーザー認証体験の可能性が広がる。

  • 以下の両分野が CIBA の標準化を進めている。

    • モバイル
    • 金融 API（FAPI）

※ OpenID Foundation の MODRNA（マッダーヌァ）WG（mobile 系の WG）で策定。
　 MODRNA : Mobile Operator Discovery, Registration & autheNticAtion.

CIBA

用語

基本的な用語は、OAuth2/OIDC と変わらないが、以下が追加されている。

Consumption Device (CD)

CIBA Flow ユーザ（なんでも OK）だが、
基本的に Confidential Client(RP) を経由する。

Authentication Device (AD)

  • 認証デバイス
    EndUser（≒ Resource Owner）の所有物として認証されているデバイス。
  • Public であるが、Public "Client" ではない。
    • 要するに、従来のOAuth2 の登場人物の範囲外
    • 従って、CIBA の仕様上でも、仕様の詳細は語られない。
  • 認証デバイスへの通知には、スマホのプッシュ通知を使う想定。

BA EP（バックチャネル認証エンドポイント）

  • Authorization Server に追加される新たな認証エンドポイント。
  • Authorization Server は CD から RP 経由で認証リクエストを受付け、
  • 非同期で、CD に RP 経由で認証レスポンスを返す（Polling / Ping / Push）。

その他、用語の差異

  • 認可リクエストではなく認証リクエスト
  • しかし、AuthZ は AuthZ。AuthN ではない。
  • Resource Owner ではなく EndUser（ユーザ）

ユースケース

以下のようなユースケースがある。

  • 銀行窓口での顧客認証
  • コールセンタにおける発信者認証
  • ユーザのスマホで POS 端末の支払い

ポイント

CIBA のユースケースのポイントは、

  • 認証リクエストする人と、
  • スマホの認可 or 拒否ボタンを押下する人が、

違うコトであるもよう。

補足（この一点が本質）: 「要求する人と承認する人が別」という点が、
既存のフローとの決定的な違いである。

場面 要求する人 承認する人
通常の OAuth 本人（ブラウザ） 本人（同じブラウザ）
Device Grant 本人（TV） 本人（別端末）
CIBA 窓口係員・コールセンタ職員・店員 顧客本人（自分のスマホ）

「銀行の窓口で、係員が端末を操作し、顧客が自分のスマホで承認する」
という業務が、これで初めて標準的に実装できるようになった。

同一人物の場合

  • 2FA 的な意味合いも無いので微妙。
    （CIBA の AD を 2FA に転用することは可能だが）
  • パスワードレス的な意味も無い。
    • 仕様に詳しく書かれていないが、AD であっても認証処理は行うため。
    • Authorization Server と AD が FIDOや
      WebAuthn認証に対応していれば別だが。

OAuth 2.0 Device Authorization Grantとの違い。

CD, AD の分離

認可リクエストを行う人と、認可 or 拒否ボタンを押下する人が違う。

Device Grant CIBA
要求先 Device Grant 独自エンドポイント BA EP（バックチャネル）
ユーザーへの伝達 画面に URI とコードを表示 AD へプッシュ通知
ユーザーの動線 ユーザーが自分で URI を開く 通知をタップして AD へ
要求者と承認者 同一人物 別人でもよい
事前のユーザー識別 不要 必要（login_hint 等）

事前のユーザー識別

Client の、事前のユーザー識別は必要になる。

  • Device Grant: 不要（ユーザは 1 名）
  • CIBA: 必要（ユーザは 2 名）
    • CD: 要求時、Client が Authorization Server に認証対象ユーザを通知する。
      Authorization Server は、認証対象ユーザの AD を特定して、プッシュ通知を行う。
    • AD: 仕様に詳しく書かれていないが、AD でも認証が必要になる。

詳細（フロー）

フローを見ると、Redirect による OAuth ダンスではなく、
Device Grant風で、
デバイスへの通知に SMS ではなく、スマホのプッシュ通知を使用している感じの仕様っポイ。

  • 従来の OAuth ダンスは「Redirect フロー」と言うらしい。
  • CIBA は「Decoupled フロー」と言うらしい（decoupled and back-channel）。
    • decoupled: Client（Web アプリ）と認証デバイス（≒ スマホ）に分離。
    • back-channel: BA EP（バックチャネル認証エンドポイント）

認可エンドポイント

認証リクエストを受け付けて直ちにレスポンスする（以後、非同期的に処理）。

認可リクエスト

ユーザ特定が必要になるので、以下のパラメタのどれか一つを
ヒントとしてサーバに渡す。

パラメタ 内容
login_hint エンドユーザーを識別する e-mail、TEL、sub、userName、userId など
login_hint_token エンドユーザーを識別するためのトークン（署名が必要 ≒ JWS）
id_token_hint エンドユーザーを識別するための ID トークン（iss と aud を検証、期限切れも処理）

その他のパラメタ。

パラメタ 内容
scope OAuth 2.0 と同じ。CIBA では openid スコープが必須
client_notification_token Ping / Push モードの Callback URI に渡す Bearer Token。1024 文字以下（128bit 以上の乱数）
binding_message CD と AD の両方の画面に表示する短い文字列（後述）
acr_values（任意） 認証コンテキスト クラス値
requested_expiry（任意） auth_req_id の expires_in 値を要求する正の整数 
POST /bc-authorize HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

scope=openid%20email%20example-scope&
client_notification_token=8d67dc78-7faa-4d41-aabd-67707b374255&
binding_message=W4SCT&
login_hint_token=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

署名有りの場合は Request オブジェクトを使用する
（iss, aud, exp, iat, nbf, jti の追加が必要。
JWSのみで JWEはサポートされない）。

認可レスポンス

パラメタ 要否 内容
auth_req_id 必須 プッシュ通知 → 認証ボタン押下を識別するトランザクション識別子
expires_in 必須 auth_req_id、user_code の有効期間（秒）
interval 任意 Polling / Ping の間隔
binding_message 任意 CD と AD の画面に「表示」する短い文字列
user_code 任意 未認証状態で送信可能なプッシュ通知技術のために用意。AD の通知に表示し、応答で入力させる 
{
  "auth_req_id": "1c266114-a1be-4252-8ad1-04986c5b9ac1",
  "expires_in": 3600,
  "interval": 2
}

失敗時のエラー。

ステータス エラー
400 Bad Request invalid_request / invalid_scope / expired_login_hint_token / unknown_user_id / unauthorized_client / missing_user_code / invalid_user_code / invalid_binding_message
401 Unauthorized invalid_client
403 Forbidden access_denied

補足（binding_message が安全性の要）: CIBA は
**「要求者と承認者が別」**であるがゆえに、
「今スマホに来た承認要求は、本当に目の前の取引のものか？」という
問いが常につきまとう。

binding_message（例: W4SCT）を
CD の画面と AD の通知の両方に表示し、
ユーザーに一致を目視確認させることで、これを解決する。

[窓口の端末]              [顧客のスマホ]
 確認コード: W4SCT   ⇔    「W4SCT の取引を承認しますか？」

これが無いと、攻撃者が同時に別の要求を投げて、
ユーザーに誤って承認させる（承認要求のすり替え）ことが可能になる。
実装時に省いてはならない項目である。

通知 → 認証

Authorization Server が AD にプッシュ通知を行い、
ユーザーが AD 上で認証・同意する。
（AD 側の認証方式は CIBA の仕様範囲外）

Tokenエンドポイント

auth_req_id を使って access_token を取得する。
CIBA には3 つのモードがある。

モード Client への通知方法
Poll Client が Token エンドポイントを繰り返し問い合わせる（interval 秒間隔）
Ping Authorization Server が Client の通知エンドポイントに「準備できた」と通知し、Client が Token を取りに行く
Push Authorization Server が Client の通知エンドポイントにトークンを直接送る 
POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=urn:openid:params:grant-type:ciba
&auth_req_id=1c266114-a1be-4252-8ad1-04986c5b9ac1

Polling 中のエラー コードは
Device Grantと同様
（authorization_pending / slow_down / access_denied / expired_token）。

補足（Push モードの制約）: Push モードは
Authorization Server が Client にトークンを直接送るため、
Client がインターネットから到達可能なエンドポイントを持つ必要がある。
FAPI の CIBA プロファイルでは、
セキュリティ上の理由から Push モードが禁止されている
（トークンが Client の意図しないタイミングで飛んでくるため）。

実装の順としては Poll が最も簡単で、
スケールが問題になったら Ping を検討する、という流れになる。

FAPI

CIBA は FAPI の "Part X"（CIBA Profile）としても
プロファイルが定義されている。

  • Authorization Server / Client 双方に追加要件が課される。
  • binding_message の必須化、Push モードの禁止など。

参考

Tags: 移行, IT国際標準, 認証基盤, クレームベース認証, OAuth, OpenID Connect

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally