RFC 7523 - JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7523
タイトル : RFC 7523 - OAuth 2.0クライアント認証および許可付与のためのJSON Web Token（JWT）プロファイル
翻訳編集 : 自動生成＆有志による翻訳・編集

[要約] RFC 7523は、OAuth 2.0クライアント認証および認可グラントにおけるJSON Web Token (JWT) プロファイルを定義しています。この文書の目的は、JWTを使用してOAuth 2.0のセキュリティトークンとして、またクライアント認証メカニズムとして利用する方法を標準化することです。このプロファイルは、セキュアなAPIアクセスを提供するWebアプリケーションやサービスで広く利用されています。関連するRFCには、JWTの構造を定義するRFC 7519、OAuth 2.0フレームワークを定義するRFC 6749などがあります。RFC 7523は、OAuth 2.0プロトコルのセキュリティを強化し、より柔軟な認証と認可のオプションを提供することを目的としています。

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

JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants

OAuth 2.0クライアント認証および許可付与のためのJSON Web Token（JWT）プロファイル

Abstract

概要

This specification defines the use of a JSON Web Token (JWT) Bearer Token as a means for requesting an OAuth 2.0 access token as well as for client authentication.

この仕様では、クライアント認証だけでなく、OAuth 2.0アクセストークンをリクエストする手段として、JSON Web Token（JWT）Bearer Tokenの使用を定義しています。

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/rfc7523.

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

著作権表示

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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Notational Conventions  . . . . . . . . . . . . . . . . .   4
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  HTTP Parameter Bindings for Transporting Assertions . . . . .   4
     2.1.  Using JWTs as Authorization Grants  . . . . . . . . . . .   4
     2.2.  Using JWTs for Client Authentication  . . . . . . . . . .   5
   3.  JWT Format and Processing Requirements  . . . . . . . . . . .   5
     3.1.  Authorization Grant Processing  . . . . . . . . . . . . .   7
     3.2.  Client Authentication Processing  . . . . . . . . . . . .   8
   4.  Authorization Grant Example . . . . . . . . . . . . . . . . .   8
   5.  Interoperability Considerations . . . . . . . . . . . . . . .   9
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   7.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  10
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
     8.1.  Sub-Namespace Registration of
           urn:ietf:params:oauth:grant-type:jwt-bearer . . . . . . .  10
     8.2.  Sub-Namespace Registration of
           urn:ietf:params:oauth:client-assertion-type:jwt-bearer  .  10
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1. Introduction

1. はじめに

JSON Web Token (JWT) [JWT] is a JSON-based [RFC7159] security token encoding that enables identity and security information to be shared across security domains. A security token is generally issued by an Identity Provider and consumed by a Relying Party that relies on its content to identify the token's subject for security-related purposes.

JSON Web Token（JWT）[JWT]は、IDとセキュリティ情報をセキュリティドメイン間で共有できるようにするJSONベースの[RFC7159]セキュリティトークンエンコーディングです。セキュリティトークンは通常、IDプロバイダーによって発行され、コンテンツに依存してセキュリティ関連の目的でトークンのサブジェクトを識別する依存パーティによって消費されます。

The OAuth 2.0 Authorization Framework [RFC6749] provides a method for making authenticated HTTP requests to a resource using an access token. Access tokens are issued to third-party clients by an authorization server (AS) with the (sometimes implicit) approval of the resource owner. In OAuth, an authorization grant is an abstract term used to describe intermediate credentials that represent the resource owner authorization. An authorization grant is used by the client to obtain an access token. Several authorization grant types are defined to support a wide range of client types and user experiences. OAuth also allows for the definition of new extension grant types to support additional clients or to provide a bridge between OAuth and other trust frameworks. Finally, OAuth allows the definition of additional authentication mechanisms to be used by clients when interacting with the authorization server.

