RFC 7521 - Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7521
タイトル : RFC 7521 - OAuth 2.0クライアント認証および承認付与のためのアサーションフレームワーク
翻訳編集 : 自動生成

[要約] RFC 7521は、OAuth 2.0クライアント認証および認可グラントのためのアサーションフレームワークを定義しています。このフレームワークは、アサーション（主張）を使用してOAuth 2.0クライアント認証と認可グラントを行う方法を標準化します。主に、異なるセキュリティドメイン間での認証情報の交換に利用され、SAMLやJWTなどのアサーション形式をサポートします。関連するRFCには、RFC 7522（SAML 2.0プロファイル）、RFC 7523（JWTプロファイル）があり、これらはRFC 7521のフレームワーク内で特定のアサーション形式を使用する方法を詳述しています。

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

Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants

OAuth 2.0クライアント認証および承認付与のためのアサーションフレームワーク

Abstract

概要

This specification provides a framework for the use of assertions with OAuth 2.0 in the form of a new client authentication mechanism and a new authorization grant type. Mechanisms are specified for transporting assertions during interactions with a token endpoint; general processing rules are also specified.

この仕様は、OAuth 2.0でアサーションを使用するためのフレームワークを、新しいクライアント認証メカニズムと新しい許可付与タイプの形式で提供します。トークンエンドポイントとの対話中にアサーションを転送するためのメカニズムが指定されています。一般的な処理規則も指定されています。

The intent of this specification is to provide a common framework for OAuth 2.0 to interwork with other identity systems using assertions and to provide alternative client authentication mechanisms.

この仕様の目的は、OAuth 2.0がアサーションを使用して他のIDシステムと相互作用するための共通のフレームワークを提供し、代替のクライアント認証メカニズムを提供することです。

Note that this specification only defines abstract message flows and processing rules. In order to be implementable, companion specifications are necessary to provide the corresponding concrete instantiations.

この仕様では、抽象メッセージフローと処理ルールのみが定義されていることに注意してください。実装可能にするためには、対応する具体的なインスタンスを提供するコンパニオン仕様が必要です。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7521.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7521で入手できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1. Introduction ....................................................3
   2. Notational Conventions ..........................................4
   3. Framework .......................................................4
   4. Transporting Assertions .........................................7
      4.1. Using Assertions as Authorization Grants ...................7
           4.1.1. Error Responses .....................................8
      4.2. Using Assertions for Client Authentication .................9
           4.2.1. Error Responses ....................................10
   5. Assertion Content and Processing ...............................10
      5.1. Assertion Metamodel .......................................10
      5.2. General Assertion Format and Processing Rules .............12
   6. Common Scenarios ...............................................12
      6.1. Client Authentication .....................................13
      6.2. Client Acting on Behalf of Itself .........................13
      6.3. Client Acting on Behalf of a User .........................13
           6.3.1. Client Acting on Behalf of an Anonymous User .......14
   7. Interoperability Considerations ................................14
   8. Security Considerations ........................................15
      8.1. Forged Assertion ..........................................15
      8.2. Stolen Assertion ..........................................15
      8.3. Unauthorized Disclosure of Personal Information ...........16
      8.4. Privacy Considerations ....................................17
   9. IANA Considerations ............................................17
      9.1. "assertion" Parameter Registration ........................17
      9.2. "client_assertion" Parameter Registration .................18
      9.3. "client_assertion_type" Parameter Registration ............18
   10. References ....................................................18
      10.1. Normative References .....................................18
      10.2. Informative References ...................................18
   Acknowledgements ..................................................20
   Authors' Addresses ................................................20

1. Introduction

1. はじめに

An assertion is a package of information that facilitates the sharing of identity and security information across security domains. Section 3 provides a more detailed description of the concept of an assertion for the purpose of this specification.

アサーションは、セキュリティドメイン間でのIDおよびセキュリティ情報の共有を容易にする情報のパッケージです。セクション3は、この仕様の目的のためのアサーションの概念のより詳細な説明を提供します。

OAuth 2.0 [RFC6749] is an authorization framework that enables a third-party application to obtain limited access to a protected HTTP resource. In OAuth, those third-party applications are called clients; they access protected resources by presenting an access token to the HTTP resource. Access tokens are issued to clients by an authorization server with the (sometimes implicit) approval of the resource owner. These access tokens are typically obtained by exchanging an authorization grant, which represents the authorization granted by the resource owner (or by a privileged administrator). Several authorization grant types are defined to support a wide range of client types and user experiences. OAuth also provides an extensibility mechanism for defining additional grant types, which can serve as a bridge between OAuth and other protocol frameworks.

OAuth 2.0 [RFC6749]は、サードパーティアプリケーションが保護されたHTTPリソースへの制限付きアクセスを取得できるようにする認証フレームワークです。 OAuthでは、これらのサードパーティアプリケーションはクライアントと呼ばれます。 HTTPリソースにアクセストークンを提示することにより、保護されたリソースにアクセスします。アクセストークンは、リソース所有者の（暗黙的な）承認を伴う承認サーバーによってクライアントに発行されます。これらのアクセストークンは、通常、リソース所有者（または特権管理者）によって付与された承認を表す承認付与を交換することによって取得されます。さまざまなクライアントタイプとユーザーエクスペリエンスをサポートするために、いくつかの承認付与タイプが定義されています。 OAuthは、追加の許可タイプを定義するための拡張メカニズムも提供します。これは、OAuthと他のプロトコルフレームワーク間のブリッジとして機能します。

This specification provides a general framework for the use of assertions as authorization grants with OAuth 2.0. It also provides a framework for assertions to be used for client authentication. It provides generic mechanisms for transporting assertions during interactions with an authorization server's token endpoint as well as general rules for the content and processing of those assertions. The intent is to provide an alternative client authentication mechanism (one that doesn't send client secrets) and to facilitate the use of OAuth 2.0 in client-server integration scenarios, where the end user may not be present.

この仕様は、OAuth 2.0での許可付与としてアサーションを使用するための一般的なフレームワークを提供します。また、クライアント認証に使用されるアサーションのフレームワークも提供します。これは、許可サーバーのトークンエンドポイントとの対話中にアサーションを転送するための一般的なメカニズムと、それらのアサーションのコンテンツと処理に関する一般的なルールを提供します。その目的は、代替クライアント認証メカニズム（クライアントシークレットを送信しないメカニズム）を提供し、エンドユーザーが存在しない可能性があるクライアント/サーバー統合シナリオでOAuth 2.0の使用を容易にすることです。

This specification only defines abstract message flows and processing rules. In order to be implementable, companion specifications are necessary to provide the corresponding concrete instantiations. For instance, "Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants" [RFC7522] defines a concrete instantiation for Security Assertion Markup Language (SAML) 2.0 Assertions and "JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants" [RFC7523] defines a concrete instantiation for JWTs.

この仕様では、抽象メッセージフローと処理ルールのみが定義されています。実装可能にするためには、対応する具体的なインスタンスを提供するコンパニオン仕様が必要です。たとえば、「OAuth 2.0クライアント認証および許可付与用のセキュリティアサーションマークアップ言語（SAML）2.0プロファイル」[RFC7522]は、OAuthのセキュリティアサーションマークアップ言語（SAML）2.0アサーションおよび「JSON Webトークン（JWT）プロファイルの具体的なインスタンス化を定義します。 2.0クライアント認証および許可付与」[RFC7523]は、JWTの具体的なインスタンス化を定義しています。

Note: The use of assertions for client authentication is orthogonal to and separable from using assertions as an authorization grant. They can be used either in combination or separately. Client assertion authentication is nothing more than an alternative way for a client to authenticate to the token endpoint and must be used in conjunction with some grant type to form a complete and meaningful protocol request. Assertion authorization grants may be used with or without client authentication or identification. Whether or not client authentication is needed in conjunction with an assertion authorization grant, as well as the supported types of client authentication, are policy decisions at the discretion of the authorization server.

注：クライアント認証でのアサーションの使用は、アサーションを許可付与として使用することと直交しており、分離できます。これらは組み合わせて、または別々に使用できます。クライアントアサーション認証は、クライアントがトークンエンドポイントに対して認証するための代替方法にすぎず、完全で意味のあるプロトコル要求を形成するために、いくつかの許可タイプと組み合わせて使用する必要があります。アサーション許可付与は、クライアント認証または識別の有無にかかわらず使用できます。アサーション許可の付与とともにクライアント認証が必要かどうか、およびサポートされているクライアント認証のタイプは、許可サーバーの裁量によるポリシー決定です。

2. Notational Conventions

2. 表記規則

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。

Throughout this document, values are quoted to indicate that they are to be taken literally. When using these values in protocol messages, the quotes must not be used as part of the value.

このドキュメント全体で、値は引用されており、文字どおりに解釈されることを示しています。プロトコルメッセージでこれらの値を使用する場合、引用符を値の一部として使用しないでください。

3. Framework

3. フレームワーク

An assertion is a package of information that allows identity and security information to be shared across security domains. An assertion typically contains information about a subject or principal, information about the party that issued the assertion and when was it issued, and the conditions under which the assertion is to be considered valid, such as when and where it can be used.

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

The entity that creates and signs or integrity-protects the assertion is typically known as the "Issuer", and the entity that consumes the assertion and relies on its information is typically known as the "Relying Party". In the context of this document, the authorization server acts as a relying party.

アサーションを作成して署名または整合性を保護するエンティティは通常「発行者」と呼ばれ、アサーションを消費してその情報に依存するエンティティは通常「依存パーティ」と呼ばれます。このドキュメントのコンテキストでは、認可サーバーは証明書利用者として機能します。

Assertions used in the protocol exchanges defined by this specification MUST always be integrity protected using a digital signature or Message Authentication Code (MAC) applied by the issuer, which authenticates the issuer and ensures integrity of the assertion content. In many cases, the assertion is issued by a third party, and it must be protected against tampering by the client that presents it. An assertion MAY additionally be encrypted, preventing unauthorized parties (such as the client) from inspecting the content.

この仕様で定義されているプロトコル交換で使用されるアサーションは、発行者によって適用されるデジタル署名またはメッセージ認証コード（MAC）を使用して、常に整合性を保護する必要があります。MACは、発行者を認証し、アサーションコンテンツの整合性を保証します。多くの場合、アサーションはサードパーティによって発行され、それを提示するクライアントによる改ざんから保護する必要があります。アサーションはさらに暗号化されてもよい（MAY）。これにより、権限のない当事者（クライアントなど）がコンテンツを検査することを防止できます。

Although this document does not define the processes by which the client obtains the assertion (prior to sending it to the authorization server), there are two common patterns described below.

このドキュメントでは、クライアントが（承認サーバーに送信する前に）アサーションを取得するプロセスを定義していませんが、以下の2つの一般的なパターンがあります。

In the first pattern, depicted in Figure 1, the client obtains an assertion from a third-party entity capable of issuing, renewing, transforming, and validating security tokens. Typically, such an entity is known as a "security token service" (STS) or just "token service", and a trust relationship (usually manifested in the exchange of some kind of key material) exists between the token service and the relying party. The token service is the assertion issuer; its role is to fulfill requests from clients, which present various credentials, and mint assertions as requested, fill them with appropriate information, and integrity-protect them with a signature or message authentication code. WS-Trust [OASIS.WS-Trust] is one available standard for requesting security tokens (assertions).

図1に示す最初のパターンでは、クライアントは、セキュリティトークンの発行、更新、変換、および検証が可能なサードパーティエンティティからアサーションを取得します。通常、このようなエンティティは "セキュリティトークンサービス"（STS）または単に "トークンサービス"と呼ばれ、信頼関係（通常、ある種のキーマテリアルの交換で明示されます）がトークンサービスと証明書利用者の間に存在します。。トークンサービスはアサーション発行者です。その役割は、さまざまな資格情報を提示するクライアントからの要求を満たし、要求に応じてアサーションを作成し、適切な情報をクライアントに入力し、署名またはメッセージ認証コードで完全性を保護することです。 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

図1：サードパーティによって作成されたアサーション

In the second pattern, depicted in Figure 2, the client creates assertions locally. To apply the signatures or message authentication codes to assertions, it has to obtain key material: either symmetric keys or asymmetric key pairs. The mechanisms for obtaining this key material are beyond the scope of this specification.

図2に示す2番目のパターンでは、クライアントはアサーションをローカルに作成します。署名またはメッセージ認証コードをアサーションに適用するには、対称鍵または非対称鍵ペアのいずれかの鍵素材を取得する必要があります。このキーマテリアルを取得するメカニズムは、この仕様の範囲を超えています。

Although assertions are usually used to convey identity and security information, self-issued assertions can also serve a different purpose. They can be used to demonstrate knowledge of some secret, such as a client secret, without actually communicating the secret directly in the transaction. In that case, additional information included in the assertion by the client itself will be of limited value to the relying party, and for this reason, only a bare minimum of information is typically included in such an assertion, such as information about issuing and usage conditions.

アサーションは通常、IDおよびセキュリティ情報を伝えるために使用されますが、自己発行のアサーションは別の目的にも役立ちます。それらは、実際にトランザクションで直接シークレットを通信することなく、クライアントシークレットなどのシークレットの知識を示すために使用できます。その場合、クライアント自体によるアサーションに含まれる追加情報は、証明書利用者にとっては限られた価値しかありません。このため、発行や使用に関する情報など、通常、そのようなアサーションには最小限の情報のみが含まれます条件。

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

Figure 2: Self-Issued Assertion

図2：自己発行のアサーション

Deployments need to determine the appropriate variant to use based on the required level of security, the trust relationship between the entities, and other factors.

デプロイメントでは、必要なセキュリティレベル、エンティティ間の信頼関係、およびその他の要因に基づいて、使用する適切なバリアントを決定する必要があります。

From the perspective of what must be done by the entity presenting the assertion, there are two general types of assertions:

アサーションを提示するエンティティが何をしなければならないかという観点から、アサーションには2つの一般的なタイプがあります。

1. Bearer Assertions: Any entity in possession of a bearer assertion (the bearer) can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer assertions need to be protected from disclosure in storage and in transport. Secure communication channels are required between all entities to avoid leaking the assertion to unauthorized parties.

1. ベアラーアサーション：ベアラーアサーション（ベアラー）を所持しているエンティティは、それを使用して、関連するリソースにアクセスできます（暗号化キーの所持を示すことなく）。誤用を防ぐために、無記名の主張は保管および輸送中の開示から保護する必要があります。無許可の関係者へのアサーションの漏洩を回避するために、すべてのエンティティ間で安全な通信チャネルが必要です。

2. Holder-of-Key Assertions: To access the associated resources, the entity presenting the assertion must demonstrate possession of additional cryptographic material. The token service thereby binds a key identifier to the assertion, and the client has to demonstrate to the relying party that it knows the key corresponding to that identifier when presenting the assertion.

2. Key-of-Keyアサーション：関連するリソースにアクセスするには、アサーションを提示するエンティティが追加の暗号化マテリアルの所有を示す必要があります。これにより、トークンサービスはキー識別子をアサーションにバインドし、クライアントはアサーションを提示するときに、その識別子に対応するキーを知っていることを証明書利用者に示す必要があります。

The protocol parameters and processing rules defined in this document are intended to support a client presenting a bearer assertion to an authorization server. They are not directly suitable for use with holder-of-key assertions. While they could be used as a baseline for a holder-of-key assertion system, there would be a need for additional mechanisms (to support proof-of-possession of the secret key), and possibly changes to the security model (e.g., to relax the requirement for an Audience).

このドキュメントで定義されているプロトコルパラメータと処理ルールは、ベアラアサーションを許可サーバーに提示するクライアントをサポートすることを目的としています。これらは、holder-of-keyアサーションでの使用には直接適していません。それらはキーホルダー保持アサーションシステムのベースラインとして使用できますが、追加のメカニズム（秘密キーの所有証明をサポートするため）が必要であり、セキュリティモデル（たとえば、オーディエンスの要件を緩和します）。

4. Transporting Assertions

4. アサーションの転送

This section defines HTTP parameters for transporting assertions during interactions with a token endpoint of an OAuth authorization server. Because requests to the token endpoint result in the transmission of clear-text credentials (in both the HTTP request and response), all requests to the token endpoint MUST use Transport Layer Security (TLS), as mandated in Section 3.2 of OAuth 2.0 [RFC6749].

このセクションでは、OAuth承認サーバーのトークンエンドポイントとの対話中にアサーションを転送するためのHTTPパラメーターを定義します。トークンエンドポイントへのリクエストは（HTTPリクエストとレスポンスの両方で）クリアテキストの認証情報を送信するため、トークンのエンドポイントへのすべてのリクエストは、OAuth 2.0のセクション3.2 [RFC6749 ]。

4.1. Using Assertions as Authorization Grants

4.1. 認可付与としてのアサーションの使用

This section defines the use of assertions as authorization grants, based on the definition provided in Section 4.5 of OAuth 2.0 [RFC6749]. When using assertions as authorization grants, the client includes the assertion and related information using the following HTTP request parameters:

このセクションでは、OAuth 2.0 [RFC6749]のセクション4.5で提供されている定義に基づいて、許可付与としてのアサーションの使用を定義します。アサーションを許可付与として使用する場合、クライアントは、以下のHTTPリクエストパラメータを使用してアサーションと関連情報を含めます。

grant_type REQUIRED. The format of the assertion as defined by the authorization server. The value will be an absolute URI.

grant_typeは必須です。許可サーバーによって定義されたアサーションのフォーマット。値は絶対URIになります。

assertion REQUIRED. The assertion being used as an authorization grant. Specific serialization of the assertion is defined by profile documents.

アサーションが必要です。許可付与として使用されるアサーション。アサーションの特定のシリアル化は、プロファイルドキュメントによって定義されます。

scope OPTIONAL. The requested scope as described in Section 3.3 of OAuth 2.0 [RFC6749]. When exchanging assertions for access tokens, the authorization for the token has been previously granted through some out-of-band mechanism. As such, the requested scope MUST be equal to or less than the scope originally granted to the authorized accessor. The authorization server MUST limit the scope of the issued access token to be equal to or less than the scope originally granted to the authorized accessor.

スコープオプション。 OAuth 2.0 [RFC6749]のセクション3.3で説明されているリクエストされたスコープ。アクセストークンのアサーションを交換するとき、トークンの承認は、以前にいくつかのアウトオブバンドメカニズムを通じて付与されていました。そのため、要求されたスコープは、最初に許可されたアクセサーに付与されたスコープ以下でなければなりません。承認サーバーは、発行されたアクセストークンのスコープを、承認されたアクセサーに最初に付与されたスコープ以下に制限する必要があります。

Authentication of the client is optional, as described in Section 3.2.1 of OAuth 2.0 [RFC6749], and consequently, the "client_id" is only needed when a form of client authentication that relies on the parameter is used.

OAuth 2.0 [RFC6749]のセクション3.2.1で説明されているように、クライアントの認証はオプションです。そのため、「client_id」は、パラメータに依存するクライアント認証の形式が使用される場合にのみ必要です。

The following example demonstrates an assertion being used as an authorization grant (with extra line breaks for display purposes only):

以下の例は、許可付与として使用されるアサーションを示しています（表示目的でのみ追加の改行を使用）。

     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

grant_type = urn％3Aietf％3Aparams％3Aoauth％3Agrant-type％3Asaml2-bearer＆assertion = PHNhbWxwOl ... [簡潔にするために省略] ... ZT4

An assertion used in this context is generally a short-lived representation of the authorization grant, and authorization servers SHOULD NOT issue access tokens with a lifetime that exceeds the validity period of the assertion by a significant period. In practice, that will usually mean that refresh tokens are not issued in response to assertion grant requests, and access tokens will be issued with a reasonably short lifetime. Clients can refresh an expired access token by requesting a new one using the same assertion, if it is still valid, or with a new assertion.

このコンテキストで使用されるアサーションは通常、許可付与の有効期間が短い表現であり、許可サーバーは、アサーションの有効期間を大幅に超える存続期間を持つアクセストークンを発行してはなりません（SHOULD NOT）。実際には、これは通常、アサーション許可要求に応答してリフレッシュトークンが発行されず、アクセストークンがかなり短い有効期間で発行されることを意味します。クライアントは、有効な場合は同じアサーションを使用して新しいトークンを要求するか、新しいアサーションを使用して、期限切れのアクセストークンを更新できます。

An IETF URN for use as the "grant_type" value can be requested using the template in [RFC6755]. A URN of the form urn:ietf:params:oauth:grant-type:* is suggested.

「grant_type」値として使用するIETF URNは、[RFC6755]のテンプレートを使用して要求できます。 urn：ietf：params：oauth：grant-type：*という形式のURNが推奨されます。

4.1.1. Error Responses

4.1.1. エラー応答

If an assertion is not valid or has expired, the authorization server constructs an error response as defined in OAuth 2.0 [RFC6749]. The value of the "error" parameter MUST be the "invalid_grant" error code. The authorization server MAY include additional information regarding the reasons the assertion was considered invalid using the "error_description" or "error_uri" parameters.

アサーションが無効または期限切れの場合、承認サーバーはOAuth 2.0 [RFC6749]で定義されているエラー応答を作成します。「error」パラメータの値は、「invalid_grant」エラーコードである必要があります。許可サーバーは、「error_description」または「error_uri」パラメーターを使用して、アサーションが無効と見なされた理由に関する追加情報を含めることができます。

For example:

例えば：

     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

4.2. クライアント認証のためのアサーションの使用

The following section defines the use of assertions as client credentials as an extension of Section 2.3 of OAuth 2.0 [RFC6749]. When using assertions as client credentials, the client includes the assertion and related information using the following HTTP request parameters:

次のセクションでは、OAuth 2.0 [RFC6749]のセクション2.3の拡張として、クライアント認証情報としてのアサーションの使用を定義します。アサーションをクライアント資格情報として使用する場合、クライアントには、以下のHTTPリクエストパラメータを使用してアサーションと関連情報が含まれます。

client_assertion_type REQUIRED. The format of the assertion as defined by the authorization server. The value will be an absolute URI.

client_assertion_typeが必要です。許可サーバーによって定義されたアサーションのフォーマット。値は絶対URIになります。

client_assertion REQUIRED. The assertion being used to authenticate the client. Specific serialization of the assertion is defined by profile documents.

client_assertionが必要です。クライアントの認証に使用されるアサーション。アサーションの特定のシリアル化は、プロファイルドキュメントによって定義されます。

client_id OPTIONAL. The client identifier as described in Section 2.2 of OAuth 2.0 [RFC6749]. The "client_id" is unnecessary for client assertion authentication because the client is identified by the subject of the assertion. If present, the value of the "client_id" parameter MUST identify the same client as is identified by the client assertion.

client_idオプション。 OAuth 2.0 [RFC6749]のセクション2.2で説明されているクライアント識別子。「client_id」は、クライアントがアサーションのサブジェクトによって識別されるため、クライアントアサーション認証には不要です。存在する場合、「client_id」パラメータの値は、クライアントアサーションによって識別されるのと同じクライアントを識別しなければなりません（MUST）。

The following example demonstrates a client authenticating using an assertion during an access token request, as defined in Section 4.1.3 of OAuth 2.0 [RFC6749] (with extra line breaks for display purposes only):

次の例は、OAuth 2.0 [RFC6749]のセクション4.1.3で定義されている、アクセストークンリクエスト中にアサーションを使用してクライアントを認証する方法を示しています（表示目的でのみ改行が追加されています）。

     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

grant_type = authorization_code＆code = n0esc3NRze7LTCu7iYzS6a5acc3f0ogp4＆client_assertion_type = urn％3Aietf％3Aparams％3Aoauth％3Aclient-assertion-type％3Asaml2-bearer＆client_assertion = PHNhbTity ... Zmitted for ...

Token endpoints can differentiate between assertion-based credentials and other client credential types by looking for the presence of the "client_assertion" and "client_assertion_type" parameters, which will only be present when using assertions for client authentication.

トークンエンドポイントは、「client_assertion」および「client_assertion_type」パラメータの存在を探すことにより、アサーションベースの認証情報と他のクライアント認証情報タイプを区別できます。これらのパラメータは、クライアント認証にアサーションを使用する場合にのみ存在します。

An IETF URN for use as the "client_assertion_type" value may be requested using the template in [RFC6755]. A URN of the form urn:ietf:params:oauth:client-assertion-type:* is suggested.

「client_assertion_type」の値として使用するIETF URNは、[RFC6755]のテンプレートを使用してリクエストできます。 urn：ietf：params：oauth：client-assertion-type：*という形式のURNが推奨されます。

4.2.1. Error Responses

4.2.1. エラー応答

If an assertion is invalid for any reason or if more than one client authentication mechanism is used, the authorization server constructs an error response as defined in OAuth 2.0 [RFC6749]. The value of the "error" parameter MUST be the "invalid_client" error code. The authorization server MAY include additional information regarding the reasons the client assertion was considered invalid using the "error_description" or "error_uri" parameters.

何らかの理由でアサーションが無効である場合、または複数のクライアント認証メカニズムが使用されている場合、承認サーバーはOAuth 2.0 [RFC6749]で定義されているエラー応答を作成します。「error」パラメータの値は、「invalid_client」エラーコードである必要があります。許可サーバーは、「error_description」または「error_uri」パラメーターを使用して、クライアントのアサーションが無効と見なされた理由に関する追加情報を含めることができます。

For example:

例えば：

     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

5. アサーションのコンテンツと処理

This section provides a general content and processing model for the use of assertions in OAuth 2.0 [RFC6749].

このセクションでは、OAuth 2.0 [RFC6749]でアサーションを使用するための一般的なコンテンツと処理モデルについて説明します。

5.1. Assertion Metamodel

5.1. アサーションメタモデル

The following are entities and metadata involved in the issuance, exchange, and processing of assertions in OAuth 2.0. These are general terms, abstract from any particular assertion format. Mappings of these terms into specific representations are provided by profiles of this specification.

以下は、OAuth 2.0でのアサーションの発行、交換、および処理に関連するエンティティとメタデータです。これらは一般的な用語であり、特定のアサーション形式からの抜粋です。これらの用語の特定の表現へのマッピングは、この仕様のプロファイルによって提供されます。

Issuer A unique identifier for the entity that issued the assertion. Generally, this is the entity that holds the key material used to sign or integrity-protect the assertion. Examples of issuers are OAuth clients (when assertions are self-issued) and third-party security token services. If the assertion is self-issued, the Issuer value is the client identifier. If the assertion was issued by a security token service (STS), the Issuer should identify the STS in a manner recognized by the authorization server. In the absence of an application profile specifying otherwise, compliant applications MUST compare Issuer values using the Simple String Comparison method defined in Section 6.2.1 of RFC 3986 [RFC3986].

発行者アサーションを発行したエンティティの一意の識別子。通常、これは、アサーションの署名または整合性保護に使用される主要な資料を保持するエンティティです。発行者の例は、OAuthクライアント（アサーションが自己発行の場合）やサードパーティのセキュリティトークンサービスです。アサーションが自己発行の場合、発行者の値はクライアント識別子です。アサーションがセキュリティトークンサービス（STS）によって発行された場合、発行者は、承認サーバーによって認識される方法でSTSを識別する必要があります。特に指定しないアプリケーションプロファイルがない場合、準拠するアプリケーションは、RFC 3986 [RFC3986]のセクション6.2.1で定義されているSimple String Comparisonメソッドを使用して発行者の値を比較する必要があります。

Subject A unique identifier for the principal that is the subject of the assertion.

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

* When using assertions for client authentication, the Subject identifies the client to the authorization server using the value of the "client_id" of the OAuth client.

* クライアント認証にアサーションを使用する場合、サブジェクトはOAuthクライアントの「client_id」の値を使用して、認可サーバーに対してクライアントを識別します。

* When using assertions as an authorization grant, the Subject identifies an authorized accessor for which the access token is being requested (typically, the resource owner or an authorized delegate).

* アサーションを承認付与として使用する場合、サブジェクトは、アクセストークンが要求されている承認済みアクセサー（通常、リソース所有者または承認済み委任）を識別します。

Audience A value that identifies the party or parties intended to process the assertion. The URL of the token endpoint, as defined in Section 3.2 of OAuth 2.0 [RFC6749], can be used to indicate that the authorization server is a valid intended audience of the assertion. In the absence of an application profile specifying otherwise, compliant applications MUST compare the Audience values using the Simple String Comparison method defined in Section 6.2.1 of RFC 3986 [RFC3986].

オーディエンスアサーションを処理することを目的とした当事者を識別する値。 OAuth 2.0 [RFC6749]のセクション3.2で定義されているトークンエンドポイントのURLを使用して、認証サーバーがアサーションの有効な対象オーディエンスであることを示すことができます。特に指定しないアプリケーションプロファイルがない場合、準拠するアプリケーションは、RFC 3986 [RFC3986]のセクション6.2.1で定義されている単純な文字列比較メソッドを使用して、オーディエンス値を比較する必要があります。

Issued At The time at which the assertion was issued. While the serialization may differ by assertion format, it is REQUIRED that the time be expressed in UTC with no time zone component.

発行時刻アサーションが発行された時刻。シリアライゼーションはアサーションフォーマットによって異なる場合がありますが、タイムゾーンコンポーネントのないUTCで時刻を表す必要があります。

Expires At The time at which the assertion expires. While the serialization may differ by assertion format, it is REQUIRED that the time be expressed in UTC with no time zone component.

期限切れアサーションが期限切れになる時刻。シリアライゼーションはアサーションフォーマットによって異なる場合がありますが、タイムゾーンコンポーネントのないUTCで時刻を表す必要があります。

Assertion ID A nonce or unique identifier for the assertion. The Assertion ID may be used by implementations requiring message de-duplication for one-time use assertions. Any entity that assigns an identifier MUST ensure that there is negligible probability for that entity or any other entity to accidentally assign the same identifier to a different data object.

アサーションIDアサーションのナンスまたは一意の識別子。アサーションIDは、1回限りのアサーションでメッセージの重複排除を必要とする実装で使用できます。識別子を割り当てるエンティティは、そのエンティティまたは他のエンティティが誤って同じ識別子を異なるデータオブジェクトに割り当てる可能性が無視できる程度であることを確認する必要があります。

5.2. General Assertion Format and Processing Rules

5.2. 一般的なアサーション形式と処理ルール

The following are general format and processing rules for the use of assertions in OAuth:

OAuthでアサーションを使用するための一般的な形式と処理規則は次のとおりです。

o The assertion MUST contain an Issuer. The Issuer identifies the entity that issued the assertion as recognized by the authorization server. If an assertion is self-issued, the Issuer MUST be the value of the client's "client_id".

o アサーションには発行者を含める必要があります。発行者は、アサーションを発行したエンティティを、認可サーバーによって認識されたものとして識別します。アサーションが自己発行の場合、発行者はクライアントの「client_id」の値でなければなりません。

o The assertion MUST contain a Subject. The Subject typically identifies an authorized accessor for which the access token is being requested (i.e., the resource owner or an authorized delegate) but, in some cases, may be a pseudonymous identifier or other value denoting an anonymous user. When the client is acting on behalf of itself, the Subject MUST be the value of the client's "client_id".

o アサーションにはサブジェクトが含まれている必要があります。サブジェクトは通常、アクセストークンが要求されている承認済みアクセサー（つまり、リソース所有者または承認済み委任者）を識別しますが、場合によっては、匿名ユーザーまたは匿名ユーザーを示す他の値の場合もあります。クライアントが自身の代わりに動作している場合、サブジェクトはクライアントの「client_id」の値である必要があります。

o The assertion MUST contain an Audience that identifies the authorization server as the intended audience. The authorization server MUST reject any assertion that does not contain its own identity as the intended audience.

o アサーションには、認可サーバーを対象のオーディエンスとして識別するオーディエンスが含まれている必要があります。承認サーバーは、対象となる対象者としての独自のIDを含まないアサーションを拒否する必要があります。

o The assertion MUST contain an Expires At entity that limits the time window during which the assertion can be used. The authorization server MUST reject assertions that have expired (subject to allowable clock skew between systems). Note that the authorization server may reject assertions with an Expires At attribute value that is unreasonably far in the future.

o アサーションには、アサーションを使用できる時間枠を制限するExpires Atエンティティが含まれている必要があります。承認サーバーは、有効期限が切れたアサーションを拒否する必要があります（システム間の許容クロックスキューが条件です）。認可サーバーは、将来的に不当に遠いExpires At属性値を持つアサーションを拒否する可能性があることに注意してください。

o The assertion MAY contain an Issued At entity containing the UTC time at which the assertion was issued.

o アサーションには、アサーションが発行されたUTC時間を含むIssued Atエンティティが含まれる場合があります。

o The authorization server MUST reject assertions with an invalid signature or MAC. The algorithm used to validate the signature or message authentication code and the mechanism for designating the secret used to generate the signature or message authentication code over the assertion are beyond the scope of this specification.

o 承認サーバーは、無効な署名またはMACのアサーションを拒否する必要があります。署名またはメッセージ認証コードを検証するために使用されるアルゴリズムと、アサーションに対して署名またはメッセージ認証コードを生成するために使用される秘密を指定するためのメカニズムは、この仕様の範囲を超えています。

6. Common Scenarios

6. 一般的なシナリオ

The following provides additional guidance, beyond the format and processing rules defined in Sections 4 and 5, on assertion use for a number of common use cases.

以下では、セクション4と5で定義されている形式と処理ルールの他に、多くの一般的なユースケースでのアサーションの使用に関する追加のガイダンスを示します。

6.1. Client Authentication

6.1. クライアント認証

A client uses an assertion to authenticate to the authorization server's token endpoint by using the "client_assertion_type" and "client_assertion" parameters as defined in Section 4.2. The Subject of the assertion identifies the client. If the assertion is self-issued by the client, the Issuer of the assertion also identifies the client.

