OpenID Connect, December 2011

第8回情報セキュリティ技術動向調査TG
アイデンティティ管理技術

2011年12月22日

株式会社野村総合研究所
IT基盤インテグレーション事業本部
DIソリューション事業部

工藤達雄
〒105-7113
東京都港区東新橋1-5-2 汐留シティセンター13階

更新履歴

Dec/22/2011
初版
Jan/17/2012
SlideShareにて公開
OpenID Connect Protocol Suiteを修正
▪ 「公式マップ」（左の図）をJan/12/2012の版に差し替え
▪ 私的解釈（右の図）を修正 (Thanks to 崎村さん)

Copyright © 2011 Nomura Research Institute, Ltd. All Rights Reserved. 1

アジェンダ

2011年7月から12月にかけての技術動向を概観
OpenID Connect
▪ https://openid.net/connect/


OpenID Connectとは
http://openid.net/connect

OpenIDの次期バージョン
OAuth 2.0 仕様をベースに拡張
「シンプルな認証結果と属性情報の取得」 (後述) の範囲であれば、
一般的なOAuth 2.0認可 + API アクセスのフローとほぼ同様
メッセージ形式にJSONを採用
加えてJWT (JSON Web Token) を活用することにより、署
名と暗号化をサポート
仕様のモジュラー化
かんたんなことをシンプルにする一方、複雑なことも実現可能に


OpenID 2.0
OpenIDプロバイダ（OP） OpenIDリライング・パーティ（RP）
RPのリクエストに基づきユーザー認証を行い OPに認証結果や属性情報をリクエストし
その認証結果と属性情報を提供その情報をもとにユーザーにサービスを提供
2. OPの場所を特定し、リクエスト/
レスポンスに用いる署名鍵を交換

5. 認証レスポンス 3. 認証リクエスト
（ブラウザを（ブラウザを
リダイレクト）リダイレクト）

4. ユーザー認証の実施と
認証結果と属性情報の 1. 「OPの 6. アクセスを
提供可否の確認 IDで許可し
ログイン」サービスを
提供
PCのWebブラウザ

ユーザー
RPへのアクセスを試みる過程においてOPから
RPへの認証結果と属性情報の提供を許可

OpenID 2.0の課題 (≒ OpenID Connectの注力分野)
「OP/RP間の設定をもっとかんたんに、
OpenIDプロバイダ（OP）もしくは省略したい」 OpenIDリライング・パーティ（RP）
RPのリクエストに基づきユーザー認証を行い OPに認証結果や属性情報をリクエストし
その認証結果と属性情報を提供その情報をもとにユーザーにサービスを提供
2. OPの場所を特定し、リクエスト/
レスポンスに用いる署名鍵を交換

Web API
（ID情報、ｌセッション管理、「認証リクエスト/
ソーシャル、決済、レスポンスに対して、
アクティビティ、…）
公開鍵を用いて
暗号化・署名したい」
5. 認証レスポンス 3. 認証リクエスト
「OPの提供する（ブラウザを（ブラウザを
他のAPIとリダイレクト）リダイレクト）
かんたんに
組み合わせたい」 4. ユーザー認証の実施と
1. 「OPの 6. アクセスを
認証結果と属性情報の
提供可否の確認 IDで許可し
ログイン」サービスを
提供
PCのWebブラウザ

「携帯電話のWebブラウザや、
Webブラウザ以外の
ユーザー・エージェント
（ネイティブ・アプリケーションや
JavaScriptクライアントなど）
ユーザー
にも対応したい」
RPへのアクセスを試みる過程においてOPから
RPへの認証結果と属性情報の提供を許可

OpenID Connectのフロー（概要）
9.（オプション）:
ユーザー属性
9 10 （オプショ
クレームクレーム
ソース
提供要求
ン）: ユーザー
プロバイダ 10 属性提供
7. ユーザー属性
提供要求
7 8. ユーザー
属性提供
OpenID ユーザー UserInfo
8
クライアント
プロバイダ情報
エンドポイント

2. トークン 2
（クレーム）取得要求 4. アクセス・
4 トークンとID
トークンを返却
5（オプション）:
IDトークン検証 5
エンドユーザー
認可
要求 6（オプション）.
エンドポイント 6 検証結果返却
認可
サーバーチェックID
エンドポイント
1. サービスに 11. サービス
アクセス 1 11 提供

3

3. ユーザー
認証・認可


OpenID Connect Protocol Suite
「公式マップ」 …が、以下のほうが実態に近
http://openid.net/connect い気がする
Profiles
•OpenID Connect Basic Client
•Other Vendor Proprietary / Community Specific Profiles

Bindings
•OpenID Connect Standard
•Other Vendor Proprietary / Community Specific Bindings

Optional Functionality
Endpoints and •OpenID Connect Discovery
•OpenID Connect Dynamic Client
associated message Registration
•OpenID Connect Session
formats Management
•OpenID Connect Messages •Other Vendor Proprietary /
Community Specific Functionality

Underpinnings


OpenID Connect のユースケース
1. シンプルな認証結果と属性情報の取得
OpenID Connectフローの処理の結果、クライアントは認可サーバーから
id_tokenとアクセス・トークンを得る
認証結果: id_tokenを検証し取得
id_token
▪ JWT(JSON Web Token)形式
▪ JWS (JSON Web Signature)により署名
▪ user_id、auth_timeなどが含まれている
検証方法
▪ 取得したクライアント自身がid_tokenを検証
▪ 外部の「Check IDエンドポイント」にid_tokenを送付し、検証を依頼
属性情報: アクセス・トークンを用いて取得
クライアントはフロー開始時（認可リクエスト）のscopeに、取得したい「クレーム」を指定
▪ 指定可能なクレームはprofile (一般的なユーザー属性(address, emailを除く)), address (住所),
email (メールアドレス) の3種類（複数同時に指定可能）
取得したアクセス・トークンを用いてUserInfoエンドポイントにアクセスし、属性を取得
▪ JSON形式


