![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
Open棟梁Project - マイクロソフト系技術情報 Wiki
| 項番 | 名称 | 実体例 | やること |
| １ | ResourceOwner? | ユーザ（人間） | ResourceOwnerのCredentialsを入力してリソースにアクセスする。 |
| ２ | Client | Program(Webブラウザ, Webアプリケーション, etc.) | １、３、４を繋ぐ忙しいプログラム（だからクレームベース認証は難しい） |
| ３ | AuthorizationServer? | 認証・認可のサーバー機能 | 認証チケットとAccess Tokenの発行を行うWebアプリケーション。 |
| ４ | ResourceServer? | リソースアクセスを提供するサーバー機能、 AuthorizationServer?と別でも良い | Access Tokenを受けてリソースアクセスを提供するWebアプリケーション。 |
+--------+ +---------------+ | |--(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 ---| | +--------+ +---------------+
ResourceOwner?は、Clientを経由して、AuthorizationServer?（の認証画面）で認証する。
認証後、Clientは、AuthorizationServer?の認可エンドポイントで認可グラントを受け取る。
Clientは、AuthorizationServer?のTokenエンドポイントに認可グラントを提示することで、Access Tokenを要求する.
AuthorizationServer?は、Clientと 認可グラントが正当であれば、ClientにAccess Tokenを発行する。
Clientは、ResourceServer?にAccess Tokenを提示してProtected Resourceにアクセスする。
以下４つのフローがある。
client_idを使用して、Clientを登録する。
RFCを読むと、
RFCを読むと、
仕様の外（ユーザID、パスワードなどを使用してResourceOwner?を認証）
セキュリティに関する考察
既知の問題点を組み合わせた攻撃手法。
以下の2つが組み合わさって成立する。
state パラメタとは、
ザックリ言って、
と言うモノらしい。
「OAuth 2.0 の implicit grant flow を認証に使うと、車が通れる程どてかいセキュリティ・ホールが開く。」らしい。
この、セキュリティ・ホールとは、
ザックリ言って、
と言うモノらしい。
この問題に対しては、
以下のように対策できる。
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 ---| | +--------+ +---------------+
