RFC 9068 - JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens 日本語訳

原文URL : https://www.rfc-editor.org/rfc/rfc9068.html
タイトル : RFC 9068 - OAuth 2.0アクセストークンのJSON Webトークン（JWT）プロファイル
翻訳編集 : 自動生成

[要約] RFC 9068は、OAuth 2.0アクセストークンとしてのJSON Web Token (JWT) の使用に関するプロファイルを定義しています。この文書の目的は、JWTをOAuth 2.0アクセストークンとして使用する際の実装ガイドラインを提供し、相互運用性を高めることです。利用場面としては、セキュアなAPIアクセス制御が挙げられ、OAuth 2.0フレームワーク内での認証と認可プロセスの一環としてJWTが活用されます。関連するRFCには、RFC 7519 (JWTの構造を定義)、RFC 6749 (OAuth 2.0認証フレームワーク)、RFC 7523 (JWTを使用したOAuth 2.0クライアント認証とアサーション) などがあります。

Internet Engineering Task Force (IETF)                       V. Bertocci
Request for Comments: 9068                                         Auth0
Category: Standards Track                                   October 2021
ISSN: 2070-1721

JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens

OAuth 2.0アクセストークンのJSON Webトークン（JWT）プロファイル

Abstract

概要

This specification defines a profile for issuing OAuth 2.0 access tokens in JSON Web Token (JWT) format. Authorization servers and resource servers from different vendors can leverage this profile to issue and consume access tokens in an interoperable manner.

この仕様は、JSON Webトークン（JWT）形式でOAuth 2.0アクセストークンを発行するためのプロファイルを定義しています。さまざまなベンダーの認証サーバーとリソースサーバーは、このプロファイルを活用してアクセストークンを相互運用可能な方法で発行および消費することができます。

Status of This Memo

本文書の位置付け

This is an Internet Standards Track document.

これはインターネット規格のトラック文書です。

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

この文書はインターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それはパブリックレビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。インターネット規格に関する詳細情報は、RFC 7841のセクション2で利用できます。

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

この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc9068で入手できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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トラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。

Table of Contents

   1.  Introduction
     1.1.  Requirements Notation and Conventions
     1.2.  Terminology
   2.  JWT Access Token Header and Data Structure
     2.1.  Header
     2.2.  Data Structure
       2.2.1.  Authentication Information Claims
       2.2.2.  Identity Claims
       2.2.3.  Authorization Claims
         2.2.3.1.  Claims for Authorization Outside of Delegation
                 Scenarios
   3.  Requesting a JWT Access Token
   4.  Validating JWT Access Tokens
   5.  Security Considerations
   6.  Privacy Considerations
   7.  IANA Considerations
     7.1.  Media Type Registration
       7.1.1.  Registry Content
     7.2.  Claims Registration
       7.2.1.  Registry Content
         7.2.1.1.  Roles
         7.2.1.2.  Groups
         7.2.1.3.  Entitlements
   8.  References
     8.1.  Normative References
     8.2.  Informative References
   Acknowledgements
   Author's Address

1. Introduction

1. はじめに

The original OAuth 2.0 Authorization Framework [RFC6749] specification does not mandate any specific format for access tokens. While that remains perfectly appropriate for many important scenarios, in-market use has shown that many commercial OAuth 2.0 implementations elected to issue access tokens using a format that can be parsed and validated by resource servers directly, without further authorization server involvement. The approach is particularly common in topologies where the authorization server and resource server are not co-located, are not run by the same entity, or are otherwise separated by some boundary. At the time of writing, many commercial implementations leverage the JSON Web Token (JWT) [RFC7519] format.

オリジナルのOAuth 2.0承認フレームワーク[RFC6749]指定は、アクセストークンの特定の形式を義務付けていません。それは多くの重要なシナリオに完全に適していますが、市場内使用は、多くの市販のOAuth 2.0実装が、リソースサーバーによって直接解析および検証できる形式を使用してアクセストークンを発行することを選択したことを示しています。このアプローチは、許可サーバーとリソースサーバーが同じ場所に配置されていないトポロジで特に一般的ですが、同じエンティティによって実行されていないか、またはその他の境界によって区切られています。執筆時点では、多くの商業実装がJSON Webトークン（JWT）[RFC7519]フォーマットを活用しています。

Many vendor-specific JWT access tokens share the same functional layout, using JWT claims to convey the information needed to support a common set of use cases: token validation, transporting authorization information in the form of scopes and entitlements, carrying identity information about the subject, and so on. The differences are mostly confined to the claim names and syntax used to represent the same entities, suggesting that interoperability could be easily achieved by standardizing a common set of claims and validation rules.

多くのベンダー固有のJWTアクセストークンは、JWTクレームを使用して同じ機能レイアウトを共有し、一般的なユースケースのセットをサポートするために必要な情報を伝達します。トークン検証、スコープとエンタイトルメントの形式での承認情報の転送、件名に関するID情報を運ぶ、等々。違いは、同じエンティティを表すために使用されるクレーム名と構文にはほとんど限定されており、その相互運用性は、共通の請求項と検証規則を標準化することによって容易に達成できることを示唆しています。

The assumption that access tokens are associated with specific information doesn't appear only in commercial implementations. Various specifications in the OAuth 2.0 family (such as resource indicators [RFC8707], OAuth 2.0 bearer token usage [RFC6750], and others) postulate the presence of scoping mechanisms, such as an audience, in access tokens. The family of specifications associated with introspection also indirectly suggests a fundamental set of information that access tokens are expected to carry or at least be associated with.

アクセストークンが特定の情報に関連付けられているという仮定は、商業実装にのみ表示されません。OAuth 2.0ファミリ（リソースインジケータ[RFC8707]、OAuth 2.0ベアラトークン使用法[RFC6750]など）のさまざまな仕様（およびその他）は、アクセストークン内のオーディエンスなどのスコープメカニズムの存在を仮定します。イントロスペクションに関連する仕様のファミリーはまた、アクセストークンが持ち運びまたは少なくとも関連付けることが期待される基本的な情報のセットを間接的に示唆している。

This specification aims to provide a standardized and interoperable profile as an alternative to the proprietary JWT access token layouts going forward. Besides defining a common set of mandatory and optional claims, the profile provides clear indications on how authorization request parameters determine the content of the issued JWT access token, how an authorization server can publish metadata relevant to the JWT access tokens it issues, and how a resource server should validate incoming JWT access tokens.

この仕様は、将来の独自のJWTアクセストークンレイアウトの代わりに標準化された相互運用可能なプロファイルを提供することを目的としています。義務的な要求および任意の特許請求の一般的なセットを定義することに加えて、プロファイルは発行されたJWTアクセストークンの内容をどのように決定するかについての明確な指示を提供し、許可サーバーがそれが問題となるJWTアクセストークンに関連するメタデータを発行する方法、およびリソースサーバーは、着信JWTアクセストークンを検証する必要があります。

Finally, this specification provides security and privacy considerations meant to prevent common mistakes and anti-patterns that are likely to occur in naive use of the JWT format to represent access tokens.