OAuth 2.0 Authorization Framework [RFC6749]は、アクセストークンを使用してリソースへの認証済みHTTPリクエストを作成する方法を提供します。アクセストークンは、リソース所有者の（暗黙的な）承認を伴う承認サーバー（AS）によってサードパーティのクライアントに発行されます。 OAuthでは、許可付与は、リソース所有者の許可を表す中間資格情報を説明するために使用される抽象的な用語です。認可付与は、アクセストークンを取得するためにクライアントによって使用されます。さまざまなクライアントタイプとユーザーエクスペリエンスをサポートするために、いくつかの承認付与タイプが定義されています。 OAuthでは、追加のクライアントをサポートするため、またはOAuthと他の信頼フレームワーク間のブリッジを提供するために、新しい拡張付与タイプを定義することもできます。最後に、OAuthを使用すると、追加の認証メカニズムを定義して、承認サーバーとやり取りするときにクライアントが使用できます。

"Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants" [RFC7521] is an abstract extension to OAuth 2.0 that provides a general framework for the use of assertions (a.k.a. security tokens) as client credentials and/or authorization grants with OAuth 2.0. This specification profiles the OAuth Assertion Framework [RFC7521] to define an extension grant type that uses a JWT Bearer Token to request an OAuth 2.0 access token as well as for use as client credentials. The format and processing rules for the JWT defined in this specification are intentionally similar, though not identical, to those in the closely related specification "Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants" [RFC7522]. The differences arise where the structure and semantics of JWTs differ from SAML Assertions. JWTs, for example, have no direct equivalent to the <SubjectConfirmation> or <AuthnStatement> elements of SAML Assertions.

「OAuth 2.0クライアント認証および承認付与のためのアサーションフレームワーク」[RFC7521]は、OAuth 2.0に対する抽象拡張であり、OAuth 2.0を使用したクライアント資格情報または認可付与としてアサーション（別名、セキュリティトークン）を使用するための一般的なフレームワークを提供します。この仕様は、OAuthアサーションフレームワーク[RFC7521]のプロファイルを作成して、JWTベアラートークンを使用してOAuth 2.0アクセストークンを要求するだけでなく、クライアント資格情報として使用する拡張付与タイプを定義します。この仕様で定義されているJWTのフォーマットと処理ルールは、密接に関連している仕様「OAuth 2.0クライアント認証および承認付与のセキュリティアサーションマークアップ言語（SAML）2.0プロファイル」[RFC7522]のものと意図的に似ていますが、同一ではありません。 JWTの構造とセマンティクスがSAMLアサーションと異なる場合に違いが生じます。たとえば、JWTには、SAMLアサーションの<SubjectConfirmation>または<AuthnStatement>要素に直接相当するものはありません。

This document defines how a JWT Bearer Token can be used to request an access token when a client wishes to utilize an existing trust relationship, expressed through the semantics of the JWT, without a direct user-approval step at the authorization server. It also defines how a JWT can be used as a client authentication mechanism. The use of a security token for client authentication is orthogonal to and separable from using a security token as an authorization grant. They can be used either in combination or separately. Client authentication using a JWT 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. JWT authorization grants may be used with or without client authentication or identification. Whether or not client authentication is needed in conjunction with a JWT authorization grant, as well as the supported types of client authentication, are policy decisions at the discretion of the authorization server.

このドキュメントでは、クライアントが既存の信頼関係を利用したい場合に、JWTベアラートークンを使用してJWTのセマンティクスで表現された、認証サーバーでの直接的なユーザー承認ステップなしのアクセストークンの要求方法を定義します。また、JWTをクライアント認証メカニズムとして使用する方法も定義します。クライアント認証にセキュリティトークンを使用することは、セキュリティトークンを許可付与として使用することとは直交しており、分離できます。これらは組み合わせて、または別々に使用できます。 JWTを使用したクライアント認証は、クライアントがトークンエンドポイントに対して認証するための代替方法に過ぎず、完全で意味のあるプロトコル要求を形成するために、いくつかの許可タイプと組み合わせて使用する必要があります。 JWT許可付与は、クライアント認証または識別の有無にかかわらず使用できます。 JWT許可付与とともにクライアント認証が必要かどうか、およびサポートされているタイプのクライアント認証は、許可サーバーの裁量でのポリシー決定です。

