「[[マイクロソフト系技術情報 Wiki>http://techinfoofmicrosofttech.osscons.jp/]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。 -[[戻る>クレームベース認証#ya3d2a7b]] * 目次 [#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]]の署名アルゴリズムも影響を受ける。 *その他 [#xce3cadb] 比較的、重要度の高い仕様についてまとめる。 -OAuth & OpenID Connect 関連仕様まとめ - Qiita~ https://qiita.com/TakahikoKawasaki/items/185d34814eb9f7ac7ef3 **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クレームをscopeやclaimsリクエスト・パラメタで要求できる。 -通常のリクエスト・パラメタ~ --client_id, redirect_uri, scopeなどと同じ、~ acr_values リクエスト・パラメタとしてACRを指定する。 --http://openid.net/specs/openid-connect-core-1_0.html#AuthRequest -claimsリクエスト・パラメタ --[[claimsリクエスト・パラメタ>#e26320e4]]を使用して、ACRを指定する。 --http://openid.net/specs/openid-connect-core-1_0.html#acrSemantics ***参考 [#v871b342] 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] 認可エンドポイントに渡すリクエスト・パラメタ群を~ [[JWT]]形式(認証要求に署名し、オプションで暗号化できる)で渡す方法。 ***渡し方 [#cf64a89f] -request パラメタ~ リクエストオブジェクトの値を直接渡す。 -request_uri パラメタ~ リクエストオブジェクトの場所を伝える。 ***処理 [#r8ebe8ae] -requestパラメタ~ requestパラメタからリクエスト・オブジェクトを取得する。 -request_uriパラメタ~ request_uriパラメタからリクエスト・オブジェクトを取得する。 -リクエスト・オブジェクト取得後 --リクエスト・オブジェクトの署名・検証(若しくは復号)用の鍵を取得。~ ・・・クライアント・メタデータが、 ---登録されている場合、~ JWK Setをjwks クライアントメタデータ値から取得。 ---登録されていない場合、~ jwks_uriからクライアント・メタデータ(JWK Set)を取得。 --リクエスト・オブジェクトから認可エンドポイントへのパラメタを取り出す。 ***参考 [#y3622476] -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 --The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR)~ https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-08 --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 *参考 [#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 ファウンデーション・ジャパン~ 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: [[:認証基盤]], [[:クレームベース認証]]