最後に、この仕様はセキュリティとプライバシーの考慮事項を提供し、アクセストークンを表すためにJWTフォーマットのナイーブ使用で発生する可能性が高い一般的な間違いやアンチパターンを防ぐことを意味しています。

Please note: Although both this document and [RFC7523] use JSON Web Tokens in the context of the OAuth2 framework, the two specifications differ in both intent and mechanics. Whereas [RFC7523] defines how a JWT Bearer Token can be used to request an access token, this document describes how to encode access tokens in JWT format.

注意：この文書と[RFC7523]の両方がOAuth2フレームワークのコンテキストでJSON Webトークンを使用していますが、2つの仕様は意図と力学の両方で異なります。[RFC7523] JWTベアラトークンを使用してアクセストークンを要求する方法を定義します。このドキュメントでは、JWT形式でアクセストークンをエンコードする方法について説明します。

1.1. Requirements Notation and Conventions

1.1. 要件表記法と規則

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。

1.2. Terminology

1.2. 用語

JWT access token: An OAuth 2.0 access token encoded in JWT format and complying with the requirements described in this specification.

JWTアクセストークン：JWTフォーマットでエンコードされ、本明細書に記載されている要件に準拠したOAuth 2.0アクセストークン。

This specification uses the terms "access token", "refresh token", "authorization server", "resource server", "authorization endpoint", "authorization request", "authorization response", "token endpoint", "grant type", "access token request", "access token response", and "client" defined by The OAuth 2.0 Authorization Framework [RFC6749].

この仕様書「アクセストークン」、「承認トークン」、「承認サーバー」、「承認エンドポイント」、「承認要求」、「承認要求」、「承認応答」、「トークンエンドポイント」、「付与タイプ」、"アクセストークン要求"、 "Access Token Response"、およびOAuth 2.0承認フレームワーク[RFC6749]で定義されています。

2. JWT Access Token Header and Data Structure

2. JWTアクセストークンヘッダーとデータ構造

2.1. Header

2.1. ヘッダ

JWT access tokens MUST be signed. Although JWT access tokens can use any signing algorithm, use of asymmetric cryptography is RECOMMENDED as it simplifies the process of acquiring validation information for resource servers (see Section 4). JWT access tokens MUST NOT use "none" as the signing algorithm. See Section 4 for more details.

JWTアクセストークンを署名する必要があります。JWTアクセストークンは任意の署名アルゴリズムを使用することができるが、リソースサーバの検証情報を取得するプロセスを簡略化するので、非対称暗号化の使用を推奨する（セクション4を参照）。JWTアクセストークンは、署名アルゴリズムとして「なし」を使用してはいけません。詳細についてはセクション4を参照してください。

Authorization servers and resource servers conforming to this specification MUST include RS256 (as defined in [RFC7518]) among their supported signature algorithms.

この仕様に準拠した認証サーバーとリソースサーバーには、サポートされている署名アルゴリズムの中でRS256（[RFC7518]で定義されている）が含まれていなければなりません。

This specification registers the "application/at+jwt" media type, which can be used to indicate that the content is a JWT access token. JWT access tokens MUST include this media type in the "typ" header parameter to explicitly declare that the JWT represents an access token complying with this profile. Per the definition of "typ" in Section 4.1.9 of [RFC7515], it is RECOMMENDED that the "application/" prefix be omitted. Therefore, the "typ" value used SHOULD be "at+jwt". See the Security Considerations section for details on the importance of preventing OpenID Connect ID Tokens (as defined by Section 2 of [OpenID.Core]) from being accepted as access tokens by resource servers implementing this profile.

この仕様は、コンテンツがJWTアクセストークンであることを示すために使用できる「アプリケーション/ AT JWT」メディアタイプを登録します。JWTアクセストークンは、このプロファイルに準拠したアクセストークンを表すように明示的に宣言するために、「typ」ヘッダーパラメータにこのメディアタイプを含める必要があります。[RFC7515]のセクション4.1.9の「TYP」の定義ごとに、「アプリケーション/」のプレフィックスを省略することをお勧めします。したがって、使用される「Typ」値は「JWTで」にする必要があります。このプロファイルを実装するリソースサーバによるOpenID Connect IDトークン（OpenID.COREのセクション2で定義されている）がアクセストークンとして受け入れられるのを防止することの重要性については、セキュリティ上の考慮事項のセクションを参照してください。

2.2. Data Structure

2.2. データ構造

The following claims are used in the JWT access token data structure.

以下の特許請求の範囲は、JWTアクセストークンデータ構造に使用される。

iss REQUIRED - as defined in Section 4.1.1 of [RFC7519].

ISS必須 - [RFC7519]のセクション4.1.1で定義されているように。

exp REQUIRED - as defined in Section 4.1.4 of [RFC7519].

Exp Required - [RFC7519]のセクション4.1.4で定義されているように。

aud REQUIRED - as defined in Section 4.1.3 of [RFC7519]. See Section 3 for indications on how an authorization server should determine the value of "aud" depending on the request.

OUDが必要 - [RFC7519]のセクション4.1.3で定義されているように。要求に応じて、許可サーバーが「AUD」の値を決定する方法についての指示については、セクション3を参照してください。

sub REQUIRED - as defined in Section 4.1.2 of [RFC7519]. In cases of access tokens obtained through grants where a resource owner is involved, such as the authorization code grant, the value of "sub" SHOULD correspond to the subject identifier of the resource owner. In cases of access tokens obtained through grants where no resource owner is involved, such as the client credentials grant, the value of "sub" SHOULD correspond to an identifier the authorization server uses to indicate the client application. See Section 5 for more details on this scenario. Also, see Section 6 for a discussion about how different choices in assigning "sub" values can impact privacy.

SUB必須 - [RFC7519]のセクション4.1.2で定義されているように。許可コード許可のようなリソース所有者が関与している許可を介して取得されたアクセストークンの場合、「サブ」の値は、リソース所有者のサブジェクト識別子に対応するべきである。クライアント認証情報許可のようなリソース所有者が関与していない許可を介して取得されたアクセストークンの場合、「サブ」の値は、許可サーバーがクライアントアプリケーションを示すために使用する識別子に対応する必要があります。このシナリオの詳細については5を参照してください。また、「SUB」値を割り当てる際の異なる選択肢についての説明については、Privacyに影響を与える可能性があるかについての議論についても参照してください。

client_id REQUIRED - as defined in Section 4.3 of [RFC8693].

client_idが必要 - [RFC8693]のセクション4.3で定義されているように。

iat REQUIRED - as defined in Section 4.1.6 of [RFC7519]. This claim identifies the time at which the JWT access token was issued.

IATが必要 - [RFC7519]のセクション4.1.6で定義されているように。この主張は、JWTアクセストークンが発行された時刻を識別する。

jti REQUIRED - as defined in Section 4.1.7 of [RFC7519].

JTIが必要 - [RFC7519]のセクション4.1.7で定義されているように。

2.2.1. Authentication Information Claims

