OpenID Connect 入門〜コンシューマーにおけるID連携のトレンド〜

2015.8.26
OpenID ファウンデーション・ジャパン
倉林雅
OpenID Connect 入門 
∼コンシューマーにおけるID連携のトレンド∼

倉林林雅（kura）
OpenID ファウンデーション・ジャパン 
　　　　　　　　エヴァンジェリスト
ヤフー株式会社 IDサービスエンジニア
ID厨
@kura_̲lab

アジェンダ
1. 解説の前に
2. OpenID Connectの特徴
3. OpenID Connectの流れ
4. IDトークンについて
5. UserInfo Endpointについて

RPはつらいよ
数年年に⼀一度度くらいの頻度度で 
新しい認証・認可プロトコルがでてくる
…SAML・OpenID・OAuth 1.0・OAuth 2.0
対応するにも実装⽅方法全然違う
SOAP or RESTful / XML or JSON

RPはつらいよ
これまでのプロトコルに⽐比べて 
　　　　　　　　OpenID Connectは実装が簡単
いろいろなユースケースに対応している
Apps：Web・Native
Flow：Authorization Code・Implicit・Hybrid

RPはつらいよ
それぞれ実装⽅方法、検証⽅方法が微妙に異異なっていて
複数のクライアント・フローを実装するのはツライ
ですが、パスワードを⾃自前で管理理するコストを 
　　　　　　　　　　　　　考えれば全然楽なもの

IdPはもっとつらいよ
何世代も前のプロトコルもまだまだ現役
改修するにもビルドもできなくてメンテがツライ
パスワードの管理理はかなりセンシティブ
ハッシュ化・アクセス制限

RPはつらくない
IdPに⽐比べたらRPはそこまでつらくない
ぜひOpenID Connectを覚えてかえってください！

OpenID Connect
2014年2月27日ローンチ
OpenID ConnectはOAuth 2.0を 
拡張したプロトコル
OpenIDって名前がついてますが、 
OpenID 2.0とは異なります

基本的にOpenIDは認証の技術
（OpenID AXで属性を取得できますが）
OpenIDは認証

OAuth 1.0・OAuth 2.0は認可の技術
ユーザーのリソースアクセス（Web API）が目的
OAuthは認可

認証も認可も
認証も認可もやりたい場合は 
OpenIDもOAuthも実装しなくてはいけない
そこで実装しやすいOAuth 2.0を拡張して 
認証機能を追加
認可認証
OpenID Connect

さらに属性取得機能も
よく利用されるユーザーの属性情報APIの 
仕様も定義されている
ユーザー識別子・氏名・性別・生年・ 
住所・メールアドレスなど
認可認証
OpenID Connect
属性取得

OpenID Connect
ID連携のトレンド！

http://openid.net/connect/

OpenID Connect 認証フロー
Authorization Code Flow
サーバーサイドで認証
Implicit Flow
クライアントサイドで認証
Hybrid Flow
サーバーサイド・クライアントサイドの両方で認証

基本のフローをみてみよう
基本となる「Authorization Code Flow」を 
まずは覚えよう
OAuth 2.0のフローと比較しながら 
OpenID Connectで追加された処理と 
ポイントを確認しよう

OAuth 2.0

IdPRPEnd-User
Resource
Server
Start OAuth

IdPRPEnd-User
Authorization Request (Redirect)
Resource
Server
Start OAuth

IdPRPEnd-User
Resource
Server
Start OAuth
Login / Consent

IdPRPEnd-User
Resource
Server
Start OAuth
Authorization Code (Redirect)
Login / Consent

IdPRPEnd-User
Resource
Server
Start OAuth
Login / Consent
Token Request
Access Token / Refresh Token

IdPRPEnd-User
Resource
Server
Start OAuth
Login / Consent
Token Request
Access Token / Refresh Token
Resource Access
Resource

OpenID Connect

IdPRPEnd-User
UserInfo
Endpoint
Start OpenID Connect

IdPRPEnd-User
UserInfo
Endpoint

HTTP/1.1 302 Found
Location: https://server.example.com/authorize?
response_type=code
&scope=openid%20proﬁle%20email
&client_id=s6BhdRkqt3
&state=af0ifjsldkj
&nonce=n-0S6_WzA2Mj
&redirect_uri=https%3A%2F
%2Fclient.example.org%2Fcb
Authorization Request

HTTP/1.1 302 Found
response_type=code
&state=af0ifjsldkj
&nonce=n-0S6_WzA2Mj
Scopeパラメーターに
openid は必須

HTTP/1.1 302 Found
response_type=code
&state=af0ifjsldkj
&nonce=n-0S6_WzA2Mj
取得する属性情報を指定

HTTP/1.1 302 Found
response_type=code
&state=af0ifjsldkj
&nonce=n-0S6_WzA2Mj
CSRF対策のランダム文字列を指定
セッションにひも付けて保存しておく

HTTP/1.1 302 Found
response_type=code
&state=af0ifjsldkj
&nonce=n-0S6_WzA2Mj
リプレイアタック対策のランダム文字列を指定
セッションにひも付けて保存しておく

