OpenID Connecr Self-Issued OP(IdP) の仕様と応用

きっかけ

先日、OpenID TechNight Vol.15 にて、Self-Issued IdPに関する発表がありました。

Self-Issued IdP(以下、SIOP)は仕様自体はOpenID Connect Core 1.0に含まれていますが、実装されてプロダクション環境で運用されている例に出会うのは滅多にないため(知らないだけかも？)、内容もとても興味深いものでした。

この記事では、SIOPについて、
* ここまでが仕様で定義されている
* それをどのように応用しているか
という視点でとらえた内容となります。

と、書き始めたところで、同じような趣旨の記事が投稿されました。
OpenID Connect Self-issued OP概要 ~OpenID Technight #15より~

もう、下書き削除でいいんじゃないかという思いが頭をよぎりつつも、似たような記事を投下することにします。

仕様では何が定義されているのか

2013年頃にSIOPについて紹介したブログ記事を書きました。
OpenID ConnectのSelf-Issued OPの話

仕様で定義されているのは、

端末上で動作
鍵ペアを生成、保存
AuthZ Request
- client_id, grant_type=id_token などのパラメータ
AuthZ Response
- ID Token の中身

までで、

ID Tokenに含むことで端末内で保持されている情報を署名付きで受け渡しできる

というのがSIOPの基本的な機能であり、この 仕組み をどう応用していくかが実際のプロダクトへの導入の鍵と言えるでしょう。

SIOPの応用 : ユーザー認証 + 追加認証

発表にあった実装は、 SIOP をユーザー認証と追加認証の二点における応用と言えるでしょう。

AuthZ Serverが登場
AuthZ ServerはリクルートID/パスワードの認証機能を持つ
AuthZ Server が SIOP の Client となり、 SIOP から受け取った ID Token の中の sub の値をリクルートのアカウントとの紐付けに利用
- 初回は、SIOP の ID Token を受け取った後にユーザー認証を行い、紐付け
- ２回目以降、SIOP の ID Token を用いてログイン可能
nonce　を用いて SIOP のフローが正しく行われることを担保

のあたりが、ユーザー認証への応用というところです。

より話を一般化すると、SIOP自体がユーザー認証の機能を持ったり、属性情報を保持する実装も可能でしょう。
「信頼のおける」SIOPが確認済みのメールアドレスやSMS番号を保持しておいて、ユーザー未登録状態の Client に対して提供(ID Token に含む)することで、新規登録のフローを簡略化するようなシナリオも描けるかもしれません。

追加認証への応用については、

AuthZ Server に acr パラメータをつけてリクエスト
AuthZ Server は amr パラメータをつけて SIOP にリクエスト
SIOPは適切な認証を行い、ID Tokenを返す

の部分がそれにあたります。

SIOP を利用することで、「端末上で動作するアプリケーションのみが実装できる機能」がwebアプリからも比較的疎結合な実装で利用できると言えるでしょう。
あらかじめ認証強度などの整理をしておき、それを要求できるようにすることで、端末上で新たな認証機能が実装された時もスムーズに対応していけそうです。

まとめ

仕様で定義されているのは鍵ペア作るよ＆やりとりの方法まで
ユーザー認証への応用について
追加認証への応用について

今後もこのようなSIOPの実装例が増えてくると良いですね。
ではまた！