![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
ここでは、基本的に、OAuth 2.0について言及する。
OAuth 2.0は、認証ではなく認可のためのプロトコル（権限委譲プロトコル）。
+--------+ +---------------+ | |--(A)- Authorization Request ->| Resource | | | | Owner | | |<-(B)-- Authorization Grant ---| | | | +---------------+ | | | | +---------------+ | |--(C)-- Authorization Grant -->| Authorization | | Client | | Server | | |<-(D)----- Access Token -------| | | | +---------------+ | | | | +---------------+ | |--(E)----- Access Token ------>| Resource | | | | Server | | |<-(F)--- Protected Resource ---| | +--------+ +---------------+
Resource Ownerは、Clientを経由して、Authorization Server（の認証画面）で認証する。
認証後、Clientは、Authorization Serverの認可エンドポイントで認可グラントを受け取る。
Clientは、Authorization ServerのTokenエンドポイントに認可グラントを提示することで、Access Tokenを要求する.
Authorization Serverは、Clientと 認可グラントが正当であれば、ClientにAccess Tokenを発行する。
Clientは、Resource ServerにAccess Tokenを提示してProtected Resourceにアクセスする。
ココのスライドが参考になる。
以下、4つのグラント種別に対応するフローがある。
「この認可タイプを使用可能にするときには特に注意を払い、
他のフローが実行可能でない場合にのみ許可する必要があります。」
RFCを読むと、
GET /resource/1 HTTP/1.1 Host: example.com Authorization: Bearer XXXXXXXXXX
RFCを読むと、
Resource Ownerの認証用のCredentialsはOAuth 2.0 仕様の外
（Authorization ServerはユーザID、パスワードなどを使用してResource Ownerを認証）
Clientの認証用のCredentials
（Authorization ServerはこれによりClientを認証）
URLは仕様で規定されない。
Redirectエンドポイント
認可エンドポイントにGETで送付する。
以下のように、グラント種別毎に、決まったパラメタを指定する必要がある。
| 項番 | グラント種別 | パラメタ値 | 意味 |
| １ | Authorization Code | code | 仲介コードを要求 |
| ２ | Implicit | token | Access Tokenを要求 |
Clientの識別や認証のために、色々な所で使用されるパラメタ。
client_idに対応するRedirectエンドポイントを指定するために指定するパラメタ。
TokenエンドポイントにPOSTを送付するときに指定するパラメタ。
以下のように、グラント種別毎に、決まったパラメタを指定する必要がある。
| 項番 | グラント種別 | パラメタ値 |
| １ | Authorization Code | authorization_code |
| ２ | Resource Owner Password Credentials | password |
| ３ | Client Credentials | client_credentials |
| ４ | 上記１、２、３のグラント種別でRefreshトークンを使用する際 | refresh_token |
CSRFのセキュリティ対策に使用が推奨されるパラメタ。
code, access_token, refresh_token
| 項番 | パラメタ値 | 意味 |
| １ | code | access_tokenを取得するためのtokenで、Authorization Codeグラント種別でのみ使用する。 |
| ２ | access_token | コチラを参照 |
| ３ | refresh_token | コチラを参照 |
GET /authorize?response_type=code&client_id=XXXX&state=YYYY
&redirect_uri=http... HTTP/1.1
Host: ...HTTP/1.1 302 Found Location: http...?code=YYYY&state=ZZZZ
HTTP/1.1 302 Found Location: http...#error=access_denied&state=ZZZZ
POST /token HTTP/1.1 Host: ... Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded grant_type=authorization_code&code=XXXX&redirect_uri=http...
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"XXX",
"token_type":"Bearer", ---> 署名なしトークン (Bearer Token)の場合
"expires_in":3600,
"refresh_token":"YYY",
"example_parameter":"ZZZ"
}HTTP/1.1 400 Bad Request
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"error":"invalid_request"
}OAuth 2.0仕様には4つのフローが定義されている。
これらのフローのタイプを「グラント種別」と呼ばれる。
以下の様な「グラント種別」がある模様。
+----------+
| Resource |
| Owner |
| |
+----------+
^
|
(B)
+----|-----+ Client Identifier +---------------+
| -+----(A)-- & Redirection URI ---->| |
| User- | | Authorization |
| Agent -+----(B)-- User authenticates --->| Server |
| | | |
| -+----(C)-- Authorization Code ---<| |
+-|----|---+ +---------------+
| | ^ v
(A) (C) | |
| | | |
^ v | |
+---------+ | |
| |>---(D)-- Authorization Code ---------' |
| Client | & Redirection URI |
| | |
| |<---(E)----- Access Token -------------------'
+---------+ (w/ Optional Refresh Token)Note: The lines illustrating steps (A), (B), and (C) are broken into two parts as they pass through the user-agent.
+----------+
| Resource |
| Owner |
| |
+----------+
^
|
(B)
+----|-----+ Client Identifier +---------------+
| -+----(A)-- & Redirection URI --->| |
| User- | | Authorization |
| Agent -|----(B)-- User authenticates -->| Server |
| | | |
| |<---(C)--- Redirection URI ----<| |
| | with Access Token +---------------+
| | in Fragment
| | +---------------+
| |----(D)--- Redirection URI ---->| Web-Hosted |
| | without Fragment | Client |
| | | Resource |
| (F) |<---(E)------- Script ---------<| |
| | +---------------+
+-|--------+
| |
(A) (G) Access Token
| |
^ v
+---------+
| |
| Client |
| |
+---------+Note: The lines illustrating steps (A) and (B) are broken into two parts as they pass through the user-agent.
+----------+
| Resource |
| Owner |
| |
+----------+
v
| Resource Owner
(A) Password Credentials
|
v
+---------+ +---------------+
| |>--(B)---- Resource Owner ------->| |
| | Password Credentials | Authorization |
| Client | | Server |
| |<--(C)---- Access Token ---------<| |
| | (w/ Optional Refresh Token) | |
+---------+ +---------------++---------+ +---------------+ | | | | | |>--(A)- Client Authentication --->| Authorization | | Client | | Server | | |<--(B)---- Access Token ---------<| | | | | | +---------+ +---------------+
+--------+ +---------------+ | |--(A)- Authorization Request ->| Resource | | | | Owner | | |<-(B)-- Authorization Grant ---| | | | +---------------+ | | | | +---------------+ | |--(C)-- Authorization Grant -->| Authorization | | Client | | Server | | |<-(D)----- Access Token -------| | | | +---------------+ | | | | +---------------+ | |--(E)----- Access Token ------>| Resource | | | | Server | | |<-(F)--- Protected Resource ---| | +--------+ +---------------+
Tags: :IT国際標準, :認証基盤, :クレームベース認証, :OAuth
