「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
ここでは、基本的に、OAuth 2.0について言及する。
OAuth 2.0は、認証ではなく認可のためのプロトコル（権限委譲プロトコル）。
変遷 †
OAuth 1.0 †
- OpenIDを使ってTwitterやMa.gnoliaのAPIの認証委譲する方法を議論を開始。
- 2007/10
OAuth Core 1.0 の最終草案がリリース。
- 2008/11
第73回のIETF会合でOAuthの非公式会合も開かれ、
IETFにOAuthプロトコルを提案するかどうかを議論。
- 2009/4/23
OAuth 1.0のセキュリティ問題が判明。
この問題は、OAuth 1.0aで修正された。
OAuth 2.0 †
- OAuth 1.0とは後方互換性を持たない。
- 次世代のOAuthプロトコルとして、2012年にRFCとして発行された。
OAuth 1.0とOAuth 2.0の違い †
概要 †
- HTTPSを必須にし、署名をなくし、トークン取得も簡略化
- Access Tokenのみでリソース取得が可能に
- Webアプリも含め、4つのClient Profileを仕様化
- Webサーバ（Web Server）
Webアプリケーション
- User Agentベースアプリケーション
WWWブラウザ上のJavaScript
- ネイティブアプリ（Native Application）
モバイルやデスクトップアプリ（ガイドライン程度しか定義されていない）
- 自立クライアント（Autonomous）
既存の認証フレームワークとSAMLなどのプロトコルを使って連携する場合のフロー。
参考 †
OAuth 2.0とOpenID Connectの違い †
概要 †
- トークンがJWTアサーション形式で暗号化・署名される。
- 新しく、Hybrid Flowが追加されている。
- Authorization Codeグラント種別 ---> Authorization Code Flow
- Implicitグラント種別 ---> Implicit Flow
- 上記の組合せたようなグラント種別 ---> Hybrid Flow
参考 †
- OpenID Connect 入門 〜コンシューマーにおけるID連携のトレンド〜
- OAuth 2.0 Authorization Code Flow
- OpenID Connect Authorization Code Flow
詳細 †
登場人物 †
Resource Owner †
Client †
- 実体例:
- Resource ServerにアクセスするClient。
- Program
- Webブラウザ
- スマホ ネイティブ
- Webアプリケーション
- , etc.
- やること:
- Authorization Serverの認可を受けてResources Serverのリソースにアクセスする。
- 認可レイヤの設置により、認証・認可の役割が分割されたため、
Resource Owner, Authorization Server, Resource Serverを繋ぐ
忙しいプログラムになった（だからOAuthはClient側でも難しい）。
Authorization Server †
- 実体例:認証・認可のサーバー機能（Webアプリケーション）
- やること:
- Authorization Server用の認証チケットの発行を行う。
- Resource Server用のAccess Tokenの発行を行う。
Resource Server †
- 実体例:
- リソースアクセスを提供するサーバー機能（WebAPIなど）
- Authorization Serverと別でも良い
プロトコル・フロー †
+--------+ +---------------+
| |--(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) Authorization Request †
Resource Ownerは、Clientを経由して、Authorization Server（の認証画面）で認証する。
(B) Authorization Grant †
認証後、Clientは、Authorization Serverの認可エンドポイントで認可グラントを受け取る。
(C) Authorization Grant †
Clientは、Authorization ServerのTokenエンドポイントに認可グラントを提示することで、Access Tokenを要求する.
(D) Access Token †
Authorization Serverは、Clientと 認可グラントが正当であれば、ClientにAccess Tokenを発行する。
(E) Access Token, (F) Protected Resource †
Clientは、Resource ServerにAccess Tokenを提示してProtected Resourceにアクセスする。
★ 参考 †
ココのスライドが参考になる。
グラント種別毎のフロー †
以下、4つのグラント種別に対応するフローがある。
Authorization Codeグラント種別 †
- 特徴
- Authorization ServerはClientを認証する。
Implicitグラント種別 †
- 特徴
- Authorization ServerはClientを認証しない。
Resource Owner Password Credentialsグラント種別 †
- 概要
- ベース クライアント セキュリティ モデルみたいなもんだが、
以下のようにあるため、本グラント種別の利用は、特殊なケースに留める。
「この認可タイプを使用可能にするときには特に注意を払い、
他のフローが実行可能でない場合にのみ許可する必要があります。」
- 特徴
- Resource OwnerのCredentialsをClientに送ってしまう。
- 従って、Confidential Clientから使用する。
- Resource OwnerとClientの間に高い信頼関係があること。
- Authorization Serverは、Clientを認証すること。
- 以下のような、特殊なケースに留める。
Client Credentialsグラント種別 †
- 特徴
- Clientと Authorization Server間で調整済みの、
Clientの保有するリソースにアクセスする場合に使用する。
- 従って、Confidential Clientから使用する。
- Authorization Serverは、Clientを認証すること。
Clientについて †
種類 †
- Public
Client Credentialsの機密性を維持不可能なClient
- WWWブラウザ
- ネイティブ・アプリケーション
- Resource Ownerのデバイスにインストールされたアプリケーション
- Client Profile（クライアント属性）による分類
- Confidential
- Public
- ネイティブ・アプリケーション
- User Agentベースアプリケーション（WWWブラウザ上のJavaScript）
事前登録 †
認可用のCredentials（Token） †
Access Token †
RFCを読むと、
- 保護されたリソースにアクセスするために使用されるCredential。
- Authorization ServerによってClientに対して発行されるランダムな文字列。
- アクセス範囲とアクセス期間を表す。
- 発行はResource Ownerによって許可される。
- Authorization ServerのTokenエンドポイントが発行し、
- Resource Serverへの要求に対して、以下の様な形式で送信される。
GET /resource/1 HTTP/1.1
Host: example.com
Authorization: Bearer XXXXXXXXXX
Refresh Token †
RFCを読むと、
Accessトークンのタイプ †
- Bearer Token
- 署名無しトークン（Access Tokenは基本的にBearer Token）
- トークンが誰に対して発行されたのかを確認せずに、
「トークンを持っていること」をベースに API 利用を許可する。
- ∴ 利用する際、暗号鍵の所持を証明するよう要求されない。
- MAC Token
- アクセストークンと共にMessage Authentication Code (MAC)キーを発行する。
- MACキーはHTTPリクエストの一部分を署名するのに利用される。
認証用のCredentials †
Resource Owner †
Resource Ownerの認証用のCredentialsはOAuth 2.0 仕様の外
（Authorization ServerはユーザID、パスワードなどを使用してResource Ownerを認証）
Client †
Clientの認証用のCredentials
（Authorization ServerはこれによりClientを認証）
- クライアント識別子
クライアント識別子（2つのセット）の情報は、URIで送信しない。
- client_id（1つだけの場合、URIに露見する）
- client_secret（URIに露見しない、させない）
- 認証方法
- ベーシック認証などのパスワードベースのHTTP認証スキーム
- HTTP認証スキームを使用できない場合にPOSTを使用する（非推奨）。
エンドポイントの種類 †
URLは仕様で規定されない。
Authorization Server上のエンドポイント †
- 認可エンドポイント
- 概要
- Resource Ownerを認可するエンドポイント
- 認証画面ではないので注意（認証結果を見て認可する）。
- 仲介コードや、Access Tokenを発行するエンドポイント。
- 特徴
- HTTPSのGETを使用する。
- Authorization Codeや、Implicitグラント種別で使用する。
Client上のエンドポイント †
Redirectエンドポイント
- 特徴
- HTTPSのGETを使用する。
- Authorization Codeや、Implicitグラント種別で使用する。
- 注意点
- Authorization Codeでは、なるべくエンドポイント・コンテンツにトークンが露見しないようにする。
- Implicitグラントなど、トークンがコンテンツに露見してしまう場合、以下に従い拡散を防止する。
- コンテンツには、3rd partyのscriptを含めるべきでない。
- Client自身のscriptが初回に実行されるようにすること。
- URIからトークンを抽出し、露見しないように他へPOSTしBodyに含めるなどする。
Requestパラメタ †
response_typeパラメタ †
認可エンドポイントにGETで送付する。
以下のように、グラント種別毎に、決まったパラメタを指定する必要がある。
| 項番 | グラント種別 | パラメタ値 | 意味 |
| １ | Authorization Code | code | 仲介コードを要求 |
| ２ | Implicit | token | Access Tokenを要求 |
client_id, client_secretパラメタ †
Clientの識別や認証のために、色々な所で使用されるパラメタ。
redirect_uriパラメタ †
client_idに対応するRedirectエンドポイントを指定するために指定するパラメタ。
grant_typeパラメタ †
TokenエンドポイントにPOSTを送付するときに指定するパラメタ。
以下のように、グラント種別毎に、決まったパラメタを指定する必要がある。
| 項番 | グラント種別 | パラメタ値 |
| １ | Authorization Code | authorization_code |
| ２ | Resource Owner Password Credentials | password |
| ３ | Client Credentials | client_credentials |
| ４ | 上記１、２、３のグラント種別でRefreshトークンを使用する際 | refresh_token |
scopeパラメタ †
- Authorization Codeグラント種別
- 認可エンドポイントにGETで送付する。
- 送信前に、画面で認可scopeをResource Ownerに提示する。
- Resource Owner Password Credentialsグラント種別
stateパラメタ †
CSRFのセキュリティ対策に使用が推奨されるパラメタ。
- 概要
- 認可エンドポイントにGETを送付するときに指定する。
- Redirectエンドポイントを使用する、Authorization Code, Implicitグラント種別で使用する。
- 以降のやり取りでも引き継がれて使用される（値は変更しないこと）。
- 要件
- 推測困難な文字列である必要がある。（ワンタイム性は必須ではない）
Responseパラメタ †
code, access_token, refresh_token
| 項番 | パラメタ値 | 意味 |
| １ | code | access_tokenを取得するためのtokenで、Authorization Codeグラント種別でのみ使用する。 |
| ２ | access_token | コチラを参照 |
| ３ | refresh_token | コチラを参照 |
参考 †
OAuth 1.0 †
OAuth 2.0 †
＠IT †
- OAuth 2.0でWebサービスの利用方法はどう変わるか
Qiita †
slideshare †
Tags: :認証基盤, :クレームベース認証, :OAuth
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
