OpenID Connect

• spec
  • OpenID Connect Core 1.0 incorporating errata set 1

• 特徴

  • 認証 と 認可 の両方をサポートしたプロトコル
  • OpenID Connect は OAuth のフローをそのままに、クライアント（Relying Party）が信頼できるように、認証サーバー（OpenID Provider）が安全な方式（JWT）で認証結果（ID Token）を提供するプロトコル
  • OAuth 2.0 を拡張する形で規程
    • OAuth で発行される Access Token に加えて、エンドユーザ本人証明書として ID token も発行される
      • ID 連携
        • エンドユーザの ID 連携をサポート
        • これを実現する ID token を追加
          • ID token は IdP で管理するエンドユーザの ID を保持
          • ID token を介して IdP の ID が RP と共有されることから、エンドユーザの認証が可能となる
          • ID token
            • エンドユーザは誰であるか(ID), どの IdP が どの RP に対し、いつ発行したものかが分かるトークン
            • さらに、これらの情報が改ざんされていないことを検証できる署名が付与されている
            • JWT(JSON Web Token) という技術を採用
    • OAuth 2.0 ベースにしており OAuth 2.0 の特徴をおおよそ継承する
      • SSL/TLS 必須
      • 署名は必須ではない
      • Access token は Authorization ヘッダの Bearer スキームに入れてリクエストする
      • Access token の寿命は結構短い
  • Hybrid Flow 追加
    • フロントエンド + バックエンド構成アプリを考慮した Hybrid Flow

• 登場人物

  name	description
  OpenID Provider(OP)	ユーザーの認証を行う機能を有するサーバー また、ユーザーの認証時に Relying Party から要求された ID 情報を供給することができる REST エンドポイントを有するサーバー
  Relying Party(RP)	OP に ID Token と ID 情報を要求するサーバー SSO 対象のアプリケーションを指す
  ID Token	認証と認可の情報を含む JWT(JSON Web Token) 形式のトークン
  Access Token	UserInfo エンドポイントにアクセスするためのトークン
  UserInfo	Access Token を提示するクライアントに対して、 ID 情報を提供する

• OpenID Connect プロトコルはおおまかに言って以下のステップに従う

  1. RP (Client) が OP に認可リクエストを送る

  2. ユーザは OP にサインインし、認可をされる

  3. OP は ID Token および (通常は) Access Token を返す

  4. RP は Access Token を添えて UserInfo Endpoint にリクエストを送る

  5. UserInfo Endpoint は ユーザに基づく ID 情報を返却する

     +--------+                                   +--------+
     |        |                                   |        |
     |        |---------(1) AuthN Request-------->|        |
     |        |                                   |        |
     |        |  +--------+                       |        |
     |        |  |        |                       |        |
     |        |  |  End-  |<--(2) AuthN & AuthZ-->|        |
     |        |  |  User  |                       |        |
     |   RP   |  |        |                       |   OP   |
     |        |  +--------+                       |        |
     |        |                                   |        |
     |        |<--------(3) AuthN Response--------|        |
     |        |                                   |        |
     |        |---------(4) UserInfo Request----->|        |
     |        |                                   |        |
     |        |<--------(5) UserInfo Response-----|        |
     |        |                                   |        |
     +--------+                                   +--------+
     

通信フロー

下記フローが定義されており、これらを RP が指定できる仕組みになっている

1. Authorization Code Flow
2. Implicit Flow
3. Hybrid Flow

Authorization Code Flow

• OP がエンドユーザー経由で RP に発行した認可コードをキーに ID Token や Access Token を取得する方式

• フロー図

  • 

• ID Token のやり取りを OP と RP が直接通信で行うため、互いに疎通できる環境下でのみ使用可

Implicit Flow

• 前述の Authorization Code Flow で使用していた Token Endpoint を使用せず、ID Token と Access Token は Authorization エンドポイントから返却

• フロー図

  • 

• ID Token の受け渡しは Web ブラウザを介して行うため、OP と RP の間に直接通信できない環境でも採用することが可

• 図中に示す通り、ID Token の受け渡しは URL フラグメントによる受け渡しとなるため、RP はフラグメント部分をパースした後、情報の検証を行うエンドポイントに対して、POST でのデータ送信を行うようなスクリプトを配備する必要がある

Hybrid Flow

ID 情報の提供

