OpenID Connect CIBAフローを実装してみた感想

最近OpenID ConnectのCIBAフローを実装する機会があったので、その感想をメモっときます。

そもそもCIBAフローって何？

authleteの川崎さんのqiitaがマジ詳しいです。

認可コードフローなどの通常のフローはリダイレクトでトークンのやりとりを行うのでブラウザ上で動くことが前提となりますが、CIBAはブラウザ以外での認証リクエストを受け付けることができるので、いろんなとこに応用が効くと思ってます。

以下、川崎さんの記事を読んだりして、CIBAフローの雰囲気を理解した方向けに、実装してみた感想をカンタンにまとめます。

すでにOpenID Connectの実装があるんなら、POLLモードで最低限のCIBAフローそのものの実装はそこまで難しくないです。
tokenエンドポイント以外は新規実装でよいので既存の設定の整合性を考えなくてよいですし、tokenエンドポイントはgrant_typeで処理を分岐させるだけです。

ただ、認証リクエストがきたときにユーザに通知を行う必要があるのですが、どんな手段で通知するかはCIBAの仕様範囲外です。
普通のOP/IdP実装だとユーザ通知なんて用意してないでしょうから、そこが完全にゼロベースでの実装となって非常にめんどくさかったです。

なお、まだ手元の実装では対応してはないですが、POLLモードができれば、PINGモードもちょちょいと実装追加で対応可能です。

でもPUSHモードはトークンを直接外部のエンドポイントに送りつけることになるので、そのエンドポイントの確認と管理(RPが管理しているエンドポイントじゃなかったら即事故になる)が必要なのがネックになって、正直どう実装したらよいか全くわからないです。

サーバ実装とあわせてクライアントも必要になるわけですが、POLLモードでは以下の2タイプのリクエストを投げるだけです。

curlで確認できるくらいカンタンなんですが、カッとなってgolangでラップしてみました。

READMEのサンプルコード見ていただければわかると思いますが、認証処理が 関数一つ呼び出しでOK というくらいカンタンです。
ID danceを理解しないと実装が困難な認可コードフローやimplicitフローとは大違いです。

個人的にはココがCIBAフローの一番嬉しいトコだと思っています。
応用のユースケースで、ネイティブアプリのバックエンドサーバでのユーザ認証を考えても、独自拡張したID danceなんかを実装しなくてすむので、本当に本当にメリットしかカンジられません。

これだけクライアント実装がカンタンなら2020年にはCIBAフローが市民権をえるんじゃないかなー。。。

CIBA対応のIdPがもっと出てくるといいなぁと思います。