Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants

Internet Engineering Task Force (IETF)                       B. Campbell
Request for Comments: 7521                                 Ping Identity
Category: Standards Track                                   C. Mortimore
ISSN: 2070-1721                                               Salesforce
                                                                M. Jones
                                                               Y. Goland
                                                               Microsoft
                                                                May 2015

Abstract

本仕様は、OAuth 2.0においてアサーションを用いるための枠組みを提供する。具体的には、新しいクライアント認証メカニズムおよび新しい認可グラント種別としてアサーションを利用するための枠組みである。token endpoint との相互作用においてアサーションを転送するためのメカニズムを規定し、あわせて一般的な処理規則も規定する。

本仕様の目的は、アサーションを用いてOAuth 2.0が他のアイデンティティシステムと相互運用できる共通の枠組みを提供し、代替となるクライアント認証メカニズムを提供することである。

なお、本仕様が定義するのは抽象的なメッセージフローと処理規則のみである。実装可能とするには、対応する具体的な具現化を提供する補完仕様が必要となる。

Status of This Memo

本文書は Internet Standards Track 文書である。

本文書は Internet Engineering Task Force (IETF) の成果物である。IETFコミュニティの合意を表す。公開レビューを受け、Internet Engineering Steering Group (IESG) により発行が承認された。Internet Standards に関する追加情報は RFC 5741 の Section 2 にある。

本文書の現在の状態、正誤表、およびフィードバックの提供方法に関する情報は、以下から入手できる。

http://www.rfc-editor.org/info/rfc7521.

Copyright Notice

