Chapter 04

OpenID Connect 1.0

このチャプターの目次

この章の目的

OAuth では認証時の情報 ( 日時や手段など ) やユーザの情報 ( id や名前やメアドなど ) を取得する仕様が定められていない
- クライアントが共通仕様で共有できるアクセストークンだけではユーザ情報の共有が難しい
OAuth を認証に使ってしまうケースが増えたが、インプリシットフローなどを安易に認証に使うと極めて危険
- 詳細は参考資料 1, 2 を
ID/PW を管理するのはシビアだしリスクがあるのでクライアントでやりたくない、SNS とかに認証を任せたい
いろいろなクライアントで ID/PW を管理するのは大変だし、ユーザもなんどもログイン操作をしたくないので、Single Sign-On をしたい

超ざっくり言うと アクセストークン に加えて ID トークン も得られる

大半は OAuth と同じで、以下の差分がある

Claim と呼ぶ Key-Value の情報で認証時の情報やユーザの情報を持つ
- name, profile, picture, email, gender, locale, phone_number, address...
標準的なものは OpenID Connect Core 1.0 # Claims で定義されている
OAuth にこれが増えたので、ユーザの情報を共通書式でクライアント間で共有できる

RFC7519 で定められた データ形式
Claims のデータを電子署名する JSON Web Signature ( JWS ) と Claims のデータを暗号化する JSON Web Encryption ( JWE ) がある
ID トークン は基本的に JWS
３つの要素を Base64URL エンコーディングして . で繋いだもの
- ヘッダ: 電子署名したアルゴリズムの情報など
- ペイロード: トークンの発行元など
- 電子署名
アクセストークン でも、電子署名をしたい場合は JWT 形式にしたりする

OAuth で認可エンドポイントに response_type というパラメータがあり、code か token のどちらかを指定する必要があった
OpenID Connect では code か token か id_token を任意数、もしくは none という値を指定できる
- OpenID Connect Core 1.0 # Authentication を見ると、code 指定は認可コードフローと、id_token 指定や id_token, token 指定はインプリシットフローと同じだったりする
- 詳細は参考資料 6 を

最後に アクセストークン に加えて ID トークン も手に入る OAuth だと理解して、とりあえずは良いと思う

OAuth ではなく OpenID Connect が Single Sign-On のための仕組みと言われるのは、こんな感じの背景のはず

と OAuth の時点で考えたけど、よく考えたら問題があった

だから ID トークン が必要だ

これなら Single Sign-On に使える