The process by which the client obtains the JWT, prior to exchanging it with the authorization server or using it for client authentication, is out of scope.

許可サーバーと交換する前、またはクライアント認証に使用する前に、クライアントがJWTを取得するプロセスは範囲外です。

1.1. Notational Conventions

1.1. 表記規則

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 RFC 2119 [RFC2119].

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

Unless otherwise noted, all the protocol parameter names and values are case sensitive.

特に明記しない限り、すべてのプロトコルパラメータの名前と値は大文字と小文字が区別されます。

1.2. Terminology

1.2. 用語

All terms are as defined in the following specifications: "The OAuth 2.0 Authorization Framework" [RFC6749], the OAuth Assertion Framework [RFC7521], and "JSON Web Token (JWT)" [JWT].

「OAuth 2.0 Authorization Framework」[RFC6749]、OAuthアサーションフレームワーク[RFC7521]、および "JSON Web Token（JWT）" [JWT]で定義されている用語はすべて次のとおりです。

2. HTTP Parameter Bindings for Transporting Assertions

2. アサーションを転送するためのHTTPパラメータバインディング

The OAuth Assertion Framework [RFC7521] defines generic HTTP parameters for transporting assertions (a.k.a. security tokens) during interactions with a token endpoint. This section defines specific parameters and treatments of those parameters for use with JWT Bearer Tokens.

OAuthアサーションフレームワーク[RFC7521]は、トークンエンドポイントとの対話中にアサーション（別名、セキュリティトークン）を転送するための汎用HTTPパラメータを定義します。このセクションでは、JWTベアラートークンで使用する特定のパラメーターとそれらのパラメーターの処理を定義します。

2.1. Using JWTs as Authorization Grants

2.1. 許可付与としてのJWTの使用

To use a Bearer JWT as an authorization grant, the client uses an access token request as defined in Section 4 of the OAuth Assertion Framework [RFC7521] with the following specific parameter values and encodings.

Bearer JWTを許可付与として使用するには、クライアントは、OAuthアサーションフレームワーク[RFC7521]のセクション4で定義されているアクセストークンリクエストを使用して、次の特定のパラメーター値とエンコードを指定します。

The value of the "grant_type" is "urn:ietf:params:oauth:grant-type:jwt-bearer".

「grant_type」の値は「urn:ietf:params:oauth:grant-type:jwt-bearer」です。

The value of the "assertion" parameter MUST contain a single JWT.

「assertion」パラメーターの値には、単一のJWTが含まれている必要があります。

The "scope" parameter may be used, as defined in the OAuth Assertion Framework [RFC7521], to indicate the requested scope.

OAuthアサーションフレームワーク[RFC7521]で定義されている「スコープ」パラメーターを使用して、リクエストされたスコープを示すことができます。

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 access token request with a JWT as an authorization grant (with extra line breaks for display purposes only):

次の例は、許可付与としてJWTを使用したアクセストークンリクエストを示しています（表示目的でのみ改行が追加されています）。

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

     grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer
     &assertion=eyJhbGciOiJFUzI1NiIsImtpZCI6IjE2In0.
     eyJpc3Mi[...omitted for brevity...].
     J9l-ZhwP[...omitted for brevity...]

2.2. Using JWTs for Client Authentication

2.2. クライアント認証にJWTを使用する

To use a JWT Bearer Token for client authentication, the client uses the following parameter values and encodings.

クライアント認証にJWTベアラートークンを使用するには、クライアントは次のパラメーター値とエンコードを使用します。

The value of the "client_assertion_type" is "urn:ietf:params:oauth:client-assertion-type:jwt-bearer".

「client_assertion_type」の値は「urn:ietf:params:oauth:client-assertion-type:jwt-bearer」です。

The value of the "client_assertion" parameter contains a single JWT. It MUST NOT contain more than one JWT.

「client_assertion」パラメーターの値には、単一のJWTが含まれています。複数のJWTを含めることはできません。

The following example demonstrates client authentication using a JWT during the presentation of an authorization code grant in an access token request (with extra line breaks for display purposes only):

次の例は、アクセストークンリクエストでの承認コード付与の表示中にJWTを使用するクライアント認証を示しています（表示目的でのみ改行が追加されています）。

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

     grant_type=authorization_code&
     code=n0esc3NRze7LTCu7iYzS6a5acc3f0ogp4&
     client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3A
     client-assertion-type%3Ajwt-bearer&
     client_assertion=eyJhbGciOiJSUzI1NiIsImtpZCI6IjIyIn0.
     eyJpc3Mi[...omitted for brevity...].
     cC4hiUPo[...omitted for brevity...]

3. JWT Format and Processing Requirements

3. JWTフォーマットと処理要件

In order to issue an access token response as described in OAuth 2.0 [RFC6749] or to rely on a JWT for client authentication, the authorization server MUST validate the JWT according to the criteria below. Application of additional restrictions and policy are at the discretion of the authorization server.

OAuth 2.0 [RFC6749]で説明されているようにアクセストークン応答を発行するため、またはクライアント認証をJWTに依存するために、承認サーバーは以下の基準に従ってJWTを検証する必要があります。追加の制限およびポリシーの適用は、許可サーバーの裁量に委ねられています。

1. The JWT MUST contain an "iss" (issuer) claim that contains a unique identifier for the entity that issued the JWT. 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].

1. JWTには、JWTを発行したエンティティの一意の識別子を含む「iss」（発行者）クレームを含める必要があります。特に指定しないアプリケーションプロファイルがない場合、準拠するアプリケーションは、RFC 3986 [RFC3986]のセクション6.2.1で定義されているSimple String Comparisonメソッドを使用して発行者の値を比較する必要があります。

2. The JWT MUST contain a "sub" (subject) claim identifying the principal that is the subject of the JWT. Two cases need to be differentiated:

2. JWTには、JWTのサブジェクトであるプリンシパルを識別する「sub」（サブジェクト）クレームを含める必要があります。 2つのケースを区別する必要があります。

A. For the authorization grant, 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.

A.承認付与の場合、サブジェクトは通常、アクセストークンが要求されている承認済みのアクセサー（つまり、リソース所有者または承認済みの委任者）を識別しますが、場合によっては、匿名の識別子または匿名を示す他の値の場合もありますユーザー。

B. For client authentication, the subject MUST be the "client_id" of the OAuth client.

B.クライアント認証の場合、サブジェクトはOAuthクライアントの「client_id」である必要があります。

3. The JWT MUST contain an "aud" (audience) claim containing a value that identifies the authorization server as an intended audience. The token endpoint URL of the authorization server MAY be used as a value for an "aud" element to identify the authorization server as an intended audience of the JWT. The authorization server MUST reject any JWT that does not contain its own identity as the intended audience. 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]. As noted in Section 5, the precise strings to be used as the audience for a given authorization server must be configured out of band by the authorization server and the issuer of the JWT.

3. JWTには、承認サーバーを対象のオーディエンスとして識別する値を含む「aud」（audience）クレームを含める必要があります。許可サーバーのトークンエンドポイントURLを「aud」要素の値として使用して、許可サーバーをJWTの対象ユーザーとして識別することができます。許可サーバーは、対象となるオーディエンスとして自身のIDを含まないJWTを拒否する必要があります。特に指定しないアプリケーションプロファイルがない場合、準拠するアプリケーションは、RFC 3986 [RFC3986]のセクション6.2.1で定義されている単純な文字列比較メソッドを使用して、オーディエンス値を比較する必要があります。セクション5で説明したように、特定の承認サーバーの対象ユーザーとして使用される正確な文字列は、承認サーバーとJWTの発行者が帯域外で構成する必要があります。

4. The JWT MUST contain an "exp" (expiration time) claim that limits the time window during which the JWT can be used. The authorization server MUST reject any JWT with an expiration time that has passed, subject to allowable clock skew between systems. Note that the authorization server may reject JWTs with an "exp" claim value that is unreasonably far in the future.

4. JWTには、JWTを使用できる時間枠を制限する「exp」（有効期限）クレームを含める必要があります。許可サーバーは、システム間の許容クロックスキューに従って、有効期限が過ぎたJWTを拒否する必要があります。認可サーバーは、将来的に不当に遠い「exp」クレーム値を持つJWTを拒否する可能性があることに注意してください。

5. The JWT MAY contain an "nbf" (not before) claim that identifies the time before which the token MUST NOT be accepted for processing.

5. JWTには、トークンが処理のために受け入れられてはならない時間を識別する「nbf」（以前ではない）クレームが含まれる場合があります。

6. The JWT MAY contain an "iat" (issued at) claim that identifies the time at which the JWT was issued. Note that the authorization server may reject JWTs with an "iat" claim value that is unreasonably far in the past.

6. JWTには、JWTが発行された時刻を識別する「iat」（発行場所）クレームを含めることができます（MAY）。認可サーバーは、過去に不当に遠い「iat」クレーム値を持つJWTを拒否する場合があることに注意してください。

7. The JWT MAY contain a "jti" (JWT ID) claim that provides a unique identifier for the token. The authorization server MAY ensure that JWTs are not replayed by maintaining the set of used "jti" values for the length of time for which the JWT would be considered valid based on the applicable "exp" instant.

7. JWTには、トークンに一意の識別子を提供する「jti」（JWT ID）クレームを含めることができます（MAY）。許可サーバーは、該当する「exp」の瞬間に基づいてJWTが有効と見なされる時間の長さについて、使用される「jti」値のセットを維持することにより、JWTが再生されないようにすることができます。

8. The JWT MAY contain other claims.

8. JWTには他のクレームが含まれる場合があります。

9. The JWT MUST be digitally signed or have a Message Authentication Code (MAC) applied by the issuer. The authorization server MUST reject JWTs with an invalid signature or MAC.

9. JWTはデジタル署名されているか、発行者によって適用されたメッセージ認証コード（MAC）を持っている必要があります。承認サーバーは、無効な署名またはMACを持つJWTを拒否する必要があります。

10. The authorization server MUST reject a JWT that is not valid in all other respects per "JSON Web Token (JWT)" [JWT].

10. 認可サーバーは、「JSON Web Token（JWT）」[JWT]に従って他のすべての点で有効ではないJWTを拒否する必要があります。

3.1. Authorization Grant Processing

3.1. 認可付与処理

JWT authorization grants may be used with or without client authentication or identification. Whether or not client authentication is needed in conjunction with a JWT authorization grant, as well as the supported types of client authentication, are policy decisions at the discretion of the authorization server. However, if client credentials are present in the request, the authorization server MUST validate them.

JWT許可付与は、クライアント認証または識別の有無にかかわらず使用できます。 JWT許可付与とともにクライアント認証が必要かどうか、およびサポートされているタイプのクライアント認証は、許可サーバーの裁量でのポリシー決定です。ただし、クライアント資格情報がリクエストに存在する場合、承認サーバーはそれらを検証する必要があります。

If the JWT is not valid, or the current time is not within the token's valid time window for use, 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 JWT was considered invalid using the "error_description" or "error_uri" parameters.

JWTが有効でない場合、または現在の時刻がトークンの有効な有効期間内にない場合、認証サーバーはOAuth 2.0 [RFC6749]で定義されているエラー応答を作成します。「error」パラメータの値は、「invalid_grant」エラーコードである必要があります。許可サーバーは、「error_description」または「error_uri」パラメーターを使用して、JWTが無効と見なされた理由に関する追加情報を含めることができます（MAY）。

For example:

例えば：

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

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

