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)

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. ユーザーエージェント(User-Agent)
      JavaScript
    3. ネイティブアプリ(Native Application)
      モバイルやデスクトップアプリ(ガイドライン程度しか定義されていない)
    4. 自立クライアント(Autonomous)
      既存の認証フレームワークとSAMLなどのプロトコルを使って連携する場合のフロー。

OAuth 2.0とOpenID Connectの違い

セキュリティ

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

全グラント種別共通

Clientなりすまし(偽装)

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

Open Redirect

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

Authorization Codeグラント種別

CSRF

Open Redirect

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

Implicitグラント種別

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

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

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

ザックリ言って、

と言うモノらしい。

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

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

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

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

以下のBlogを参照して、

「OAuthが権限委譲(認可伝達)プロトコルなのは事実です。
・・・権限委譲プロトコルのひとつの利用方法に過ぎないからです。」

「権限委譲プロトコルOAuthで、事実上、認証伝達ができる。」

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

ただし、OAuth 2.0には以下の問題があると考える。

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

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

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

従って、この問題は、

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

参考

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


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