OIDC Client Initiated Backchannel Authentication Flow (CIBA)とは - 概要編

ritouです。

今回ご紹介する仕様は、OpenID Connect の Client Initiated Backchannel Authentication Flow(CIBA) でございます。

openid.net

OpenIDファウンデーションの MODRNA WG でただいま絶賛 Public Review 中の一品であります。

サクッと終わるだろと思ってましたが書いてるうちに細かいリクエストのところで盛り盛りになってしまったので、分割して今回は概要編みたいな感じにします。

概要

既存の OIDC の認証フローはユーザーのブラウザを介して RP -> OP -> RP といういわゆる OAuth Dance のために HTTP リダイレクションを利用します。 3-legged な OAuth Dance の感じを示すとこんな感じです。

f:id:ritou:20181229000232p:plain

  1. RP上で「OPのアカウントでログイン」を選択
  2. RPからOPにリダイレクト
  3. OP上で認証、データアクセスの許可
  4. RPにリダイレクト
  5. RPはOPから各種トークン取得

シーケンスでいうとこんなです。

f:id:ritou:20181229000342p:plain

いつものやつですね。

それに対して、今回紹介する CIBA の認証フローでは次のようになります。

  • RP はなんらかの方法(仕様の対象外)でユーザーの識別子を知る
  • ユーザーの識別子を知っている RP が OP と直接通信してトークンを要求、取得する
  • 認証結果の受け渡しに関するユーザーの許可などについては、スマートフォンなどで OP とやり取りする

これだけではわからんと思いますが、なーんとなく、CIBAの認証フローに近くてイメージしやすそうなのは、Google に自分のスマートフォンを利用してログインする機能でしょう。 実際は CIBA とは異なりますが、Google 内部で RP=Youtube, OP=Google みたいな立ち位置にすると、近くなるかもしれません。

f:id:ritou:20181229004954p:plain

  1. RP上でユーザー識別(例:メアド入力)
  2. RPはOPに対してこのユーザーの認証を要求
  3. 手元のスマートフォン + OP上でユーザー認証、データアクセスの許可
  4. RPはOPから各種トークン取得

今のは仕様に書いてなくて私が説明のために考えた例ですが、仕様に記載されているユースケースを見てみましょう。

ユースケースと用語

例として、次の3つが記載されています。後の説明のためにちょっと順番を変えています。

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

ソーシャルログインなどに代表される OIDC の認証フローの説明では UserAgent(エンドユーザー), RP, OP の3者が登場人物となるユースケースが一般的です。 しかし、このユースケースにおける

  • POS 端末を操作している人
  • 銀行窓口の担当者
  • コールセンターの担当者

という人たちは、実際に認証とアクセス許可を行う UserAgent(エンドユーザー) と同一人物ではなさそうです。

CIBA ではこの人たちが利用しているのを RP 、操作している端末などを Consumption Device (CD)スマートフォンなどユーザーが認証/認可処理を行う端末を Authentication Device (AD) と呼びます。

OIDC では CD = AD = UserAgent と言えるでしょう。 CIBA では CDAD が別でも大丈夫です。 ということは、システム的/物理的に離れていてもユーザー識別がうまくてきればユーザー認証結果を取得して利用できて、「これは良いのではないか」って感じになってきたんじゃないでしょうか?

おまけで、現在のなんたらPayブームに乗って、仮に Ponta の ID と決済できるとこのIDが紐づいてたら

コンビニ店員「Pontaカードカモン」
客「はい」
店員「XXX円です」
客「CIBA Pay(ダッサ)」
店員「はい(ポチ)」
客のスマホ「(XXX円をローソンに支払います。よろしいですか?)」
客「おk」
店員「支払いおわた。レシートどぞ」

ぐらいは出来そうです。

OAuth 2.0 Device Flow との違い

そういえば、OAuth 2.0 には Device Flow ってのがあります。 Device Flow はテレビやスマートスピーカーのような、エンドユーザーとの対話機能に制限があるデバイス上で動作する Client(RP) の 認可処理を別の端末で行うための仕様です。

qiita.com

CIBA とあえて比較するとしたら、

  • CD , AD の分離
    • Device Flow は既存の OAuth Dance の RP -> OP にリダイレクトするタイミングでQRコードやURL表示などで手元のスマートフォンなどに誘導し、 CDAD が分離
    • CIBA は最初から CDAD が分離していて、 OP が AD を用いてユーザーと対話
  • ユーザー識別
    • Device Flow では OP の所でユーザー認証するので事前のユーザー識別は不要
    • CIBA では Client が OP に「このユーザーを認証してください」と要求し、OP は紐づく AD を特定 するため、事前のユーザー識別が必要

という感じで、完全に CIBA が Device Flow を置き換えるような感じではなさそうです。 互いに適切な用途があると思うのでこの辺りの導入を検討する際は気をつけましょう。

概要編の最後に、ざっくりと CIBA の認証フローを見ていきます。

認証フロー概要

CIBA では次のような認証フローが定義されています。

  1. Client は OP の Backchannel Authentication Endpoint にユーザー識別子などを含む HTTP POST を送ってエンドユーザーの認証を要求
  2. OP はバックグラウンドで認証を試みる間、その認証に一意にひもづく識別子を返す
  3. ClientID Token, Access Token, Refresh Token(optional) を受け取る。その方法について、Poll, Ping, Push というモードがある

モードによって最後のトークン取得方法が異なります。

  • Poll : Client は OP の Token Endpoint をポーリングして応答を受け取る
  • Ping : 事前に Client が登録しておいた Callback URI に対して OP が認証の識別子と共に通知用のリクエストを送る。ClientToken Endpoint からトークンを取得する。
  • Push : 事前に Client が登録しておいた Callback URI に対して OP がトークンを含むリクエストを送る。

Poll モードについては Device Flow と似ています。

Ping / Push モードでは OP から RP へのリクエストも考慮されています。 ということで、このモードを使う場合、RP にも新たなエンドポイントが必要となりますね。

次回予告

ここからの詳細の説明、ちょっと長くなるので次回にします。 また、Device Flow の時もそうだったんですが、こういう飛び道具系の仕組みはセキュリティ面で色々考えるところがあるので仕様の Security Considerations, Privacy Considerations のあたりも見ていきましょう(今回のに含めたかったけどパラメータについての言及があったのでやめます)。

CIBAについてもっと詳しく聞きたい?

誰が詳しいの?と CIBA OIDC あたりでググった結果...

f:id:ritou:20181229192822p:plain

1個めが仕様、その外はこれ全部くどーさんですね。 ということで、CIBAについてすでに情報を発信しており、私よりも熱い思いを持つ人、くどーさんに聞けばいいじゃない。ソレガイイ、ソレガイイ。

私も行きます。行けたら。

参考になりそうなスライド

www.slideshare.net

www.slideshare.net

おまけ : 発音

そういえば、今回初めて CIBA を知った方、ここまで脳内でどう発音してきましたか? 親切な仕様だと発音についての記載があったりしますが、まずは文章やスライドだけ読むマンにとって、OAuth、JOSE、CBORなど、発音に困ることが多々あります。

さすがくどーさん親切ですね。

ではまた!