ritouです。
今回ご紹介する仕様は、OpenID Connect の Client Initiated Backchannel Authentication Flow(CIBA) でございます。
OpenIDファウンデーションの MODRNA WG でただいま絶賛 Public Review 中の一品であります。
Public Review Period for OpenID Connect Client Initiated Backchannel Authentication (CIBA) Core Started https://t.co/measgNado6 #OpenID #Connect #CIBA #MODRNA
— OpenID (@openid) 2018年12月15日
サクッと終わるだろと思ってましたが書いてるうちに細かいリクエストのところで盛り盛りになってしまったので、分割して今回は概要編みたいな感じにします。
概要
既存の OIDC の認証フローはユーザーのブラウザを介して RP -> OP -> RP
といういわゆる OAuth Dance のために HTTP リダイレクションを利用します。
3-legged
な OAuth Dance の感じを示すとこんな感じです。
- RP上で「OPのアカウントでログイン」を選択
- RPからOPにリダイレクト
- OP上で認証、データアクセスの許可
- RPにリダイレクト
- RPはOPから各種トークン取得
シーケンスでいうとこんなです。
いつものやつですね。
それに対して、今回紹介する CIBA の認証フローでは次のようになります。
- RP はなんらかの方法(仕様の対象外)でユーザーの識別子を知る
- ユーザーの識別子を知っている RP が OP と直接通信してトークンを要求、取得する
- 認証結果の受け渡しに関するユーザーの許可などについては、スマートフォンなどで OP とやり取りする
これだけではわからんと思いますが、なーんとなく、CIBAの認証フローに近くてイメージしやすそうなのは、Google に自分のスマートフォンを利用してログインする機能でしょう。
実際は CIBA とは異なりますが、Google 内部で RP=Youtube
, OP=Google
みたいな立ち位置にすると、近くなるかもしれません。
今のは仕様に書いてなくて私が説明のために考えた例ですが、仕様に記載されているユースケースを見てみましょう。
ユースケースと用語
例として、次の3つが記載されています。後の説明のためにちょっと順番を変えています。
- ユーザーのスマートフォンで POS 端末の支払い
- 銀行窓口での顧客認証
- コールセンターにおける発信者認証
ソーシャルログインなどに代表される OIDC の認証フローの説明では UserAgent(エンドユーザー)
, RP, OP の3者が登場人物となるユースケースが一般的です。
しかし、このユースケースにおける
- POS 端末を操作している人
- 銀行窓口の担当者
- コールセンターの担当者
という人たちは、実際に認証とアクセス許可を行う UserAgent(エンドユーザー)
と同一人物ではなさそうです。
CIBA ではこの人たちが利用しているのを RP 、操作している端末などを Consumption Device (CD)
、スマートフォンなどユーザーが認証/認可処理を行う端末を Authentication Device (AD)
と呼びます。
OIDC では CD = AD = UserAgent
と言えるでしょう。
CIBA では CD
と AD
が別でも大丈夫です。
ということは、システム的/物理的に離れていてもユーザー識別がうまくてきればユーザー認証結果を取得して利用できて、「これは良いのではないか」って感じになってきたんじゃないでしょうか?
おまけで、現在のなんたらPayブームに乗って、仮に Ponta の ID と決済できるとこのIDが紐づいてたら
コンビニ店員「Pontaカードカモン」 客「はい」 店員「XXX円です」 客「CIBA Pay(ダッサ)」 店員「はい(ポチ)」 客のスマホ「(XXX円をローソンに支払います。よろしいですか?)」 客「おk」 店員「支払いおわた。レシートどぞ」
ぐらいは出来そうです。
OAuth 2.0 Device Flow との違い
そういえば、OAuth 2.0 には Device Flow ってのがあります。 Device Flow はテレビやスマートスピーカーのような、エンドユーザーとの対話機能に制限があるデバイス上で動作する Client(RP) の 認可処理を別の端末で行うための仕様です。
CIBA とあえて比較するとしたら、
CD
,AD
の分離- ユーザー識別
- Device Flow では OP の所でユーザー認証するので事前のユーザー識別は不要
- CIBA では Client が OP に「このユーザーを認証してください」と要求し、OP は紐づく
AD
を特定 するため、事前のユーザー識別が必要
という感じで、完全に CIBA が Device Flow を置き換えるような感じではなさそうです。 互いに適切な用途があると思うのでこの辺りの導入を検討する際は気をつけましょう。
概要編の最後に、ざっくりと CIBA の認証フローを見ていきます。
認証フロー概要
CIBA
では次のような認証フローが定義されています。
Client
は OP のBackchannel Authentication Endpoint
にユーザー識別子などを含む HTTP POST を送ってエンドユーザーの認証を要求- OP はバックグラウンドで認証を試みる間、その認証に一意にひもづく識別子を返す
Client
はID Token
,Access Token
,Refresh Token(optional)
を受け取る。その方法について、Poll
,Ping
,Push
というモードがある
モードによって最後のトークン取得方法が異なります。
Poll
:Client
は OP のToken Endpoint
をポーリングして応答を受け取るPing
: 事前にClient
が登録しておいたCallback URI
に対して OP が認証の識別子と共に通知用のリクエストを送る。Client
はToken Endpoint
からトークンを取得する。Push
: 事前にClient
が登録しておいたCallback URI
に対して OP がトークンを含むリクエストを送る。
Poll
モードについては Device Flow と似ています。
Ping
/ Push
モードでは OP から RP へのリクエストも考慮されています。
ということで、このモードを使う場合、RP にも新たなエンドポイントが必要となりますね。
次回予告
ここからの詳細の説明、ちょっと長くなるので次回にします。
また、Device Flow の時もそうだったんですが、こういう飛び道具系の仕組みはセキュリティ面で色々考えるところがあるので仕様の Security Considerations
, Privacy Considerations
のあたりも見ていきましょう(今回のに含めたかったけどパラメータについての言及があったのでやめます)。
CIBAについてもっと詳しく聞きたい?
誰が詳しいの?と CIBA OIDC
あたりでググった結果...
1個めが仕様、その外はこれ全部くどーさんですね。 ということで、CIBAについてすでに情報を発信しており、私よりも熱い思いを持つ人、くどーさんに聞けばいいじゃない。ソレガイイ、ソレガイイ。
[勉強会第2弾開催のお知らせ] これまで数回開催させていただいた OIDC 勉強会の第2弾として、来年1月16日に #FAPI と #CIBA にフォーカスした勉強会を開催いたします。今回の講師は @tkudos の予定です。ご興味のある方、ぜひ登録してみてください! https://t.co/NyjlAqzLoL
— Authlete (@authlete_jp) 2018年12月3日
私も行きます。行けたら。
参考になりそうなスライド
www.slideshare.net
おまけ : 発音
そういえば、今回初めて CIBA を知った方、ここまで脳内でどう発音してきましたか? 親切な仕様だと発音についての記載があったりしますが、まずは文章やスライドだけ読むマンにとって、OAuth、JOSE、CBORなど、発音に困ることが多々あります。
あ、今日のスライドに「まっだーぬぁ」「しーば」ってふりがなつけるの忘れた
— Tatsuo Kudo (@tkudos) 2018年11月8日
さすがくどーさん親切ですね。
ではまた!