「[[マイクロソフト系技術情報 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] Finalを参照して記述。 -[[OpenID Connect]]の用途としては、「認証の仕様である」と言ってイイ。 -しかし技術的には、「[[IDトークン>#ofb73c59]]発行のための仕様」と考えたほうがイイ。 -[[JWT]] --この[[IDトークン>#ofb73c59]]と呼ばれる[[トークン]]は[[JWT]]アサーションを使用している。~ (JSON Serializationではなく、Compact Serializationを用いる。) --従って、[[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-----| | | | | | +--------+ +--------+ Client(RP) IdP/STS(OP) ***[[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 **概要 [#fcc9fa97] ***フロー選択の指針 [#zcd03aad] 特定のコンテキストにおいてどのフローを選択すればよいかの指針 |#|Property|[[Authorization Code Flow>#mcde509a]]|[[Implicit Flow>#e7adf5c2]]|[[Hybrid Flow>#l565139a]]|h |1|全てのトークンは Authorization Endpoint から返却される|no|yes|no| |2|全てのトークンは Token Endpoint から返却される|yes|no|no| |3|トークンが User Agent に渡らない|yes|no|no| |4|Client 認証が可能である|yes|no|yes| |5|Refresh Token を利用できる|yes|no|yes| |6|通信が1往復だけである|no|yes|no| |7|殆どの通信がサーバ間通信である|yes|no|varies| ***response_type 値とフローの対応 [#aff816e3] -[[追加の応答タイプ (response_type) >#yf733ad4]]を使用する。 -どのフローを利用するかを決定する 値とフローの対応 |#|response_type値|Flow|h |1|code|[[Authorization Code Flow>#mcde509a]]| |2|id_token|[[Implicit Flow>#e7adf5c2]]| |3|id_token token|[[Implicit Flow>#e7adf5c2]]| |4|code id_token|[[Hybrid Flow>#l565139a]]| |5|code token|[[Hybrid Flow>#l565139a]]| |6|code id_token token|[[Hybrid Flow>#l565139a]]| ***メッセージのシリアライズ方法 [#ke1f0a07] -GETリクエスト:~ application/x-www-form-urlencoded (Query String Serialization) -POSTリクエスト:~ application/x-www-form-urlencoded (Form Serialization) -JSON~ 定義されていないが、以下で利用されるモノと思われる。 --POSTリクエスト:~ Request body --GET, POSTレスポンス:~ Response body --[[JWT]]化すれば以下のリクエストで使用可 ---GETリクエスト:~ Query String Serialization ---POSTリクエスト:~ Form Serialization ***リクエスト・パラメタの追加・変更 [#nd004268] -OPTIONAL ---> &color(red){REQUIRED}; --redirect_uri --[[scope>OpenID Connect - ユーザー属性クレーム関連#k95e5b83]]~ scope="* openid *"は必須。 ---OpenID Connect リクエストは scope に openid を含まねばならない (MUST). ---openid scope 値が存在しない場合の挙動は定義しない. ---他の scope 値が存在していても良い (MAY). -[[response_type>#aff816e3]]~ 追加のパラメタ値がある。 -[[nonce>OpenID Connect - IDトークン#d9a64ea2]] --[[Authorization Code Flow>#mcde509a]]ではOPTIONAL --[[Implicit Flow>#e7adf5c2]]では&color(red){REQUIRED}; --[[Hybrid Flow>#l565139a]]では&color(red){REQUIRED}; -claims系 --claims (OPTIONAL)~ [[scopeパラメタの詳細版>OpenID Connect - ユーザー属性クレーム関連#lfaacf35]] --claims_locales (OPTIONAL)~ [[クレームの多言語化対応>OpenID Connect - ユーザー属性クレーム関連#u1556f80]] -[[Requestオブジェクト>#q19eeb33]] (OPTIONAL) --request~ Requestオブジェクト([[JWT]]) --request_uri~ Requestオブジェクト([[JWT]])を返すエンドポイントのUrl(https) -[[Authorization Code Flow>#mcde509a]] --[[response_mode>OAuth 2.0 Form Post Response Mode]] (OPTIONAL) --max_age ---最大認証期間 ---[[IDトークン>#ofb73c59]]に、[[auth_timeクレーム>OpenID Connect - IDトークン#d9a64ea2]]が必要になる。 --display (OPTIONAL)~ Authorization Server は認証/認可の同意 UI を、 ---page~ User Agent の全画面に表示すべき(既定値) ---popup~ User Agent のポップアップウィンドウに表示すべき. ---touch~ タッチ・インタフェースを持つデバイスに適した形で表示すべき. ---wap~ "feature phone"に適した形で表示すべき. --prompt (OPTIONAL)~ 再認証/認可の同意を要求するかどうか指定するスペース区切りの ASCII 文字列のリスト ---none~ 再認証/認可の同意を要求(表示)してはならない. ---login~ 再認証の同意を要求(表示)すべき. ---consent~ 再認証/認可の同意を要求(表示)すべき. ---select_account~ 複数アカウント前提の際に、アカウント選択を促すべき. --hint~ 基本、(素?)無視。 ---id_token_hint (OPTIONAL)~ prompt=noneの時に使う ---login_hint (OPTIONAL)~ 複数アカウント前提の際に、識別子のヒントとして利用する。 --その他 ---ui_locales (OPTIONAL)~ UI の表示言語および文字種スペース区切りの言語タグ値のリスト ---acr_values (OPTIONAL)~ [[認証コンテキスト クラス>#ja81c8fa]]値 ***レスポンス・パラメタの追加・変更 [#q4d3f512] -Token Endpoint --id_token~ [[response_type>#aff816e3]]で要求した場合に追加される。 --token_type~ Bearer もしくは Client が Authorization Server と交渉した他の token_type の値と規定。 ***TLS要件 [#m1e4ec12] 以下との通信は、TLS を用いなければならない (MUST). -Authorization Endpoint -Token Endpoint ***その他の追加要件 [#dae2bcbf] -Token Response に 以下の HTTP レスポンスヘッダーを指定(MUST). |#|Header Name|Header Value|h |1|Cache-Control|no-store| |21|Pragma|no-cache| **Authorization Code Flow [#mcde509a] -scope="* openid *" -[[response_type>#aff816e3]]="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>#aff816e3]]= --"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]] ***ポイント [#wbd35b35] -[[IDトークン>OpenID Connect - IDトークン]]クレームの追加要件~ Authorization Endpoint から返される[[IDトークン>OpenID Connect - IDトークン]]に対して以下が必要になる。 --[[nonce>OpenID Connect - IDトークン#d9a64ea2]] --[[at_hash>OpenID Connect - IDトークン#c007540d]]("id_token token"の場合) **Hybrid Flow [#l565139a] -scope="* openid *"~ [["code token"の場合も必要!>http://openid.net/specs/openid-connect-core-1_0.html#code-tokenExample]] -[[response_type>#aff816e3]]= --"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トークン>OpenID Connect - IDトークン]]クレームの追加要件 --Authorization Endpoint から返される[[IDトークン>OpenID Connect - IDトークン]]に対して以下が必要になる。 ---[[nonce>OpenID Connect - IDトークン#d9a64ea2]] ---[[at_hash>OpenID Connect - IDトークン#c007540d]] ---[[c_hash>OpenID Connect - IDトークン#c007540d]] --Authorization Endpoint と Token Endpoint から返される[[IDトークン>OpenID Connect - IDトークン]]のクレームについて以下が必要になる。 ---issクレームと subクレームは同一でなければならない (MUST). ---両方に同じ Authentication イベントに関する Claim を含めるべき(SHOULD). ---End-User に関するクレームは、~ Authorization Endpoint ≦ Token Endpointから返すクレームとしてよい (MAY).~ ただし、クレームが両方に存在する場合, その値は同値であるべき (SHOULD). *主要な仕様 [#kafe9228] **subクレームの種類 [#cf801b20] (Subject Identifier Types) -「5.7. Claim Stability and Uniqueness」で言われているように、~ --通常、subクレーム値は、iss内で一意 --故に、エンドユーザにとっては、iss+subで一意 -故に、「8. Subject Identifier Types」では、 --pairwiseというオプションで、 --Client毎にsubクレーム値を変えることにより、 --Clientを跨った名寄せを困難にしてプライバシーを保護する。 ***種類 [#b1467737] -public~ 全ての Client に対し同一の subクレーム値を提供する(既定値) -pairwise~ 各々の Client に対し異なる subクレーム値を提供する。 ***サポート [#y1136a79] -[[Discovery: subject_types_supported>OpenID Connect - Discovery#t527fffb]] -[[Registration:>OpenID Connect - Dynamic Client Registration#e9256189]] --subject_type --sector_identifier_uri ***pairwiseの値 [#m3999d6f] pairwiseのsubクレーム値 -要件 --subクレーム値が, OP(IdP/STS) 以外の Party にとって, 可逆であってはならない (MUST NOT). --異なる Sector Identifier 値は, 異なる Subject Identifier 値にならなければならない (MUST). --同じ入力に対して必ず同じsubクレーム値となる決定的アルゴリズムでなければならない (MUST). -計算例 --sub = SHA-256 ( sector_identifier || local_account_id || salt ) --sub = AES-128 ( sector_identifier || local_account_id || salt ) --GUID = ローカルアカウントID, Sector Identifier(変換テーブル) **[[IDトークン>OpenID Connect - IDトークン]] [#ofb73c59] **[[暗号関連>OpenID Connect - 暗号関連]] [#h9b10c6c] **ユーザー属性 [#j46ce3c0] ***[[ユーザー属性クレーム群>OpenID Connect - ユーザー属性クレーム関連]] [#kb7212b1] ***[[ユーザー情報エンドポイント>OpenID Connect - ユーザー属性クレーム関連#k1d9c845]] [#k1d9c845] *追加の仕様 [#xce3cadb] 追加された仕様についてまとめる。 **追加の[[応答タイプ (response_type)>OAuth 2.0 Multiple Response Type Encoding Practices]] [#yf733ad4] **追加の[[応答モード (response_mode)>OAuth 2.0 Form Post Response Mode]] [#h5f19339] *オプションの仕様 [#rc15ce54] **[[認証コンテキスト クラス>OpenID Connect - Authentication Context Class Reference]] [#ja81c8fa] **[[Requestオブジェクト>OpenID Connect - Requestオブジェクト]] [#q19eeb33] **[[クライアント認証>OpenID Connect - クライアント認証]] [#y7bdab62] **[[Self-Issued OP>OpenID Connect - Self-Issued OP]] [#qc1295b1] **その他 [#q279be97] ***Offline Access [#a22453e9] offline_access scopeにより、 -Clientは、Resource Ownerの代わりに、長期間にわたってリソースにアクセスできる。 -このため、このパラメタは、Refresh Tokenの発行に関係する。 ***Session Management [#z36f893f] -Draft: OpenID Connect Session Management 1.0 - draft 28~ http://openid.net/specs/openid-connect-session-1_0.html --エンドユーザのログインステータスを監視する方法を定義 --IdP/STS(OP)上でユーザーがログアウトしたときにClient(RP)側から検知する方法など、セッション管理の方法 --Client(RP)が、IdP/STS(OP)からログアウトしたエンドユーザを検知してClientからもログアウトできるようにする。 ***ログイン開始エンドポイント [#ze94647d] アプリXのログイン・フローが、サード・パーティーの~ Client(RP)やIdP/STS(OP)によって開始される仕組み。 -要するに、サード・パーティーのClient(RP)やIdP/STS(OP)から、 --リダイレクト(とは言え、GETとPOST要求を受入)で --Client(RP)のログイン開始エンドポイントに遷移し、 --IdP/STS(OP)に認可リクエストを送信する。 --IdP/STS(OP)で認証後、Client(RP)のRedirectエンドポイントに遷移し、 --更に、その後、指定されたランディング・ページに遷移する。 -パラメタ --iss (&color(red){REQUIRED};)~ 認可リクエストを送信するIdP/STS(OP)を示す --login_hint (OPTIONAL)~ 認可リクエストにlogin_hintパラメタ値として含める. --target_link_uri (OPTIONAL) ---Redirectエンドポイントから、指定されたランディング・ページに遷移。 ---オープンリダイレクターとして使用されることを防ぐためtarget_link_uri値を検証する (MUST). *考慮点 [#yb6d697f] **IdP/STS(OP)の実装 [#ia77d57c] ***必須の実装 [#xef2ea35] -すべてのIdP/STS(OP) --署名: RS256 --認可画面 管理機能を用いた事前の認可の同意など ---display ---prompt --Locales ---ui_locales ---claims_locales --認可リクエスト・パラメタへ対応 ---max_age ---acr_values --以下のクレームの格納要求 ---auth_time -動的なIdP/STS(OP) --Response Type ---id_token ---code (Self-Issued OP 以外) ---id_token token (Self-Issued OP 以外) --UserInfo Endpoint (Self-Issued OP 以外) --[[JWK]] 公開(jwks_uri、X.509 形式でも可) --Requestオブジェクトのrequest_uri --[[Discovery、Dynamic Client Registration>#h5793a09]] ***Client(RP)次第の実装 [#xef2ea35] -Confidential Client: Authoriation Code Flow -Public Client: Implicit Flow -[[Discovery、Dynamic Client Registration>#h5793a09]] ***Discovery、Dynamic Client Registration [#h5793a09] 事前登録のない Client(RP) と IdP/STS(OP) 間の~ 予期しないやりとりをサポートすることを選択した場合に実装が必要。 -[[Discovery>OpenID Connect - Discovery]] -[[Dynamic Client Registration>OpenID Connect - Dynamic Client Registration]] **セキュリティ [#h9f4ec8e] ***[[OAuth 2.0 Threat Model and Security Considerations]] [#k3a85d0c] ***サーバ認証 [#x9aefc3b] [[ID Token>OpenID Connect - IDトークン]]の署名・暗号化で提供される。 ***トークン [#w3cd047e] -トークン生成 --[[JWT]]([[JWS])を使用する。 --TLS を使用する。 -アクセス許可の制限~ aud の scope に対して制限をかける。 -有効期限の制限~ code, access_token, refresh_token, -置換攻撃の防止 --iss(完全一致) --sub --aud --azp --at_hash --c_hash ***暗号化 [#zbd19110] -各実装は TLS をサポート -共通鍵暗号~ HS256などのMACを使用する場合、client_secret は最低でも32オクテットが必要 -暗号関連の様々な攻撃 --タイミング・アタック --[[JWT]] ---[[JWT]] の Security Considerations ---[[JWT]] が参照する, 各脆弱性を防ぐための仕様群 ***Requestオブジェクト [#nf6b5630] リクエストの漏洩や改ざんの防止 -特に、max_age と acr_valuesなどの改ざん防止。 -特に、claims や acr_valuesなどの漏洩防止 *参考 [#p95f33f1] -第一回 認証基盤のこれからを支える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 -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 ファウンデーション・ジャパン [#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を拡張 **Qiita [#k7288da4] -超速習 OpenID Connect~ http://qiita.com/sylph01/items/208ae313c03426feedc1 ***TakahikoKawasaki [#n96b57cd] -一番分かりやすい OpenID Connect の説明~ https://qiita.com/TakahikoKawasaki/items/498ca08bbfcc341691fe -[[IDトークンが分かれば OpenID Connect が分かる - Qiita>OpenID Connect - IDトークン#yce99a85]] **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/STS(OP)にClient(RP)を登録) --IdP/STS(OP)にClient(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の取得 --Client(RP)がIdP/STS(OP)からAuthorization codeを取得。 --スターターのリクエストをIdP/STS(OP)に送信する。 ---電文 https://・・・IdP/STS(OP)のAuthorization code取得用のURL・・・? response_type=code+id_token &client_id={client_id} &redirect_uri=・・・Client(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|Implicit or Hybrid Flowでid_tokenを取得する際は必須|リプレイアタック対策のランダム文字列を指定| |7|display||ユーザのUIを選択:&br;・page(PC用UI、デフォルト値)&br;・touch(スマートフォン用UI)&br;・wap(フィーチャーフォン用UI)&br;・inapp(ネイティブアプリ用UI)~| |8|その他、IdP/STS(OP)独自パラメタ||-| ---成功すると認証/認可の同意画面が表示される。~ 一度同意すると、次回以降、認証/認可の同意画面は省略される。 --認証/認可の同意が完了する(もしくは事前に認証/認可の同意をしている)と、~ 以下のようなURLで「・・・Client(RP)のURL・・・」にリダイレクトされる。 ---電文 http://・・・Client(RP)のURL・・・?code=xxxxxxxx&state=CSRF対策のランダム文字列 ---上記のパラメタの説明 |#|パラメタ|説明|h |1|code|”code=xxxxxxxx”を取得する。| |2|state|”state=CSRF対策のランダム文字列”が、一致していることを確認する。| -STEP 2 : Access Token、[[ID Token>OpenID Connect - IDトークン]]の取得 --Tokenを取得する際は、POSTでリクエストを送信する~ (HTTPリクエストのヘッダーやデータにTokenリクエストに必要な値を指定する必要がある)~ ため、CUIのcURLコマンドを使用して、Access Token、[[ID Token>OpenID Connect - IDトークン]]を取得する。 --cURLコマンドなどでリクエストする。 ---電文 |#|部分|説明|h |1|Header|Authorization: Basic {basicAuth}| |2|URL|https://・・・IdP/STS(OP)のAccess Token、[[ID Token>OpenID Connect - IDトークン]]取得用の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 : 属性情報の取得~ Client(RP)がIdP/STS(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/STS(OP)探索と動的なClient(RP)登録 --IdP/STS(OP)探索~ 「○○のIDでログイン」というリンクを選択する替わりに、~ 次の2種類の値をIdP/STS(OP)特定(Discovery)のためのヒントとして利用できる。 ---mailアドレス~ 例 : ritou@openidconnect.info ---IdP/STS(OP)URL~ 例 : https://openidconnect.info --動的なClient(RP)登録~ Client(RP)登録用エンドポイントにPOSTリクエストを送ることで、~ 動的なClient(RP)登録(Dynamic Client Registration)もできる。 >結果的に、IdP/STS(OP)からClient(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/AuthN_AuthZ/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(IdP/STS(OP))で認証できることを確認する。 **[[Microsoft Azure Active Directory]] [#if197a37] ***[[Azure Active Directory B2C]] [#n13f7bac] **子ページ [#d8deccc8] ***[[IDトークン>OpenID Connect - IDトークン]] [#z61b0607] ***[[ユーザー属性クレーム関連>OpenID Connect - ユーザー属性クレーム関連]] [#cab82491] ***[[暗号関連>OpenID Connect - 暗号関連]] [#l779d038] ***[[Discovery>OpenID Connect - Discovery]] [#nb01070c] ***[[Dynamic Client Registration>OpenID Connect - Dynamic Client Registration]] [#a2a2eeeb] ***[[クライアント認証>OpenID Connect - クライアント認証]] [#n8124d8c] ***[[認証コンテキスト クラス>OpenID Connect - Authentication Context Class Reference]] [#u8929cca] ***[[Requestオブジェクト>OpenID Connect - Requestオブジェクト]] [#j1bd1f74] ***[[Self-Issued OP>OpenID Connect - Self-Issued OP]] [#qa1b8e4d] ---- Tags: [[:IT国際標準]], [[:認証基盤]], [[:クレームベース認証]], [[:OAuth]]