本文書は、発行日現在有効な IETF Trust の「IETF文書に関する法的規定」 (http://trustee.ietf.org/license-info) に従う。これらの文書には、本文書に関する権利および制限が記載されているため、注意深く確認されたい。本文書から抽出されたコード構成要素は、Trust の法的規定の Section 4.e に記載された Simplified BSD License の文言を含めなければならず、また Simplified BSD License に記載のとおり無保証で提供される。

1. Introduction

アサーションとは、セキュリティドメインを越えてアイデンティティおよびセキュリティ情報を共有することを容易にする情報のパッケージである。本仕様の目的におけるアサーションという概念のより詳細な説明は、Section 3 に示す。

OAuth 2.0 [RFC6749] は、第三者アプリケーションが保護されたHTTPリソースへの限定的なアクセスを取得できるようにする認可フレームワークである。OAuthにおいて、これらの第三者アプリケーションはクライアントと呼ばれる。クライアントは、保護されたHTTPリソースに対して Access Token を提示することでアクセスする。Access Token は、(ときに暗黙の) Resource Owner の承認の下で Authorization Server によりクライアントへ発行される。これらの Access Token は通常、認可グラント（Resource Owner から付与された認可、あるいは特権管理者による認可を表す）を交換することで取得される。幅広いクライアント種別およびユーザー体験に対応するため、複数の認可グラント種別が定義されている。OAuthはまた、追加のグラント種別を定義するための拡張メカニズムを提供しており、OAuthと他のプロトコル・フレームワークとの橋渡しとして機能し得る。

本仕様は、OAuth 2.0でアサーションを認可グラントとして使用するための一般的な枠組みを提供する。また、クライアント認証にアサーションを使用するための枠組みも提供する。Authorization Server の token endpoint との相互作用におけるアサーションの転送についての汎用メカニズム、ならびにアサーションの内容と処理に関する一般規則を提供する。意図は、代替のクライアント認証メカニズム（client secret を送信しないもの）を提供し、エンドユーザーが存在しない可能性があるクライアント・サーバー統合シナリオにおいて OAuth 2.0 の利用を容易にすることである。

本仕様が定義するのは抽象的なメッセージフローと処理規則のみである。実装可能とするには、対応する具体的な具現化を提供する補完仕様が必要となる。例えば、"Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants" [RFC7522] は Security Assertion Markup Language (SAML) 2.0 Assertions の具体的な具現化を定義し、"JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants" [RFC7523] は JWTs の具体的な具現化を定義する。

注: クライアント認証にアサーションを用いることは、アサーションを認可グラントとして用いることとは直交し、分離可能である。両者は組み合わせても、別々にも使用できる。クライアントのアサーションによる認証は、クライアントが token endpoint に対して認証するための代替手段に過ぎず、完全かつ意味のあるプロトコルリクエストを構成するには、何らかのグラント種別と併用しなければならない。アサーションの認可グラントは、クライアント認証または識別の有無にかかわらず使用できる。アサーションの認可グラントと併せてクライアント認証が必要かどうか、またサポートされるクライアント認証の種別は、Authorization Server の裁量に委ねられるポリシー上の判断である。

2. Notational Conventions

本文書中のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" は、[RFC2119] に記載のとおり解釈される。

本文書を通して、値はそれが文字どおりに解釈されるべきであることを示すために引用符で囲まれている。これらの値をプロトコルメッセージで使用する際、引用符は値の一部として使用してはならない。

3. Framework

アサーションとは、セキュリティドメインを越えてアイデンティティおよびセキュリティ情報を共有できるようにする情報のパッケージである。アサーションには一般に、サブジェクトまたはプリンシパルに関する情報、アサーションを発行した当事者および発行時刻に関する情報、ならびにアサーションが有効と見なされる条件（いつ、どこで使用できるか等）が含まれる。

アサーションを作成し、署名または完全性保護を行う主体は通常 "Issuer" として知られ、アサーションを消費し、その情報に依拠する主体は通常 "Relying Party" として知られる。本書の文脈では、Authorization Server が Relying Party として振る舞う。

本仕様が定義するプロトコル交換で使用されるアサーションは、Issuer によって適用されるデジタル署名または Message Authentication Code (MAC) を用いて、常に完全性保護されなければならない。これにより Issuer が認証され、アサーション内容の完全性が確保される。多くの場合、アサーションは第三者により発行され、提示するクライアントによる改ざんから保護されなければならない。アサーションはさらに暗号化してもよい（MAY）。その場合、（クライアントなどの）権限のない主体が内容を閲覧できないようにする。

本文書は、クライアントがアサーションを取得するプロセス（Authorization Server に送信する前）を定義しないが、一般的なパターンが2つある。それらを以下に示す。

Third-partyによるアサーション発行（Figure 1）

図1に示す第1のパターンでは、クライアントは、セキュリティトークンを発行・更新・変換・検証できる第三者エンティティからアサーションを取得する。通常、このようなエンティティは "security token service" (STS) または単に "token service" として知られ、token service と Relying Party との間には信頼関係（通常は何らかの鍵素材の交換として表れる）が存在する。token service はアサーションの Issuer であり、その役割は、各種クレデンシャルを提示するクライアントからの要求に応え、要求に従ってアサーションを鋳造し、適切な情報を格納し、署名または message authentication code により完全性保護することである。WS-Trust [OASIS.WS-Trust] は、セキュリティトークン（アサーション）を要求するための利用可能な標準の1つである。

  Relying
  Party                     Client                   Token Service
    |                          |                         |
    |                          |  1) Request Assertion   |
    |                          |------------------------>|
    |                          |                         |
    |                          |  2) Assertion           |
    |                          |<------------------------|
    |    3) Assertion          |                         |
    |<-------------------------|                         |
    |                          |                         |
    |    4) OK or Failure      |                         |
    |------------------------->|                         |
    |                          |                         |
    |                          |                         |

             Figure 1: Assertion Created by Third Party

自己発行アサーション（Figure 2）

図2に示す第2のパターンでは、クライアントがローカルでアサーションを作成する。アサーションに署名または message authentication code を適用するには、鍵素材（共通鍵または公開鍵暗号の鍵ペア）を入手しておく必要がある。この鍵素材を取得するためのメカニズムは本仕様の範囲外である。

アサーションは通常、アイデンティティおよびセキュリティ情報を伝達するために用いられるが、自己発行のアサーションは別の目的にも利用できる。例えば client secret など、ある秘密を知っていることを示すために、秘密そのものを取引の中で直接伝えずに用いることができる。この場合、クライアント自身がアサーションに含める追加情報は Relying Party にとっての価値が限定的である。このため、通常は発行と利用条件に関する情報など、最小限の情報のみを含める。

  Relying
  Party                     Client
    |                          |
    |                          | 1) Create
    |                          |    Assertion
    |                          |--------------+
    |                          |              |
    |                          | 2) Assertion |
    |                          |<-------------+
    |    3) Assertion          |
    |<-------------------------|
    |                          |
    |    4) OK or Failure      |
    |------------------------->|
    |                          |
    |                          |

                   Figure 2: Self-Issued Assertion