2.2.1. 認証情報のクレーム

The claims listed in this section MAY be issued in the context of authorization grants involving the resource owner and reflect the types and strength of authentication in the access token that the authentication server enforced prior to returning the authorization response to the client. Their values are fixed and remain the same across all access tokens that derive from a given authorization response, whether the access token was obtained directly in the response (e.g., via the implicit flow) or after one or more token exchanges (e.g., obtaining a fresh access token using a refresh token or exchanging one access token for another via [RFC8693] procedures).

このセクションに記載されている特許請求の範囲は、リソース所有者を含む認証許可の文脈で発行され、認証サーバーがクライアントに認証応答を返す前に認証サーバー内の認証の種類と強さを反映させることができます。それらの値は固定され、特定の許可応答から派生したすべてのアクセストークンにわたって、アクセストークンが（例えば、暗黙的フローを介して）または1つまたは複数のトークン交換の後にアクセストークンが取得されたか（例えば、取得する）。リフレッシュトークンを使用するか、または1つのアクセストークンを使用した新しいアクセストークン[RFC8693]プロシージャ）。

auth_time OPTIONAL - as defined in Section 2 of [OpenID.Core].

auth_timeオプション - [OpenID.Core]のセクション2で定義されているように。

acr OPTIONAL - as defined in Section 2 of [OpenID.Core].

ACRオプション - [OpenID.Core]のセクション2で定義されているように。

amr OPTIONAL - as defined in Section 2 of [OpenID.Core].

AMRオプション - [OpenID.Core]のセクション2で定義されています。

2.2.2. Identity Claims

2.2.2. アイデンティティクレーム

In the context of authorization grants involving the resource owner, commercial authorization servers will often include resource owner attributes directly in access tokens so that resource servers can consume them directly for authorization or other purposes without any further round trips to introspection ([RFC7662]) or UserInfo ([OpenID.Core]) endpoints. This is particularly common in scenarios where the client and the resource server belong to the same entity and are part of the same solution, as is the case for first-party clients invoking their own backend API.

リソース所有者を含む認証許可の文脈では、コマーシャル認証サーバーには、リソースサーバーがイントロスペクションへの往復のない往復なしでそれらを直接アクセスすることができるように、アクセストークンに直接リソース所有者属性を含めることがよくあります（[RFC7662]）UserInfo（[OpenID.CORE]）エンドポイント。これは、クライアントとリソースサーバーが同じエンティティに属し、独自のバックエンドAPIを呼び出す最初のパーティクライアントの場合と同様に、シナリオで特に一般的です。

This profile does not introduce any mechanism for a client to directly request the presence of specific claims in JWT access tokens, as the authorization server can determine what additional claims are required by a particular resource server by taking the client_id of the client and the "scope" and the "resource" parameters included in the request into consideration.

このプロファイルは、クライアントのclient_idを取得することによって特定のリソースサーバがどのような追加の請求が必要かを判断できるため、クライアントがJWTアクセストークンの存在を直接要求するためのメカニズムは導入されません。そして、要求に含まれる「リソース」パラメータを考慮する。

Any additional identity attribute whose semantic is well described by an entry in the "JSON Web Token (JWT)" IANA registry introduced in [RFC7519] SHOULD be encoded using the corresponding claim name, if that attribute is to be included in the JWT access token. Note that the JWT IANA registry includes the claims found in Section 5.1 of [OpenID.Core].

[RFC7519]で導入された「JSON Webトークン（JWT）」IANAレジストリのエントリがよく記述されている追加のID属性は、その属性がJWTアクセストークンに含まれる場合は、対応する請求名を使用してエンコードされている必要があります。。JWT IANAレジストリには、[OpenID.Core]のセクション5.1にあるクレームが含まれています。

Authorization servers MAY return arbitrary attributes not defined in any existing specification, as long as the corresponding claim names are collision resistant or the access tokens are meant to be used only within a private subsystem. Please refer to Sections 4.2 and 4.3 of [RFC7519] for details.

許可サーバーは、対応する請求名が衝突に抵抗しているか、アクセストークンがプライベート・サブシステム内でのみ使用されることを意図している限り、既存の仕様で定義されていない任意の属性を返すことがあります。詳細については、[RFC7519]のセクション4.2と4.3を参照してください。

Authorization servers including resource owner attributes in JWT access tokens need to exercise care and verify that all privacy requirements are met, as discussed in Section 6.

JWTアクセストークンのリソース所有者属性を含む認可サーバーは、セクション6で説明したように、すべてのプライバシー要件が満たされていることを確認する必要があります。

2.2.3. Authorization Claims

2.2.3. 許可のクレーム

If an authorization request includes a scope parameter, the corresponding issued JWT access token SHOULD include a "scope" claim as defined in Section 4.2 of [RFC8693].

許可要求にスコープパラメータが含まれている場合、対応する発行されたJWTアクセストークンは[RFC8693]のセクション4.2で定義されている「スコープ」クレームを含める必要があります。

All the individual scope strings in the "scope" claim MUST have meaning for the resources indicated in the "aud" claim. See Section 5 for more considerations about the relationship between scope strings and resources indicated by the "aud" claim.

「スコープ」クレームの個々のスコープ文字列はすべて、「AUD」クレームに記載されているリソースの意味を持たなければなりません。「AUD」クレームで示される範囲の文字列とリソースの関係についてのより多くの考慮事項については、セクション5を参照してください。

2.2.3.1. Claims for Authorization Outside of Delegation Scenarios

2.2.3.1. 委任シナリオ以外の承認の請求

Many authorization servers embed authorization attributes that go beyond the delegated scenarios described by [RFC7519] in the access tokens they issue. Typical examples include resource owner memberships in roles and groups that are relevant to the resource being accessed, entitlements assigned to the resource owner for the targeted resource that the authorization server knows about, and so on.

多くの承認サーバーは、[RFC7519]が[RFC7519]が発行する委任シナリオを超えて行く承認属性を埋め込みます。典型的な例には、アクセスされているリソースに関連するリソース所有者のメンバーシップ、ターゲットリソースが認識されているターゲットリソースが知っているターゲットリソースに関連するエンタイトルメントなどが含まれます。

An authorization server wanting to include such attributes in a JWT access token SHOULD use the "groups", "roles", and "entitlements" attributes of the "User" resource schema defined by Section 4.1.2 of [RFC7643]) as claim types.

JWTアクセストークンにそのような属性を含みたい承認サーバは、「グループ」、「ロール」、および「rfc7643」）によって定義された「user」リソーススキーマの「グループ」、「ロール」、および「エンタイトルメント」属性をクレームタイプとして使用する必要があります。。

Authorization servers SHOULD encode the corresponding claim values according to the guidance defined in [RFC7643]. In particular, a non-normative example of a "groups" attribute can be found in Section 8.2 of [RFC7643]. No specific vocabulary is provided for "roles" and "entitlements".

許可サーバーは[RFC7643]で定義されているガイダンスに従って対応する請求値をエンコードする必要があります。特に、「グループ」属性の非規範的な例は、[RFC7643]のセクション8.2にあります。「役割」と「資格」には、特定の語彙は提供されていません。

