- 追加された行はこの色です。
- 削除された行はこの色です。
「[[マイクロソフト系技術情報 Wiki>http://techinfoofmicrosofttech.osscons.jp/]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。
-[[戻る>OpenID / OAuth / OpenID Connect]]
* 目次 [#tc83c978]
#contents
*概要 [#bb0360e2]
-[[OpenID Connect]]の用途としては、「認証の仕様である」と言ってイイ。
-しかし技術的には、「[[ID トークン>#ofb73c59]]発行のための仕様」と考えたほうがイイ。
-[[JWT]]
--この[[ID トークン>#ofb73c59]]と呼ばれる[[トークン]]は[[JWT]]アサーションを使用している。
--従って、[[JWT]]の生成（署名）・検証の仕組みについては、[[JWT]]を参照のこと。
--このページでは、[[OpenID Connect]]の認証用の[[JWT]]アサーションの~
トークン・プロファイル（オプション仕様）についてを説明する。
**特徴 [#n9af5768]
***モジュラーデザイン [#he3af831]
ユースケースに対応するため、
-複数の仕様から成り立っており、
-それらをモジュール的に組み合わせることで
多様な環境をサポートできる。
***プロトコル概要 [#a4aac78c]
ざっくり、リクエスト→認証・認可→ユーザ情報を取得。
+--------+ +--------+
| | | |
| |---------(1) AuthN Request-------->| |
| | | |
| | +--------+ | |
| | | | | |
| | | End- |<--(2) AuthN & AuthZ-->| |
| | | User | | |
| RP | | | | OP |
| | +--------+ | |
| | | |
| |<--------(3) AuthN Response--------| |
| | | |
| |---------(4) UserInfo Request----->| |
| | | |
| |<--------(5) UserInfo Response-----| |
| | | |
+--------+ +--------+
***[[OAuth]] 2.0への認証拡張 [#u9589aff]
[[OAuth]] 2.0との違いは、認証拡張機能が追加実装された点にある。
-[[OAuth]] 2.0では
--認証機能（「認証Endpointから[[ユーザー属性クレーム群>#kb7212b1]]を取得する」）の仕様が無かった。
--このため、この部分の拡張仕様（認証Endpoint）に方言があり、実装上問題だった。
-これに対し[[OpenID Connect]]では、
--[[ユーザー属性クレーム群>#kb7212b1]]取得のEndpointが[[ユーザー情報エンドポイント>#k1d9c845]]に標準化された。
--これによって「認可」だけでなく「認証」の仕様も標準化された。
-参考
--Idcon11 implicit demo~
http://www.slideshare.net/ritou/idcon11-implicit-demo
--matake
---OpenID Connect 101 @ OpenID TechNight vol.11~
http://www.slideshare.net/matake/technight11
---OAuth認証再考からのOpenID Connect #devlove~
http://www.slideshare.net/matake/connect-intro-dev-love
--OpenID Connect 入門 〜コンシューマーにおけるID連携のトレンド〜~
---OAuth 2.0 Authorization Code Flow~
http://www.slideshare.net/kura_lab/openid-connect-id/21
---OpenID Connect Authorization Code Flow~
http://www.slideshare.net/kura_lab/openid-connect-id/28
--OpenID Connectユースケース、OAuth 2.0の違い・共通点まとめ - Build Insider~
http://www.buildinsider.net/enterprise/openid/connect
**仕様の柱 [#p054dc3f]
***[[フロー>#p1446f50]] [#oa1adfa6]
[[OAuth]] 2.0に認証結果とプロフィールの受渡し機能を追加。
-[[Authorization Code Flow>#mcde509a]]
-[[Implicit Flow>#e7adf5c2]]
-[[Hybrid Flow>#l565139a]]
***[[ID トークン>#ofb73c59]] [#x6b0558c]
-[[基本構造>#ofb73c59]]
-[[取得方法（認証のシーケンス）>#p1446f50]]
-[[ユーザー属性クレーム群>#kb7212b1]]
***追加のエンドポイント [#ib0fba2c]
-[[ユーザー情報エンドポイント>#k1d9c845]]
*フロー [#p1446f50]
-Final: OpenID Connect Core 1.0 incorporating errata set 1 > 3. Authentication~
http://openid.net/specs/openid-connect-core-1_0.html#Authentication
**Authorization Code Flow [#mcde509a]
-scope="* openid *"
-response_type="code"
***概要 [#t8011dab]
[[OAuth]] 2.0 からのステップ上の拡張部分は無い。
ただし、
-クライアントは[[ID トークン>#ofb73c59]]を使用して、[[ユーザー属性クレーム群>#kb7212b1]]を取得して検証でき、
-アクセス先がResources ServerのEndpointが[[ユーザー情報エンドポイント>#k1d9c845]]に特定されており、~
ここから、認証されたユーザとして[[ユーザー属性クレーム群>#kb7212b1]]を取得できる。
***ステップ [#a56bf502]
朱書きは、[[OAuth]] 2.0 からのステップ上の変更・拡張部分。
The Authorization Code Flow goes through the following steps.
+Client prepares an Authentication Request containing the desired request parameters.
+Client sends the request to the Authorization Server.
+Authorization Server Authenticates the End-User.
+Authorization Server obtains End-User Consent/Authorization.
+Authorization Server sends the End-User back to the Client with an Authorization Code.
+Client requests a response using the Authorization Code at the Token Endpoint.
+Client receives a response that contains an &color(red){ID Token and}; Access Token in the response body.
+&color(red){Client validates the ID token and retrieves the End-User's Subject Identifier.};
-[[以下で説明しているシーケンス>#h438d001]]
**Implicit Flow [#e7adf5c2]
-scope="* openid *"
-response_type=
--"id_token"
--"id_token token"
***概要 [#aaa498b8]
-クライアント（User-Agentやスマホネイティブ）は、~
[[ID トークン>#ofb73c59]]を使用して、[[ユーザー属性クレーム群>#kb7212b1]]を取得して検証でき、
-標準化された[[ユーザー情報エンドポイント>#k1d9c845]]などから、~
認証されたユーザとして[[ユーザー属性クレーム群>#kb7212b1]]を取得できる。
***ステップ [#j537479c]
朱書きは、[[OAuth]] 2.0 からのステップ上の変更・拡張部分。
The Implicit Flow follows the following steps:
+Client prepares an Authentication Request containing the desired request parameters.
+Client sends the request to the Authorization Server.
+Authorization Server Authenticates the End-User.
+Authorization Server obtains End-User Consent/Authorization.
+Authorization Server sends the End-User back to the Client with an &color(red){ID Token and, if requested, an}; Access Token.
+&color(red){Client validates the ID token and retrieves the End-User's Subject Identifier.};
-[[以下で説明しているシーケンス>#v2c717b3]]
**Hybrid Flow [#l565139a]
-scope="* openid *"~
[["code token"の場合も必要！>http://openid.net/specs/openid-connect-core-1_0.html#code-tokenExample]]
-response_type=
--"code token"
--"code id_token"
--"code id_token token"
***概要 [#a3306ca0]
[[ID トークン>#ofb73c59]]と同時に、アクセストークンや認可コードが一緒に発行される。~
-Hybrid な Flowであるため、
--前段が、[[Authorization Code Flow>#mcde509a]]、
--中段が、[[Implicit Flow>#e7adf5c2]]に近いフローになる。~
--後段は、Hybrid Flowの独自のフローになる。
-前段・中段・後段
--前段：[[Authorization Code Flow>#mcde509a]]~
スターターから、認可エンドポイントへのリクエストまで。
--中段：[[Implicit Flow>#e7adf5c2]]~
認可エンドポイントからRedirectエンドポイントへ、~
Implicitなフラグメント部を使用したリダイレクトをするまで。
--後段：Hybrid Flow~
UserAgent側でフラグメント部のcode, id_token, tokenを取得、
---id_tokenはUserAgentで利用する。~
[[ID トークン>#ofb73c59]]を使用して、[[ユーザー属性クレーム群>#kb7212b1]]を取得して検証できる。
---tokenはUserAgentで利用する。~
[[ユーザー情報エンドポイント>#k1d9c845]]などから、~
認証されたユーザとして[[ユーザー属性クレーム群>#kb7212b1]]などを取得できる。
---codeをClientで利用する。~
その後、UserAgentがClientにcodeを送付し、~
Client側でcodeを使用してアクセストークン・リクエストを行う。
-参考
--[[OAuth 2.0 Multiple Response Type Encoding Practices]]
--Yahoo! ID連携:Hybridフロー - Yahoo!デベロッパーネットワーク~
https://developer.yahoo.co.jp/yconnect/v2/hybrid/
***ステップ [#q42c3018]
朱書きは、[[Authorization Code Flow>#mcde509a]]との差異。
The Hybrid Flow follows the following steps:
+Client prepares an Authentication Request containing the desired request parameters.
+Client sends the request to the Authorization Server.
+Authorization Server Authenticates the End-User.
+Authorization Server obtains End-User Consent/Authorization.
+Authorization Server sends the End-User back to the Client with an Authorization Code and,~
&color(red){depending on the Response Type, one or more additional parameters.};
+Client requests a response using the Authorization Code at the Token Endpoint.
+Client receives a response that contains an ID Token and Access Token in the response body.
+Client validates the ID Token and retrieves the End-User's Subject Identifier.
***ポイント [#x6b33770]
-codeをUserAgentからClientに渡す方法~
定義されていないが、クライアント側・サーバ側の違いはあるが、~
双方ともClientなので、恐らく、POSTなどでcodeをUserAgentからClientに渡せば良さそう。
-codeとtokenのaccess_tokenの差異~
セキュリティ特性によって以下が異なって良いと定義されている。
--scope
--expires_in
-ID Token Claim の追加要件
--Authorization Endpoint から返される ID Token に対して以下が必要になる。
---[[nonce>#d9a64ea2]]
---[[at_hash>#c007540d]]
---[[c_hash>#c007540d]]
--Authorization Endpoint と Token Endpoint から返されるID Token に対して以下が必要になる。
---iss Claim と sub Claim は同一でなければならない (MUST).
---Authentication イベントに関する Claim~
両方に同じ Claim を含めるべき(SHOULD).
---End-User に関する Claim~
Authorization Endpointから返すClaimは、~
Token Endpointから返すClaimより少なくしてよい (MAY).~
ただし、Claimが両方に存在する場合, その値は同値であるべき (SHOULD).
---at_hash および c_hash Claim~
Authorization Endpoint から返す ID Tokenに含める。~
Token Endpoint から返す ID Token からは省略可能。
*IDトークン [#ofb73c59]
-Final: OpenID Connect Core 1.0 incorporating errata set 1~
http://openid.net/specs/openid-connect-core-1_0.html
--2. ID Token~
http://openid.net/specs/openid-connect-core-1_0.html#IDToken
--3.3.2.11. ID Token (Hybrid Flow)~
http://openid.net/specs/openid-connect-core-1_0.html#HybridIDToken
**概要 [#fe1155a7]
-OpenID Connect で [[OAuth]] 2.0 を拡張した主要なクレームが、[[ID トークン>#ofb73c59]]。
-仕様全体を通してメッセージ形式に[[JWT]]を採用。
--メッセージ形式：[[JWT]]（JSON Web Tokenの略）
--クレーム暗号化：[[JWT]]の JWS or JWE を使用する。
-以下のクレームの値を含む[[クレームセット>#h586dfab]]。
--発行元のIdp（OP）識別子
--発行先のRP識別子（client_id）
--ユーザー識別子
--発行日時
-クレームの扱いについて[[外部クレーム>#jb63c82f]]機能を定義している。
--集約クレーム
--分散クレーム
**クレームセット [#h586dfab]
***必須クレーム群 [#ffe4c45b]
-iss (issuer) クレーム
--（[[OAuth]] 2.0で言う所の）Authorization Serverの識別子。
--URI形式が推奨
これは、OpenID Connect Discovery 1.0 仕様をサポートするのであれば、~
「{issクレームの値}/.well-known/openid-configuration」という URL で~
リクエストを受け付ける必要があるため。
-sub (subject) クレーム~
ユーザーテーブルのプライマリーキーやそれに準ずるもの。
-aud (audience) クレーム~
（[[OAuth]] 2.0で言う所の）クライアント識別子。
-exp (expiration time) クレーム
--JWT の有効期限
--Unix エポックからの経過秒数（ミリ秒ではなく秒）
-iat (issued at)クレーム
--JWT の発行日時
--Unix エポックからの経過秒数（ミリ秒ではなく秒）
***ケースバイケースなクレーム群 [#d9a64ea2]
-auth_time クレーム
--ユーザー認証時刻
--Unix エポックからの経過秒数（ミリ秒ではなく秒）
--リクエスト・パラメタやメタ情報設定次第で必須となるもよう。
-[[nonce>https://ja.wikipedia.org/wiki/%E3%83%8E%E3%83%B3%E3%82%B9]] クレーム
--リプレイアタック防止を目的とするクレーム。
--[[ID トークン>#ofb73c59]]発行依頼に付属するnonce 値を、そのまま埋め込む。
--[[Implicit Flow>#e7adf5c2]]、[[Hybrid Flow>#l565139a]]の場合は必須となるもよう。
***オプションのクレーム群 [#l52144f8]
-acr クレーム
--認証コンテキストのクラス
--必要に応じて再認証を催す。
--仕様で幾つか定義されているらしいが詳細不明。
-amr クレーム
--認証手法を示す。
--利用用途が不明。
--仕様範囲外、クレームの利用者が規則を決めて運用する。
-azp クレーム
--認可された対象者
--認証されたユーザと認可されたユーザが違うケースを想定している模様。
***[[Hybrid Flow>#l565139a]]のクレーム [#c007540d]
[[Hybrid Flow>#l565139a]]の場合、以下が必須。
-at_hash
--Access Token のハッシュ値~
ID Token の JOSE Header にある alg Header Parameterのアルゴリズムで使用されるハッシュアルゴリズムを用い、~
Access Token のASCII オクテット列からハッシュ値を求め、左半分を base64url エンコードした値。
--response_typeにid_tokenとtokenが含まれる時に必須だが、ソレ以外の場合は任意。
-c_hash
--Code のハッシュ値~
ID Token の JOSE Header にある alg Header Parameterのアルゴリズムで使用されるハッシュアルゴリズムを用い、~
Code のASCII オクテット列からハッシュ値を求め、左半分を base64url エンコードした値。
--response_typeにcodeとid_tokenが含まれる時に必須だが、ソレ以外の場合は任意。
***[[ユーザー属性クレーム群>#kb7212b1]] [#r21f1653]
その他、[[ユーザー属性クレーム群>#kb7212b1]]を格納する。
**外部クレーム [#jb63c82f]
Idp（OP）は、扱うクレームの内容によって、
-[[集約クレーム>#yfd0840d]]
-[[分散クレーム>#xaa4e17c]]
どちらを利用すべきかを判断する必要がある。
***集約クレーム（Aggregated Claims） [#yfd0840d]
-別のIdp（OP）が持つクレームを署名付きで提供すること。
-RPからリクエストを受けたIdp（OP）は、事前に取得していた、~
もしくは動的に取得した別のIdp（OP）のクレームをレスポンスに含む。
一定期間変更されないことが保証されており~
キャッシュの効果があるものは集約クレーム。
***分散クレーム（Distributed Claims） [#xaa4e17c]
クレームそのものではなく、問い合わせ先のURLを扱う。
-Publicなクレームの場合
--エンドポイントのURL
-ユーザー認可が必要な場合
--エンドポイントのURL
--OAuth 2.0のアクセストークン
をレスポンスに含む。
頻繁に更新されるものは分散クレーム。
**例 [#m4e7fa61]
***Google [#jaec1c75]
GoogleでOpenID Connectの認証で取得したクレームセット。~
（id_tokenそのものなのか？、[[ユーザー情報エンドポイント>#k1d9c845]]から取得したクレームか？）
{
"iss":"accounts.google.com",
"at_hash":"・・・", ← Hybrid Flowの追加クレーム
"email_verified":"true",
"sub":"ユーザーの一意識別子",
"azp":"認可された対象者のID.apps.googleusercontent.com",
"email":"・・・・",
"aud":"クライアント識別子.apps.googleusercontent.com",
"iat":JWT の発行日時（Unix時間）,
"exp":JWT の有効期限（Unix時間）
}
[[ココ>#v5e6dad3]]を見ると、これは恐らく、id_tokenなのだろうなと。
以下のGoogle公式のマニュアルにも記載があった。
-OpenID Connect | Google Identity Platform | Google Developers~
https://developers.google.com/identity/protocols/OpenIDConnect
*ユーザー属性クレーム群 [#kb7212b1]
-Final: OpenID Connect Core 1.0 incorporating errata set 1 > 5.1. Standard Claims~
http://openid.net/specs/openid-connect-core-1_0.html#StandardClaims
**Standard Claims [#c71c8ad5]
|項番|>|グループ名|意味|h
|~||クレーム名|~|h
|1|>|sub|ユーザーの一意識別子|
|2|>|profile|プロフィール|
|2-1|・|name|フルネーム|
|2-2|・|given_name|名|
|2-3|・|family_name|姓|
|2-4|・|middle_name|ミドルネーム|
|2-5|・|nickname|ニックネーム|
|2-6|・|preferred_username|好みのユーザー名|
|2-7|・|profile|プロフィールページの URL|
|2-8|・|picture|プロフィール画像の URL|
|2-9|・|website|Web サイトやブログの URL|
|2-10|・|gender|性別。female と male が定義済み。|
|2-11|・|birthdate|誕生日。YYYY-MM-DD。|
|2-12|・|zoneinfo|タイムゾーン。Europe/Paris など。|
|2-13|・|locale|ロケール。en-US など。|
|2-14|・|updated_at|情報最終更新日。Unix エポックからの経過秒数。|
|3|>|email|電子メール|
|3-1|・|email|電子メールアドレス|
|3-2|・|email_verified|電子メールアドレスが検証済みか否かの真偽値|
|4|>|phone|電話|
|4-1|・|phone_number|電話番号|
|4-2|・|phone_number_verified|電話番号が検証済みか否かの真偽値|
|5|>|address|住所 JSON object。書式は「5.1.1. Address Claim」に記載。|
|5-1|・|formatted|フォーマットされたフルメールアドレス、表示用・郵送用に使用|
|5-2|・|street_address|通り・番地、号室、私書箱、複数行の拡張された住所情報。|
|5-3|・|locality|City or locality|
|5-4|・|region|State, province, prefecture, or region.|
|5-5|・|postal_code|Zip code or postal code|
|5-6|・|country|Country name|
**多言語化 [#u1556f80]
-クレームによっては多言語化可能
-クレーム名に続いて"#ja-Kana-JP"などの言語タグを付与する。
*ユーザー属性クレーム群の格納要求 [#qb26baa1]
**scope値による格納要求 [#k95e5b83]
scope値によってユーザー属性クレーム群の格納要求を行うことができる。
-Final: OpenID Connect Core 1.0 incorporating errata set 1 >~
5.4. Requesting Claims using Scope Values~
http://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims
***グループ名 [#xc20fc3f]
[[前述のグループ名>#c71c8ad5]]（profile, email, phone, address）をscope値に指定可能。
***格納部位 [#z4362392]
-UserInfoエンドポイントからUserInfoレスポンス（JSON オブジェクト）として返される.
-response_type 値が id_token の場合、
--この場合、Access Token が発行されない。
--ユーザー属性クレーム群はID Token で返却される。
**クレーム要求JSONによる格納要求 [#lfaacf35]
-クレームをリスト化したJSON オブジェクトを使用して特定のクレームの返却を要求する。
--[[ユーザー属性クレーム群>#kb7212b1]]に含まれていない Claim を要求する唯一の方法。
--scope 値では指定することが出来ない[[ユーザー属性クレーム群>#kb7212b1]]の特定の組み合わせを要求する唯一の方法。
-Final: OpenID Connect Core 1.0 incorporating errata set 1 >~
5.5. Requesting Claims using the "claims" Request Parameter~
https://openid-foundation-japan.github.io/openid-connect-core-1_0.ja.html#ClaimsParameter
***トップレベルメンバ [#va260684]
-userinfoメンバ
--OPTIONAL.
--UserInfoエンドポイントへ返却を要求する個々のクレームのリスト。
--当メンバが存在した場合、
---scope 値で要求されたクレームに加え、
---当メンバでリストされたクレームも返却される。
--当メンバーが存在しなかった場合、
---scope 値で要求されたクレームのみが返却される。
---userinfoメンバを指定する際は、UserInfo Endpoint を使用するために、~
response_type に対し, Access Token を Client に発行するタイプの値を指定しなければならない。
-id_tokenメンバ
--OPTIONAL.
--[[ID トークン>#ofb73c59]]内に格納して返却を要求する個々のクレームのリストを示す。
--当メンバーが存在した場合、
---デフォルトのクレームに加え
---当メンバーでリストされたクレームも返却される。
--当メンバーが存在しなかった場合、
---デフォルトのクレームのみが返却される。
***クレーム要求JSONの例 [#pd68c57b]
クレーム要求JSONの例を以下に示す:
{
"userinfo":
{
"given_name": {"essential": true},
"nickname": null,
"email": {"essential": true},
"email_verified": {"essential": true},
"picture": null,
"http://example.info/claims/groups": null
},
"id_token":
{
"auth_time": {"essential": true},
"acr": {"values": ["urn:mace:incommon:iap:silver"] }
}
}
*ユーザー情報エンドポイント [#k1d9c845]
-Final: OpenID Connect Core 1.0 incorporating errata set 1 > 5.3. UserInfo Endpoint~
http://openid.net/specs/openid-connect-core-1_0.html#UserInfo
**概要 [#i3f298f2]
-OAuth 2.0のResource ServerのWebAPI
-HTTP的には、HTTPS必須
***リクエスト [#y620d43e]
-HTTP の GET と POST メソッドをサポートする。
-UserInfoリクエストの一例を示す:
GET /userinfo HTTP/1.1
Host: server.exampletechinfoofmicrosofttech.osscons.jp
Authorization: Bearer ・・・・・
***レスポンス [#k20c216c]
-UserInfoレスポンスは JSON オブジェクトとして返される。
--UserInfoクレームは JSON オブジェクトのメンバーとして返される。
--UserInfoレスポンスのクレームセットには、必ず sub (subject) クレームを含める。
--[[ユーザー属性クレーム群>#kb7212b1]]に加え、そこに明記されていないクレームも返却可能。
--Idp（OP）は要求された クレームの値を、必ずしも返さなくてもよい。
--クレームが返されない場合、null や空文字列ではなく、JSON オブジェクトのメンバーから除かれるべき。
-JWTによる署名 or 暗号化、若しくは、署名 and 暗号化を行う場合
--Claim は JWT で返されるため、Content-Type は application/jwtとする。
--署名する場合、subに加え、iss (issuer) Claim と aud (audience) Claim を含むべき。
--署名と暗号化の両方が要求された場合、レスポンスは [[JWT]] で定義されているように、~
結果はネストされた [[JWT]] となり、 署名した後に暗号化しなければならない。
-以下に UserInfoレスポンスの一例を示す:
HTTP/1.1 200 OK
Content-Type: application/json
{
"sub": "ユーザID 的 な情報",
"name": "Jane Doe",
"given_name": "Jane",
"family_name": "Doe",
"preferred_username": "j.doe",
"email": "janedoe@techinfoofmicrosofttech.osscons.jp",
"picture": "http://techinfoofmicrosofttech.osscons.jp/janedoe/me.jpg"
}
-クライアントによるUserInfoレスポンスの検証
--TLS サーバー証明書チェックを通じてIdp（OP）を検証する。
--UserInfoレスポンスが[[JWT]]の場合、署名検証や復号化を行う。
--[[ID トークン>#ofb73c59]]とUserInfoクレームのsubが一致することを検証する必要がある。
**[[Discovery、Dynamic Client Registration>#h5793a09]]との関連 [#u39da1e3]
-この仕様は、[[Discovery、Dynamic Client Registration>#h5793a09]]と関係がある。
-設定によって、
--[[ID トークン>#ofb73c59]]相当の情報が、
--[[JWT]] 形式もしくは [[JSON]] 形式で返される。
--設定によって、[[JWT]]の署名アルゴリズムも影響を受ける。
*暗号関連 [#h9b10c6c]
**共通 [#x7229242]
***共通鍵暗号化方式 [#e5523f68]
client_secret の UTF-8 オクテットを使用する。
***公開鍵暗号化方式 [#j91b8b04]
-公開鍵は[[JWK Set>JWK#od5799a4]]で公開する必要がある。
-[[JWK Set>JWK#od5799a4]]中に複数の鍵がある場合、[[JWS]]・[[JWE]]ヘッダにkidが必要。
**署名 [#o03ae7d8]
***共通鍵暗号化方式 [#mbbefc9e]
-MACベースの署名
-[[JWS]]ヘッダに alg パラメタ値を設定
-[[MAC 鍵>#e5523f68]]は、アルゴリズムの最低限のオクテット長を持つ必要がある。
--例えばHS256では, 最低でも32オクテットが必要になる。
--アルファベットに限定される場合、それ以上のオクテットが必要となる。
***公開鍵暗号化方式 [#qfdd7483]
-RSAおよびECDSA署名
-[[JWS]]ヘッダに alg パラメタ値を設定
**暗号化 [#f27913d9]
***共通鍵暗号化方式 [#b1a871e7]
-[[鍵>#e5523f68]]をハッシュし切り詰めた左側を使用する。
-ハッシュ・アルゴリズムは、以下を用いる。
--256ビット以下の鍵には SHA-256
--257-384ビットの鍵には SHA-384
--385-512ビットの鍵には SHA-512
-例えば
--A128KW~
SHA-256ハッシュを切り詰めて128ビットを取り出す。
--512ビット以上の鍵が必要になった場合~
client_secretから鍵を導出する何らかの拡張仕様を定義する。
***公開鍵暗号化方式 [#v10f5f1a]
-RSA~
ランダムな Content Encryption Key によって[[JWS]]をRSA暗号化アルゴリズムで暗号化する。
-Elliptic Curve~
--[[JWE]]ヘッダの epk に指定する短命な Elliptic Curve公開鍵を生成する。
--ECDH-ES アルゴリズムを用いContent Encryption Keyの鍵を交換し、[[JWS]]を暗号化する。
**鍵のローテーション [#tdf4ee76]
-jwks_uri + [[JWK Set>JWK#od5799a4]] + kidでローテーションする。
-Cache-Control ヘッダに max-age を含め[[JWK Set>JWK#od5799a4]]のキャッシュを適切にコントロールする。
***署名 [#mc831a6c]
署名者がローテーションを行う。
-署名者は、
--jwks_uriで、秘密鍵に対応する公開鍵のセットを[[JWK Set>JWK#od5799a4]]として公開する。
--[[JWS]]ヘッダに、署名に使用した公開鍵（[[JWK Set>JWK#od5799a4]]中の kid）を含める
-検証者は、
--jwks_uriで指定した場所から[[JWK Set>JWK#od5799a4]]を取得する。
--[[JWS]]ヘッダの kid から署名に使用した公開鍵を、上記の[[JWK Set>JWK#od5799a4]]中から取得する。
--取得した公開鍵を使用して署名の検証を行う。
***暗号化 [#q3cf4c4c]
複合化を行う主体がローテーションを行う。~
（古い鍵が使用される可能性があるため、鍵を暫く保持する）。
-複合化を行う主体は、
--jwks_uriで、秘密鍵のセットを[[JWK Set>JWK#od5799a4]]として公開する。
-暗号化を行う主体は、
--jwks_uriで指定した場所から[[JWK Set>JWK#od5799a4]]を取得する。
--[[JWE]]ヘッダに、暗号化に使用した秘密鍵（[[JWK Set>JWK#od5799a4]]中の kid）を含める。
-複合化を行う主体は、
--[[JWE]]ヘッダの kid から暗号化に使用した秘密鍵を、上記の[[JWK Set>JWK#od5799a4]]中から取得する。
--取得した秘密鍵を使用して複合化を行う。
*その他 [#xce3cadb]
比較的、重要度の高い仕様についてまとめる。
-OAuth & OpenID Connect 関連仕様まとめ - Qiita~
https://qiita.com/TakahikoKawasaki/items/185d34814eb9f7ac7ef3
**追加のクライアント認証 [#y7bdab62]
Client Registrationの際、Tokenエンドポイントにアクセスする際に追加のクライアント認証を登録可能。
***client_secret_XXXX [#b5b6ff3c]
-client_secret_basic
--既定値、[[OAuth]] 2.0と同じ方法。
--client_idとclient_secretを~
HTTP Basic 認証スキーマで送信する。
-client_secret_post~
Client Credential をリクエストボディに含めて送信する。
***jwt [#cee38fe3]
-client_secret_jwt~
[[前述>#h9b10c6c]]に従い、HS256のアルゴリズムを使用する。
-private_key_jwt~
[[前述>#h9b10c6c]]に従い、RS256のアルゴリズムを使用する。
-共通項
--[[JWT bearer token authorizationグラント種別]]に準拠~
（リンク先の「クライアント認証あり」の場合に相当する）
--クレーム
---iss（REQUIRED）
---sub（REQUIRED）
---aud（REQUIRED
---jti（REQUIRED）
---exp（REQUIRED
---iat（OPTIONAL）
***none [#a886d9f6]
以下のケースでTokenエンドポイントでの認証を行わない場合。
-Implicit Flow
-Public クライアント
-およびその他の何らかの認証手段を用いる場合
**claimsリクエスト・パラメタ [#e26320e4]
-通常、scopeパラメタを使用して、claimを要求するが、~
http://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims
-claimsパラメタを使用して、claimを要求することもできる。~
http://openid.net/specs/openid-connect-core-1_0.html#ClaimsParameter
-claimsリクエスト・パラメタでは、~
userinfoと、id_tokenに対するclaimを要求できる。
-以下、claimsリクエスト・パラメタの値
{
"userinfo":
{
"given_name": {"essential": true},
"nickname": null,
"email": {"essential": true},
"email_verified": {"essential": true},
"picture": null,
"http://example.info/claims/groups": null
},
"id_token":
{
"auth_time": {"essential": true},
"acr": {"values": ["urn:mace:incommon:iap:silver"] }
}
}
**認証コンテキストクラス [#ja81c8fa]
クライアントアプリケーションは、認証コンテキストクラスを使用して、~
ユーザー認証時に満たして欲しい認証コンテキストクラスを指定する。
***識別子 [#za241ab5]
Authentication Context Class Reference(ACR)識別子。
-パスワード~
urn:oasis:names:tc:SAML:2.0:ac:classes:Password
-X.509 証明書~
urn:oasis:names:tc:SAML:2.0:ac:classes:X509
***要求方法 [#na5ae06f]
arcクレームを
-acr_values リクエスト・パラメタや
-[[claimsリクエスト・パラメタ>#e26320e4]]で
要求できる。
-通常のリクエスト・パラメタ~
--client_id, redirect_uri, scopeなどと同じ、~
acr_values リクエスト・パラメタとしてACRを指定する。
--http://openid.net/specs/openid-connect-core-1_0.html#AuthRequest
-[[claimsリクエスト・パラメタ>#e26320e4]]
--[[claimsリクエスト・パラメタ>#e26320e4]]を使用して、ACRを指定する。
--http://openid.net/specs/openid-connect-core-1_0.html#acrSemantics
***参考 [#v871b342]
-OAuth & OpenID Connect 関連仕様まとめ - Qiita
--16. 認証コンテキストクラス~
https://qiita.com/TakahikoKawasaki/items/185d34814eb9f7ac7ef3#16-%E8%AA%8D%E8%A8%BC%E3%82%B3%E3%83%B3%E3%83%86%E3%82%AD%E3%82%B9%E3%83%88%E3%82%AF%E3%83%A9%E3%82%B9
**リクエスト・オブジェクト [#m6d72953]
-OpenID Connect Core 1.0 incorporating errata set 1 > 6. Passing Request Parameters as JWTs~
http://openid.net/specs/openid-connect-core-1_0.html#JWTRequests
***[[JWT Secured Authorization Request (JAR)]] [#q19eeb33]
***参考 [#q8b5f8f1]
-OAuth & OpenID Connect 関連仕様まとめ - Qiita
--24. リクエストオブジェクト~
https://qiita.com/TakahikoKawasaki/items/185d34814eb9f7ac7ef3#24-%E3%83%AA%E3%82%AF%E3%82%A8%E3%82%B9%E3%83%88%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88
*参考 [#p95f33f1]
-Final: OpenID Connect Core 1.0 incorporating errata set 1
--http://openid.net/specs/openid-connect-core-1_0.html
--https://openid-foundation-japan.github.io/openid-connect-core-1_0.ja.html
-超速習 OpenID Connect - Qiita~
http://qiita.com/sylph01/items/208ae313c03426feedc1
-第一回 認証基盤のこれからを支えるOpenID Connect | オブジェクトの広場~
https://www.ogis-ri.co.jp/otc/hiroba/technical/openid-connect/chap1.html
-デジタル・アイデンティティ技術最新動向（4）：「OpenID Connect」を理解する - ＠IT
--http://www.atmarkit.co.jp/ait/articles/1209/27/news138.html
--http://www.atmarkit.co.jp/ait/articles/1209/27/news138_2.html
-[前編] IDトークンが分かれば OpenID Connect が分かる - Qiita~
http://qiita.com/TakahikoKawasaki/items/8f0e422c7edd2d220e06
-OpenID Connectはそんなに大変かね？ - OAuth.jp~
http://oauth.jp/blog/2016/02/24/is-openid-connect-far-from-oauth2/
-エンタープライズITでのOpenID Connect利用ガイドライン~
http://www.slideshare.net/tkudo/openid-connect-for-enterprise
**OpenID Foundation [#z4c28dbb]
-OpenID Connect | OpenID~
http://openid.net/connect/
--Final: OpenID Connect Core 1.0 incorporating errata set 1~
http://openid.net/specs/openid-connect-core-1_0.html
---Final: OpenID Connect Discovery 1.0 incorporating errata set 1~
https://openid.net/specs/openid-connect-discovery-1_0.html
---Final: OpenID Connect Dynamic Client Registration 1.0 incorporating errata set 1~
https://openid.net/specs/openid-connect-registration-1_0.html
-公開資料 | OpenID ファウンデーション・ジャパン~
***OpenID ファウンデーション・ジャパン [#k81b738c]
-公開資料~
http://www.openid.or.jp/document/
--OpenID Foundation Japan - 翻訳・教育 Working Group~
https://openid-foundation-japan.github.io/
---Final: OpenID Connect Core 1.0 incorporating errata set 1~
https://openid-foundation-japan.github.io/openid-connect-core-1_0.ja.html
---Draft: OpenID Connect Basic Client Implementer's Guide 1.0 - draft 37~
https://openid-foundation-japan.github.io/openid-connect-basic-1_0.ja.html
---Draft: OpenID Connect Implicit Client Implementer's Guide 1.0 - draft 20~
https://openid-foundation-japan.github.io/openid-connect-implicit-1_0.ja.html
***Client Implementer's Guide [#c4eeb3ab]
WebアプリケーションのClientに当該フローを実装する場合の実装ガイド。
-OpenID Connect Client Implementer's Guide
--Basic Client Profile~
http://openid.net/specs/openid-connect-basic-1_0.html
>OAuth 2.0 Authorization Code Grantを拡張
--Implicit Client Profile~
http://openid.net/specs/openid-connect-implicit-1_0.html
>OAuth 2.0 Implicit Grantを拡張
***関連仕様 [#h5793a09]
-Discovery~
http://openid.net/specs/openid-connect-discovery-1_0.html
>メールアドレスやURLからユーザが利用しているIdp（OP）を特定する方法
-Dynamic Client Registration~
http://openid.net/specs/openid-connect-registration-1_0.html
>（Discoveryで発見したIdp（OP）に、）動的なRP登録を行う方法
-Session Management~
http://openid.net/specs/openid-connect-session-1_0.html
>Idp（OP）上でユーザーがログアウトしたときにRP側から検知する方法など、セッション管理の方法
-[[応答タイプ (response_type)、応答モード (response_mode)>OAuth#m0985cde]]
**IdM実験室 [#l12e411e]
***WIF [#p153dc92]
-IdM実験室 WIF Extension for OAuth を使って OpenID Connect を体験~
http://idmlab.eidentity.jp/2012/03/wif-extension-for-oauth-openid-connect.html
WIF Extension for OAuthは古い？
***OWIN [#x00c009d]
Microsoft.Owin.Security.OpenIdConnect
-IdM実験室: [AAD/ASP.NET]
--OpenID Connectを使ってAADでログオンする~
http://idmlab.eidentity.jp/2014/05/aadaspnet-openid-connectaad.html
---Ad（microsoftの方）のOpenId Connect対応~
http://www.slideshare.net/naohiro.fujie/admicrosoftopen-id-connect
--（続）OpenID Connectを使ってAADでログオンする～response_mode=fragment編~
http://idmlab.eidentity.jp/2014/05/aadaspnet-openid-connectaadresponsemode.html
***ADFS [#hcd0bd22]
-IdM実験室: [AD FS]OpenID Connectに対応した次期AD FSを試す~
http://idmlab.eidentity.jp/2015/08/ad-fsopenid-connectad-fs.html
**OpenID Connectのシーケンス [#s55b276e]
STEP 0 は事前準備なので、STEP 1 からが実際の認証・認可のシーケンス。
***Webアプリ（Basic Client Profile） [#h438d001]
-概要~
Basic Client Profile：OAuth 2.0 Authorization Code Grantを拡張
-参考
--デジタル・アイデンティティ技術最新動向（4）：「OpenID Connect」を理解する (1/2) - ＠IT~
http://www.atmarkit.co.jp/ait/articles/1209/27/news138.html
--OpenID Connect 入門 〜コンシューマーにおけるID連携のトレンド〜~
OpenID Connect Authorization Code Flow~
http://www.slideshare.net/kura_lab/openid-connect-id/28
--OpenID Connect体験 - Qiita~
http://qiita.com/sonedazaurus/items/753a65186f1be7185b39
-STEP 0 : 事前準備（Idp（OP）にRPを登録）
--Idp（OP）にRPを登録し、下記を入手する。
---アプリケーションID(client_id)
---シークレット(client_secret)
--参考
---Yahoo! JAPAN IDの登録ページ~
https://account.edit.yahoo.co.jp/registration
---アプリケーションIDの登録ページ~
https://e.developer.yahoo.co.jp/register
-STEP 1 : Authorization codeの取得
--RPがIdp（OP）からAuthorization codeを取得。
--スターターのリクエストをIdp（OP）に送信する。
---電文
https://・・・Idp（OP）のAuthorization code取得用のURL・・・?
response_type=code+id_token
&client_id={client_id}
&redirect_uri=・・・RPのURL・・・
&state=CSRF対策のランダム文字列
&scope=openid+profile
&nonce=リプレイアタック対策のランダム文字列
---上記のパラメタの説明
|#|パラメタ|必須|説明|h
|1|response_type|○|「code」と「id_token」を指定|
|2|client_id|○|事前に準備したclient_idの値を指定|
|3|redirect_uri|○|アプリケーションID登録時のコールバックURLに入力したURLを指定|
|4|state||CSRF対策のランダム文字列を指定|
|5|scope|○|・openid：ユーザー識別子を取得（必須）&br;・profile：姓名・生年・性別が取得&br;・email：メールアドレスと確認済みフラグを取得&br;・address：ユーザー登録住所情報が取得|
|6|nonce|id_tokenを取得する際は必須|リプレイアタック対策のランダム文字列を指定|
|7|display||ユーザのUIを選択：&br;・page（PC用UI、デフォルト値）&br;・touch（スマートフォン用UI）&br;・wap（フィーチャーフォン用UI）&br;・inapp（ネイティブアプリ用UI）～|
|8|その他、Idp（OP）独自パラメタ||－|
---成功するとログイン/同意画面が表示される。~
一度同意すると、次回以降同意画面は省略される。
--ログイン/同意が完了する(もしくは事前にログイン、同意している)と、~
以下のようなURLで「・・・RPのURL・・・」にリダイレクトされる。
---電文
http://・・・RPのURL・・・?code=xxxxxxxx&state=CSRF対策のランダム文字列
---上記のパラメタの説明
|#|パラメタ|説明|h
|1|code|”code=xxxxxxxx”を取得する。|
|2|state|”state=CSRF対策のランダム文字列”が、一致していることを確認する。|
-STEP 2 : Access Token、ID Tokenの取得
--Tokenを取得する際は、POSTでリクエストを送信する~
（HTTPリクエストのヘッダーやデータにTokenリクエストに必要な値を指定する必要がある）~
ため、CUIのcURLコマンドを使用して、Access Token、ID Tokenを取得する。
--cURLコマンドなどでリクエストする。
---電文
|#|部分|説明|h
|1|Header|Authorization: Basic {basicAuth}|
|2|URL|https://・・・Idp（OP）のAccess Token、ID Token取得用のURL・・・?grant_type=authorization_code&code=・・・&redirect_uri=・・・"|
---上記のパラメタの説明
|#|パラメタ|必須|説明|h
|1|{basicAuth}|○|基本認証を使用したクライアント認証のため、&br;アプリケーションID(client_id)、シークレット(client_secret)を":"区切りで結合しBase64文字列化|
|2|grant_type|○|authorization_code という固定文字列を指定|
|3|code|○|Authorization codeを指定、リクエスト送信後は使用できなくなる。|
|4|redirect_uri|○|STEP 1 のredirect_uriで指定したURLを入力。|
--以下の様なレスポンスが返る。
---電文
{
"access_token":"{ヘッダー部}.{ペイロード部}.{シグネチャー部}",
"token_type":"bearer",
"expires_in":"3600",
"refresh_token":"・・・",
"id_token":"・・・"
}
-STEP 3 : [[ID トークン>#ofb73c59]]の正当性の検証~
--"access_token"の{ヘッダー部}を取り出して、base64デコード。
---{ヘッダー部}の電文
{
"typ":"JWT",
"alg":"HS256"
}
---{ヘッダー部}のパラメタの説明
|#|パラメタ|説明|h
|1|typ|typ:JWT（JSON Web Token）|
|2|alg|alg:HMAC-SHA256（署名に使用したハッシュ）|
--{ペイロード部}を取り出して、base64デコード。
---{ペイロード部}の電文
{
"iss":"https:\/\/・・・Access Tokenの発行元URL・・・",
"user_id":"ユーザー識別子",
"aud":"アプリケーションID(client_id)と一致する値",
"iat":IDトークンの発行時刻,
"exp":IDトークンの有効期限,
"nonce":"STEP 1 のnonceと一致する値"
}
--署名の検証
---"{ヘッダー部}.{ペイロード部}"を使用して、~
{ヘッダー部}のalg:HMAC-SHA256でバイナリ形式でハッシュ化。
---それをBase64文字列化した文字列が"{シグネチャー部}"と一致していることを確認する。
-STEP 4 : 属性情報の取得~
RPがIdP（OP）で認証したユーザ属性情報を取得する。
--[[ユーザー情報エンドポイント>#k1d9c845]]に、以下の形式でAccess Tokenを渡す。
---電文
|#|部分|説明|h
|1|Header|'Authorization: Bearer {access_token}'|
|2|URL|URL:https://・・・ユーザ属性情報の発行元URL・・・?schema=openid|
---上記のパラメタの説明~
{access_token}に、準備、STEP 0-3 で取得したAccess Tokenを使う。
--以下のユーザ属性情報を含んだクレームが取得できる。
---電文
{
"user_id":"・・・",
"name":"・・・",
"given_name":"・・・",
"given_name#ja-Kana-JP":"・・・",
"given_name#ja-Hani-JP":"・・・",
"family_name":"・・・",
"family_name#ja-Kana-JP":"・・・",
"family_name#ja-Hani-JP":"・・・",
"gender":"male or female",
"birthday":"YYYY",
"locale":"ja-JP,etc."
}
***モバイルアプリ（Implicit Client Profile） [#v2c717b3]
-概要
--Implicit Client Profile：OAuth 2.0 Implicit Grantを拡張
--Webアプリ（Basic Client Profile）との違い
---STEP 0は、前提の違いによる差異。
---STEP 1以降は、[[Implicit Flow>#e7adf5c2]]がベースとなっている。
-参考
--デジタル・アイデンティティ技術最新動向（4）：「OpenID Connect」を理解する (2/2) - ＠IT~
http://www.atmarkit.co.jp/ait/articles/1209/27/news138_2.html
-STEP 0 : Discovery & Dynamic Client Registration~
IdP（OP）探索と動的なRP登録
--IdP（OP）探索~
「○○のIDでログイン」というリンクを選択する替わりに、~
次の2種類の値をIdP（OP）特定（Discovery）のためのヒントとして利用できる。
---メールアドレス~
例 : ritou@openidconnect.info
---OP URL~
例 : https://openidconnect.info
--動的なRP登録~
RP登録用エンドポイントにPOSTリクエストを送ることで、~
動的なRP登録（Dynamic Client Registration）もできる。
>結果的に、OPからRP識別のための“cient_id”がレスポンスされる。
-STEP 1 : Authorization Request~
認可リクエスト
-STEP 2 : Authorization Response~
認可応答
-STEP 3 : ID Token Verification~
[[ID トークン>#ofb73c59]]の検証
-STEP 4 : Accessing to UserInfo Endpoint~
[[ユーザー情報エンドポイント>#k1d9c845]]へのアクセス
**OpenId Connectのサンプル [#l2d6ff73]
***Microsoft.Owin.Security.OpenIdConnect [#i4f26644]
AzureADに対して、OpenId Connectを使用して認証する。
https://github.com/OpenTouryoProject/SampleProgram/tree/master/ASPNET/OpenID_Connect/
-サンプル・アプリケーションをAzure Active Directoryに登録
>
+Azureの管理ポータルにサインイン。
+Azure Active Directoryのタブを開く。
+サンプル・アプリケーションを登録するテナント（ドメイン）を開く。
+[Applications]タブに移動し、ページの下部の[Add]アイコンををクリック。
+[What do you want to do?]画面で[Add an application my organization is developing]を選択。
+[Tell us about your application]画面が表示される。
++アプリケーションの名前を入力（例：OpenIDConnect_sample）。
++[Web Application and / or Web API]を選択する。
++[Next]をクリックする。
+[App properties]画面が表示される。
++サンプルのサインオンURLを入力（例：https://localhost:xxxxxx/）~
サンプル・プロジェクトのプロパティにある開発サーバのSSL URLプロパティを指定~
http://www.codeproject.com/Tips/766918/Visual-Studio-Use-HTTPS-SSL-On-Web-Application-Pro
++アプリのID URIを入力（例：https://<your_tenant_name>/OpenIDConnect_sample）~
'<your_tenant_name>はAzure ADのテナント（ドメイン）名。
++[Complete]をクリック。
-サンプル・アプリケーションの構成
>
+web.configファイルを開く。
+FxTenantにAzure ADのテナント（ドメイン）名を指定（例：xxxxx.onmicrosoft.com）
+FxClientId にAzureのポータルから入手することができるClient IDを指定
++クライアントIDを取得するには、
++Azureの管理ポータルにサインイン。
++Azure Active Directoryのタブを開く。
++サンプル・アプリケーションを登録したテナント（ドメイン）を開く。
++[Applications]タブに移動しサンプル・アプリケーションを選択。
++アプリケーション画面で[ACCESS WEB APIS IN OTHER APPLICATIONS]を選択。
++Client IDをコピー。
+FxPostLogoutRedirectUriにサンプルのサインオンURLを入力（例：https://localhost:xxxxxx/）
-サンプル・アプリケーションの実行
>F5実行でリダイレクトされた先のAzure AD（STS）で認証できることを確認する。
**[[Microsoft Azure Active Directory]] [#if197a37]
***[[Azure Active Directory B2C]] [#n13f7bac]
----
Tags: [[:認証基盤]], [[:クレームベース認証]], [[:OAuth]]
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
