「マイクロソフト系技術情報 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で公開しているリソースへのアクセスを認可する。」
という限られた権限より、(システムにログインできるということは)大きい権限を委譲することになるので、
この発言の背景では、「認可に比べ、認証に使用した場合、リスクが大きい。」という問題が懸念されている。
従って、この問題は、
以下のように対策できる。
その他、新しい仕様も策定されている。
詳しくは、コチラを参照。
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 | | | +----------+ +----------------+
Figure 1: Device Flow.
が使用できる。
Tags: :認証基盤, :クレームベース認証, :OAuth