1. ID Token から ID 情報を取得

   • OP から RP に ID Token を返却する際、この ID Token に含める方法

   • どういった属性を含めるかの権限要求は認可リクエスト時に行うことができ、下記のように指定

     HTTP/1.1 302 Found
     Location: https://op.example.domain/authorize?
     response_type=code
     &scope=openid%20profile%20email # 属性の要求箇所
     &client_id=XXXXXX
     &state=abcdefg123
     &redirect_uri=https%3A%2F%2Frp.example.domain%2Fcallback
     

     • URL クエリストリングの scope パラメータを用いて、 ID 情報の部分集合(クレーム)を指定
     • OpenID Connect の仕様では、クレームを要求する際に、下記の scope パラメータが定義
       • profile
         • 姓、名、ニックネーム、生年月日、ロケールなどの情報を含む
       • email
       • address
       • phone
2. UserInfo エンドポイントで提供する方法

   • Authorization Code Flow では「7.」で要求し、「8.」で受け取る

   • Implicit Flow では「5.」で要求し、「6.」で受け取る

   • RP が Access Token を用いて、UserInfo エンドポイントに対して、 ID 情報を要求する方法

   • UserInfo エンドポイントは OAuth 2.0 でいうところの「Resource Server」に当たる

     • http://tools.ietf.org/html/rfc6749#section-7

   • RP は下記のようなリクエストを UserInfo エンドポイントに送り、応答として JSON 形式の ID 情報を取得することができる

     GET /userinfo HTTP/1.1
     Host: server.example.domain
     Authorization: Bearer SlAV32hkKG
      
     HTTP/1.1 200 OK
     Content-Type: application/json
      
     {
       "sub": "1234567",
       "name": "OGIS TARO",
       "given_name": "TARO",
       "family_name": "OGIS",
       "preferred_username": "t.ogis",
       "email": "t.ogis@example.domain"
     }
     

• OpenID Japan

zatsu

• OpenID Connect
  • 2014年
  • JSON 形式
  • OAuth 2.0 をベースに、認証やセッション管理なども実現
  • OpenID からの脱却
  • OAuth を使いながら安全に身元確認をできるようにしている
  • OpenID トークン
  • クレームの扱い
    • 外部クレームの提供
    • クレームの暗号化

• OpenID Authentication

  • OpenID Provider が行う認証

• OpenID

  • いま来ている人の身元を認証
  • OP(OpenID Provider) - RP(Relying Party)間で認証結果と属性情報(クレーム)の受け渡しができること
  • 認証結果のやり取り
    • ID トークン
      • 下記値を含むデータをエンコードして署名を付けたもの
        • 発行元の OP 識別子
        • 発行先の RP 識別子(client_id)
        • ユーザの識別子
        • 発行日時
  • OAuth 2.0 のフローでやり取りされるアクセストークン(Access Token)や認可コード(Authorization Code)とともに、認証結果を表す ID トークンを受け渡すことで ID 連携を可能にしている
  • クレーム提供のために UserInfo エンドポイントではユーザの新規登録に必要なメールアドレス、氏名などの基本的なクレーム一覧が定義

• SSO リクエストはサービスプロバイダーの WEB サイトかまたは SSO ベンダーの WEB サイトから開始できる

  • SAML はどちらの方法もサポートする
  • OpenID はサービスプロバイダーの WEB サイトにアクセスする必要がある

• ユーザープロビジョニングの問題もある。OpenID では、特定のアプリケーションの全てのユーザーが、 自分の OpenID 資格情報をそのアプリケーションに対して登録しなければならない。数百人、さらには数 千人のユーザー向けに OpenID を有効にしなければならない場合、多大な手間が掛かってしまう。SAML は X.509 証明書に対応しており、全てのユーザーに対して直ちに有効にできるので、はるかに簡単

OpenID

• 2006 年に発明

• コンシューマが単一のログイン情報を複数の WEB サイトで使えるようにすることを目的に設計

• web サイト同士は必ずしも信頼関係にある必要はなし

  • SaaS、ユーザディレクトリ、SSO アプリケーション間で安全な通信を確立する必要は必ずしも必要なし

• 標準化されなかった（独自方法が乱立）

• 2011 年 OpenID サポート打ち切り

• 認証

  • 1 回のログインで多くのサービスへアクセスしたい
    • この問題を解決するためにプラッド・フィッツパトリック氏が 2005 年に OpenID を発明
    • Web で人気を博したのは SAML(2002 年) だ
    • SAML 2.0 ではセキュリティに重点が置かれ、高い安全性が保証されたアプリケーションで利用できるように鳴った
  • 従業員などがアプリなどにアクセスするための ID を 1 つで管理したい