クライアントは、セクション4.2で定義されている「client_assertion_type」および「client_assertion」パラメーターを使用して、アサーションを使用して許可サーバーのトークンエンドポイントに対して認証します。アサーションのサブジェクトはクライアントを識別します。アサーションがクライアントによって自己発行された場合、アサーションの発行者もクライアントを識別します。

The example in Section 4.2 shows a client authenticating using an assertion during an access token request.

セクション4.2の例は、アクセストークン要求中にアサーションを使用して認証するクライアントを示しています。

6.2. Client Acting on Behalf of Itself

6.2. 自分に代わって行動するクライアント

When a client is accessing resources on behalf of itself, it does so in a manner analogous to the Client Credentials Grant defined in Section 4.4 of OAuth 2.0 [RFC6749]. This is a special case that combines both the authentication and authorization grant usage patterns. In this case, the interactions with the authorization server should be treated as using an assertion for Client Authentication according to Section 4.2, while using the "grant_type" parameter with the value "client_credentials" to indicate that the client is requesting an access token using only its client credentials.

クライアントが自身に代わってリソースにアクセスする場合、OAuth 2.0 [RFC6749]のセクション4.4で定義されているクライアント資格情報付与に類似した方法でアクセスします。これは、認証と許可付与の使用パターンを組み合わせた特別なケースです。この場合、認可サーバーとの対話は、セクション4.2に従ってクライアント認証のアサーションを使用するものとして扱う必要があります。一方、値が「client_credentials」の「grant_type」パラメータを使用して、クライアントがのみを使用してアクセストークンをリクエストしていることを示します。そのクライアント資格情報。

The following example demonstrates an assertion being used for a client credentials access token request, as defined in Section 4.4.2 of OAuth 2.0 [RFC6749] (with extra line breaks for display purposes only):

次の例は、OAuth 2.0 [RFC6749]のセクション4.4.2で定義されているように、クライアント資格情報アクセストークンリクエストに使用されるアサーションを示しています（表示目的でのみ改行が追加されています）。

     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

grant_type = client_credentials＆client_assertion_type = urn％3Aietf％3Aparams％3Aoauth％3Aclient-assertion-type％3Asaml2-bearer＆client_assertion = PHNhbW ... [省略のため省略...] ... ZT

6.3. Client Acting on Behalf of a User

6.3. ユーザーに代わって行動するクライアント

When a client is accessing resources on behalf of a user, it does so by using the "grant_type" and "assertion" parameters as defined in Section 4.1. The Subject identifies an authorized accessor for which the access token is being requested (typically, the resource owner or an authorized delegate).

クライアントがユーザーに代わってリソースにアクセスする場合、セクション4.1で定義されている「grant_type」および「assertion」パラメーターを使用してアクセスします。サブジェクトは、アクセストークンが要求されている承認済みアクセサー（通常、リソース所有者または承認済み委任）を識別します。

The example in Section 4.1 shows a client making an access token request using an assertion as an authorization grant.

セクション4.1の例は、アサーションを許可付与として使用してアクセストークンリクエストを行うクライアントを示しています。

6.3.1. Client Acting on Behalf of an Anonymous User

6.3.1. 匿名ユーザーに代わって動作するクライアント

When a client is accessing resources on behalf of an anonymous user, a mutually agreed-upon Subject identifier indicating anonymity is used. The Subject value might be an opaque persistent or transient pseudonymous identifier for the user or be an agreed-upon static value indicating an anonymous user (e.g., "anonymous"). The authorization may be based upon additional criteria, such as additional attributes or claims provided in the assertion. For example, a client might present an assertion from a trusted issuer asserting that the bearer is over 18 via an included claim. In this case, no additional information about the user's identity is included, yet all the data needed to issue an access token is present.

クライアントが匿名ユーザーに代わってリソースにアクセスする場合、匿名性を示す相互に合意したサブジェクト識別子が使用されます。 Subject値は、ユーザーの不透明な永続的または一時的な仮名IDか、匿名ユーザーを示す合意済みの静的な値（例： "anonymous"）の場合があります。認可は、アサーションで提供される追加の属性またはクレームなどの追加の基準に基づく場合があります。たとえば、クライアントは、含まれるクレームを介して、ベアラが18歳以上であることをアサートする信頼できる発行者からのアサーションを提示する場合があります。この場合、ユーザーのIDに関する追加情報は含まれていませんが、アクセストークンの発行に必要なすべてのデータは存在しています。

More information about anonymity, pseudonymity, and privacy considerations in general can be found in [RFC6973].

匿名性、偽名性、およびプライバシーに関する一般的な考慮事項の詳細については、[RFC6973]を参照してください。

7. Interoperability Considerations

7. 相互運用性に関する考慮事項

This specification defines a framework for using assertions with OAuth 2.0. However, as an abstract framework in which the data formats used for representing many values are not defined, on its own, this specification is not sufficient to produce interoperable implementations.

この仕様は、OAuth 2.0でアサーションを使用するためのフレームワークを定義しています。ただし、多くの値を表すために使用されるデータ形式が定義されていない抽象的なフレームワークとして、この仕様だけでは相互運用可能な実装を生成するには不十分です。

Two other specifications that profile this framework for specific assertions have been developed: [RFC7522] uses SAML 2.0 Assertions and [RFC7523] uses JSON Web Tokens (JWTs). These two instantiations of this framework specify additional details about the assertion encoding and processing rules for using those kinds of assertions with OAuth 2.0.

特定のアサーションに対してこのフレームワークをプロファイルする他の2つの仕様が開発されました。[RFC7522]はSAML 2.0アサーションを使用し、[RFC7523]はJSON Web Token（JWT）を使用します。このフレームワークのこれら2つのインスタンス化は、OAuth 2.0でこれらの種類のアサーションを使用するためのアサーションエンコーディングと処理ルールに関する追加の詳細を指定します。

However, even when profiled for specific assertion types, agreements between system entities regarding identifiers, keys, and endpoints are required in order to achieve interoperable deployments. Specific items that require agreement are as follows: values for the Issuer and Audience identifiers, supported assertion and client authentication types, the location of the token endpoint, the key used to apply and verify the digital signature or MAC over the assertion, one-time use restrictions on assertions, maximum assertion lifetime allowed, and the specific Subject and attribute requirements of the assertion. The exchange of such information is explicitly out of the scope of this specification. Deployments for particular trust frameworks, circles of trust, or other uses cases will need to agree among the participants on the kinds of values to be used for some abstract fields defined by this specification. In some cases, additional profiles may be created that constrain or prescribe these values or specify how they are to be exchanged. The "OAuth 2.0 Dynamic Client Registration Core Protocol" [OAUTH-DYN-REG] is one such profile that enables OAuth Clients to register metadata about themselves at an authorization server.

