Chapter 04

OpenID Connect 1.0

ほげさん
ほげさん
2021.08.14に更新

この章の目的

  • 引き続き 認証認可 についての理解を深める
  • どんな単語が OpenID Connect に関係している単語か、マッピングしておく
  • Single Sign-On の理解の準備知識とする

概要

  • 主要部分は OpenID Connect Core 1.0 で定められている
  • OAuth 2.0 を 認証 として活用するために拡張した、ID 連携 のための仕組み

なぜ必要になったか

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

関連する要素・流れ

  • OpenID 1.0 作成 ( 2005 )
  • OpenID 2.0 公開 ( 2007 )
  • OAuth 2.0 リリース ( RFC6749 / 2012 )
  • OpenID Connect 1.0 公開 ( OpenID Connect Core 1.0 / 2014 )
    • OAuth 2.0 の拡張仕様
    • OpenID 2.0 とは互換性もなく別物
  • PKCE リリース ( RFC7636 / 2015 )
    • OAuth 2.0 の拡張仕様

これ以降は特に明記しない限り OpenID Connect は OpenID Connect 1.0 を指すものとする

概略

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

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

ID トークン

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

JSON Web Token ( JWT )

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

8つのフロー

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

ユーザ情報エンドポイント

  • 認可サーバ からユーザに関する情報を取得できる
    • ただ、通常は ID トークン にも含まれている

OpenID Connect 超要約

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

なぜ Single Sign-On に使えるか

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

  1. ID/PW とかで認証をした結果 認可コード が得られていて、それと アクセストークン を引き換えている
  2. だから アクセストークン があるってことは 認証済み
  3. どこかの最初のクライアントが アクセストークン を手に入れたなら、ほかのクライアントにはそれを伝授すれば良い

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

    1. の部分が問題
    • OAuth は 認可 のプロトコルなので、 アクセストークン を持っている人のことを把握してるわけではない
  • アクセストークン には認証元や認証アルゴリズムの情報がない ( スコープと有効期限だけ )

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

  • ID トークン は認証時の情報やクライアントの情報を含んでいるので、これを伝授するなら 認証 も安心だ

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

この章の参考資料

  1. 単なる OAuth 2.0 を認証に使うと、車が通れるほどのどでかいセキュリティー・ホールができる
  2. 「単なるOAUTH 2.0を認証に使うと、車が通れるほどのどでかいセキュリティー・ホールができる」について | SIOS Tech. Lab
  3. OpenID Connect入門: 概念からセキュリティまで体系的に押さえる ( amazon ) ( 再掲 )
  4. 多分わかりやすいOpenID Connect | SIOS Tech. Lab
  5. 一番分かりやすい OpenID Connect の説明 - Qiita
  6. OpenID Connect 全フロー解説 - Qiita
  7. OpenID Connect 入門 〜コンシューマーにおけるID連携のトレンド〜
  8. ID連携の歴史とOpenID-Connect概要 - Speaker Deck