導入環境（デプロイメント）では、求められるセキュリティレベル、エンティティ間の信頼関係、その他の要因に基づいて、使用すべき適切な変種を決定する必要がある。

アサーションを提示するエンティティが何を行う必要があるかという観点から、アサーションには大きく2種類がある。

Bearer Assertions: bearer assertion を所持する任意のエンティティ（bearer）は、関連するリソースへのアクセスを得るためにそれを使用できる（暗号鍵の所持を示す必要はない）。悪用を防ぐため、bearer assertion は保存時および転送時の漏えいから保護する必要がある。アサーションが権限のない主体に漏えいしないよう、すべてのエンティティ間で安全な通信チャネルが必要である。
Holder-of-Key Assertions: 関連するリソースへアクセスするには、アサーションを提示するエンティティが追加の暗号素材の所持を示さなければならない。token service は鍵識別子をアサーションに結び付け、クライアントはアサーション提示時に、その識別子に対応する鍵を知っていることを Relying Party に示す必要がある。

本文書で定義するプロトコルパラメータおよび処理規則は、クライアントが bearer assertion を Authorization Server に提示することを支援する意図である。これらは holder-of-key assertion には直接適合しない。holder-of-key assertion システムのベースラインとして用いることはできるが、その場合は（秘密鍵の所持を証明するための）追加メカニズムが必要となり、場合によってはセキュリティモデルの変更（例: Audience 要件の緩和）が必要となる。

4. Transporting Assertions

本節は、OAuth Authorization Server の token endpoint との相互作用においてアサーションを転送するためのHTTPパラメータを定義する。token endpoint へのリクエストは（HTTPリクエストおよびレスポンスの両方において）平文のクレデンシャルの送信を伴うため、OAuth 2.0 [RFC6749] の Section 3.2 で義務付けられているとおり、token endpoint へのすべてのリクエストは Transport Layer Security (TLS) を使用しなければならない（MUST）。

4.1. Using Assertions as Authorization Grants

本節は、OAuth 2.0 [RFC6749] の Section 4.5 による定義に基づき、アサーションを認可グラントとして使用する方法を定義する。アサーションを認可グラントとして使用する場合、クライアントはアサーションおよび関連情報を次のHTTPリクエストパラメータで含める。

Parameters

grant_type\ REQUIRED。Authorization Server が定義するアサーションの形式。値は絶対URIとなる。

assertion\ REQUIRED。認可グラントとして使用されるアサーション。アサーションの具体的なシリアライズ形式はプロファイル文書により定義される。

scope\ OPTIONAL。OAuth 2.0 [RFC6749] の Section 3.3 に記載される要求 scope。アサーションを Access Token と交換する場合、トークンの認可はすでに何らかのアウトオブバンドの仕組みにより付与されている。そのため、要求 scope は、元々認可されたアクセス主体に付与された scope 以下でなければならない（MUST）。Authorization Server は、発行する Access Token の scope を、元々認可されたアクセス主体に付与された scope 以下に制限しなければならない（MUST）。

クライアントの認証は、OAuth 2.0 [RFC6749] の Section 3.2.1 に記載のとおり任意である。したがって、"client_id" が必要となるのは、当該パラメータに依拠するクライアント認証形式が使用される場合に限られる。

Example request

次の例は、アサーションが認可グラントとして使用されることを示す（表示の都合上のみ、余分な改行を含む）。

POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Asaml2-bearer&
assertion=PHNhbWxwOl...[omitted for brevity]...ZT4

この文脈で使用されるアサーションは一般に短命な認可グラント表現であり、Authorization Server は、アサーションの有効期間を大きく超える寿命の Access Token を発行すべきではない（SHOULD NOT）。実務上は、アサーション・グラント要求への応答として Refresh Token は発行されないことが多く、Access Token は適度に短い寿命で発行される。クライアントは、Access Token が失効した場合、アサーションがまだ有効であれば同じアサーションを使用して、あるいは新しいアサーションを用いて新たな Access Token を要求することで更新できる。

"grant_type" 値として使用するためのIETF URNは、[RFC6755] のテンプレートを用いて要求できる。urn:ietf:params:oauth:grant-type:* 形式のURNが提案される。

4.1.1. Error Responses

