OpenID Connect Self-issued OP は自己署名 ID トークンを発行する、ユーザ個人の自己 OpenID プロバイダ。
ユーザが利用する端末やブラウザ上で動作し、自己署名 ID トークンを発行することで、
- SIOP が動作する端末の識別 (端末認証)
- 安全な端末情報の受け渡し (改ざん検出)
を実現する。
仕様👉http://openid.net/specs/openid-connect-core-1_0.html#SelfIssued
ユーザの端末でユニークな鍵ペアを生成・保存・管理する。ID トークンに公開鍵が含まれているので、改ざんされていないかを検証できる。
また、公開鍵のハッシュのようなものを識別子として扱うので、SIOP が動作する端末やブラウザの識別ができる。
SIOP の場合、ユーザの端末やブラウザが認証サーバ・リソースサーバとなり、Web アプリなどのバックエンドサーバがクライアントとなる。
フロー
Implicit Flow と同様のフロー。
認可リクエストを受けたら、自己署名された ID トークンを返す。
なお、事前に鍵ペアの生成とバックエンドサーバへの公開鍵の登録が行われている。
- ユーザがネイティブアプリ (SIOP) を開く
- アプリがバックエンドサーバにアクセスする
- バックエンドサーバはアプリに認可リクエストを送る
- アプリはユーザを認証する
- アプリは ID トークンを発行し、署名する
- アプリからバックエンドサーバに ID トークンを送る
- バックエンドサーバは ID トークンを検証し、ID トークンに含まれる情報を取得する
ID トークン
- iss (発行者) は https://self-issued.me
- sub (識別子) は公開鍵のハッシュ値を Base64 エンコードしたもの
- sub_jwk は署名検証に用いる公開鍵情報
認可リクエスト
- URL はカスタム URL スキーマ (
openid://)- ネイティブアプリからネイティブアプリへ認可リクエストを送ることもできる
- reaponse_type は id_token
- 認可エンドポイントで ID トークンを発行
- トークンエンドポイントは使用しない
- client_id は URL 形式
- この URL のフラグメントに ID トークンが付加される。静的/動的なクライアント登録ができないため
認可レスポンス
- Implicit Flow と同様
事例
OpenID Connect Self-Issued IdPを応用したSingle Sign Onの実装
キラーアプリを SIOP にして、他アプリは SIOP に認証をリクエストすることでシングルサインオンを実現。
Next
- FIDO UAF との比較