Section 7.2.1 of this document provides entries for registering "groups", "roles", and "entitlements" attributes from [RFC7643] as claim types to be used in this profile.

この文書の7.2.1項では、「グループ」、「ロール」、および「参考文献」属性を[RFC7643]からこのプロファイルで使用されるクレームタイプとして登録するためのエントリがあります。

3. Requesting a JWT Access Token

3. JWTアクセストークンを要求します

An authorization server can issue a JWT access token in response to any authorization grant defined by [RFC6749] and subsequent extensions meant to result in an access token.

許可サーバーは、[RFC6749]で定義された承認グラントに応答してJWTアクセストークンを発行でき、後続の拡張機能はアクセストークンを引き起こすことを意味します。

If the request includes a "resource" parameter (as defined in [RFC8707]), the resulting JWT access token "aud" claim SHOULD have the same value as the "resource" parameter in the request.

リクエストに「RESOURCE」パラメータが含まれている場合（[RFC8707]で定義されているように）、結果のJWTアクセストークン「AUD」クレームは、要求内の「リソース」パラメータと同じ値を持つべきです。

Example request below:

以下のリクエストの例：

   GET /as/authorization.oauth2?response_type=code
           &client_id=s6BhdRkqt3
           &state=xyz
           &scope=openid%20profile%20reademail
           &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
           &resource=https%3A%2F%2Frs.example.com%2F HTTP/1.1
        Host: authorization-server.example.com

Figure 1: Authorization Request with Resource and Scope Parameters

図1：リソースおよびスコープパラメータを使用した認証要求

Once redeemed, the code obtained from the request above will result in a JWT access token in the form shown below:

償還されると、上記の要求から得られたコードは、以下に示す形式のJWTアクセストークンになります。

Header:

ヘッダ：

      {"typ":"at+JWT","alg":"RS256","kid":"RjEwOwOA"}

Claims:

請求：

      {
        "iss": "https://authorization-server.example.com/",
        "sub": "5ba552d67",
        "aud":   "https://rs.example.com/",
        "exp": 1639528912,
        "iat": 1618354090,
        "jti" : "dbe39bf3a3ba4238a513f51d6e1691c4",
        "client_id": "s6BhdRkqt3",
        "scope": "openid profile reademail"
      }

Figure 2: The Header and JWT Claims Set of a JWT Access Token

図2：ヘッダーとJWTクレームJWTアクセストークンのセット

The authorization server MUST NOT issue a JWT access token if the authorization granted by the token would be ambiguous. See Section 5 for more details about common cases that might lead to ambiguity and strategies an authorization server can enact to prevent them.

トークンによって付与された許可があいまいになると、認証サーバーはJWTアクセストークンを発行してはいけません。あいまいさや戦略につながる可能性がある一般的なケースの詳細については、セクション5を参照してください。

If the request does not include a "resource" parameter, the authorization server MUST use a default resource indicator in the "aud" claim. If a "scope" parameter is present in the request, the authorization server SHOULD use it to infer the value of the default resource indicator to be used in the "aud" claim. The mechanism through which scopes are associated with default resource indicator values is outside the scope of this specification. If the values in the "scope" parameter refer to different default resource indicator values, the authorization server SHOULD reject the request with "invalid_scope" as described in Section 4.1.2.1 of [RFC6749].

要求に「リソース」パラメータが含まれていない場合、許可サーバーは「AUD」クレームでデフォルトのリソースインジケータを使用する必要があります。要求に「scope」パラメータが存在する場合、許可サーバーはそれを使用して、「AUD」クレームで使用されるデフォルトのリソースインジケータの値を推測する必要があります。スコープがデフォルトのリソースインジケータ値に関連付けられているメカニズムは、この仕様の範囲外です。「scope」パラメータの値がさまざまなデフォルトのリソースインジケータ値を参照している場合、承認サーバーは[RFC6749]のセクション4.1.2.1で説明されているように「invalid_scope」で要求を拒否する必要があります。

4. Validating JWT Access Tokens

4. JWTアクセストークンの検証

For the purpose of facilitating validation data retrieval, it is RECOMMENDED here that authorization servers sign JWT access tokens with an asymmetric algorithm.

検証データの検索を容易にする目的で、認可サーバーが非対称アルゴリズムでJWTアクセストークンに署名することをお勧めします。

Authorization servers SHOULD use OAuth 2.0 Authorization Server Metadata [RFC8414] to advertise to resource servers their signing keys via "jwks_uri" and what "iss" claim value to expect via the "issuer" metadata value. Alternatively, authorization servers implementing OpenID Connect MAY use the OpenID Connect discovery [OpenID.Discovery] document for the same purpose. If an authorization server supports both OAuth 2.0 Authorization Server Metadata and OpenID Connect discovery, the values provided MUST be consistent across the two publication methods.

許可サーバーは、OAuth 2.0認証サーバーメタデータ[RFC8414]を使用して、「jwks_uri」を介してリソースサーバーに宣伝し、「ISS」メタデータ値を介して期待する担当者の署名者に署名する必要があります。あるいは、OpenID Connectを実装する認可サーバーは、同じ目的のためにOpenID Connect Discovery [OpenID.Discovery]ドキュメントを使用することがあります。許可サーバーがOAuth 2.0認証サーバーメタデータとOpenID Connect Discoveryの両方をサポートしている場合、提供されている値は2つのパブリケーションメソッドにわたって一貫性がある必要があります。

An authorization server MAY elect to use different keys to sign OpenID Connect ID Tokens and JWT access tokens. This specification does not provide a mechanism for identifying a specific key as the one used to sign JWT access tokens. An authorization server can sign JWT access tokens with any of the keys advertised via authorization server (AS) metadata or OpenID Connect discovery. See Section 5 for further guidance on security implications.

認可サーバーは、OpenID Connect IDトークンとJWTアクセストークンに署名するためにさまざまなキーを使用することを選択できます。この仕様は、JWTアクセストークンに署名するために使用されるものとして特定のキーを識別するためのメカニズムを提供しません。許可サーバーは、認可サーバー（AS）メタデータまたはOpenID Connect Discoveryを介してアドバタイズされた鍵のいずれかでJWTアクセストークンに署名できます。セキュリティの影響に関するさらなるガイダンスについては、セクション5を参照してください。

Resource servers receiving a JWT access token MUST validate it in the following manner.

JWTアクセストークンを受信したリソースサーバは、次のように検証する必要があります。

* The resource server MUST verify that the "typ" header value is "at+jwt" or "application/at+jwt" and reject tokens carrying any other value.

* リソースサーバは、「Typ」ヘッダ値が「jwt」または「アプリケーション/ at jwt」であることを確認し、他の値を伝えるトークンを拒否しなければならない。

* If the JWT access token is encrypted, decrypt it using the keys and algorithms that the resource server specified during registration. If encryption was negotiated with the authorization server at registration time and the incoming JWT access token is not encrypted, the resource server SHOULD reject it.

* JWTアクセストークンが暗号化されている場合は、登録中に指定されたリソースサーバーが指定されたキーとアルゴリズムを使用して復号化します。登録時に認証サーバーと暗号化がネゴシエートされ、着信JWTアクセストークンが暗号化されていない場合、リソースサーバーはそれを拒否する必要があります。

* The issuer identifier for the authorization server (which is typically obtained during discovery) MUST exactly match the value of the "iss" claim.

* 許可サーバーの発行者識別子（通常は発見中に取得されます）は、「ISS」クレームの値と正確に一致している必要があります。

* The resource server MUST validate that the "aud" claim contains a resource indicator value corresponding to an identifier the resource server expects for itself. The JWT access token MUST be rejected if "aud" does not contain a resource indicator of the current resource server as a valid audience.

* リソースサーバは、「aud」クレームに、リソースサーバが自分自身を予想する識別子に対応するリソースインジケータ値を含むことを検証する必要があります。"aud"に有効な聴衆として現在のリソースサーバーのリソースインジケータが含まれていない場合は、JWTアクセストークンを拒否する必要があります。

* The resource server MUST validate the signature of all incoming JWT access tokens according to [RFC7515] using the algorithm specified in the JWT "alg" Header Parameter. The resource server MUST reject any JWT in which the value of "alg" is "none". The resource server MUST use the keys provided by the authorization server.

* Resource Serverは、JWT "ALG"ヘッダーパラメーターで指定されたアルゴリズムを使用して、[RFC7515]に従って、すべての着信JWTアクセストークンの署名を検証する必要があります。リソースサーバは、「ALG」の値が「なし」であるJWTを拒否する必要があります。リソースサーバーは、許可サーバーによって提供されているキーを使用する必要があります。

* The current time MUST be before the time represented by the "exp" claim. Implementers MAY provide for some small leeway, usually no more than a few minutes, to account for clock skew.

* 現在の時間は、「EXP」請求によって表される時間の前になければなりません。実装者は、時計のスキューを説明するために、いくつかの小さなリーウェイ、通常は数分以内に提供することがあります。

The resource server MUST handle errors as described in Section 3.1 of [RFC6750]. In particular, in case of any failure in the validation checks listed above, the authorization server response MUST include the error code "invalid_token". Please note that this requirement does not prevent JWT access tokens from using authentication schemes other than "Bearer".

リソースサーバーは[RFC6750]の3.1節で説明されているようにエラーを処理する必要があります。特に、上記の検証チェックに失敗した場合、許可サーバーの応答にはエラーコード "invalid_token"を含める必要があります。この要件は、JWTアクセストークンが「ベアラ」以外の認証方式を使用するのを妨げないことに注意してください。

If the JWT access token includes authorization claims as described in Section 2.2.3, the resource server SHOULD use them in combination with any other contextual information available to determine whether the current call should be authorized or rejected. Details about how a resource server performs those checks is beyond the scope of this profile specification.

セクション2.2.3で説明されているように、JWTアクセストークンに許可クレームが含まれている場合、リソースサーバーはそれらを利用可能な他の文脈情報と組み合わせて使用して、現在の通話を許可または拒否されるべきかどうかを判断する必要があります。リソースサーバーがそれらのチェックを実行する方法の詳細は、このプロファイル仕様の範囲を超えています。

5. Security Considerations

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

The JWT access token data layout described here is very similar to that of the id_token as defined by [OpenID.Core]. The explicit typing required in this profile, in line with the recommendations in [RFC8725], helps the resource server to distinguish between JWT access tokens and OpenID Connect ID Tokens.

ここで説明したJWTアクセストークンデータレイアウトは、[OpenID.Core]によって定義されているID_TOKENのそれと非常に似ています。[RFC8725]の推奨事項に沿って、このプロファイルで必要な明示的な入力は、リソースサーバーがJWTアクセストークンとOpenID Connect IDトークンを区別するのに役立ちます。

Authorization servers should prevent scenarios where clients can affect the value of the "sub" claim in ways that could confuse resource servers. For example, if the authorization server elects to use the client_id as the "sub" value for access tokens issued using the client credentials grant, the authorization server should prevent clients from registering an arbitrary client_id value, as this would allow malicious clients to select the sub of a high-privilege resource owner and confuse any authorization logic on the resource server relying on the "sub" value. For more details, please refer to Section 4.14 of [OAuth2.Security.BestPractices].

認証サーバーは、クライアントがリソースサーバーを混同する可能性のある方法でクライアントが「SUB」クレームの値に影響を与えることができるシナリオを防ぐ必要があります。たとえば、クライアント認証情報を使用して発行されたアクセストークンの「サブ」値としてCLIENT_IDを使用すると、クライアントはクライアントが任意のclient_id値を登録できないようにする必要があります。高特権のリソース所有者のサブ、および「sub」値に依存しているリソースサーバーに承認ロジックを混同します。詳細については、[OAUTH2.Security.BESTPRACTICES]のセクション4.14を参照してください。

To prevent cross-JWT confusion, authorization servers MUST use a distinct identifier as an "aud" claim value to uniquely identify access tokens issued by the same issuer for distinct resources. For more details on cross-JWT confusion, please refer to Section 2.8 of [RFC8725].

Cross-JWTの混乱を防ぐために、許可サーバーは、異なるリソースに対して同じ発行者によって発行されたアクセストークンを一意に識別するために、「AUD」クレーム値として異なる識別子を使用する必要があります。JWTの混乱の詳細については、[RFC8725]のセクション2.8を参照してください。

Authorization servers should use particular care when handling requests that might lead to ambiguous authorization grants. For example, if a request includes multiple resource indicators, the authorization server should ensure that each scope string included in the resulting JWT access token, if any, can be unambiguously correlated to a specific resource among the ones listed in the "aud" claim. The details on how to recognize and mitigate this and other ambiguous situations is highly scenario dependent and hence is out of scope for this profile.

許可サーバーは、あいまいな承認許可につながる可能性がある要求を処理するときに特定のケアを使用する必要があります。たとえば、要求に複数のリソースインジケータが含まれている場合、許可サーバーは、結果として得られるJWTアクセストークンに含まれる各スコープ文字列が、「AUD」クレームに記載されているものの中で特定のリソースと明確に相関させることができるようにする必要があります。これを認識して軽減する方法についての詳細は、シナリオに依存し、このプロファイルの範囲外です。

Authorization servers cannot rely on the use of different keys for signing OpenID Connect ID Tokens and JWT tokens as a method to safeguard against the consequences of leaking specific keys. Given that resource servers have no way of knowing what key should be used to validate JWT access tokens in particular, they have to accept signatures performed with any of the keys published in AS metadata or OpenID Connect discovery; consequently, an attacker just needs to compromise any key among the ones published to be able to generate and sign JWTs that will be accepted as valid by the resource server.

認可サーバーは、特定のキーの漏洩の影響に対して保護する方法として、OpenID Connect IDトークンとJWTトークンに署名するためのさまざまなキーを使用することはできません。特にJWTアクセストークンを検証するためにどのキーを使用する必要があるかを知らないことを考えると、MetadataまたはOpenID Connect Discoveryとして公開されているキーで実行された署名を受け入れる必要があります。その結果、攻撃者は、リソースサーバーによって有効であると受け入れられるJWTSを生成して署名することができるように公開されているものの中に任意のキーを侵害する必要があります。

6. Privacy Considerations

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

As JWT access tokens carry information by value, it now becomes possible for clients and potentially even end users to directly peek inside the token claims collection of unencrypted tokens.

JWTアクセストークンが値ごとに情報をキャリーにしているため、クライアントとエンドユーザーが暗号化されていないトークンのコレクションのコレクションの中で直接PEEKを直接PEEKにすることが可能になりました。

The client MUST NOT inspect the content of the access token: the authorization server and the resource server might decide to change the token format at any time (for example, by switching from this profile to opaque tokens); hence, any logic in the client relying on the ability to read the access token content would break without recourse. The OAuth 2.0 framework assumes that access tokens are treated as opaque by clients. Administrators of authorization servers should also take into account that the content of an access token is visible to the client. Whenever client access to the access token content presents privacy issues for a given scenario, the authorization server needs to take explicit steps to prevent them.

クライアントはアクセストークンの内容を検査してはいけません。許可サーバーとリソースサーバーはいつでもトークン形式をいつでも変更することを決定します（たとえば、このプロファイルから不透明トークンに切り替えることによって）。したがって、クライアント内のすべてのロジックは、アクセストークンコンテンツを読み取る機能に依存している任意のロジックは、頼みなしで壊れるでしょう。OAuth 2.0フレームワークは、アクセストークンがクライアントによって不透明として扱われると仮定しています。許可サーバーの管理者は、アクセストークンの内容がクライアントに表示されることも考慮に入れる必要があります。アクセストークンコンテンツへのクライアントアクセスが特定のシナリオに対してプライバシーの問題を提示するたびに、許可サーバーはそれらを防ぐために明示的な手順を取る必要があります。

In scenarios in which JWT access tokens are accessible to the end user, it should be evaluated whether the information can be accessed without privacy violations (for example, if an end user would simply access his or her own personal information) or if steps must be taken to enforce confidentiality.

JWTアクセストークンがエンドユーザにアクセス可能なシナリオでは、情報がプライバシー違反なしでアクセスできるかどうかを評価する必要があります（たとえば、エンドユーザーが単に自分の個人情報にアクセスする場合）、またはステップがある場合機密性を強制するために取られる。

Possible measures to prevent leakage of information to clients and end users include: encrypting the access token, encrypting the sensitive claims, omitting the sensitive claims or not using this profile, and falling back on opaque access tokens.

クライアントやエンドユーザーへの情報の漏洩を防ぐための可能な措置には、次のものが含まれます。アクセストークンの暗号化、敏感なクレームの暗号化、敏感なクレームを省略したり、このプロファイルを使用したり、不透明なアクセストークンに戻ります。

In every scenario, the content of the JWT access token will eventually be accessible to the resource server. It's important to evaluate whether the resource server gained the proper entitlement to have access to any content received in the form of claims, for example, through user consent in some form, policies and agreements with the organization running the authorization servers, and so on. For example, a user might not wish to consent to granting given resource server information about any of the non-mandatory claims enumerated in Section 2 (and its subsections).

すべてのシナリオで、JWTアクセストークンの内容が最終的にリソースサーバーにアクセス可能になります。リソースサーバが、例えば、許可サーバを実行している組織との組織との何らかの形式、ポリシー、および契約において、特許請求の範囲で受信されたコンテンツにアクセスできるように適切な権利を与えたかどうかを評価することが重要です。たとえば、ユーザーは、セクション2（およびそのサブセクション）で列挙されているいずれかの非必須請求のいずれかに関する、特定のリソースサーバー情報の付与に同意したくない場合があります。

This profile mandates the presence of the "sub" claim in every JWT access token, making it possible for resource servers to rely on that information for correlating incoming requests with data stored locally for the authenticated principal. Although the ability to correlate requests might be required by design in many scenarios, there are scenarios where the authorization server might want to prevent correlation. The "sub" claim should be populated by the authorization servers according to a privacy impact assessment. For instance, if a solution requires preventing tracking of principal activities across multiple resource servers, the authorization server should ensure that JWT access tokens meant for different resource servers have distinct "sub" values that cannot be correlated in the event of resource server collusion. Similarly, if a solution requires preventing a resource server from correlating the principal's activity within the resource itself, the authorization server should assign different "sub" values for every JWT access token issued. In turn, the client should obtain a new JWT access token for every call to the resource server to ensure that the resource server receives different "sub" and "jti" values at every call, thus preventing correlation between distinct requests.

このプロファイルは、すべてのJWTアクセストークンで「サブ」クレームの存在を義務付けており、リソースサーバが受信要求を認証されたプリンシパルに対してローカルに格納されているデータと関連付けるためにその情報に依存することを可能にする。多くのシナリオでデザインによってリクエストを相関させることができますが、許可サーバーが相関を防ぐことができるシナリオがあります。「サブ」クレームは、プライバシー影響評価に従って認可サーバーによって入力されるべきです。たとえば、ソリューションで複数のリソースサーバーにわたる主なアクティビティの追跡を防ぐ必要がある場合、許可サーバーは、Resource Server Conlusionのイベントでは、異なるリソースサーバーを意味するJWTアクセストークンが相関できる「サブ」の値を持つようにする必要があります。同様に、ソリューションでリソースサーバーがリソース自体内のプリンシパルのアクティビティを相互接続するのを防ぐ必要がある場合、許可サーバーは発行されたすべてのJWTアクセストークンに対して異なる「サブ」値を割り当てる必要があります。順に、リソースサーバへの呼び出しごとにクライアントが新しいJWTアクセストークンを取得し、リソースサーバがすべての呼び出しで異なる「SUB」および「JTI」の値を受信し、それによって異なる要求間の相関関係を防ぐべきである。

7. IANA Considerations

7. IANAの考慮事項

7.1. Media Type Registration

7.1. メディアタイプ登録

7.1.1. Registry Content

7.1.1. レジストリ内容

This section registers "application/at+jwt", a new media type [RFC2046] in the "Media Types" registry [IANA.MediaTypes] in the manner described in [RFC6838]. It can be used to indicate that the content is an access token encoded in JWT format.

このセクションでは、[RFC6838]に記載されている方法で、「メディアタイプ」レジストリ[IANA.MEDIATYPES]の新しいメディアタイプ[RFC2046]で、「アプリケーション/ AT JWT」を登録します。コンテンツがJWT形式でエンコードされたアクセストークンであることを示すために使用できます。

Type name: Application

タイプ名：アプリケーション

Subtype name: at+jwt

サブタイプ名：JWTで

Required parameters: N/A

必要なパラメータ：N / A

Optional parameters: N/A

オプションのパラメータ：n / A.