アサーションが無効である、または期限切れである場合、Authorization Server は OAuth 2.0 [RFC6749] で定義されたエラーレスポンスを構成する。"error" パラメータの値は "invalid_grant" エラーコードでなければならない（MUST）。Authorization Server は、アサーションが無効と判断された理由に関する追加情報を "error_description" または "error_uri" パラメータで含めてもよい（MAY）。

Example response

HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store

{
  "error":"invalid_grant",
  "error_description":"Audience validation failed"
}

4.2. Using Assertions for Client Authentication

次の節は、OAuth 2.0 [RFC6749] の Section 2.3 の拡張として、アサーションを client credentials として使用する方法を定義する。アサーションを client credentials として使用する場合、クライアントはアサーションおよび関連情報を次のHTTPリクエストパラメータで含める。

Parameters

client_assertion_type\ REQUIRED。Authorization Server が定義するアサーションの形式。値は絶対URIとなる。

client_assertion\ REQUIRED。クライアントを認証するために使用されるアサーション。アサーションの具体的なシリアライズ形式はプロファイル文書により定義される。

client_id\ OPTIONAL。OAuth 2.0 [RFC6749] の Section 2.2 に記載のクライアント識別子。クライアントはアサーションの Subject により識別されるため、アサーションによるクライアント認証では "client_id" は不要である。もし存在する場合、"client_id" パラメータの値は、クライアントアサーションが識別するのと同一のクライアントを識別しなければならない（MUST）。

Example request

次の例は、OAuth 2.0 [RFC6749] の Section 4.1.3 で定義される Access Token 要求中に、クライアントがアサーションを用いて認証することを示す（表示の都合上のみ、余分な改行を含む）。

POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&
code=n0esc3NRze7LTCu7iYzS6a5acc3f0ogp4&
client_assertion_type=urn%3Aietf%3Aparams%3Aoauth
%3Aclient-assertion-type%3Asaml2-bearer&
client_assertion=PHNhbW...[omitted for brevity]...ZT

token endpoint は、"client_assertion" および "client_assertion_type" パラメータの有無を見ることで、アサーションに基づくクレデンシャルと、他のクライアントクレデンシャル種別を区別できる。これらのパラメータは、クライアント認証にアサーションを使用する場合にのみ存在する。

"client_assertion_type" 値として使用するためのIETF URNは、[RFC6755] のテンプレートを用いて要求できる。urn:ietf:params:oauth:client-assertion-type:* 形式のURNが提案される。

4.2.1. Error Responses

アサーションが何らかの理由で無効である場合、または複数のクライアント認証メカニズムが使用された場合、Authorization Server は OAuth 2.0 [RFC6749] で定義されたエラーレスポンスを構成する。"error" パラメータの値は "invalid_client" エラーコードでなければならない（MUST）。Authorization Server は、クライアントアサーションが無効と判断された理由に関する追加情報を "error_description" または "error_uri" パラメータで含めてもよい（MAY）。

Example response

HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store

{
  "error":"invalid_client"
  "error_description":"assertion has expired"
}

5. Assertion Content and Processing

本節は、OAuth 2.0 [RFC6749] におけるアサーション利用のための一般的な内容および処理モデルを提供する。

5.1. Assertion Metamodel

以下は、OAuth 2.0におけるアサーションの発行、交換、および処理に関与するエンティティおよびメタデータである。これらは特定のアサーション形式から独立した一般用語である。これらの用語を具体的な表現へ対応付ける方法は、本仕様のプロファイルにより提供される。

Issuer

アサーションを発行したエンティティの一意識別子。一般に、アサーションへ署名または完全性保護を行うために用いられる鍵素材を保持するエンティティである。Issuer の例としては、（アサーションが自己発行の場合の）OAuth クライアントや、第三者の security token service がある。アサーションが自己発行であれば、Issuer の値はクライアント識別子である。アサーションが security token service (STS) により発行された場合、Issuer は Authorization Server が認識できる方法で STS を識別すべきである（should）。アプリケーション・プロファイルが別段の規定をしない限り、準拠するアプリケーションは、RFC 3986 [RFC3986] の Section 6.2.1 で定義される Simple String Comparison により Issuer 値を比較しなければならない（MUST）。

Subject

アサーションのサブジェクトであるプリンシパルの一意識別子。

クライアント認証にアサーションを用いる場合、Subject は OAuth クライアントの "client_id" の値を用いて、Authorization Server に対しクライアントを識別する。
アサーションを認可グラントとして用いる場合、Subject は、Access Token が要求されている認可済みアクセス主体（通常は Resource Owner または認可された委任者）を識別する。

Audience

アサーションを処理することが意図された当事者（複数可）を識別する値。OAuth 2.0 [RFC6749] の Section 3.2 で定義される token endpoint のURLを用いて、Authorization Server がアサーションの正当な対象 Audience であることを示せる。アプリケーション・プロファイルが別段の規定をしない限り、準拠するアプリケーションは、RFC 3986 [RFC3986] の Section 6.2.1 で定義される Simple String Comparison により Audience 値を比較しなければならない（MUST）。

Issued At

アサーションが発行された時刻。シリアライズ形式はアサーション形式によって異なり得るが、時刻はUTCで、タイムゾーン要素を含めずに表現されなければならない（REQUIRED）。

Expires At

アサーションが失効する時刻。シリアライズ形式はアサーション形式によって異なり得るが、時刻はUTCで、タイムゾーン要素を含めずに表現されなければならない（REQUIRED）。

Assertion ID

アサーションの nonce または一意識別子。Assertion ID は、ワンタイムユースのアサーションに対してメッセージ重複排除を必要とする実装で使用できる。識別子を割り当てるエンティティは、そのエンティティ自身または他の任意のエンティティが、異なるデータオブジェクトに同一の識別子を偶発的に割り当ててしまう確率が無視できるほど小さいことを保証しなければならない（MUST）。

5.2. General Assertion Format and Processing Rules

以下は、OAuthにおけるアサーション利用のための一般的な形式および処理規則である。

アサーションは Issuer を含まなければならない（MUST）。Issuer は、Authorization Server に認識される形で、アサーションを発行したエンティティを識別する。アサーションが自己発行である場合、Issuer はクライアントの "client_id" の値でなければならない（MUST）。

アサーションは Subject を含まなければならない（MUST）。Subject は通常、Access Token が要求されている認可済みアクセス主体（すなわち Resource Owner または認可された委任者）を識別するが、場合によっては仮名化された識別子や、匿名ユーザーを示す他の値であることもある。クライアントが自分自身を代表して動作している場合、Subject はクライアントの "client_id" の値でなければならない（MUST）。

アサーションは、意図された Audience として Authorization Server を識別する Audience を含まなければならない（MUST）。Authorization Server は、意図された Audience として自らの識別子を含まないアサーションを拒否しなければならない（MUST）。

アサーションは、アサーションが使用できる時間窓を制限する Expires At エンティティを含まなければならない（MUST）。Authorization Server は、期限切れのアサーションを拒否しなければならない（MUST）（システム間で許容される時計のずれを考慮する）。なお、Authorization Server は、Expires At 属性値が不合理に遠い未来であるアサーションを拒否してもよい（may）。

アサーションは、アサーションの発行時刻を含む Issued At エンティティを含めてもよい（MAY）。

Authorization Server は、署名またはMACが無効なアサーションを拒否しなければならない（MUST）。署名または message authentication code を検証するために使用されるアルゴリズム、およびアサーションに対して署名または message authentication code を生成するために用いた秘密を指定するメカニズムは、本仕様の範囲外である。

6. Common Scenarios

以下は、Section 4 および Section 5 で定義した形式および処理規則に加えて、一般的なユースケースにおけるアサーション利用に関する追加ガイダンスを提供する。

6.1. Client Authentication

クライアントは、Section 4.2 で定義される "client_assertion_type" および "client_assertion" パラメータを用い、Authorization Server の token endpoint に対してアサーションを使用して認証する。アサーションの Subject がクライアントを識別する。アサーションがクライアントにより自己発行された場合、アサーションの Issuer もクライアントを識別する。

Section 4.2 の例は、Access Token 要求中にクライアントがアサーションを用いて認証することを示している。

6.2. Client Acting on Behalf of Itself

クライアントが自分自身を代表してリソースへアクセスする場合、OAuth 2.0 [RFC6749] の Section 4.4 で定義される Client Credentials Grant に類似した方法で行う。これは、認証と認可グラントの利用パターンの双方を組み合わせた特別なケースである。この場合、Authorization Server との相互作用は、Section 4.2 に従ってクライアント認証にアサーションを用いているものとして扱うべきであり（should）、同時に "grant_type" パラメータに値 "client_credentials" を用いて、クライアントが自身の client credentials のみを使用して Access Token を要求していることを示す。

