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

目次

概要

登場人物

項番名称実体例やること
ResourceOwner?ユーザ(人間)認証情報を入力してリソースにアクセスする。
ClientProgram(Webブラウザ, Webアプリケーション, etc.)1、3、4を繋ぐ忙しいプログラム(だからクレームベース認証は難しい)
AuthorizationServer?Webアプリケーションの認証機能認証チェットとアクセストークンの発行を行う。
ResourceServer?Webアプリケーション, AuthorizationServer?と別でも良いアクセストークンを受けてリソースアクセスを提供する。
+--------+                               +---------------+
|        |--(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 ---|               |
+--------+                               +---------------+

フロー

以下4つのフローがある。

Authorization Codeグラント種別

Implicitグラント種別

Resource Owner Password Credentialsグラント種別

Client Credentialsグラント種別

認証

ResourceOwner?

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

Client

エンドポイント

AuthorizationServer?

クライアント上

変遷

OAuth 1.0

OAuth 2.0

OAuth 1.0とOAuth 2.0の違い

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

Bearer Token Usage

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

セキュリティ

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

Authorization Codeグラント種別

Open Redirector

Covert Redirect

既知の問題点を組み合わせた攻撃手法。

以下の2つが組み合わさって成立する。

state パラメタとは、

ザックリ言って、

と言うモノらしい。

Implicitグラント種別

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

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

ザックリ言って、

と言うモノらしい。

この問題に対しては、

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

Resource Owner Password Credentialsグラント種別

HTTPSはホスト名の部分だけ情報として渡し、
以後のパスやクエリストリング情報は暗号化される。

従ってGETでも一応安全だが、

という問題がある。

従って、このグラント種別では、

などが必要になると考える。

IISならW3Cログの出力をカスタマイズできる。

参考

OAuth 2.0 and the Road to Hell

Inspecting access tokens

参考

OAuth 1.0

OAuth 2.0


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