Open棟梁Project - マイクロソフト系技術情報 Wiki

目次

概要

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

登場人物

項番名称実体例やること
ResourceOwner?ユーザ(人間)ResourceOwnerのCredentialsを入力してリソースにアクセスする。
ClientProgram(Webブラウザ, Webアプリケーション, etc.)ResourcesServer?にアクセスするClient。
認可レイヤの設置により、認証・認可の役割が分割されたため、
1、3、4を繋ぐ忙しいプログラムになった(だからクレームベース認証は難しい)
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 ---|               |
+--------+                               +---------------+

(A) Authorization Request

ResourceOwner?は、Clientを経由して、AuthorizationServer?(の認証画面)で認証する。

(B) Authorization Grant

認証後、Clientは、AuthorizationServer?認可エンドポイントで認可グラントを受け取る。

(C) Authorization Grant

Clientは、AuthorizationServer?Tokenエンドポイントに認可グラントを提示することで、Access Tokenを要求する.

(D) Access Token

AuthorizationServer?は、Clientと 認可グラントが正当であれば、ClientにAccess Tokenを発行する。

(E) Access Token, (F) Protected Resource

Clientは、ResourceServer?Access Tokenを提示してProtected Resourceにアクセスする。

グラント種別毎のフロー

以下、4つのグラント種別に対応するフローがある。

Authorization Codeグラント種別

Implicitグラント種別

Resource Owner Password Credentialsグラント種別

Client Credentialsグラント種別

Clientについて

種類

事前登録

認可用のCredentials(Token)

Access Token

RFCを読むと、

GET /resource/1 HTTP/1.1
Host: example.com
Authorization: Bearer XXXXXXXXXX

Refresh Token

RFCを読むと、

Accessトークンのタイプ

認証用のCredentials

ResourceOwner?

ResourceOwner?の認証用のCredentialsはOAuth 2.0 仕様の外
AuthorizationServer?はユーザID、パスワードなどを使用してResourceOwner?を認証)

Client

Clientの認証用のCredentials
AuthorizationServer?はこれによりClientを認証)

エンドポイントの種類

URLは仕様で規定されない。

AuthorizationServer?上のエンドポイント

Client上のエンドポイント

Redirectエンドポイント

パラメタの種類

response_typeパラメタ

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

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

client_id, client_secretパラメタ

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

redirect_uriパラメタ

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

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グラント種別でのみ使用する。
access_tokenコチラを参照
refresh_tokenコチラを参照

変遷

OAuth 1.0

OAuth 2.0

OAuth 1.0とOAuth 2.0の違い

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

OAuth 2.0とOpenID Connectの違い

セキュリティ

セキュリティに関する考察

全グラント種別共通

Clientなりすまし(偽装)

Authorization Code, Implicitグラント種別共通

Open Redirect

Redirectエンドポイントの変更により、攻撃者のClientに誘導できる。

Authorization Codeグラント種別

CSRF

Implicitグラント種別

Tokenの置き換え(不正利用)

「OAuth 2.0 の implicit grant flow を認証に使うと、
車が通れる程どてかいセキュリティ・ホールが開く。」らしい。

この、セキュリティ・ホールとは、

ザックリ言って、

と言うモノらしい。

この内容の良くない所は、

が、ごちゃ混ぜになっていること。

OAuth2.0を認証に使用する際の問題点とその対応方法

OAuth 2.0は認証で使用できるが、以下の問題がある。

認証ではなく認可のためのプロトコル(権限委譲プロトコル)である。
OAuth 2.0の仕様を熟読してもOAuth2.0を認証に使用しても問題ないように見える。

以下のBlogを参照して、

の部分を見ると、全権限の認可は≒認証で、
OAuth 2.0による認証も、OAuth 2.0の一利用方法と捉えることができる。

従って、「OAuth 2.0は認証で使用できる。」と考える。
ただし、「OAuth 2.0には以下の問題がある。」と考える。

このため、これらの問題がある状態で、OAuth 2.0を認証に使用すると、

ResourceServer?で公開しているリソースへのアクセスを認可する。」

という限られた権限より、大きい権限を委譲することになるので、この発言の背景では、
「認可に比べ、認証に使用した場合、リスクが大きい。」という問題が懸念されている。

OAuth 2.0を認証で使用する際の、対応方法

従って、この問題は、

以下のように対策できる。

OAuthによる外部ログイン(認証)の研究

OAuth 2.0の新しい仕様など、

詳しくは、コチラを参照。

参考

OAuth 2.0 and the Road to Hell

Inspecting access tokens

The OAuth 2.0 Authorization Framework

(RFC 6749) OAuth 2.0のフロー定義

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

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

Authorization Codeグラント種別

Note: The lines illustrating steps (A), (B), and (C) are broken into two parts as they pass through the user-agent.

Implicitグラント種別

Note: The lines illustrating steps (A) and (B) are broken into two parts as they pass through the user-agent.

Resource Owner Password Credentialsグラント種別

Client Credentialsグラント種別

RFC 6750 - Bearer Token Usage

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

OAuth 2.0


Tags: :認証基盤, :クレームベース認証, :OAuth


トップ   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS