Identity Deep Dive

RFC 7523 · side by side

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

Official text at the RFC EditorSpec page

The English text is the RFC as published by the RFC Editor, copyright the IETF Trust and the persons identified as the document authors, reproduced under the IETF Trust Legal Provisions. The Japanese is an unofficial machine translation; only the English is authoritative. Examples, figures and references are shown in English only.

100% of paragraphs translated · Machine translation by Claude Fable 5.1 · 2026-11-13

Contents
  1. Abstract
  2. 1 Introduction
  3. 1.1 Notational Conventions
  4. 1.2 Terminology
  5. 2 HTTP Parameter Bindings for Transporting Assertions
  6. 2.1 Using JWTs as Authorization Grants
  7. 2.2 Using JWTs for Client Authentication
  8. 3 JWT Format and Processing Requirements
  9. 3.1 Authorization Grant Processing
  10. 3.2 Client Authentication Processing
  11. 4 Authorization Grant Example
  12. 5 Interoperability Considerations
  13. 6 Security Considerations
  14. 7 Privacy Considerations
  15. 8 IANA Considerations
  16. 8.1 Sub-Namespace Registration of urn:ietf:params:oauth:grant-type:jwt-bearer
  17. 8.2 Sub-Namespace Registration of urn:ietf:params:oauth:client-assertion-type:jwt-bearer
  18. 9 References
  19. 9.1 Normative References
  20. 9.2 Informative References
  21. Acknowledgements

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 を使用する方法を定義する。

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] は、JSON [RFC7159] に基づくセキュリティトークンのエンコーディングであり、アイデンティティおよびセキュリティ情報をセキュリティドメインをまたいで共有できるようにするものである。セキュリティトークンは一般に Identity Provider によって発行され、Relying Party によって消費される。Relying Party は、セキュリティ関連の目的でトークンのサブジェクトを識別するために、その内容に依拠する。

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 認可フレームワーク [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.

「Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants」[RFC7521] は OAuth 2.0 の抽象的な拡張であり、アサーション (別名セキュリティトークン) を OAuth 2.0 のクライアントクレデンシャルおよび/または認可グラントとして使用するための一般的なフレームワークを提供する。本仕様は OAuth Assertion Framework [RFC7521] をプロファイルし、JWT Bearer Token を用いて OAuth 2.0 アクセストークンを要求する拡張グラント種別を定義するとともに、それをクライアントクレデンシャルとして使用する方法を定義する。本仕様で定義する JWT のフォーマットおよび処理規則は、密接に関連する仕様「Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants」[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 Bearer Token をどのように使用できるかを定義する。また、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].

すべての用語は、次の仕様で定義されたとおりである: 「The OAuth 2.0 Authorization Framework」[RFC6749]、OAuth Assertion Framework [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 Assertion Framework [RFC7521] は、トークンエンドポイントとのやり取りにおいてアサーション (別名セキュリティトークン) を転送するための汎用的な HTTP パラメータを定義している。本節では、JWT Bearer Token で使用するための具体的なパラメータと、それらのパラメータの扱いを定義する。

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 Assertion Framework [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 を含まなければならない (MUST)。

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

"scope" パラメータは、OAuth Assertion Framework [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 Bearer Token をクライアント認証に使用するには、クライアントは次のパラメータ値とエンコーディングを使用する。

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 を含んではならない (MUST NOT)。

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 を検証しなければならない (MUST)。追加の制約やポリシーの適用は、認可サーバーの裁量による。

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" (issuer) クレームを含まなければならない (MUST)。別途規定するアプリケーションプロファイルがない限り、準拠するアプリケーションは RFC 3986 [RFC3986] の 6.2.1 節で定義された単純文字列比較 (Simple String Comparison) 方式を用いて発行者の値を比較しなければならない (MUST)。

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" (subject) クレームを含まなければならない (MUST)。次の 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" でなければならない (MUST)。

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) クレームを含まなければならない (MUST)。認可サーバーを JWT の意図した受信者として識別するために、認可サーバーのトークンエンドポイント URL を "aud" 要素の値として使用してもよい (MAY)。認可サーバーは、自身のアイデンティティを意図した受信者として含まない JWT をすべて拒否しなければならない (MUST)。別途規定するアプリケーションプロファイルがない限り、準拠するアプリケーションは RFC 3986 [RFC3986] の 6.2.1 節で定義された単純文字列比較 (Simple String Comparison) 方式を用いて受信者の値を比較しなければならない (MUST)。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" (expiration time) クレームを含まなければならない (MUST)。認可サーバーは、システム間で許容されるクロックのずれを考慮したうえで、有効期限が過ぎている JWT をすべて拒否しなければならない (MUST)。認可サーバーは、"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 は、その時刻より前にはトークンを処理のために受け入れてはならない (MUST NOT) 時刻を識別する "nbf" (not before) クレームを含んでもよい (MAY)。

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" (issued at) クレームを含んでもよい (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 が再利用されないことを保証してもよい (MAY)。

8. The JWT MAY contain other claims.

8. JWT は他のクレームを含んでもよい (MAY)。

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) が適用されていなければならない (MUST)。認可サーバーは、署名または MAC が無効な JWT を拒否しなければならない (MUST)。

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 を拒否しなければならない (MUST)。

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 認可グラントと併せてクライアント認証が必要かどうか、およびサポートするクライアント認証の種類は、認可サーバーの裁量によるポリシー上の決定である。ただし、リクエストにクライアントクレデンシャルが含まれている場合、認可サーバーはそれを検証しなければならない (MUST)。

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" エラーコードでなければならない (MUST)。認可サーバーは、JWT が無効と判断された理由に関する追加情報を、"error_description" または "error_uri" パラメータを用いて含めてもよい (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" エラーコードでなければならない (MUST)。認可サーバーは、JWT が無効と判断された理由に関する追加情報を、"error_description" または "error_uri" パラメータを用いて含めてもよい (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 Claims Set を生成するためにエンコードされうる 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".

JWT のヘッダーとして使用される次の JSON オブジェクトの例は、"kid" 値 "16" で識別される鍵を用いて、JWT が Elliptic Curve Digital Signature Algorithm (ECDSA) P-256 SHA-256 で署名されていることを宣言する。

     {"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 の一回限りの使用制限、許容される JWT の最大有効期間、および JWT の具体的なサブジェクトとクレームの要件。こうした情報の交換は、本仕様の範囲外であることを明示しておく。場合によっては、これらの値を制約または規定したり、それらをどのように交換するかを指定したりする追加のプロファイルが作成されることがある。そのようなプロファイルの例としては、OAuth 2.0 Dynamic Client Registration Core Protocol [OAUTH-DYN-REG]、OpenID Connect Dynamic Client Registration 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 Signature アルゴリズムである。

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

次の仕様に記述されたセキュリティに関する考慮事項は、すべて本文書に適用される: 「Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants」[RFC7521]、「The OAuth 2.0 Authorization Framework」[RFC6749]、および「JSON Web Token (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 の使用についても、クライアント認証としての 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 はプライバシー上機微な情報を含むことがあり、そのような情報が意図しない相手に開示されるのを防ぐため、Transport Layer Security (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 Assertion Framework [RFC7521] の 6.3.1 節に記述されているとおり、"sub" (subject) クレームを匿名または仮名のユーザーを表す値とすることができる。

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

本節は、「An IETF URN Sub-Namespace for OAuth」[RFC6755] によって確立された IANA の「OAuth URI」レジストリに、値 "grant-type:jwt-bearer" を登録する。

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 一般名: JWT Bearer Token Grant Type Profile for OAuth 2.0

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

本節は、「An IETF URN 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 一般名: JWT Bearer Token Profile for OAuth 2.0 Client Authentication

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

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

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.

本プロファイルは、本文書と同じ著者による「Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants」[RFC7522] から派生したものである。