ただし、特定のアサーションタイプのプロファイルを作成した場合でも、相互運用可能な展開を実現するには、識別子、キー、およびエンドポイントに関するシステムエンティティ間の合意が必要です。同意が必要な具体的な項目は次のとおりです。発行者とオーディエンスの識別子の値、サポートされているアサーションとクライアント認証の種類、トークンエンドポイントの場所、アサーションに対するデジタル署名またはMACの適用と検証に使用されるキー、1回アサーションの制限、許可されるアサーションの最大存続期間、およびアサーションの特定のサブジェクトと属性の要件を使用します。このような情報の交換は、明示的にこの仕様の範囲外です。特定の信頼フレームワーク、信頼の輪、またはその他のユースケースのデプロイメントでは、この仕様で定義されているいくつかの抽象フィールドに使用される値の種類について、参加者間で合意する必要があります。場合によっては、これらの値を制約または規定する、またはそれらの交換方法を指定する追加のプロファイルが作成されることがあります。「OAuth 2.0動的クライアント登録コアプロトコル」[OAUTH-DYN-REG]は、OAuthクライアントが認証サーバーで自身に関するメタデータを登録できるようにするプロファイルの1つです。

8. Security Considerations

8. セキュリティに関する考慮事項

This section discusses security considerations that apply when using assertions with OAuth 2.0 as described in this document. As discussed in Section 3, there are two different ways to obtain assertions: either as self-issued or obtained from a third-party token service. While the actual interactions for obtaining an assertion are outside the scope of this document, the details are important from a security perspective. Section 3 discusses the high-level architectural aspects. Many of the security considerations discussed in this section are applicable to both the OAuth exchange as well as the client obtaining the assertion.

このセクションでは、このドキュメントで説明されているOAuth 2.0でアサーションを使用するときに適用されるセキュリティの考慮事項について説明します。セクション3で説明したように、アサーションを取得するには2つの異なる方法があります。自己発行またはサードパーティのトークンサービスから取得します。アサーションを取得するための実際の対話はこのドキュメントの範囲外ですが、詳細はセキュリティの観点から重要です。セクション3では、アーキテクチャの概要について説明します。このセクションで説明するセキュリティの考慮事項の多くは、OAuth交換とアサーションを取得するクライアントの両方に適用できます。

The remainder of this section focuses on the exchanges that concern presenting an assertion for client authentication and for the authorization grant.

このセクションの残りの部分では、クライアント認証および許可付与のアサーションの提示に関係する交換に焦点を合わせます。

8.1. Forged Assertion

8.1. 偽造されたアサーション

Threat: An adversary could forge or alter an assertion in order to obtain an access token (in the case of the authorization grant) or to impersonate a client (in the case of the client authentication mechanism).

脅威：攻撃者は、アサーションを偽造または変更して、アクセストークンを取得する（承認付与の場合）、またはクライアントを偽装する（クライアント認証メカニズムの場合）可能性があります。

Countermeasures: To avoid this kind of attack, the entities must assure that proper mechanisms for protecting the integrity of the assertion are employed. This includes the issuer digitally signing the assertion or computing a MAC over the assertion.

対応策：この種の攻撃を回避するには、エンティティはアサーションの整合性を保護するための適切なメカニズムが採用されていることを確認する必要があります。これには、発行者がアサーションにデジタル署名したり、アサーションに対してMACを計算したりすることが含まれます。

8.2. Stolen Assertion

8.2. 盗まれた主張

Threat: An adversary may be able obtain an assertion (e.g., by eavesdropping) and then reuse it (replay it) at a later point in time.

脅威：攻撃者はアサーションを（たとえば、盗聴によって）取得し、後でそれを再利用（リプレイ）できる可能性があります。

Countermeasures: The primary mitigation for this threat is the use of secure communication channels with server authentication for all network exchanges.

対応策：この脅威の主な緩和策は、すべてのネットワーク交換でサーバー認証を使用した安全な通信チャネルの使用です。

An assertion may also contain several elements to prevent replay attacks. There is, however, a clear trade-off between reusing an assertion for multiple exchanges and obtaining and creating new, fresh assertions.

アサーションには、リプレイ攻撃を防ぐためのいくつかの要素が含まれる場合もあります。ただし、複数の交換でアサーションを再利用することと、新しい新鮮なアサーションを取得および作成することの間には、明確なトレードオフがあります。

Authorization servers and resource servers may use a combination of the Assertion ID and Issued At/Expires At attributes for replay protection. Previously processed assertions may be rejected based on the Assertion ID. The addition of the validity window relieves the authorization server from maintaining an infinite state table of processed Assertion IDs.

承認サーバーとリソースサーバーは、アサーションIDと発行時/期限切れ時の属性の組み合わせを使用して、再生保護を行うことができます。以前に処理されたアサーションは、アサーションIDに基づいて拒否される場合があります。有効期間ウィンドウの追加により、承認サーバーは処理されたアサーションIDの無限状態テーブルを維持する必要がなくなります。

8.3. Unauthorized Disclosure of Personal Information

8.3. 個人情報の不正開示

Threat: The ability for other entities to obtain information about an individual, such as authentication information, role in an organization, or other authorization-relevant information, raises privacy concerns.

脅威：他のエンティティが認証情報、組織での役割、または他の承認関連情報などの個人に関する情報を取得する機能は、プライバシーの懸念を引き起こします。

Countermeasures: To address this threat, two cases need to be differentiated:

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

First, a third party that did not participate in any of the exchange is prevented from eavesdropping on the content of the assertion by employing confidentiality protection of the exchange using TLS. This ensures that an eavesdropper on the wire is unable to obtain information. However, this does not prevent legitimate protocol entities from obtaining information that they are not allowed to possess from assertions. Some assertion formats allow for the assertion to be encrypted, preventing unauthorized parties from inspecting the content.

まず、いずれの交換にも参加しなかった第三者は、TLSを使用して交換の機密保護を採用することにより、アサーションの内容を盗聴することが防止されます。これにより、ネットワーク上の盗聴者が情報を取得できないことが保証されます。ただし、これは、正当なプロトコルエンティティがアサーションから所有を許可されていない情報を取得することを妨げるものではありません。一部のアサーションフォーマットでは、アサーションを暗号化して、権限のない者がコンテンツを検査できないようにすることができます。

Second, an authorization server may obtain an assertion that was created by a third-party token service and that token service may have placed attributes into the assertion. To mitigate potential privacy problems, prior consent for the release of such attribute information from the resource owner should be obtained. OAuth itself does not directly provide such capabilities, but this consent approval may be obtained using other identity management protocols or user consent interactions; it may also be obtained in an out-of-band fashion.

次に、承認サーバーがサードパーティのトークンサービスによって作成されたアサーションを取得し、そのトークンサービスがアサーションに属性を配置した可能性があります。潜在的なプライバシー問題を軽減するために、リソース所有者からのそのような属性情報のリリースについて事前の同意を得る必要があります。 OAuth自体はそのような機能を直接提供しませんが、この同意の承認は、他のID管理プロトコルまたはユーザーの同意の相互作用を使用して取得できます。帯域外で取得することもできます。