IdPRPEnd-User
UserInfo
Endpoint
Login / Consent

HTTP/1.1 302 Found
Location: https://client.example.org/cb?
code=SplxlOBeZQQYbYS6WxSbIA
&state=af0ifjsldkj
Authorization Response

HTTP/1.1 302 Found
&state=af0ifjsldkj
Authorization Code（認可コード） 
がクエリに付与されて返却される

HTTP/1.1 302 Found
&state=af0ifjsldkj
セッションにひも付けておいた
State値と比較
値が一致しない場合は処理を中断

IdPRPEnd-User
UserInfo
Endpoint
Login / Consent
Token Request

POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
Authorization: Basic
czZCaGRSa3F0MzpnWDFmQmF0M2JW
grant_type=authorization_code 
&code=SplxlOBeZQQYbYS6WxSbIA
Token Request

Token Request
Basic認証
base64_encode(Client_ID . : . Secret);

Token Request
取得したAuthorization Codeを指定

Token Request
SecretやAuthorization Codeを 
扱うので POST メソッド

IdPRPEnd-User
UserInfo
Endpoint
Login / Consent
Token Request
Access Token / Refresh Token / ID Token

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
"access_token": "SlAV32hkKG",
"token_type": "Bearer",
"refresh_token": "8xLOxBtZp8",
"expires_in": 3600,
"id_token":
“eyJhbGciOi6IjFlOWdkazcifQ.eyJewogImlzc6ICJzZCaGRSa3F0MyIsCiA
ibm9uY2UiOiODA5NzAKfQ.eyJggW8hZ16IcmD3HP99Obi1PRs-
cwhJ3LO-p146waJMzqg"
}
Token Response

HTTP/1.1 200 OK
Pragma: no-cache
{
"expires_in": 3600,
"id_token":
}
Token Response
JSON形式（XMLじゃない）

HTTP/1.1 200 OK
Pragma: no-cache
{
"expires_in": 3600,
"id_token":
}
Token Response
Access Tokenと 
Refresh Tokenを取得

HTTP/1.1 200 OK
Pragma: no-cache
{
"expires_in": 3600,
"id_token":
}
Token Response
Access Tokenは Bearer形式
Authorization: Bearer <Access Token>

HTTP/1.1 200 OK
Pragma: no-cache
{
"expires_in": 3600,
"id_token":
}
Token Response
ID Token（認証用トークン）を取得
シグネチャとデコードして各パラメーターを検証

HTTP/1.1 200 OK
Pragma: no-cache
{
"expires_in": 3600,
"id_token":
ibm9uY2UiOiODA5NzAKfQ.JggW8hZ16IcmD3HP99Obi1PRs-
}
Token Response
eyj...eyj...（テンション↑↑）

IdPRPEnd-User
UserInfo
Endpoint
Login / Consent
Token Request
Resource Access

GET /userinfo HTTP/1.1
Authorization: Bearer SlAV32hkKG…segsef
UserInfo Request

GET /userinfo HTTP/1.1
Authorization: Bearer SlAV32hkKG…segsef
UserInfo Request
Bearerトークン
Authorization: Bearer <Access Token>

IdPRPEnd-User
UserInfo
Endpoint
Login / Consent
Token Request
Resource Access
Resource

HTTP/1.1 200 OK
{
"sub": "248289761001",
"name": "Jane Doe",
"given_name": "Jane",
"family_name": "Doe",
"preferred_username": "j.doe",
"picture": “http://example.com/janedoe/me.jpg”,
"email": "janedoe@example.com"
}
UserInfo Response

HTTP/1.1 200 OK
{
"sub": "248289761001",
"name": "Jane Doe",
}
UserInfo Response
JSON形式（XMLじゃない）

HTTP/1.1 200 OK
{
"sub": "248289761001",
"name": "Jane Doe",
}
UserInfo Response
ユーザー識別子（openid）

HTTP/1.1 200 OK
{
"sub": "248289761001",
"name": "Jane Doe",
}
UserInfo Response
プロフィール情報（proﬁle）

HTTP/1.1 200 OK
{
"sub": "248289761001",
"name": "Jane Doe",
}
UserInfo Response
メールアドレス（email）

GREEログイン Y!ログイン YConnect 同意画面 GREE登録
倉林雅
倉林
雅

倉林雅
倉林
雅
RPのログインボタン
OpenID Connect開始

倉林雅
倉林
雅
IdPのログイン 
（認証機能）

倉林雅
倉林
雅
アプリへの
アクセス確認
属性・API
利用内容

倉林雅
倉林
雅氏名・生年・性別 
のプリセット 
（属性情報取得機能）

issuer が audience のために
subject を認証したかを⽰示すトークン
IDトークンとは

Identity Provider

Relying Party

End-User

Facebook が SlideShare のために
kura を認証したかを⽰示すトークン

Yahoo! が GREE のために
kura を認証したかを⽰示すトークン