Encoding considerations: Binary; JWT values are encoded as a series of base64url-encoded values (with trailing '=' characters removed), some of which may be the empty string, separated by period ('.') characters.

エンコードに関する考慮事項：バイナリ;JWT値は一連のBase64URLエンコードされた値としてエンコードされます（末期 '='文字が削除された状態で）エンコードされ、そのうちのいくつかは、ピリオド（ '。'）文字で区切られた空の文字列かもしれません。

Security considerations: See the Security Considerations section of RFC 9068.

セキュリティ上の考慮事項：RFC 9068のセキュリティ上の考慮事項セクションを参照してください。

Interoperability considerations: N/A

相互運用性の考慮事項：N / A.

Published specification: RFC 9068

公開仕様：RFC 9068

Applications that use this media type: Applications that access resource servers using OAuth 2.0 access tokens encoded in JWT format

このメディアタイプを使用するアプリケーション：JWT形式でエンコードされたOAuth 2.0アクセストークンを使用してリソースサーバーにアクセスするアプリケーション

Fragment identifier considerations: N/A

フラグメント識別子の考慮事項：N / A.

Additional information:

追加情報：

      Magic number(s):  N/A
      File extension(s):  N/A
      Macintosh file type code(s):  N/A

   Person & email address to contact for further information:
      Vittorio Bertocci <vittorio@auth0.com>

Intended usage: COMMON

意図された使用法：一般的な

Restrictions on usage: None

使用法の制限：なし

   Author:  Vittorio Bertocci <vittorio@auth0.com>

Change controller: IETF

変更コントローラー：IETF.

Provisional registration? No

暫定登録？番号

7.2. Claims Registration

7.2. クレーム登録

Section 2.2.3.1 of this specification refers to the attributes "roles", "groups", "entitlements" defined in [RFC7643] to express authorization information in JWT access tokens. This section registers those attributes as claims in the "JSON Web Token (JWT)" IANA registry introduced in [RFC7519].

この仕様のセクション2.2.3.1は、JWTアクセストークンの承認情報を表現するために[RFC7643]で定義されている属性 "roles"、 "groups"、 "entitlements"を指します。このセクションでは、[RFC7519]で導入された「JSON Webトークン（JWT）」IANAレジストリのクレームとして、それらの属性を登録します。

7.2.1. Registry Content

7.2.1. レジストリ内容

7.2.1.1. Roles

7.2.1.1. 役割

Claim Name: roles Claim Description: Roles Change Controller: IETF Specification Document(s): Section 4.1.2 of [RFC7643] and Section 2.2.3.1 of RFC 9068

クレーム名：ロールクレーム説明：ロール変更コントローラ：IETF仕様書：[RFC7643]のセクション4.1.2およびRFC 9068のセクション2.2.3.1

7.2.1.2. Groups

7.2.1.2. 団体

Claim Name: groups Claim Description: Groups Change Controller: IETF Specification Document(s): Section 4.1.2 of [RFC7643] and Section 2.2.3.1 of RFC 9068

クレーム名：グループクレーム説明：グループ変更コントローラ：IETF仕様書：[RFC7643]およびRFC 9068のセクション4.1.2のセクション4.1.2

7.2.1.3. Entitlements

7.2.1.3. 権利物

Claim Name: entitlements Claim Description: Entitlements Change Controller: IETF Specification Document(s): Section 4.1.2 of [RFC7643] and Section 2.2.3.1 of RFC 9068

クレーム名：エンタイトルメントクレーム説明：エンタイトルメント変更コントローラ：IETF仕様書：[RFC7643]のセクション4.1.2およびRFC 9068のセクション2.2.3.1

8. References

8. 参考文献

8.1. Normative References

8.1. 引用文献

[OpenID.Core] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, "OpenID Connect Core 1.0 incorporating errata set 1", November 2014, <https://openid.net/specs/openid-connect-core-1_0.html>.

[OpenID.CORE] SAKIMURA、N.、Bradley、J.、Jones、M.、De Medeiros、B.、Mortimore、Mortimore、「OpenID Connect Core 1.0を組み込んだエラタセット1」、2014年11月、<https：//openid.net/specs/openid-connect-core-1_0.html>。

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

[OpenID.Discovery] Sakimura、N.、Bradley、J.、Jones、M.、およびE.JAY、「OpenID Connect Discovery 1.0エラタセット1」、2014年11月、<https://openid.net/specs/OpenID-Connect-Discovery-1_0.html>。

