マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

目次

概要

ここでは、基本的に、OAuth 2.0について言及する。

OAuth 2.0は、認証ではなく認可のためのプロトコル(権限委譲プロトコル)。

変遷

OAuth 1.0

  • OpenIDを使ってTwitterやMa.gnoliaのAPIの認証委譲する方法を議論を開始。
  • 2007/4
    OAuthのコミュニティが誕生。
  • 2007/7
    OAuthの仕様の草案が完成。
  • 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の違い

概要

  1. HTTPSを必須にし、署名をなくし、Token取得も簡略化
  2. Access Tokenのみでリソース取得が可能に
  3. Webアプリも含め、4つのClient Profileを仕様化
    1. Webサーバ(Web Server)
      Webアプリケーション
    2. User Agentベースアプリケーション
      WWWブラウザ上のJavaScript
    3. ネイティブアプリ(Native Application)
      モバイルやデスクトップアプリ(ガイドライン程度しか定義されていない)
    4. 自立クライアント(Autonomous)
      既存の認証フレームワークとSAMLなどのプロトコルを使って連携する場合のフロー。

参考

OAuth 2.0とOpenID Connectの違い

概要

  • TokenがJWTアサーション形式で暗号化・署名される。
  • コレ以外にも、多数のオプションが追加されている。

参考

(OAuth 2.0 の)詳細

登場人物

Resource Owner

Client

  • 実体例:
    • Resource ServerにアクセスするClient。
    • Program
      • Webブラウザ
      • スマホ ネイティブ
      • Webアプリケーション
      • , etc.
  • やること:
    • Authorization Serverの認可を受けてResource Serverのリソースにアクセスする。
    • 認可レイヤの設置により、認証・認可の役割が分割されたため、
      Resource Owner, Authorization Server, Resource Serverを繋ぐ
      忙しいプログラムになった(だからOAuthはClient側でも難しい)。

Authorization Server

  • 実体例:認証・認可のサーバー機能(Webアプリケーション)
  • やること:
    • Authorization Server用の認証チケットの発行を行う。
    • Resource Server用のAccess Tokenの発行を行う。

Resource Server

  • 実体例:
    • リソースアクセスを提供するサーバー機能(WebAPIなど)
    • Authorization Serverと別でも良い
  • やること:
    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) 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を認証する。
      • 仲介コード(code)を使用することで、Access TokenをUser Agentに露見させずに処理可能。
      • Access Tokenの露見防止には、Clientのエンドポイント・コンテンツの実装に依存する。

Implicitグラント種別

  • 特徴
    • Authorization ServerはClientを認証しない。

Resource Owner Password Credentialsグラント種別

  • 概要
    • ベース クライアント セキュリティ モデルみたいなもんだが、
      以下のようにあるため、本グラント種別の利用は、特殊なケースに留める。

      「この認可タイプを使用可能にするときには特に注意を払い、
      他のフローが実行可能でない場合にのみ許可する必要があります。」

Client Credentialsグラント種別

  • 特徴
    • Clientと Authorization Server間で調整済みの、
      Clientの保有するリソースにアクセスする場合に使用する。
    • 従って、Confidentialクライアントから使用する。
      • Authorization Serverは、Clientを認証すること。

Clientについて

種類

  • Confidentialクライアント
    Client Credentialsの機密性を維持可能なClient
    • アクセスの制限されたサーバー
  • Publicクライアント
    Client Credentialsの機密性を維持不可能なClient
    • WWWブラウザ
    • ネイティブ・アプリケーション
    • Resource Ownerのデバイスにインストールされたアプリケーション
  • Client Profile(クライアント属性)による分類
  • Confidentialクライアント
    • Webアプリケーション
  • Publicクライアント
    • ネイティブ・アプリケーション
    • SPAなどの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 Tokenの無効化・期限切れの際に新しいAccess Token取得するために使用されるCredential。
  • Authorization ServerによってClientに対して発行されるランダムな文字列。
  • Refresh Tokenの発行はオプションであり、Access TokenRefresh Tokenも含まれる。
  • Access Tokenと異なり、Resource Serverに送信されることはない。

Accessトークンのタイプ

  • Access Tokenは基本的にBearer Token。
  • トークンが誰に対して発行されたのかを確認せずに、
    「トークンを持っていること」をベースに API 利用を許可する。
  • ∴ 利用する際、暗号鍵の所持を証明するよう要求されない。
  • MAC Token
    • Accessトークンと共に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を発行するエンドポイント。
    • 特徴

Client上のエンドポイント