フォーマット
JSON Web Token
JSONを（URLSafeな）Base64エンコードした
シグネチャ（署名）付きトークン
ヘッダー・ペイロード・シグネチャで構成される
シグネチャはハッシュ（HMAC）と公開鍵暗号
（RSA・ECDSA）

{
“typ”:”JWT”,
“alg”:”RS256”
}
ヘッダー

{
“alg”:”RS256”
}
ヘッダー
タイプ：JSON Web Token
JWTで jot（ジョット）と発音

{
“alg”:”RS256”
}
ヘッダー
シグネチャのアルゴリズム
RSA-SHA256

{
“iss”:”https://auth.login.yahoo.co.jp”,
“sub”:”123456789”,
“aud”:”abcdefg”,
“nonce”:”xyz”,
“iat”:1291836800,
“exp”:1300819380
}
ペイロード

{
“sub”:”123456789”,
“iat”:1291836800,
“exp”:1300819380
}
ペイロード
issuer
IDトークンの発行者

{
“sub”:”123456789”,
“iat”:1291836800,
“exp”:1300819380
}
ペイロード
subject
ユーザー識別子（認証の対象者）

{
“sub”:”123456789”,
“iat”:1291836800,
“exp”:1300819380
}
ペイロード
audience
Client ID（IDトークンの払い出し先）

{
“sub”:”123456789”,
“iat”:1291836800,
“exp”:1300819380
}
ペイロード
セッションにひも付けておいた
Nonce値と比較する
値が一致しない場合は処理を中断

{
“sub”:”123456789”,
“iat”:1291836800,
“exp”:1300819380
}
ペイロード
issue at
発行時のUnixタイムスタンプ
有効期限は発行から10分くらいにするとよいかも

{
“sub”:”123456789”,
“iat”:1291836800,
“exp”:1300819380
}
ペイロード
expiration
IDトークンの有効期限
RPで発行するCookieの有効期限の基準にしてもよい
同じ期限にしなくてもよい

{
“alg”:”RS256”
}
 
{
“iss”:”https://example.com”,
“sub”:”123456789”,
“iat”:1291836800,
“exp”:1300819380
}
シグネチャ

{
“alg”:”RS256”
}
 
{
“iss”:”https://example.com”,
“sub”:”123456789”,
“iat”:1291836800,
“exp”:1300819380
}
シグネチャ
Base64エンコード
URL Safeに変換
+ → -
/ → _
= →

eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
 
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogIm
h0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ
シグネチャ

 
シグネチャ
JSONの「{ 」をBase64エンコードすると
先頭が「eyJ」になる（テンション↑↑）

. 
シグネチャ
ヘッダーとペイロードを
. （ピリオド）で連結

. 
シグネチャ
秘密鍵でシグネチャを生成
（RSA-SHA256）

. 
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
シグネチャ
生成されたシグネチャを 
Base64エンコード（URL Safe）

 
IDトークン

. 
.
IDトークン
ヘッダーとペイロードを
. （ピリオド）で連結

. 
.
IDトークン
IDトークン完成

. 
.
IDトークンの検証
「ヘッダー + . + ペイロード」を
入力データとする

. 
.
IDトークンの検証
入力データとシグネチャを公開鍵で検証する

UserInfo
OpenID Connectではよく利用される氏名や住所、
メールアドレスなどの属性情報を取得しやすいよう
に属性情報（Claim）を定義している
OpenID Connect対応のIdP各社から同じScopeを
指定して同じフォーマットで属性情報を取得できる

定義されている属性
メンバー scope 説明
sub - ユーザー識別子
name profile 氏名
given_name profile 名
family_name profile 姓
middle_name profile ミドルネーム
nickname profile ニックネーム
preferred_ 
username
profile 簡略名
profile profile
プロフィール情報
のURL
picture profile
プロフィール画像
のURL
website profile サイトURL
email email メールアドレス
email_verified email
メールアドレスの
検証済みの有無
gender profile 性別
birthdate profile 生年月日

定義されている属性
zoneinfo profile タイムゾーン
locale profile 国コード
phone_number phone 電話番号
phone_number_verified phone
電話番号の検証済み 
の有無
address address 住所
updated_at profile 属性情報更新日時

UserInfoを活用しよう
UserInfoで取得できる属性情報 
（⽒氏名・住所・メールアドレスなど） 
で新規登録フォームをプリセット
わずらわしいフォームの⼊入⼒力力を 
省省略略できてコンバージョンアップ 
（⾦金金融系・コマース系サイトなど）
倉林雅
倉林
雅

まとめ
1. OpenID Connectの特徴
OAuth 2.0ベース・認証・認可・属性取得
2. OpenID Connectの流れ
基本となるAuthorization Code Flow
3. IDトークンについて
JSON Web Token
4. UserInfo Endpointについて
よく利用しそうな属性情報が定義されている

ご清聴ありがとう
ございました。

OpenID Connect 入門〜コンシューマーにおけるID連携のトレンド〜

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to OpenID Connect 入門〜コンシューマーにおけるID連携のトレンド〜 (20)