2. 仕様に規定されている以外の属性の取得
認可リクエストのscopeに独自 例: もし「edupersonクレーム」
の「クレーム」を指定を作る場合
さらに認可リクエストに「リクエ scopeにedupersonを指定
スト・オブジェクト」を付加し、要 リクエスト・オブジェクトとして以下
求する属性を指定の内容を指定
{
リクエスト・オブジェクト "user_id": null,
"urn:mace:dir:attribute-def:cn" : {"optional": true},
"urn:mace:dir:attribute-def:sn" : {"optional": true},
認可サーバーへのリクエスト・パ "urn:mace:dir:attribute-def:givenName" : {"optional": true},
"urn:mace:dir:attribute-def:mail" : null
ラメータをJWT化したもの }

認可リクエストへの付加方法 UserInfoにアクセスすることによ
▪ requestパラメータの値としてリクエり、以下の属性を取得
スト・オブジェクトを指定 {
"user_id": "248289761001",
▪ request_uriパラメータの値として、 "urn:mace:dir:attribute-def:cn" : "John Bradley",
"urn:mace:dir:attribute-def:sn" : "Bradley",
リクエスト・オブジェクトの場所を指 "urn:mace:dir:attribute-def:givenName" : "John",

定 "urn:mace:dir:attribute-def:mail" "ve7jtb@ve7jtb.com"
}


3. ユーザー認証の保証レベルの指定

認可リクエストに付加する 例
「リクエスト・オブジェクト」に、 リクエスト・オブジェクトとして
要求する保証レベルを指定以下の内容を指定
"id_token":

 ユーザー認証後得られた {
"claims":
{

id_tokenに、保証レベルが "auth_time": null,
“acr": { "values":["2"] }
},
含まれる }
"max_age": 86400,

ユーザー認証後取得した
id_tokenに以下の内容が含ま
れる
“acr": {"values":["3","2"]}


4. UserInfoエンドポイントの外部にあるクレームの取得
UserInfoから提供する外部のクレームとして、「集約
（aggregated）クレーム」と「分散（distributed）クレーム」を規
定
集約（aggregated）クレーム
UserInfoエンドポイントから提供されるクレームの中に、外部クレー
ムの「実体」が含まれる
▪ その「実体」はJWT形式に変換して含まれることにより、他のクレームと区別さ
れる
分散（distributed）クレーム
UserInfoエンドポイントから提供されるクレームの中に、外部クレー
ムを取得するための情報が含まれる
▪ 場合によっては、取得するための情報としてアクセス・トークンが指定されてい
る

5. クライアントによるOpenIDプロバイダのディスカバリ

OpenID Connect Discovery
エンドユーザーが指定した識別子をもとに、OpenIDリライング・パー
ティがOpenIDプロバイダを発見する仕組みを定義
▪ OpenID 2.0にて実現されていた機能と同様
識別子は以下のどちらかであるべきである (SHOULD)
▪ メールアドレス or URL
識別子を元にOpenIDリライング・パーティは、SWD (Simple Web
Discovery) により、OpenIDプロバイダを発見する
GET /.well-known/simple-web-discovery?principal=joe%40example.com&service=http%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer
HTTP/1.1 Host: example.com

HTTP/1.1 200 OK
Content-Type: application/json

{
"locations":["https://server.example.com"]
}


6. クライアント情報の動的な登録

OpenID Connect Dynamic Client Registration
OpenIDプロバイダとOpenIDリライング・パーティとが、動的に信頼
関係を確立する仕組みを定義
▪ OpenID 2.0にて実現されていた機能と同様
OpenIDリライング・パーティがOpenIDプロバイダの「クライアント登
録エンドポイント」に、自身を登録するようリクエスト
▪ 成功した場合、レスポンスとしてclient_id/client_secretが返却される
POST /connect/register HTTP/1.1 HTTP/1.1 200 OK
Accept: application/x-www-form-urlencoded Content-Type: application/json
Host: server.example.com Cache-Control: no-store

type=client_associate {
&redirect_uris=https://client.example.com/callback%20https://client.exam "client_id":"SlAV32hkKG",
ple.com/callback2
&logo_url=https://client.example.com/logo.png "client_secret":"cf136dc3c1fd9153029bb9c6cc9ecead918bad9887fce6c9
&user_id_type=pairwise 3f31185e5885805d",
&sector_identifier_url=https://othercompany.com/file_of_redirect_uris_for "expires_in":3600
_our_sites.js }
&token_endpoint_auth_type=client_secret_basic
&jwk_url=https://client.example.com/my_rsa_public_key.jwk
&userinfo_encrypted_response_algs=RSA1_5%20A128CBC

7. セッション管理

OpenID Connect Session Management
OpenIDプロバイダ（認可サーバー）と、その認可サーバーをユー
ザー認証に利用するOpenIDリライング・パーティ（サードパーティ）と
の間での、セッションのライフサイクル管理（生成、利用、破棄）の仕
組みを定義
id_tokenを利用


OpenID Connectの今後のロードマップ

2011/12/24 ~ 2012/02/06: Implementer’s Drafts Review
2012/02/14 (予定): Official Implementer’s Draft
その後、最終仕様に


OpenID Connect, December 2011

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to OpenID Connect, December 2011

Similar to OpenID Connect, December 2011 (20)

More from Tatsuo Kudo

More from Tatsuo Kudo (18)

Recently uploaded

Recently uploaded (12)

OpenID Connect, December 2011

Editor's Notes