メインコンテンツまでスキップ

1. Introduction (はじめに)

1. Introduction (はじめに)​

OAuth 2.0 Authorization Framework (認可フレームワーク) [RFC6749] は, サードパーティのクライアントアプリケーションが保護リソースへの委任アクセスを得られるようにする. 図 1 に示す典型的な抽象 OAuth フローでは, クライアントは authorization server (認可サーバ) と呼ばれるエンティティから access token を取得し, HTTPS API などの保護リソースにアクセスするときにそのトークンを用いる.

  +--------+                                 +---------------+
  |        |                                 |               |
  |        |<--(A)-- Get an access token --->| Authorization |
  |        |                                 |     Server    |
  |        |                                 |               |
  |        |                                 +---------------+
  |        |                                         ^
  |        |                                         |
  |        |
  |        |                               (C)       |
  | Client |                           Validate the
  |        |                           access token  |
  |        |
  |        |                                         |
  |        |                                         v
  |        |                                 +---------------+
  |        |                                 |      (C)      |
  |        |                                 |               |
  |        |<--(B)-- Use the access token -->|   Protected   |
  |        |                                 |    Resource   |
  |        |                                 |               |
  +--------+                                 +---------------+

              Figure 1: Abstract OAuth 2.0 Protocol Flow

図 1 のフローは次のステップを含む:

(A) クライアントは authorization server に対し HTTPS POST リクエストを行い, authorization grant (認可グラント) を表すクレデンシャルを提示する. 特定種のクライアント (client credentials (クライアントクレデンシャル) が発行またはその他の方法で確立されているもの) については, リクエストは認証されなければならない. 応答として authorization server はクライアントに access token を発行する.

(B) クライアントは保護リソースへのアクセス要求に access token を含める.

(C) 保護リソースは要求を認可するために access token を検証する. トークンが自己完結かつ暗号的に保護されている場合など, 保護リソースがローカルで検証できる場合もある. 他の場合は, 保護リソースが authorization server に問い合わせてトークンの状態とメタ情報を得る必要がある.

上記の抽象フローに重ねて, 本文書はクライアント証明書ベースの mutual TLS を用いた OAuth 2.0 の拡張セキュリティオプションを標準化する. セクション 2 はステップ (A) の要求を認証するオプションを提供する. ステップ (C) については, セクション 3.1 および 3.2 でそれぞれローカル処理とリモート処理の両方でトークンをクライアント証明書にバインドする意味論によりサポートされる. これによりセクション 3 のとおり, ステップ (B) の保護リソースアクセスは, 証明書バインドトークンを用い証明書に対応する秘密鍵を保持する正当なクライアントのみが可能となる.

OAuth 2.0 は共有秘密によるクライアント認証を定義するが, authorization server との直接対話において追加のクライアント認証メカニズムの定義と使用も許容する. 本文書は mutual-TLS 証明書ベースのクライアント認証の追加メカニズムを記述し, 共有秘密より良好なセキュリティ特性を提供する. [RFC6749] は token endpoint への要求のクライアント認証を記載しているが, OAuth 2.0 の拡張 (Introspection [RFC7662], Revocation [RFC7009], [OpenID.CIBA] の Backchannel Authentication Endpoint など) はクライアント認証を用いるエンドポイントも定義しており, 本文で定義する mutual-TLS 方法はそれらのエンドポイントにも適用できる.

Mutual-TLS certificate-bound access token は, 証明書に対応する秘密鍵を保持する当事者のみがトークンを用いて関連リソースにアクセスできることを保証する. この制約は key confirmation, proof-of-possession, holder-of-key などと呼ばれ, [RFC6750] の bearer token の場合とは異なり, access token を保持する任意の当事者がリソースにアクセスできるわけではない. access token をクライアント証明書にバインドすると, 盗まれたトークンの使用や不正当事者によるトークンのリプレイを防ぐ.

Mutual-TLS 証明書バインド access token と mutual-TLS クライアント認証は別メカニズムであり補完的だが, 必ずしも一緒に導入または使用する必要はない.

本文書は証明書バインド access token および mutual-TLS クライアント認証を支援する追加の client metadata (クライアントメタデータ) パラメータを導入する. authorization server は Dynamic Client Registration Protocol [RFC7591] によりクライアントメタデータを取得できる. また [RFC7591] で定義されたメタデータと登録済み拡張は, 動的クライアント登録プロトコルを用いない場合でも authorization server 実装に有用なクライアントの一般データモデルを示唆する. そのような実装では通常, クライアント設定を管理するユーザーインターフェースを備える.

に最終更新