Example request

次の例は、OAuth 2.0 [RFC6749] の Section 4.4.2 で定義される client credentials による Access Token 要求において、アサーションが使用されることを示す（表示の都合上のみ、余分な改行を含む）。

POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials&
client_assertion_type=urn%3Aietf%3Aparams%3Aoauth
%3Aclient-assertion-type%3Asaml2-bearer&
client_assertion=PHNhbW...[omitted for brevity]...ZT

6.3. Client Acting on Behalf of a User

クライアントがユーザーを代表してリソースへアクセスする場合、Section 4.1 で定義される "grant_type" および "assertion" パラメータを用いる。Subject は、Access Token が要求されている認可済みアクセス主体（通常は Resource Owner または認可された委任者）を識別する。

Section 4.1 の例は、クライアントがアサーションを認可グラントとして用いて Access Token を要求することを示している。

6.3.1. Client Acting on Behalf of an Anonymous User

クライアントが匿名ユーザーを代表してリソースへアクセスする場合、匿名であることを示す、相互に合意された Subject 識別子が使用される。Subject の値は、ユーザーの不透明な永続または一時の仮名識別子である場合もあれば、匿名ユーザーを示すために合意された固定値（例: "anonymous"）である場合もある。認可は、アサーション内で提供される追加属性や claims など、追加基準に基づく場合がある。例えば、クライアントは、bearer が18歳以上であることを含められた claim により主張する、信頼された Issuer からのアサーションを提示するかもしれない。この場合、ユーザーのアイデンティティに関する追加情報は含まれないが、Access Token を発行するために必要なデータはすべて存在する。

匿名性、仮名性、ならびに一般的なプライバシー考慮事項に関する詳細は [RFC6973] にある。

7. Interoperability Considerations

本仕様は、OAuth 2.0においてアサーションを用いるための枠組みを定義する。しかし、値の多くを表現するために使用されるデータ形式が定義されていない抽象的枠組みであるため、本仕様単独では相互運用可能な実装を生み出すには不十分である。

特定のアサーションに対してこの枠組みをプロファイル化した別の仕様が2つ策定されている。[RFC7522] は SAML 2.0 Assertions を、[RFC7523] は JSON Web Tokens (JWTs) を使用する。これら2つの具現化は、それらの種類のアサーションを OAuth 2.0 で使用するための、アサーションのエンコードおよび処理規則に関する追加詳細を規定する。

しかし、特定のアサーション種別に対してプロファイル化された場合であっても、相互運用可能なデプロイメントを実現するには、識別子、鍵、endpoint などに関してシステムエンティティ間の合意が必要である。合意を要する具体的項目は次のとおりである: Issuer および Audience 識別子の値、サポートするアサーションおよびクライアント認証の種別、token endpoint の位置、アサーションに対してデジタル署名またはMACを適用および検証するための鍵、アサーションのワンタイムユース制約、許容される最大アサーション寿命、ならびにアサーションにおける具体的な Subject および属性要件。こうした情報の交換は、明示的に本仕様の範囲外である。特定の信頼フレームワーク、サークル・オブ・トラスト、または他のユースケースのためのデプロイメントでは、本仕様で定義される抽象フィールドの一部について、参加者間で使用すべき値の種類に合意する必要がある。場合によっては、これらの値を制約または規定したり、それらを交換する方法を規定したりする追加プロファイルが作成され得る。"OAuth 2.0 Dynamic Client Registration Core Protocol" [OAUTH-DYN-REG] は、そのようなプロファイルの1つであり、OAuth Clients が自身に関するメタデータを Authorization Server に登録できるようにする。

8. Security Considerations

本節は、本書で述べた OAuth 2.0におけるアサーション利用に適用されるセキュリティ考慮事項を議論する。Section 3 で述べたとおり、アサーションを得る方法には2通りある。すなわち、自己発行か、第三者の token service から取得する方法である。アサーションを取得するための実際の相互作用は本仕様の範囲外であるが、詳細はセキュリティ観点から重要である。Section 3 は高レベルのアーキテクチャ観点を議論する。本節で議論されるセキュリティ考慮事項の多くは、OAuth の交換だけでなく、クライアントがアサーションを取得する側面にも適用される。