Redirectエンドポイント

  • 概要
    エンドポイント・コンテンツを返す。
  • 注意点
    • Authorization Codeでは、なるべくエンドポイント・コンテンツにTokenが露見しないようにする。
    • Implicitグラントなど、Tokenがコンテンツに露見してしまう場合、以下に従い拡散を防止する。
      • コンテンツには、3rd partyのscriptを含めるべきでない。
      • Client自身のscriptが初回に実行されるようにすること。
      • URIからTokenを抽出し、露見しないように他へPOSTしBodyに含めるなどする。

Requestパラメタ

response_typeパラメタ

認可エンドポイントにGETで送付する。
以下のように、グラント種別毎に、決まったパラメタを指定する必要がある。

項番グラント種別パラメタ値意味
Authorization Codecode仲介コードを要求
ImplicittokenAccess Tokenを要求

client_id, client_secretパラメタ

Clientの識別や認証のために、色々な所で使用されるパラメタ。

redirect_uriパラメタ

client_idに対応するRedirectエンドポイントを指定するために指定するパラメタ。

  • 認可エンドポイントにGETを送付するときに、部分一致するオプション値として絶対パスで指定する。

grant_typeパラメタ

TokenエンドポイントにPOSTを送付するときに指定するパラメタ。
以下のように、グラント種別毎に、決まったパラメタを指定する必要がある。

項番グラント種別パラメタ値
Authorization Codeauthorization_code
Resource Owner Password Credentialspassword
Client Credentialsclient_credentials
上記1、2、3のグラント種別でRefreshトークンを使用する際refresh_token

scopeパラメタ

stateパラメタ

CSRFのセキュリティ対策に使用が推奨されるパラメタ。

  • 要件
    • 推測困難な文字列である必要がある。(ワンタイム性は必須ではない)

Responseパラメタ

code, access_token, refresh_token

認可エンドポイント

項番パラメタ値意味
codeaccess_tokenを取得するためのtokenで、
Authorization Codeグラント種別でのみ使用する。

Tokenエンドポイント

項番パラメタ値意味
access_tokenコチラを参照
refresh_tokenコチラを参照

Request & Responseの例

認可エンドポイント

  • リクエスト例
     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=YYY
  • リクエスト例
     GET /authorize?response_type=token&client_id=XXX&state=YYY&redirect_uri=http... HTTP/1.1
     Host: ...
  • 成功レスポンス例
     HTTP/1.1 302 Found
     Location: http...#access_token=XXX&state=YYY&token_type=Bearer&expires_in=3600
  • 失敗レスポンス例
     HTTP/1.1 302 Found
     Location: http...#error=access_denied&state=YYY

Tokenエンドポイント

  • リクエスト例
    • authorization_code
       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...
  • refresh_token
     POST /token HTTP/1.1
     Host: server.example.com
     Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
     Content-Type: application/x-www-form-urlencoded
     
     grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
  • レスポンス例
    • 成功
       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"
     }

The OAuth 2.0 Authorization Framework

RFC 6749 - OAuth 2.0のフロー定義

OAuth 2.0仕様には4つのフローが定義されている。
これらのフローのタイプを「グラント種別」と呼ばれる。

以下の様な「グラント種別」がある模様。

Authorization Codeグラント種別

  • Authorization Code Flow
    +----------+
    | 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.

Implicitグラント種別

  • Implicit Grant Flow
    +----------+
    | 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 Password Credentialsグラント種別

  • Resource Owner Password Credentials Flow
    +----------+
    | Resource |
    |  Owner   |
    |          |
    +----------+
         v
         |    Resource Owner
        (A) Password Credentials
         |
         v
    +---------+                                  +---------------+
    |         |>--(B)---- Resource Owner ------->|               |
    |         |         Password Credentials     | Authorization |
    | Client  |                                  |     Server    |
    |         |<--(C)---- Access Token ---------<|               |
    |         |    (w/ Optional Refresh Token)   |               |
    +---------+                                  +---------------+

Client Credentialsグラント種別

  • Client Credentials Grant
    +---------+                                  +---------------+
    |         |                                  |               |
    |         |>--(A)- Client Authentication --->| Authorization |
    | Client  |                                  |     Server    |
    |         |<--(B)---- Access Token ---------<|               |
    |         |                                  |               |
    +---------+                                  +---------------+

RFC 6750 - Bearer Token Usage

概要

  • 認可サーバーにより発行されたAccessトークンを、
    保護リソースエンドポイント (狭義の Web API) に渡す方法を定めた仕様

フロー

 +--------+                               +---------------+
 |        |--(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 ---|               |
 +--------+                               +---------------+

OAuth 2.0 拡張

OAuth 2.0 セキュリティ関連トピック

参考

OAuth 1.0

OAuth 2.0

@IT

Qiita

slideshare

技術文書中での Shall / Should / May

Microsoft Azure Active Directory


Tags: :IT国際標準, :認証基盤, :クレームベース認証, :OAuth


トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2018-11-22 (木) 16:16:19 (25d)