3.2. Client Authentication Processing

3.2. クライアント認証処理

If the client JWT is not valid, 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 JWT was considered invalid using the "error_description" or "error_uri" parameters.

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

4. Authorization Grant Example

4. 認可付与の例

The following examples illustrate what a conforming JWT and an access token request would look like.

次の例は、準拠するJWTとアクセストークンリクエストがどのようになるかを示しています。

The example shows a JWT issued and signed by the system entity identified as "https://jwt-idp.example.com". The subject of the JWT is identified by email address as "mike@example.com". The intended audience of the JWT is "https://jwt-rp.example.net", which is an identifier with which the authorization server identifies itself. The JWT is sent as part of an access token request to the authorization server's token endpoint at "https://authz.example.net/ token.oauth2".

この例は、「https://jwt-idp.example.com」として識別されるシステムエンティティによって発行および署名されたJWTを示しています。 JWTの件名は、メールアドレスで「mike@example.com」として識別されます。 JWTの対象読者は「https://jwt-rp.example.net」です。これは、承認サーバーがそれ自体を識別するための識別子です。 JWTは、アクセストークンリクエストの一部として、「https://authz.example.net/token.oauth2」にある認証サーバーのトークンエンドポイントに送信されます。

Below is an example JSON object that could be encoded to produce the JWT Claims Set for a JWT:

以下は、JWTのJWTクレームセットを生成するためにエンコードできるJSONオブジェクトの例です。

     {"iss":"https://jwt-idp.example.com",
      "sub":"mailto:mike@example.com",
      "aud":"https://jwt-rp.example.net",
      "nbf":1300815780,
      "exp":1300819380,
      "http://claims.example.com/member":true}

The following example JSON object, used as the header of a JWT, declares that the JWT is signed with the Elliptic Curve Digital Signature Algorithm (ECDSA) P-256 SHA-256 using a key identified by the "kid" value "16".

次のJSONオブジェクトの例は、JWTのヘッダーとして使用され、「子供」の値「16」で識別される鍵を使用して、楕円曲線デジタル署名アルゴリズム（ECDSA）P-256 SHA-256でJWTが署名されることを宣言しています。

     {"alg":"ES256","kid":"16"}

To present the JWT with the claims and header shown in the previous example as part of an access token request, for example, the client might make the following HTTPS request (with extra line breaks for display purposes only):

たとえば、前の例で示したクレームとヘッダーをアクセストークンリクエストの一部としてJWTに表示するには、クライアントが次のHTTPSリクエストを行う場合があります（表示目的でのみ改行を追加します）。

     POST /token.oauth2 HTTP/1.1
     Host: authz.example.net
     Content-Type: application/x-www-form-urlencoded

     grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer
     &assertion=eyJhbGciOiJFUzI1NiIsImtpZCI6IjE2In0.
     eyJpc3Mi[...omitted for brevity...].
     J9l-ZhwP[...omitted for brevity...]

5. Interoperability Considerations

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

Agreement between system entities regarding identifiers, keys, and endpoints is required in order to achieve interoperable deployments of this profile. Specific items that require agreement are as follows: values for the issuer and audience identifiers, the location of the token endpoint, the key used to apply and verify the digital signature or MAC over the JWT, one-time use restrictions on the JWT, maximum JWT lifetime allowed, and the specific subject and claim requirements of the JWT. The exchange of such information is explicitly out of scope for this specification. In some cases, additional profiles may be created that constrain or prescribe these values or specify how they are to be exchanged. Examples of such profiles include the OAuth 2.0 Dynamic Client Registration Core Protocol [OAUTH-DYN-REG], OpenID Connect Dynamic Client Registration 1.0 [OpenID.Registration], and OpenID Connect Discovery 1.0 [OpenID.Discovery].