For the cases where a third-party token service creates assertions to be used for client authentication, privacy concerns are typically lower, since many of these clients are Web servers rather than individual devices operated by humans. If the assertions are used for client authentication of devices or software that can be closely linked to end users, then privacy protection safeguards need to be taken into consideration.

サードパーティのトークンサービスがクライアント認証に使用されるアサーションを作成する場合、これらのクライアントの多くは人間が操作する個々のデバイスではなくWebサーバーであるため、プライバシーの懸念は通常低くなります。アサーションがエンドユーザーに密接にリンクできるデバイスまたはソフトウェアのクライアント認証に使用される場合、プライバシー保護のセーフガードを考慮する必要があります。

Further guidance on privacy friendly protocol design can be found in [RFC6973].

プライバシーに配慮したプロトコル設計の詳細なガイダンスは、[RFC6973]にあります。

8.4. Privacy Considerations

8.4. プライバシーに関する考慮事項

An assertion may contain privacy-sensitive information and, to prevent disclosure of such information to unintended parties, should only be transmitted over encrypted channels, such as TLS. In cases where it is desirable to prevent disclosure of certain information to the client, the assertion (or portions of it) should be encrypted to the authorization server.

アサーションにはプライバシーに敏感な情報が含まれている可能性があり、意図しない関係者へのそのような情報の開示を防ぐために、TLSなどの暗号化されたチャネルでのみ送信する必要があります。特定の情報がクライアントに開示されないようにすることが望ましい場合は、アサーション（またはその一部）を認証サーバーに暗号化する必要があります。

Deployments should determine the minimum amount of information necessary to complete the exchange and include only such information in the assertion. In some cases, the Subject identifier can be a value representing an anonymous or pseudonymous user, as described in Section 6.3.1.

デプロイメントでは、交換を完了するために必要な最小限の情報を決定し、そのような情報のみをアサーションに含める必要があります。場合によっては、サブジェクト識別子は、セクション6.3.1で説明されているように、匿名または偽名のユーザーを表す値になることがあります。

9. IANA Considerations

9. IANAに関する考慮事項

This section registers three values, as listed in the subsections below, in the IANA "OAuth Parameters" registry established by RFC 6749 [RFC6749].

このセクションは、RFC 6749 [RFC6749]によって確立されたIANA "OAuth Parameters"レジストリに、以下のサブセクションにリストされている3つの値を登録します。

9.1. "assertion" Parameter Registration

9.1. 「アサーション」パラメーターの登録

o Name: assertion

o 名前：アサーション

o Parameter Usage Location: token request

o パラメータ使用場所：トークン要求

o Change Controller: IESG

o コントローラーの変更：IESG

o Specification Document(s): RFC 7521

o 仕様書：RFC 7521

9.2. "client_assertion" Parameter Registration

9.2. 「client_assertion」パラメータの登録

o Name: client_assertion

o 名前：client_assertion

o Parameter Usage Location: token request

o パラメータ使用場所：トークン要求

o Change Controller: IESG

o コントローラーの変更：IESG

o Specification Document(s): RFC 7521

o 仕様書：RFC 7521

9.3. "client_assertion_type" Parameter Registration

9.3. 「client_assertion_type」パラメータの登録

o Name: client_assertion_type

o 名前：client_assertion_type

o Parameter Usage Location: token request

o パラメータ使用場所：トークン要求

o Change Controller: IESG

o コントローラーの変更：IESG

o Specification Document(s): RFC 7521

o 仕様書：RFC 7521

10. References

10. 参考文献

10.1. Normative References

10.1. 引用文献

[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>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<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>.

[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、DOI 10.17487 / RFC3986、2005年1月、<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>.

[RFC6749] Hardt、D。、編、「The OAuth 2.0 Authorization Framework」、RFC 6749、DOI 10.17487 / RFC6749、2012年10月、<http://www.rfc-editor.org/info/rfc6749>。

10.2. Informative References

10.2. 参考引用

[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>.

[OASIS.WS-Trust] Nadalin、A.、Ed。、Goodner、M.、Ed。、Gudgin、M.、Ed。、Barbir、A.、Ed。、and H. Granqvist、Ed。、 "WS- Trust」、2009年2月、<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.

[OAUTH-DYN-REG] Richer、J.、Ed。、Jones、M.、Bradley、J.、Machulak、M。、およびP. Hunt、「OAuth 2.0 Dynamic Client Registration Protocol」、Work in Progress、draft- ietf-oauth-dyn-reg-29、2015年5月。

[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>.

[RFC6755] Campbell、B.およびH. Tschofenig、「An OTF URN Sub-Namespace for OAuth」、RFC 6755、DOI 10.17487 / RFC6755、2012年10月、<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>.

[RFC6973] Cooper、A.、Tschofenig、H.、Aboba、B.、Peterson、J.、Morris、J.、Hansen、M。、およびR. Smith、「インターネットプロトコルのプライバシーに関する考慮事項」、RFC 6973、DOI 10.17487 / RFC6973、2013年7月、<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>.

[RFC7522] Campbell、B.、Mortimore、C。、およびM. Jones、「セキュリティアサーションマークアップ言語（SAML）2.0プロファイルのOAuth 2.0クライアント認証および許可付与」、RFC 7522、DOI 10.17487 / RFC7522、2015年5月、< 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>.

[RFC7523]ジョーンズ、M。、キャンベル、B。、およびC.モーティモア、「OAuth 2.0クライアント認証および許可付与のためのJSON Webトークン（JWT）プロファイル」、RFC 7523、DOI 10.17487 / RFC7523、2015年5月、<http： //www.rfc-editor.org/info/rfc7523>。

Acknowledgements

謝辞

The authors wish to thank the following people who have influenced or contributed to this specification: Paul Madsen, Eric Sachs, Jian Cai, Tony Nadalin, Hannes Tschofenig, the authors of the OAuth WRAP specification, and the members of the OAuth working group.

著者は、この仕様に影響を与えたか貢献してくれた以下の人々に感謝します。PaulMadsen、Eric Sachs、Jian Cai、Tony Nadalin、Hannes Tschofenig、OAuth WRAP仕様の作成者、およびOAuthワーキンググループのメンバー。

Authors' Addresses

著者のアドレス

Brian Campbell Ping Identity

ブライアンキャンベルピンアイデンティティ

   EMail: brian.d.campbell@gmail.com

Chuck Mortimore Salesforce.com

チャック・モーティモアSalesforce.com

   EMail: cmortimore@salesforce.com

Michael B. Jones Microsoft

マイケルB.ジョーンズマイクロソフト

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

Yaron Y. Goland Microsoft

ヤロン・Y・ゴランドマイクロソフト

   EMail: yarong@microsoft.com