本節の残りは、クライアント認証および認可グラントのためにアサーションを提示することに関わる交換に焦点を当てる。

8.1. Forged Assertion

Threat

攻撃者が、Access Token を取得する（認可グラントの場合）またはクライアントになりすます（クライアント認証メカニズムの場合）ために、アサーションを偽造または改変する可能性がある。

Countermeasures

この種の攻撃を避けるため、エンティティは、アサーションの完全性を保護するための適切なメカニズムが採用されていることを保証しなければならない。これには、Issuer がアサーションにデジタル署名を行うこと、またはアサーションに対してMACを計算することが含まれる。

8.2. Stolen Assertion

Threat

攻撃者がアサーションを入手（例: 盗聴）し、その後、後の時点でそれを再利用（リプレイ）できる可能性がある。

Countermeasures

この脅威に対する主要な緩和策は、すべてのネットワーク交換においてサーバー認証付きの安全な通信チャネルを使用することである。

アサーションは、リプレイ攻撃を防ぐための複数の要素を含むこともできる。しかし、1つのアサーションを複数回の交換で再利用することと、新しく新鮮なアサーションを取得・作成することの間には、明確なトレードオフがある。

Authorization Server および Resource Server は、リプレイ防止のために Assertion ID と Issued At/Expires At 属性の組み合わせを使用できる。過去に処理されたアサーションは Assertion ID に基づいて拒否され得る。有効期間の窓を追加することで、Authorization Server が処理済み Assertion ID の無限の状態表を維持し続ける必要性が緩和される。

8.3. Unauthorized Disclosure of Personal Information

Threat

他のエンティティが、認証情報、組織内の役割、その他の認可関連情報といった個人に関する情報を取得できてしまうことは、プライバシー上の懸念を生じさせる。

Countermeasures

この脅威に対処するには、2つのケースを区別する必要がある。

交換に参加していない第三者がアサーション内容を盗聴できないように、TLSを用いて交換の機密性保護を行う。これにより、回線上の盗聴者が情報を入手できないことが保証される。しかし、これは、正当なプロトコルエンティティが、許可されていない情報をアサーションから取得してしまうことを防ぐものではない。アサーション形式の中には、アサーションを暗号化できるものがあり、権限のない主体が内容を閲覧できないようにできる。
Authorization Server は第三者の token service により作成されたアサーションを受け取ることがあり、その token service がアサーションに属性を格納している場合がある。潜在的なプライバシー問題を緩和するため、こうした属性情報の開示については、あらかじめ Resource Owner の同意を得るべきである（should）。OAuth 自体は、そのような機能を直接提供しないが、この同意承認は、他のアイデンティティ管理プロトコルやユーザー同意の相互作用を用いて得られ得る。あるいはアウトオブバンドで得られる場合もある。

第三者の token service がクライアント認証に使用されるアサーションを作成するケースでは、多くの場合、これらのクライアントは個人が操作する端末ではなくWebサーバーであるため、プライバシー上の懸念は一般に低い。しかし、アサーションが、エンドユーザーと強く結び付けられる可能性のある端末やソフトウェアのクライアント認証に使用される場合は、プライバシー保護の安全策を考慮する必要がある。

プライバシーに配慮したプロトコル設計に関する追加ガイダンスは [RFC6973] にある。

8.4. Privacy Considerations

アサーションはプライバシー上機微な情報を含み得るため、意図しない主体への情報開示を防ぐには、TLS などの暗号化されたチャネル上でのみ送信すべきである（should）。クライアントに対して特定情報の開示を防ぎたい場合には、アサーション（またはその一部）を Authorization Server 向けに暗号化すべきである（should）。

デプロイメントでは、交換を完了するのに必要な情報の最小量を判断し、その情報のみをアサーションに含めるべきである（should）。場合によっては、Section 6.3.1 で述べたとおり、Subject 識別子は匿名または仮名のユーザーを表す値にできる。

9. IANA Considerations

本節は、RFC 6749 [RFC6749] により確立されたIANA "OAuth Parameters" レジストリに、以下のサブセクションに列挙する3つの値を登録する。

9.1. "assertion" Parameter Registration

Name: assertion
Parameter Usage Location: token request
Change Controller: IESG
Specification Document(s): RFC 7521