このプロファイルの相互運用可能な展開を実現するには、識別子、キー、およびエンドポイントに関するシステムエンティティ間の合意が必要です。同意が必要な具体的な項目は次のとおりです。発行者とオーディエンスの識別子の値、トークンエンドポイントの場所、JWTを介したデジタル署名またはMACの適用と検証に使用されるキー、JWTの1回限りの使用制限、最大JWTの有効期間、およびJWTの特定のサブジェクトとクレーム要件。このような情報の交換は、この仕様では明らかに範囲外です。場合によっては、これらの値を制約または規定する、またはそれらの交換方法を指定する追加のプロファイルが作成されることがあります。そのようなプロファイルの例には、OAuth 2.0動的クライアント登録コアプロトコル[OAUTH-DYN-REG]、OpenID Connect動的クライアント登録1.0 [OpenID.Registration]、およびOpenID Connect Discovery 1.0 [OpenID.Discovery]が含まれます。

The "RS256" algorithm, from [JWA], is a mandatory-to-implement JSON Web Signature algorithm for this profile.

[JWA]の「RS256」アルゴリズムは、このプロファイルの実装が必須のJSON Web署名アルゴリズムです。

6. Security Considerations

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

The security considerations described within the following specifications are all applicable to this document: "Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants" [RFC7521], "The OAuth 2.0 Authorization Framework" [RFC6749], and "JSON Web Token (JWT)" [JWT].

次の仕様で説明されているセキュリティの考慮事項は、すべてこのドキュメントに適用されます：「OAuth 2.0クライアント認証および承認付与のためのアサーションフレームワーク」[RFC7521]、「OAuth 2.0承認フレームワーク」[RFC6749]、および "JSON Webトークン（JWT）" [JWT]

The specification does not mandate replay protection for the JWT usage for either the authorization grant or for client authentication. It is an optional feature, which implementations may employ at their own discretion.

この仕様は、許可付与またはクライアント認証のいずれかのJWT使用に対する再生保護を義務付けていません。これはオプション機能であり、実装は独自の裁量で使用できます。

7. Privacy Considerations

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

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

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

Deployments should determine the minimum amount of information necessary to complete the exchange and include only such claims in the JWT. In some cases, the "sub" (subject) claim can be a value representing an anonymous or pseudonymous user, as described in Section 6.3.1 of the OAuth Assertion Framework [RFC7521].

デプロイメントでは、交換を完了するために必要な最小限の情報を決定し、そのようなクレームのみをJWTに含める必要があります。 OAuthアサーションフレームワーク[RFC7521]のセクション6.3.1で説明されているように、 "sub"（サブジェクト）クレームは匿名または偽名のユーザーを表す値である場合があります。

8. IANA Considerations

8. IANAに関する考慮事項

8.1. Sub-Namespace Registration of urn:ietf:params:oauth:grant-type:jwt-bearer

8.1. urn:ietf:params:oauth:grant-type:jwt-bearer のサブ名前空間の登録

This section registers the value "grant-type:jwt-bearer" in the IANA "OAuth URI" registry established by "An IETF URN Sub-Namespace for OAuth" [RFC6755].

このセクションでは、「grant-type:jwt-bearer」という値を、「OAuthのIETF URNサブ名前空間」[RFC6755]によって確立されたIANA「OAuth URI」レジストリに登録します。

o URN: urn:ietf:params:oauth:grant-type:jwt-bearer

o URN:urn:ietf:params:oauth:grant-type:jwt-bearer

o Common Name: JWT Bearer Token Grant Type Profile for OAuth 2.0

o 共通名：OAuth 2.0のJWTベアラートークン付与タイププロファイル

o Change Controller: IESG

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

o Specification Document: RFC 7523

o 仕様書：RFC 7523

8.2. Sub-Namespace Registration of urn:ietf:params:oauth:client-assertion-type:jwt-bearer

8.2. urn:ietf:params:oauth:client-assertion-type:jwt-bearer のサブ名前空間の登録

This section registers the value "client-assertion-type:jwt-bearer" in the IANA "OAuth URI" registry established by "An IETF URN Sub-Namespace for OAuth" [RFC6755].