[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996, <https://www.rfc-editor.org/info/rfc2046>.

[RFC2046] Freed、N.およびN.Borenstein、「MultiPurpose Internet Mail Extensions（MIME）パート2：メディアタイプ」、RFC 2046、DOI 10.17487 / RFC2046、1996年11月、<https：//www.rfc-editor.org/ info / rfc2046>。

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

[RFC2119] BRADNER、S、「RFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。

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

[RFC6749]ハードル、D.、ED。、「OAuth 2.0認証フレームワーク」、RFC 6749、DOI 10.17487 / RFC6749、2012年10月、<https：//www.rfc-editor.org/info/rfc6749>。

[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <https://www.rfc-editor.org/info/rfc6838>.

[RFC6838] Freed、N.、Klensin、J.、およびT.Hansen、「メディア型仕様および登録手順」、BCP 13、RFC 6838、DOI 10.17487 / RFC6838、2013年1月、<https：///www.rfc-editor.org/info/rfc6838>。

[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <https://www.rfc-editor.org/info/rfc7515>.

[RFC7515] Jones、M.、Bradley、J.、およびSAKIMURA、「JSON Web Signature（JWS）」、RFC 7515、DOI 10.17487 / RFC7515、2015年5月、<https：//www.rfc-editor.org/ info / rfc7515>。

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

[RFC7518] Jones、M.、 "JSON Web Algorithms（JWA）"、RFC 7518、DOI 10.17487 / RFC7518、<https：//www.rfc-editor.org/info/rfc7518>。

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

[RFC7519]ジョーンズ、M.、Bradley、J.、およびSakimura、「JSON Webトークン（JWT）」、RFC 7519、DOI 10.17487 / RFC7519、2015年5月、<https：//www.rfc-editor.org/ info / rfc7519>。

[RFC7643] Hunt, P., Ed., Grizzle, K., Wahlstroem, E., and C. Mortimore, "System for Cross-domain Identity Management: Core Schema", RFC 7643, DOI 10.17487/RFC7643, September 2015, <https://www.rfc-editor.org/info/rfc7643>.

[RFC7643] Hunt、P.、Ed。、Grizzle、K.、Wahlstroem、E.、Mortimore、「クロスドメインアイデンティティ管理：コアスキーマ」、RFC 7643、DOI 10.17487 / RFC7643、2015年9月、<https://www.rfc-editor.org/info/rfc7643>。

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8174] Leiba、B.、RFC 2119キーワードの「大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。

[RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, <https://www.rfc-editor.org/info/rfc8414>.

[RFC8414] Jones、M.、Sakimura、N.、J.Bradley、 "OAuth 2.0認証サーバーメタデータ"、RFC 8414、DOI 10.17487 / RFC8414、2018年6月、<https：//www.rfc-editor.org/情報/ RFC8414>。

[RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, January 2020, <https://www.rfc-editor.org/info/rfc8693>.

[RFC8693]ジョーンズ、M.、Nadalin、A。、Campbell、B.、Ed。、Bradley、J.、およびC. Mortimore、「OAuth 2.0トークン交換」、RFC 8693、DOI 10.17487 / RFC8693、2020年1月、<https://www.rfc-editor.org/info/rfc8693>。

[RFC8707] Campbell, B., Bradley, J., and H. Tschofenig, "Resource Indicators for OAuth 2.0", RFC 8707, DOI 10.17487/RFC8707, February 2020, <https://www.rfc-editor.org/info/rfc8707>.

[RFC8707] Campbell、B.、Bradley、J.、およびH.Tschofenig、「OAuth 2.0のリソースインジケータ2.0」、RFC 8707、DOI 10.17487 / RFC8707、2020年2月、<https：//www.rfc-editor.org/情報/ RFC8707>。

[RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best Current Practices", BCP 225, RFC 8725, DOI 10.17487/RFC8725, February 2020, <https://www.rfc-editor.org/info/rfc8725>.

[RFC8725] Sheffer、Y.、Hardt、D.、およびM. Jones、「JSON WebトークンBEST Current Practices」、BCP 225、RFC 8725、DOI 10.17487 / RFC8725、2020年2月、<https：///www.rfc-editor.org/info/rfc8725>。

8.2. Informative References

8.2. 参考引用

[IANA.MediaTypes] IANA, "Media Types", <https://www.iana.org/assignments/media-types/>.

[IANA.MEDIATYPES] IANA、「メディアタイプ」、<https：//www.iana.org/assignments/media-types/>。

[OAuth2.Security.BestPractices] Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett, "OAuth 2.0 Security Best Current Practice", Work in Progress, Internet-Draft, draft-ietf-oauth-security-topics-18, 13 April 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-18>.

[OAUTH2.Security.BESTPRACTICES] LodderStedt、T.、Bradley、J.、Labunets、A.、およびD. FETT、「OAUTH 2.0セキュリティ最高の現在の練習」、進行中の作業、インターネットドラフト、草案-IETF-OAUTH-Security-Topics-18、2021年4月13日、<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-topics-topics-topics-topics-topics-

[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, DOI 10.17487/RFC6750, October 2012, <https://www.rfc-editor.org/info/rfc6750>.

[RFC6750] Jones、M.およびD. Hardt、 "OAuth 2.0承認フレームワーク：Bearer Token Usage"、RFC 6750、DOI 10.17487 / RFC6750、2012年10月、<https：//www.rfc-editor.org/info/RFC6750>。

[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, <https://www.rfc-editor.org/info/rfc7523>.

[RFC7523] Jones、M.、Campbell、B.およびC. Mortimore、OAuth 2.0クライアント認証および承認基準の「JSON Webトークン（JWT）プロファイル」、RFC 7523、DOI 10.17487 / RFC7523、2015年5月、<https：//www.rfc-editor.org/info/rfc7523>。

[RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", RFC 7662, DOI 10.17487/RFC7662, October 2015, <https://www.rfc-editor.org/info/rfc7662>.

[RFC7662] RICHER、J.、ED。、「OAuth 2.0トークンイントロスペクション」、RFC 7662、DOI 10.17487 / RFC7662、2015年10月、<https：//www.rfc-editor.org/info/rfc7662>。

Acknowledgements

謝辞

The initial set of requirements informing this specification was extracted by numerous examples of access tokens issued in JWT format by production systems. Thanks to Dominick Baier (IdentityServer), Brian Campbell (Ping Identity), Daniel Dobalian (Microsoft), and Karl Guinness (Okta) for providing sample tokens issued by their products and services. Brian Campbell and Filip Skokan provided early feedback that shaped the direction of the specification. This profile was discussed at length during the OAuth Security Workshop 2019, with several individuals contributing ideas and feedback. The author would like to acknowledge the contributions of:

この仕様に知らせる要件の初期セットは、生産システムによってJWT形式で発行されたアクセストークンの多くの例によって抽出されました。製品やサービスによって発行されたサンプルトークンを提供するためのDominick Baier（IdentityServer）、Brian Campbell（Ping Identity）、Daniel Dobalian（Microsoft）、およびKarl Guinness（OKTA）のおかげで。Brian CampbellとFilip Skokanは、仕様の方向を形作る早期のフィードバックを提供しました。このプロファイルは、OAuth Security Workshop 2019の間に長さで議論され、いくつかの個人がアイデアとフィードバックを寄与しています。作者は以下の貢献を認めたいと思います。

John Bradley, Brian Campbell, Vladimir Dzhuvinov, Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig, and everyone who actively participated in the unconference discussions.

John Bradley、Brian Campbell、Vladimir Dzhuvinov、Torsten Lodderstedt、Nat Sakimura、Hannes Tschofenig、そして常に難民の議論に積極的に参加しました。

The following individuals contributed useful feedback and insights on the drafts, both at the IETF OAuth 2.0 WG mailing list and during the 28th Internet Identity Workshop (IIW 28):

次の個人は、IETF OAUTH 2.0 WGメーリングリストと28回目のインターネットIDワークショップ（IIW 28）の両方で、ドラフト上の有用なフィードバックと洞察を貢献しました。

Dale Olds, George Fletcher, David Waite, Michael Engan, Mike Jones, Hans Zandbelt, Vladimir Dzhuvinov, Martin Schanzenbach, Aaron Parecki, Annabelle Richard Backman, Dick Hardt, Denis Pinkas, Benjamin Kaduk, Dominick Baier, Andrii Deinega, Mike Jones, and everyone who actively participated in the IIW 28 unconference discussions and the IETF OAuth 2.0 WG mailing list discussions. Thanks to Roman Danyliw for the AD review; Joseph Salowey and Roni Even for the SECDIR and GENART reviews; and Francesca Palomini, Lars Eggert, Murray Kucherawy, Roberto Polli, Martin Duke, Benjamin Kaduk for the IESG reviews.

Dale Olds、George Fletcher、David Wate、Michael Engan、Mike Jones、Mike Jones、Hans Zandbelt、Vladimir Dzhuvinov、Martin Schanzenbach、Aaron Parcki、Annabelle Richard Backas、Dick Hardt、Denis Pinkas、Benjamin Kaduk、Dominick Baier、Andri Deinega、Mike Jones、IIW 28珍しい議論とIETF OAuth 2.0 WGメーリングリストのディスカッションに積極的に参加したすべての人が。広告レビューのためにローマのDanyliwに感謝します。SecdirとGenartのレビューでもヨセフサローイとロニそしてFrancesca Palomini、Lars Egger、Murray Kucherawy、Roberto Polli、Martin Duke、Benjamin KadukのIESGのレビュー。

Author's Address

作者の住所

Vittorio Bertocci Auth0

   Email: vittorio@auth0.com