9.2. "client_assertion" Parameter Registration

Name: client_assertion
Parameter Usage Location: token request
Change Controller: IESG
Specification Document(s): RFC 7521

9.3. "client_assertion_type" Parameter Registration

Name: client_assertion_type
Parameter Usage Location: token request
Change Controller: IESG
Specification Document(s): RFC 7521

10. References

10.1. Normative References

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <http://www.rfc-editor.org/info/rfc2119>.

[RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
           Resource Identifier (URI): Generic Syntax", STD 66,
           RFC 3986, DOI 10.17487/RFC3986, January 2005,
           <http://www.rfc-editor.org/info/rfc3986>.

[RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
           RFC 6749, DOI 10.17487/RFC6749, October 2012,
           <http://www.rfc-editor.org/info/rfc6749>.

10.2. Informative References

[OASIS.WS-Trust]
           Nadalin, A., Ed., Goodner, M., Ed., Gudgin, M., Ed.,
           Barbir, A., Ed., and H. Granqvist, Ed., "WS-Trust",
           February 2009, <http://docs.oasis-open.org/ws-sx/
           ws-trust/v1.4/ws-trust.html>.

[OAUTH-DYN-REG]
           Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and
           P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",
           Work in Progress, draft-ietf-oauth-dyn-reg-29, May 2015.

[RFC6755]  Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace
           for OAuth", RFC 6755, DOI 10.17487/RFC6755, October 2012,
           <http://www.rfc-editor.org/info/rfc6755>.

[RFC6973]  Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
           Morris, J., Hansen, M., and R. Smith, "Privacy
           Considerations for Internet Protocols", RFC 6973,
           DOI 10.17487/RFC6973, July 2013,
           <http://www.rfc-editor.org/info/rfc6973>.

[RFC7522]  Campbell, B., Mortimore, C., and M. Jones, "Security
           Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0
           Client Authentication and Authorization Grants", RFC 7522,
           DOI 10.17487/RFC7522, May 2015,
           <http://www.rfc-editor.org/info/rfc7522>.

[RFC7523]  Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token
           (JWT) Profile for OAuth 2.0 Client Authentication and
           Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May
           2015, <http://www.rfc-editor.org/info/rfc7523>.

Acknowledgements

著者らは、本仕様に影響を与え、または貢献した次の人々に感謝する: Paul Madsen、Eric Sachs、Jian Cai、Tony Nadalin、Hannes Tschofenig、OAuth WRAP 仕様の著者ら、ならびに OAuth working group のメンバー。

Authors' Addresses

Brian Campbell
Ping Identity

EMail: brian.d.campbell@gmail.com


Chuck Mortimore
Salesforce.com

EMail: cmortimore@salesforce.com


Michael B. Jones
Microsoft

EMail: mbj@microsoft.com
URI:   http://self-issued.info/


Yaron Y. Goland
Microsoft

EMail: yarong@microsoft.com

Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants

Abstract

Status of This Memo

Copyright Notice

Table of Contents

1. Introduction

2. Notational Conventions

3. Framework

Third-partyによるアサーション発行（Figure 1）

自己発行アサーション（Figure 2）

4. Transporting Assertions

4.1. Using Assertions as Authorization Grants

Parameters

Example request

4.1.1. Error Responses

Example response

4.2. Using Assertions for Client Authentication

Parameters

Example request

4.2.1. Error Responses

Example response

5. Assertion Content and Processing

5.1. Assertion Metamodel

Issuer

Subject

Audience

Issued At

Expires At

Assertion ID

5.2. General Assertion Format and Processing Rules

6. Common Scenarios

6.1. Client Authentication

6.2. Client Acting on Behalf of Itself

Example request

6.3. Client Acting on Behalf of a User

6.3.1. Client Acting on Behalf of an Anonymous User

7. Interoperability Considerations

8. Security Considerations

8.1. Forged Assertion

Threat

Countermeasures

8.2. Stolen Assertion

Threat

Countermeasures

8.3. Unauthorized Disclosure of Personal Information

Threat

Countermeasures

8.4. Privacy Considerations

9. IANA Considerations

9.1. "assertion" Parameter Registration

9.2. "client_assertion" Parameter Registration

9.3. "client_assertion_type" Parameter Registration

10. References

10.1. Normative References

10.2. Informative References

Acknowledgements

Authors' Addresses