- 追加された行はこの色です。
- 削除された行はこの色です。
「[[マイクロソフト系技術情報 Wiki>http://techinfoofmicrosofttech.osscons.jp/]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。
-[[戻る>OpenID Connect]]
-戻る
--[[OAuth 2.0 拡張]]
--[[OpenID Connect]]
* 目次 [#x774c2a7]
#contents
*概要 [#ta7069e9]
「新たなユーザ認証体験」のベースとなりうるものらしい。
CIBAは、シーバと読み「新たなユーザ認証体験」のベースとなりうるものらしい。
-デバイスを
--サービス利用
--ユーザー認証
>に分離することによりユーザー認証体験の可能性が広がる。
-以下の両分野がCIBAの標準化を進めている。
--モバイル
--金融API
>※ OpenID Foundation の MODRNA（マッダーヌァ） WG (mobile系 の WG)で策定。~
MODRNA : Mobile Operator Discovery, Registration & autheNticAtion.
*詳細 [#a3ba36e2]
**イメージ [#z474bd0a]
#ref(ciba.png,left,nowrap,CIBA)
**用語 [#afb03bc6]
-基本的な用語は、OAuth2/OIDCと変わらない。
-その他、以下の用語が追加されている。
--Consumption Device (CD)~
***Consumption Device (CD) [#gfdf9430]
CIBA Flow ユーザ（なんでもOK）だが、~
基本的にConfidential Clientを経由する。
基本的にConfidential Client(RP)を経由する。
--Authentication Device (AD) ~
認証デバイスでスマホのプッシュ通知を使う想定。
***Authentication Device (AD) [#n4cd6119]
-認証デバイス~
EndUser（≒ Resource Owner）の~
所有物として認証されているデバイス。
--BA EP（バックチャネル認証エンドポイント）~
AuthZ（IdP/STS）に追加される新たなエンドポイント。
-Publicであるが、Public "Client"ではない。
--要するに、従来の[[OAuth2の登場人物>OAuth#zb38b595]]の範囲外
--従って、CIBAの仕様上でも、仕様の詳細は語られない。
**フロー概要 [#mb14e0e5]
フローを見ると、RedirectによるOAuthダンスではなく、[[OAuth 2.0 Device Flow>OAuth 2.0 拡張#l14e2ae9]]風で、~
デバイスへの通知にNB（＝スマホのプッシュ通知）を使用している感じの仕様っポイ。
-認証デバイスへの通知には、スマホの[[プッシュ通知>#v6eb33df]]を使う想定。
***BA EP（バックチャネル認証エンドポイント） [#u44eb79c]
フロントエンドからリーチしない~
Confidential Client(RP)経由の~
バックチャネルと言う事だろうか。
-AuthZ（IdP/STS）に追加される新たな認証エンドポイント。
-AuthZは[[CD>#gfdf9430]]からRP経由で認証リクエストを受付け、
-非同期で、[[CD>#gfdf9430]]にRP経由で認証レスポンスを返す(Polling / Ping / Push)。
***その他、用語の差異 [#c4cd478c]
-認可リクエストではなく認証リクエスト
-しかし、AuthZ は AuthZ。AuthNではない。
-Resource Owner ではなく EndUser（ユーザ）
**ユースケース [#n46fc07e]
以下のようなユースケースがある。
-銀行窓口での顧客認証
-コールセンタにおける発信者認証
-ユーザのスマホで POS 端末の支払い
***ポイント [#z9c24ef2]
CIBAのユースケースのポイントは、
-認証リクエストする人と、
-スマホの認可 or 拒否ボタンを押下する人が、
違うコトであるもよう。
***同一人物の場合 [#i7e625ea]
-2FA的な意味合いも無いので微妙。~
（CIBAの[[AD>#n4cd6119]]を2FAに転用することは可能だが）
-パスワードレス的な意味も無い。
--仕様に詳しく書かれていないが、[[AD>#n4cd6119]]であっても認証処理は行うため。
--AuthZ と [[AD>#n4cd6119]] が [[FIDO]] や [[WebAuthn>Web Authentication API]]認証に対応していれば別だが。
**[[OAuth 2.0 Device Flow]]との違い。 [#se69e4c7]
***[[CD>#gfdf9430]], [[AD>#n4cd6119]] の分離 [#c08888c1]
認可リクエストを行う人と、認可 or 拒否ボタンを押下する人が違う。
-[[OAuth 2.0 Device Flow]]
--Device は、
---IdP/STS（OP）にDevice Flow独自エンドポイントに認証リクエストを行う。
---認証レスポンスから受け取ったURIとCodeを画面に表示する（[[QRコード>https://dotnetdevelopmentinfrastructure.osscons.jp/index.php?QR%E3%82%B3%E3%83%BC%E3%83%89]]やNFCなども利用可能）。
--ユーザは、URIでIdP/STS（OP）に接続し、対話する（認可 or 拒否）。~
（仕様に詳しく書かれていないが、AuthZ Serverに追加した画面に認証後にアクセス）
--上記の後、Device は、TokenリクエストをPollingする。
-CIBA
--[[CD>#gfdf9430]] は、IdP/STS（OP）にCIBA独自バックチャネルに認証リクエストを行う。
--IdP/STS（OP）が [[AD>#n4cd6119]] を用いて要求を認証するユーザに[[プッシュ通知>#v6eb33df]]する。
--ユーザは、[[プッシュ通知>#v6eb33df]]をトリガにして [[AD>#n4cd6119]] に遷移して対話する（認可 or 拒否）。~
（仕様に詳しく書かれていないが、[[PKCE>OAuth PKCE]]などで認証処理を行う必要がある）
--上記の後、[[CD>#gfdf9430]] は、Tokenリクエストを[[Pollingなど>#qe881045]]で行う。
***事前のユーザー識別 [#refe6482]
Clientの、事前のユーザー識別は必要になる。
-[[OAuth 2.0 Device Flow]]
--不要（ユーザは１名）
--認可 or 拒否ボタンを押下する画面を~
参照するためにAuthZにログインしたユーザが唯一のユーザ
-CIBA~
必要（ユーザは２名）
--[[CD>#gfdf9430]]
---要求時、Client が IdP/STS（OP）に認証対象ユーザを通知する。
---IdP/STS（OP）は、認証対象ユーザの[[AD>#n4cd6119]]を特定 して、[[プッシュ通知>#v6eb33df]]を行う。
--[[AD>#n4cd6119]]~
仕様に詳しく書かれていないが、[[AD>#n4cd6119]]でも認証が必要になる。
*詳細（フロー） [#a3ba36e2]
フローを見ると、RedirectによるOAuthダンスではなく、[[OAuth 2.0 Device Flow]]風で、~
デバイスへの通知にSMSではなく、スマホの[[プッシュ通知>#v6eb33df]]を使用している感じの仕様っポイ。
-従来の従来のOAuthダンスは「Redirect フロー」と言うらしい。
-CIBA は「Decoupled フロー」と言うらしい（decoupled and back-channel）。
--decoupled：~
Client（Webアプリとスマホ）と認証デバイス（≒スマホ）に分離。~
其々のスマホを、Consumption Device (CD) 、Authentication Device (AD)と言うらしい。
--decoupled：
---Client（Webアプリ）と認証デバイス（≒スマホ）に分離。
---其々のスマホを、[[Consumption Device (CD) 、Authentication Device (AD)>#afb03bc6]]と言う。
--back-channel：~
AuthZはback-channelで認証要求を受付け、認証結果を返す(Poll / Ping / Push)。
[[BA EP（バックチャネル認証エンドポイント）>#afb03bc6]]
**認証リクエスト・レスポンス [#k24365ee]
-認可リクエストではないことに注意。
-認証リクエストを非同期的に受け付けてレスポンスする。
**認可エンドポイント [#k24365ee]
認証リクエストを受け付けて直ちにレスポンスする（以後、非同期的に処理）。
***ユーザ特定 [#y479f65b]
クライアントが認可サーバのバックチャネル認可エンドポイントにリクエストを投げる際、
***認可リクエスト [#y479f65b]
-ユーザ特定が必要になるので、
--クライアントがAuthZの認証リクエストを投げる際、~
以下のパラメタのどれか一つをヒントとしてサーバに渡す。
---login_hint_token
---id_token_hint
---login_hint
-以下のパラメタのどれか一つをヒントとしてサーバに渡す。
--login_hint_token
--id_token_hint
--login_hint
--サーバはそのヒントを元に認証対象ユーザを特定する。
-サーバはそのヒントを元に認証対象ユーザを特定する。
-パラメタ
***認証要求の正当性 [#z8711778]
認証デバイスに飛んできた認証要求が正当なものかどうかを確認するためのパラメタ
--scope
---OAuth2.0のscopeと同じ。
---CIBAではopenidスコープ値が含まれている必要がある。
-Binding Message
--かなり短い単純な文字列であることが想定されている。
--Biding MessageをADにそのまま表示する
--client_notification_token
---Ping / Pushモードの際のCallback URIに渡すBearer Token
---1024文字以下（128bit以上で、160bit前後）の乱数を含む自己完結型
-user_code
--acr_values (OPTIONAL)~
[[認証コンテキスト クラス>OpenID Connect - Authentication Context Class Reference]]値
**ユーザ認証 [#r0e5aee2]
認証デバイスでスマホのプッシュ通知を使う想定。
--各種ヒント (OPTIONAL)
**Tokenリクエスト・レスポンス [#ae7a371f]
-認証リクエストの結果とTokenレスポンスを返す。
-認証リクエストとの繋がりは非同期的なので、~
Poll / Ping / Pushの3つの方式がある。
---login_hint~
エンドユーザーを識別するe-mail、TEL、sub、userName、userIdなど
---login_hint_token~
エンドユーザーを識別するためのトークン~
（署名が必要≒JWS）
---id_token_hint~
エンドユーザーを識別するためのIDトークン~
（JWS or JWEでissとaudを検証、期限切れも処理）
--requested_expiry (OPTIONAL)~
auth_req_idのexpires_in値を要求できるようにする正の整数。
-クライアント認証方法
--client_idや、[[JWT bearer token authorizationグラント種別]]のclient_assertionおよびclient_assertion_type。
--推奨は、公開鍵暗号で、署名有り認可リクエスト（[[Requestオブジェクト>OpenID Connect - Requestオブジェクト]]）を使用する場合は、そのものの検証でOK。
-リクエスト例
--署名無し
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オブジェクト>OpenID Connect - Requestオブジェクト]]を使用
---Request自体
POST /bc-authorize HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
request=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
---[[Requestオブジェクト>OpenID Connect - Requestオブジェクト]]~
別途、iss, aud, exp, iat, nbf, jtiの追加が必要（JWSのみでJWEはサポートされない）。
{
"iss": "s6BhdRkqt3",
"aud": "https://server.example.com",
"exp": 1537820086,
"iat": 1537819486,
"nbf": 1537818886,
"jti": "4LTCqACC2ESC5BWCnN3j58EnA",
"scope": "openid email example-scope",
"client_notification_token": "8d67dc78-7faa-4d41-aabd-67707b374255",
"binding_message": "W4SCT",
"login_hint_token": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
}
***認可レスポンス [#z8711778]
-パラメタ
--auth_req_id
---必須。
---[[プッシュ通知>#v6eb33df]] → 認証ボタン押下を識別するトランザクション識別子。
---1024文字以下（128bit以上で、160bit前後）の乱数を含む自己完結型
--expires_in
---必須
---auth_req_id、user_codeの有効期間（秒）。
--interval
---オプション
---Polling / Pingの間隔
--認証デバイスに飛んできた認証要求が~
正当なものかどうかを確認するためのパラメタを返す。
---binding_message (OPTIONAL)~
・かなり短い単純な文字列であることが想定されている。~
・Biding Messageを[[CD>#gfdf9430]]と[[AD>#n4cd6119]]の画面に「表示」する。~
・比較的短く、プレーンテキスト文字の限られたセットを使用する
---user_code (OPTIONAL)~
・未認証状態で送信可能な[[プッシュ通知>#v6eb33df]]技術のために用意されている。~
・認証状態でのみ利用可能な[[プッシュ通知>#v6eb33df]]の場合、使用しないを選択可能。~
・backchannel_user_code_parameterがtureの場合、configとして必須となる。~
・[[AD>#n4cd6119]]の[[プッシュ通知>#v6eb33df]]に表示し、応答で入力させる。
-レスポンス例
--成功
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
{
"auth_req_id": "1c266114-a1be-4252-8ad1-04986c5b9ac1",
"expires_in": 3600,
"interval": 2
}
--失敗
---HTTP/1.1 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
Content-Type: application/json
{
"error": "unauthorized_client",
"error_description": "The client 'client.example.org' is not allowed to use CIBA."
}
---HTTP 401 Unauthorized
Content-Type: application/json
{
"error": "invalid_client",
"error_description": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
}
---HTTP 403 Forbidden
Content-Type: application/json
{
"error": "access_denied",
"error_description": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
}
***エラーの返却 [#ra040afb]
-POSTのJSON返却なので、[[Tokenエンドポイントのレスポンス（失敗）>#z70c2acf]]と同じ。
-以下のレスポンスは、user_codeを要求するCIBAで追加されたエラー・レスポンスらしい。
HTTP/1.1 400 Bad Request
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"error":"missing_user_code"
}
**通知->認証 [#r0e5aee2]
***通知 [#ree84563]
特定した認証対象ユーザのスマホに[[プッシュ通知>#v6eb33df]]を送信する。
-binding_messageを表示する。
-[[CD>#gfdf9430]]から指定された場合は、user_codeを入力させる。
***認証 [#p4811805]
PKCE認証などして、認可 or 拒否ボタン押下で、結果をIdP/STS（OP）に伝える（？）
**Tokenエンドポイント [#ae7a371f]
-上記の識別子を使用してTokenリクエストする。
-これにより、認証リクエストの結果とTokenレスポンスを返す。
-認証リクエストとの繋がりは非同期的なので、以下の、Polling / Ping / Pushの3つの方式がある。
***Tokenリクエスト [#td76b143]
-概要
--認可リクエストの成功を確認した後、TokenリクエストのPolling / Pingを始める。
--Pushの場合は、Pushをトリガにして、動き出す（しかし、結局、Client 側は待機している）。
-パラメタ
--grant_type=urn:openid:params:grant-type:ciba
--auth_req_id
-リクエスト例
POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
grant_type=urn%3Aopenid%3Aparams%3Agrant-type%3Aciba
&auth_req_id=1c266114-a1be-4252-8ad1-04986c5b9ac1
***Tokenレスポンス [#z70c2acf]
-成功~
[[OIDC>OpenID Connect#q4d3f512]]の認可レスポンス（成功）と同じ。
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
{
"access_token": "G5kXH2wHvUra0sHlDy1iTkDJgsgUO1bN",
"token_type": "Bearer",
"refresh_token": "4bwc0ESC_IAhflf-ACC_vjD_ltc11ne-8gFPfA2Kx16",
"expires_in": 3600,
"id_token": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
}
-失敗~
[[OAuth 2.0>OAuth#n037bd41]]の認可レスポンス（失敗）に以下のパラメタを追加
--パラメタ（≒エラーコード）
---authorization_pending~
認可リクエストは保留中
---slow_down~
"authorization_pending"の変形で~
Polling間隔を5秒遅らせろの意味。
---access_denied~
Resource Owner（EndUser）は、承認要求を拒否。
---expired_token~
auth_req_id、user_codeの有効期限が切れた。
---unauthorized_client~
PushモードのためCIBAでのTokenリクエストは不可。
--レスポンス例~
・・・
***ポイント [#qe881045]
-非同期方式
--Poll~
Client は IdP/STS（OP）の Token Endpoint を~
認証の識別子と共にPollingして応答を受け取る。
+--------+ +--------+
| | | |
| |<---(1) CIBA Request-------------------------->| |
| | | |
| | +--------+ | |
| | | | | |
| Client | | AD |<--(2) User interactions---------->| OP |
| | | | | |
| | +--------+ | |
| | | |
| |----(3a) CIBA Polling Request----------------->| |
| |<---(3b) CIBA Polling Response-----------------| |
| | ... | |
| |----(3a) CIBA Polling Request----------------->| |
| |<---(3b) CIBA Polling Response-----------------| |
| | | |
+--------+ +--------+
--Ping~
事前に Client が登録しておいた Callback URI に対して~
IdP/STS（OP）が認証の識別子と共に通知用のリクエストを送る。
+--------+ +--------+
| | | |
| |<---(1) CIBA Request-------------------------->| |
| | | |
| | +--------+ | |
| | | | | |
| Client | | AD |<--(2) User interactions---------->| OP |
| | | | | |
| | +--------+ | |
| | | |
| |<---(3) CIBA Ping Callback---------------------| |
| | | |
| |----(4a) CIBA Token Request------------------->| |
| |<---(4b) CIBA Token Response-------------------| |
+--------+ +--------+
---以下の成功のレスポンスを受け取り、Bearerが、~
無効な場合、HTTP 204 No Content or HTTP 200 OK をレスポンス。~
無効な場合、HTTP 401 Unauthorized をレスポンス。
POST /cb HTTP/1.1
Host: client.example.com
Authorization: Bearer 8d67dc78-7faa-4d41-aabd-67707b374255
Content-Type: application/json
{
"auth_req_id": "1c266114-a1be-4252-8ad1-04986c5b9ac1"
}
---以下の失敗のレスポンスを受け取り、Bearerが、~
無効な場合、HTTP 204 No Content or HTTP 200 OK をレスポンス。~
無効な場合、HTTP 401 Unauthorized をレスポンス。
POST /cb HTTP/1.1
Host: client.example.com
Authorization: Bearer 8d67dc78-7faa-4d41-aabd-67707b374255
Content-Type: application/json
{
"auth_req_id": "1c266114-a1be-4252-8ad1-04986c5b9ac1",
"error": "access_denied" or "expired_token" or "transaction_failed",
"error_description": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
}
---成功のレスポンスの後、Client は Tokenリクエストを行いTokenレスポンスを取得する。
---良く解らないが、Pingで構成されたClientはPollingも可能らしい。
--Push
---事前に Client が登録しておいた Callback URI に対して~
IdP/STS（OP）がトークンを含むリクエストを送る。
+--------+ +--------+
| | | |
| |<---(1) CIBA Request-------------------------->| |
| | | |
| | +--------+ | |
| | | | | |
| Client | | AD |<--(2) User interactions---------->| OP |
| | | | | |
| | +--------+ | |
| | | |
| |<---(3) CIBA Push Callback---------------------| |
| | | |
+--------+ +--------+
---Tokenレスポンス・ライクなレスポンスが返り、Bearerが、~
無効な場合、HTTP 204 No Content or HTTP 200 OK をレスポンス。~
無効な場合、HTTP 401 Unauthorized をレスポンス。
POST /cb HTTP/1.1
Host: client.example.com
Authorization: Bearer 8d67dc78-7faa-4d41-aabd-67707b374255
Content-Type: application/json
{
"auth_req_id": "1c266114-a1be-4252-8ad1-04986c5b9ac1",
"access_token": "G5kXH2wHvUra0sHlDy1iTkDJgsgUO1bN",
"token_type": "Bearer",
"refresh_token": "4bwc0ESC_IAhflf-ACC_vjD_ltc11ne-8gFPfA2Kx16",
"expires_in": 3600,
"id_token": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
}
---id_tokenを検証する（改ざんされていないか確認）。~
urn:openid:params:jwt:claim:auth_req_idの一致と、~
at_hashを使用したaccess_token検証~
rt_hashを使用したrefresh_token検証
{
"iss": "https://server.example.com",
"sub": "248289761001",
"aud": "s6BhdRkqt3",
"email": "janedoe@example.com",
"exp": 1537819803,
"iat": 1537819503,
"at_hash": "Wt0kVFXMacqvnHeyU0001w",
"urn:openid:params:jwt:claim:rt_hash": "sHahCuSpXCRg5mkDDvvr4w",
"urn:openid:params:jwt:claim:auth_req_id":
"1c266114-a1be-4252-8ad1-04986c5b9ac1"
}
-[[PPID>OpenID Connect#m3999d6f]]の利用（subject_type が pairwiseのとき）
--Polling / Pingモード
---PPID計算のセクター識別子としてjwks_uriを使用する。
---故に、登録フェーズでjwks_uriを提供する必要がある。
---sector_identifier_uriを提示する場合、ココに、jwks_uriを含める。
---jwks_uriの妥当性はクライアント認証を用いることで検証可能。
--Pushモード
---PPID計算のセクター識別子としてbackchannel_client_notification_endpointを使用する。
---sector_identifier_uriを提示する場合、ココに、backchannel_client_notification_endpointを含める。
---jwks_uri異なり、backchannel_client_notification_endpointの妥当性検証は不要。
--[[PPID計算のセクター識別子の登録の例>#ca31c8b1]]。
--[[FAPI Profileでの気付き。>#of2b90f9]]
**その他 [#hbe781e6]
***メタデータ [#ca31c8b1]
-IdP
--必須
---grant_types~
grant_types_supported に urn:openid:params:grant-type:ciba を追加。
---認可エンドポイント~
backchannel_authentication_endpoint を追加。
---非同方式~
backchannel_token_delivery_modes_supported : ["poll", "ping", "push"]
--オプション
---認可リクエストの署名アルゴリズム~
backchannel_authentication_request_signing_alg_values_supported
---user_codeのサポートの有・無（デフォルト値はfalse）~
backchannel_user_code_parameter_supported
-Client
--必須
---非同方式~
backchannel_token_delivery_mode : "poll" or "ping" or "push"
--オプション
---PingまたはPushの際のCallbackエンドポイント~
backchannel_client_notification_endpoint
---認可リクエストの署名アルゴリズム（既定値は署名無し）~
backchannel_authentication_request_signing_alg
---user_codeのサポートの有・無（デフォルト値はfalse）~
backchannel_user_code_parameter
--登録の例
POST /connect/register HTTP/1.1
Content-Type: application/json
Accept: application/json
Host: server.example.com
Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJ ...
{
"application_type": "web",
"client_name": "My Example",
"logo_uri": "https://client.example.org/logo.png",
"subject_type": "pairwise",
"token_endpoint_auth_method": "private_key_jwt",
"grant_types": ["urn:openid:params:grant-type:ciba"],
"backchannel_token_delivery_mode": "poll",
"jwks_uri": "https://client.example.org/my_public_keys.jwks",
"userinfo_encrypted_response_alg": "RSA1_5",
"userinfo_encrypted_response_enc": "A128CBC-HS256",
"contacts": ["ve7jtb@example.org", "mary@example.org"]
}
***セキュリティ考慮事項 [#ga4f18e9]
-PPIDを含むIDトークン~
使用可能である模様（確かにclient_idでPPID計算のセクター識別子を特定可）。
-使い捨てユーザーID~
[[AD>#n4cd6119]]で認証後にIDを生成し、[[QRコード>https://dotnetdevelopmentinfrastructure.osscons.jp/index.php?QR%E3%82%B3%E3%83%BC%E3%83%89]]で[[CD>#gfdf9430]]にlogin_hint_tokenを転送
-ディスカバリー・サービス~
RPがユーザーをディスカバリサービスからlogin_hint_tokenを受信
*[[FAPI>Financial API (FAPI)]] [#fc870e7d]
-CIBAは、FAPIと直接関係は無いが、
-FAPI-CIBA プロファイルという新仕様がUK OBIEから寄付（2019 年 8 月に承認）。
-プロファイルは、読み取り専用APIと読み取り/書き込みAPIの両方に適用される。
-以下が前提知識として必要になる。
--[[FAPI Part 1 (Read Only API Security Profile)]]
--[[FAPI Part 2 (Read and Write API Security Profile)]]
**要約 [#l8e736a2]
***AuthN Server [#of2b90f9]
-FAPI-CIBA プロファイルを使えるのはConfidential Clientのみ。
-認可リクエスト
--JARを使用する。
---nbf クレームと exp クレームを含む。
---JWT の生存期間は 60 分以内。
---PPIDについては（、redirect_uriが無いので）、request_uri(URN)を使う？~
...その場合、URNのヘッダ部分をClient毎に固定する必要があるかもしれない。~
（そもそもCIBAは外部ログインには使用しないので、匿名になりさえすれば良さそう）~
（また、そもそもCIBAするClientは、名寄せなどを行わなそうなのでPPIDも不要かも。）
--request_context パラメーターが含まれることを要求してもよい。
---詐欺や脅威の決定を知らせるJSONオブジェクト（内容は仕様で定義されていない）。
---例：[[CD>#gfdf9430]]に位置情報を提供するために、信頼関係者が必要になる場合がある。
--login_hint や login_hint_token を流用してはならない。~
（流用とは、例えば、この項目を下記の意図（intent）に使用するなど。）
--複雑な認可パラメタを伝える場合、"lodging intent"パターンを考慮する。~
例えば、アクセスの範囲（scope）ではなくて、意図（intent）を指定する。~
（intentは、[[PARやRAR>JWTとOAuth2.0#o9b238a2]]で指定するとのことだが、ココではPARになる）。
-非同期方式
--Pollingモードをサポートしなければならない
--Pushモードをサポートしてはならない
--Pingモードをサポートしてもよい
-以下の何れかが必須
--認可コンテキストが一意（抽象的）
--binding_messageが必須（具体的）
***Client [#r6cb2be5]
-[[CD>#gfdf9430]]
--[[CD>#gfdf9430]]は、下記ヘッダを送信してはならない
---x-fapi-auth-date
---x-fapi-consumer-ip-address
--代わりに、以下の情報を送るべきである
---位置情報
---デバイスタイプ
**セキュリティ考慮事項 [#cff6ebb6]
-login_hint や login_hint_token
--login_hintに広く知られている識別子（電話番号など）使用される場合のリスク
--login_hint_tokenはチャネルに適切であることを確認する必要がある。
-binding_messageに加え、~
（必要に応じて）user_code パラメタも使用した方がイイ。
-JWT署名
--ES256 と PS256のみ許可
--RSA1_5（≒ RSXXX）は禁止
-TLS~
暗号スイートの許可リストに含めるべき。
--TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
--TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
*参考 [#hdf3c138]
-CIBA (Client Initiated Backchannel Authentication) の可能性~
'#authlete #api #oauth #openid #oidc #openbanking~
https://www.slideshare.net/tkudo/openid-connect-ciba-overview
**内部 [#tbb9bcdf]
***[[Financial API (FAPI)]] [#me75d2c7]
***[[プッシュ通知>https://dotnetdevelopmentinfrastructure.osscons.jp/index.php?%E3%83%97%E3%83%83%E3%82%B7%E3%83%A5%E9%80%9A%E7%9F%A5]] [#v6eb33df]
**外部 [#d899d631]
-openid / fapi / 課題 / #127 - CIBA: security issues — Bitbucket~
https://bitbucket.org/openid/fapi/issues/127/ciba-security-issues
**OpenID [#maf4557e]
-【技術解説】OpenID Connect CIBA 実装の具体例と考慮すべきポイント~
https://www.secure-sketch.com/blog/openid-connect-ciba-implementation
***OpenID [#maf4557e]
-OpenID Connect Client Initiated Backchannel Authentication Flow - Core 1.0 draft-01~
https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html
-Public Review Period for OpenID Connect Client Initiated Backchannel Authentication (CIBA) Core Started~
https://openid.net/2018/12/14/public-review-period-for-openid-connect-client-initiated-backchannel-authentication-ciba-core-started/
-Financial-grade API: Client Initiated Backchannel Authentication Profile~
https://openid.net/specs/openid-financial-api-ciba-ID1.html
**Qiita [#a3614771]
***TakahikoKawasaki [#w6fc5ef3]
-Qiita
***TakahikoKawasaki [#w6fc5ef3]
-【2019年版】世界最先端の認証認可技術、実装者による『CIBA』解説~
--【2019年版】世界最先端の認証認可技術、実装者による『CIBA』解説~
https://qiita.com/TakahikoKawasaki/items/9b9616b999d4ce959ba3
**r-weblife [#g9a31a97]
--FAPI-CIBA プロファイル~
https://qiita.com/TakahikoKawasaki/items/f478e2fd07b7236d6fbe
--Authlete を使って CIBA 対応の認可サーバーを作る~
https://qiita.com/hidebike712/items/8fc2938055d0b49cfc0a
***tkudo [#t0cf0a95]
-CIBA (Client Initiated Backchannel Authentication) の可能性~
https://www.slideshare.net/tkudo/openid-connect-ciba-overview
-FAPI (Financial-grade API) and CIBA (Client Initiated Backchannel Authentication)~
https://www.slideshare.net/tkudo/fapi-ciba-2019-03-28
***ritou [#f98f2c49]
-OIDC Client Initiated Backchannel Authentication Flow (CIBA)とは
--概要編~
https://ritou.hatenablog.com/entry/2018/12/29/224452
--詳細もとい感想編~
https://ritou.hatenablog.com/entry/2019/03/04/005238
--CIBAの認証フローを体験するためのWebアプリ(途中経過)~
https://ritou.hatenablog.com/entry/2019/06/03/070000
**OSSコンソーシアム [#j68b8691]
***開発基盤部会 Blog [#m4873357]
-FAPI-CIBAプロファイルを実装してみようかな~
（次いでにOAuth2 Device Flowも）。~
https://www.osscons.jp/jovbqpaa0-537/
-FAPI-CIBA プロファイルの実装を開始した。~
https://www.osscons.jp/jov3wu676-537/
-[[CIBA開発に見た。スタックは出来るがコラボが難しい件のディティール>https://dotnetdevelopmentinfrastructure.osscons.jp/index.php?%E3%82%B9%E3%82%BF%E3%83%83%E3%82%AF%EF%BC%86%E3%82%B3%E3%83%A9%E3%83%9C%E3%83%AC%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3#d41ee884]]
----
Tags: [[:IT国際標準]], [[:認証基盤]], [[:クレームベース認証]], [[:OAuth]]
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
