「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
ここでは、基本的に、OAuth 2.0について言及する。
OAuth 2.0は、認証ではなく認可のためのプロトコル(権限委譲プロトコル)。
- HTTPSを必須にし、署名をなくし、トークン取得も簡略化
- Access Tokenのみでリソース取得が可能に
- Webアプリも含め、4つのClient Profileを仕様化
- Webサーバ(Web Server)
Webアプリケーション- User Agentベースアプリケーション
WWWブラウザ上のJavaScript- ネイティブアプリ(Native Application)
モバイルやデスクトップアプリ(ガイドライン程度しか定義されていない)- 自立クライアント(Autonomous)
既存の認証フレームワークとSAMLなどのプロトコルを使って連携する場合のフロー。
+--------+ +---------------+ | |--(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で送付する。
以下のように、グラント種別毎に、決まったパラメタを指定する必要がある。
項番 | グラント種別 | パラメタ値 | 意味 |
1 | Authorization Code | code | 仲介コードを要求 |
2 | Implicit | token | Access Tokenを要求 |
Clientの識別や認証のために、色々な所で使用されるパラメタ。
client_idに対応するRedirectエンドポイントを指定するために指定するパラメタ。
TokenエンドポイントにPOSTを送付するときに指定するパラメタ。
以下のように、グラント種別毎に、決まったパラメタを指定する必要がある。
項番 | グラント種別 | パラメタ値 |
1 | Authorization Code | authorization_code |
2 | Resource Owner Password Credentials | password |
3 | Client Credentials | client_credentials |
4 | 上記1、2、3のグラント種別でRefreshトークンを使用する際 | refresh_token |
CSRFのセキュリティ対策に使用が推奨されるパラメタ。
項番 | パラメタ値 | 意味 |
1 | code | access_tokenを取得するためのtokenで、Authorization Codeグラント種別でのみ使用する。 |
2 | access_token | コチラを参照 |
3 | refresh_token | コチラを参照 |
その他にも、以下のようなフローがある。
セキュリティに関する考察
Redirectエンドポイントの変更により、攻撃者のClientに誘導できる。
「OAuth 2.0 の implicit grant flow を認証に使うと、
車が通れる程どてかいセキュリティ・ホールが開く。」らしい。
この、セキュリティ・ホールとは、
ザックリ言って、
と言うモノらしい。
認証ではなく認可のためのプロトコル(権限委譲プロトコル)である。
OAuth 2.0の仕様を熟読してもOAuth2.0を認証に使用しても問題ないように見える。
以下のBlogを参照して、
の部分を見ると、全権限の認可は≒認証で、
OAuth 2.0による認証も、OAuth 2.0の一利用方法と捉えることができる。
従って、「OAuth 2.0は認証で使用できる。」と考える。
ただし、「OAuth 2.0には以下の問題がある。」と考える。
このため、これらの問題がある状態で、OAuth 2.0を認証に使用すると、
「Resource Serverで公開しているリソースへのアクセスを認可する。」
という限られた権限より、(システムにログインできるということは)大きい権限を委譲することになるので、
この発言の背景では、「認可に比べ、認証に使用した場合、リスクが大きい。」という問題が懸念されている。
従って、この問題は、
以下のように対策できる。
Implicitを利用している場合、Authorization Codeを利用できないか確認する。
Authorization Codeであれば、Access Tokenの露見の可能性は低い(ただし、Clientの作り次第)。
その他、新しい仕様も策定されている。
発行されたアクセストークンやリフレッシュトークンを取り消すための手段
OAuth 2.0 Threat Model and Security Considerations
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 ---| | +--------+ +---------------+
+----------+ +----------------+ | |>---(A)-- Client Identifier --->| | | | | | | |<---(B)-- Verification Code, --<| | | | User Code, | | | | & Verification URI | | | Device | | | | Client | Client Identifier & | | | |>---(E)-- Verification Code --->| | | | polling... | | | |>---(E)-- Verification Code --->| | | | | Authorization | | |<---(F)-- Access Token --------<| Server | +----------+ (w/ Optional Refresh Token) | | v | | : | | (C) User Code & Verification URI | | : | | v | | +----------+ | | | End-user | | | | at |<---(D)-- User authenticates -->| | | Browser | | | +----------+ +----------------+
Tags: :認証基盤, :クレームベース認証, :OAuth