Open棟梁Project - マイクロソフト系技術情報 Wiki
ユースケースに対応するため、
多様な環境をサポートできる。
ざっくり、リクエスト→認証・認可→ユーザ情報を取得。
+--------+ +--------+ | | | | | |---------(1) AuthN Request-------->| | | | | | | | +--------+ | | | | | | | | | | | End- |<--(2) AuthN & AuthZ-->| | | | | User | | | | RP | | | | OP | | | +--------+ | | | | | | | |<--------(3) AuthN Response--------| | | | | | | |---------(4) UserInfo Request----->| | | | | | | |<--------(5) UserInfo Response-----| | | | | | +--------+ +--------+
OAuth 2.0との違いは、認証拡張機能が実装された点にある。
OAuth 2.0に認証結果とプロフィールの受渡し機能のみを追加した仕様
OAuth 2.0 Authorization Code Grantを拡張
OAuth 2.0 Implicit Grantを拡張
リクエスト内の細かいクレーム指定や認証コンテキストの指定
OAuth 2.0に追加で必要となるメッセージの使用
Messagesの内容をHTTPに落とし込んだHTTPバインディング仕様
メールアドレスやURLからユーザが利用しているOPを特定する方法
動的なRP登録を行う方法
Idp(OP)上でユーザーがログアウトしたときにRP側から検知する方法など、セッション管理の方法
OAuth 2.0 からのステップ上の拡張部分は無い。
ただし、アクセス先がResources ServerのEndpointがUserInfo?エンドポイントに特定されており、
ここから、認証されたユーザ情報としてユーザー属性クレーム群を取得している。
- 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 ID Token and Access Token in the response body.
- Client validates the ID token and retrieves the End-User's Subject Identifier.
朱書きは、OAuth 2.0 からのステップ上の変更・拡張部分。
ポイントは、User-Agentやスマホネイティブから直接的にAccess Tokenを使用せず、
ClientにAccess Tokenを送って、そこからユーザー属性クレーム群を取得している点。
- 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 ID Token and, if requested, an Access Token.
- Client validates the ID token and retrieves the End-User's Subject Identifier.
朱書きは、Authorization Code Flowとの差異。
ID トークンと同時に、アクセストークンや認可コードが一緒に発行される場合、
ID トークンにat_hash、c_hashクレームが追加される(用途不明)。
- 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,
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.
JWT : JSON Web Tokenの略
JWTのJWS or JWEを使用する。
Idp(OP)は、扱うクレームの内容によって、
どちらを利用すべきかを判断する必要がある。
一定期間変更されないことが保証されており
キャッシュの効果があるものは集約クレーム。
クレームそのものではなく、問い合わせ先のURLを扱う。
をレスポンスに含む。
頻繁に更新されるものは分散クレーム。
GoogleでOpenID Connectの認証で取得したクレームセット。
(id_tokenそのものなのか?、UserInfo?エンドポイントから取得したクレームか?)
{ "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時間) }
ココを見ると、これは恐らく、id_tokenなのだろうなと。
以下のGoogle公式のマニュアルにも記載があった。
項番 | クレーム名 | 意味 |
1 | sub | ユーザーの一意識別子 |
2 | name | フルネーム |
3 | given_name | 名 |
4 | family_name | 姓 |
5 | middle_name | ミドルネーム |
6 | nickname | ニックネーム |
7 | preferred_username | 好みのユーザー名 |
8 | profile | プロフィールページの URL |
9 | picture | プロフィール画像の URL |
10 | website | Web サイトやブログの URL |
11 | メールアドレス | |
12 | email_verified | メールアドレスが検証済みか否かの真偽値 |
13 | gender | 性別。female と male が定義済み。 |
14 | birthdate | 誕生日。YYYY-MM-DD。 |
15 | zoneinfo | タイムゾーン。Europe/Paris など。 |
16 | locale | ロケール。en-US など。 |
17 | phone_number | 電話番号 |
18 | phone_number_verified | 電話番号が検証済みか否かの真偽値 |
19 | address | 住所。書式は「5.1.1. Address Claim」に記載。 |
20 | updated_at | 情報最終更新日。Unix エポックからの経過秒数。 |
項番 | クレーム名 | 意味 |
1 | formatted | フォーマットされたフルメールアドレス、表示用・郵送用に使用 |
2 | street_address | 通り・番地、号室、私書箱、複数行の拡張された住所情報。 |
3 | locality | City or locality |
4 | region | State, province, prefecture, or region. |
5 | postal_code | Zip code or postal code |
6 | country | Country name |
STEP 0 は事前準備なので、STEP 1 からが実際の認証・認可のシーケンス。
Idp(OP)にRPを登録し、
を入手する。
RPがIdp(OP)からAuthorization codeを取得。
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=リプレイアタック対策のランダム文字列
パラメータ | 必須 | 説明 |
response_type | ○ | 「code」と「id_token」を指定 |
client_id | ○ | 事前に準備したclient_idの値を指定 |
redirect_uri | ○ | アプリケーションID登録時のコールバックURLに入力したURLを指定 |
state | CSRF対策のランダム文字列を指定 | |
scope | ○ | ・openid:ユーザー識別子を取得(必須) ・profile:姓名・生年・性別が取得 ・email:メールアドレスと確認済みフラグを取得 ・address:ユーザー登録住所情報が取得 |
nonce | id_tokenを取得する際は必須 | リプレイアタック対策のランダム文字列を指定 |
display | ユーザのUIを選択: ・page(PC用UI、デフォルト値) ・touch(スマートフォン用UI) ・wap(フィーチャーフォン用UI) ・inapp(ネイティブアプリ用UI)~ | |
その他、Idp(OP)独自パラメタ | - |
http://・・・RPのURL・・・?code=xxxxxxxx&state=CSRF対策のランダム文字列
パラメータ | 必須 | 説明 |
grant_type | ○ | authorization_code という固定文字列を指定 |
code | ○ | Authorization codeを指定、リクエスト送信後は使用できなくなる。 |
redirect_uri | ○ | STEP 1 のredirect_uriで指定したURLを入力。 |
{ "access_token":"{ヘッダー部}.{ペイロード部}.{シグネチャー部}", "token_type":"bearer", "expires_in":"3600", "refresh_token":"・・・", "id_token":"・・・" }
"access_token"の
{ "typ":"JWT", "alg":"HS256" }
{ "iss":"https:\/\/・・・Access Tokenの発行元URL・・・", "user_id":"ユーザー識別子", "aud":"アプリケーションID(client_id)と一致する値", "iat":IDトークンの発行時刻, "exp":IDトークンの有効期限, "nonce":"STEP 1 のnonceと一致する値" }
{ "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." }
IdP(OP)探索と動的なRP登録
結果的に、OPからRP識別のための“cient_id”がレスポンスされる。
認可リクエスト
認可応答
IDトークンの検証
UserInfo?エンドポイントへのアクセス
WIF Extension for OAuthは古い?
Microsoft.Owin.Security.OpenIdConnect?
上記のコンテンツの内容を確認すると、
双方に対応した v2.0 endpoint (App Model v2) と連携し、
OAuth 2.0(ではなく、OpenID Connect)認証をおこない、
認証結果を他の API (Service) で検証し認証させている。
https://github.com/OpenTouryoProject/SampleProgram/tree/master/ASPNET/OpenID_Connect/
F5実行でリダイレクトされた先のAzure AD(STS)で認証できることを確認する。
Tags: :認証基盤, :クレームベース認証