このセクションは、「Anauth for UAuth Sub-Namespace for OAuth」[RFC6755]によって確立されたIANA「OAuth URI」レジストリに値「client-assertion-type：jwt-bearer」を登録します。

o URN: urn:ietf:params:oauth:client-assertion-type:jwt-bearer

o URN：urn：ietf：params：oauth：client-assertion-type：jwt-bearer

o Common Name: JWT Bearer Token Profile for OAuth 2.0 Client Authentication

o 一般名：OAuth 2.0クライアント認証用のJWTベアラートークンプロファイル

o Change Controller: IESG

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

o Specification Document: RFC 7523

o 仕様書：RFC 7523

9. References

9. 参考文献

9.1. Normative References

9.1. 引用文献

[JWA] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015, <http://www.rfc-editor.org/info/rfc7518>.

[JWA]ジョーンズ、M。、「JSON Web Algorithms（JWA）」、RFC 7518、DOI 10.17487 / RFC7518、2015年5月、<http://www.rfc-editor.org/info/rfc7518>。

[JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, <http://www.rfc-editor.org/info/rfc7519>.

[JWT]ジョーンズ、M。、ブラッドリー、J.、N。崎村、「JSON Web Token（JWT）」、RFC 7519、DOI 10.17487 / RFC7519、2015年5月、<http://www.rfc-editor.org / info / rfc7519>。

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

[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, <http://www.rfc-editor.org/info/rfc7159>.

[RFC7159]ブレイ、T。、編、「JavaScriptオブジェクト表記（JSON）データ交換フォーマット」、RFC 7159、DOI 10.17487 / RFC7159、2014年3月、<http://www.rfc-editor.org/info/ rfc7159>。

[RFC7521] Campbell, B., Mortimore, C., Jones, M., and Y. Goland, "Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants", RFC 7521, DOI 10.17487/RFC7521, May 2015, <http://www.rfc-editor.org/info/rfc7521>.

[RFC7521] Campbell、B.、Mortimore、C.、Jones、M。、およびY. Goland、「OAuth 2.0クライアント認証および許可付与のためのアサーションフレームワーク」、RFC 7521、DOI 10.17487 / RFC7521、2015年5月、<http： //www.rfc-editor.org/info/rfc7521>。

9.2. Informative References

9.2. 参考引用

[OAUTH-DYN-REG] Richer, J., 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.、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月。

[OpenID.Discovery] Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID Connect Discovery 1.0 incorporating errata set 1", November 2014, <http://openid.net/specs/ openid-connect-discovery-1_0.html>.

[OpenID.Discovery] Sakimura N.、Bradley、J.、Jones、M。、およびE. Jay、「OpenID Connect Discovery 1.0 errata set 1を組み込んだ」、2014年11月、<http://openid.net/specs/ openid-connect-discovery-1_0.html>。

[OpenID.Registration] Sakimura, N., Bradley, J., and M. Jones, "OpenID Connect Dynamic Client Registration 1.0 incorporating errata set 1", November 2014, <http://openid.net/specs/ openid-connect-registration-1_0.html>.

[OpenID.Registration] Sakimura、N.、Bradley、J。、およびM. Jones、「OpenID Connect Dynamic Client Registration 1.0組み込まれたエラッタセット1」、2014年11月、<http://openid.net/specs/ openid-connect -registration-1_0.html>。

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

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

Acknowledgements

謝辞

This profile was derived from "Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants" [RFC7522], which has the same authors as this document.

このプロファイルは、「OAuth 2.0クライアント認証および許可付与のためのセキュリティアサーションマークアップ言語（SAML）2.0プロファイル」[RFC7522]から派生したもので、このドキュメントと同じ作成者がいます。

Authors' Addresses

著者のアドレス

Michael B. Jones Microsoft

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

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

Brian Campbell Ping Identity

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

   EMail: brian.d.campbell@gmail.com

Chuck Mortimore Salesforce

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

   EMail: cmortimore@salesforce.com