[要約] RFC 8707は、OAuth 2.0のためのリソース指標を定義するものであり、リソースの識別とアクセス制御を向上させることを目的としています。
Internet Engineering Task Force (IETF) B. Campbell
Request for Comments: 8707 Ping Identity
Category: Standards Track J. Bradley
ISSN: 2070-1721 Yubico
H. Tschofenig
Arm Limited
February 2020
Resource Indicators for OAuth 2.0
OAuth 2.0のリソースインジケーター
Abstract
概要
This document specifies an extension to the OAuth 2.0 Authorization Framework defining request parameters that enable a client to explicitly signal to an authorization server about the identity of the protected resource(s) to which it is requesting access.
このドキュメントでは、クライアントがアクセスをリクエストしている保護されたリソースのIDについて認可サーバーに明示的に通知できるようにするリクエストパラメータを定義するOAuth 2.0認可フレームワークの拡張を指定します。
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 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、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/rfc8707.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8707で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2020 IETFトラストおよびドキュメントの作成者として識別された人物。全著作権所有。
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 Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
1.1. Requirements Notation and Conventions
1.2. Terminology
2. Resource Parameter
2.1. Authorization Request
2.2. Access Token Request
3. Security Considerations
4. Privacy Considerations
5. IANA Considerations
5.1. OAuth Parameters Registration
5.2. OAuth Extensions Error Registration
6. References
6.1. Normative References
6.2. Informative References
Acknowledgements
Authors' Addresses
Several years of deployment and implementation experience with the OAuth 2.0 Authorization Framework [RFC6749] has uncovered a need (in some circumstances, such as an authorization server servicing a significant number of diverse resources) for the client to explicitly signal to the authorization server where it intends to use the access token it is requesting.
OAuth 2.0承認フレームワーク[RFC6749]を使用した数年にわたる導入と実装の経験により、クライアントが承認サーバーに明示的に信号を送る必要がある（状況によっては、承認サーバーが多数の多様なリソースにサービスを提供するなど）リクエストしているアクセストークンを使用する予定です。
Knowing the protected resource (a.k.a. resource server, application, API, etc.) that will process the access token enables the authorization server to construct the token as necessary for that entity. Properly encrypting the token (or content within the token) to a particular resource, for example, requires knowing which resource will receive and decrypt the token. Furthermore, various resources oftentimes have different requirements with respect to the data contained in (or referenced by) the token, and knowing the resource where the client intends to use the token allows the authorization server to mint the token accordingly.
アクセストークンを処理する保護されたリソース（リソースサーバー、アプリケーション、APIなど）を知っていると、承認サーバーはそのエンティティに必要なトークンを構築できます。たとえば、トークン（またはトークン内のコンテンツ）を特定のリソースに適切に暗号化するには、どのリソースがトークンを受信して復号化するかを知る必要があります。さらに、さまざまなリソースは、トークンに含まれる（またはトークンによって参照される）データに関して異なる要件を持っていることが多く、クライアントがトークンを使用する予定のリソースを知ることにより、承認サーバーはそれに応じてトークンを作成できます。
Specific knowledge of the intended recipient(s) of the access token also helps facilitate improved security characteristics of the token itself. Bearer tokens, currently the most commonly utilized type of OAuth access token, allow any party in possession of a token to get access to the associated resources. To prevent misuse, several important security assumptions must hold, one of which is that an access token must only be valid for use at a specific protected resource and for a specific scope of access. Section 5.2 of [RFC6750], for example, prescribes including the token's intended recipients within the token to prevent token redirect. When the authorization server is informed of the resource that will process the access token, it can restrict the intended audience of that token to the given resource such that the token cannot be used successfully at other resources.
アクセストークンの対象となる受信者に関する特定の知識も、トークン自体のセキュリティ特性の向上に役立ちます。現在最も一般的に使用されているOAuthアクセストークンのタイプであるベアラートークンを使用すると、トークンを所有しているすべての関係者が、関連するリソースにアクセスできます。誤用を防ぐために、いくつかの重要なセキュリティの前提を維持する必要があります。その1つは、アクセストークンは特定の保護されたリソースでの使用と特定のアクセススコープでのみ有効であることです。たとえば、[RFC6750]のセクション5.2は、トークンのリダイレクトを防ぐために、トークン内にトークンの意図された受信者を含めることを規定しています。承認サーバーは、アクセストークンを処理するリソースを通知されると、そのトークンの対象ユーザーを特定のリソースに制限して、他のリソースでトークンを正常に使用できないようにすることができます。
OAuth scope, from Section 3.3 of [RFC6749], is sometimes overloaded to convey the location or identity of the protected resource, however, doing so isn't always feasible or desirable. Scope is typically about what access is being requested rather than where that access will be redeemed (e.g., "email", "admin:org", "user_photos", "channels:read", and "channels:write" are a small sample of scope values in use in the wild that convey only the type of access and not the location or identity).
[RFC6749]のセクション3.3にあるOAuthスコープは、保護されたリソースの場所またはIDを伝えるために過負荷になる場合がありますが、それが常に実行可能または望ましいとは限りません。スコープは通常、アクセスが利用される場所ではなく、どのアクセスが要求されているかに関するものです（たとえば、「email」、「admin：org」、「user_photos」、「channels：read」、および「channels：write」は小さなサンプルです）アクセスのタイプのみを伝達し、場所やIDを伝達しない、実際に使用されているスコープ値のセット）。
In some circumstances and for some deployments, a means for the client to signal to the authorization server where it intends to use the access token it's requesting is important and useful. A number of implementations and deployments of OAuth 2.0 have already employed proprietary parameters toward that end. Going forward, this specification aspires to provide a standardized and interoperable alternative to the proprietary approaches.
状況や展開によっては、クライアントがリクエストするアクセストークンを使用する場所を承認サーバーに通知する手段が重要かつ有用です。 OAuth 2.0の多くの実装と展開では、そのために独自のパラメータがすでに採用されています。今後、この仕様は、独自のアプローチに対する標準化された相互運用可能な代替手段を提供することを目指しています。
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」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
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].
この仕様では、「アクセストークン」、「リフレッシュトークン」、「承認サーバー」、「リソースサーバー」、「承認エンドポイント」、「承認リクエスト」、「承認レスポンス」、「トークンエンドポイント」、「付与タイプ」、 OAuth 2.0 Authorization Framework [RFC6749]で定義されている「アクセストークンリクエスト」、「アクセストークンレスポンス」、「クライアント」。
In requests to the authorization server, a client MAY indicate the protected resource (a.k.a. resource server, application, API, etc.) to which it is requesting access by including the following parameter in the request.
認可サーバーへのリクエストでは、クライアントはリクエストに次のパラメーターを含めることにより、アクセスをリクエストしている保護されたリソース（別名リソースサーバー、アプリケーション、APIなど）を示すことができます（MAY）。
resource Indicates the target service or resource to which access is being requested. Its value MUST be an absolute URI, as specified by Section 4.3 of [RFC3986]. The URI MUST NOT include a fragment component. It SHOULD NOT include a query component, but it is recognized that there are cases that make a query component a useful and necessary part of the resource parameter, such as when one or more query parameters are used to scope requests to an application. The "resource" parameter URI value is an identifier representing the identity of the resource, which MAY be a locator that corresponds to a network-addressable location where the target resource is hosted. Multiple "resource" parameters MAY be used to indicate that the requested token is intended to be used at multiple resources.
resourceアクセスが要求されているターゲットサービスまたはリソースを示します。 [RFC3986]のセクション4.3で指定されているように、その値は絶対URIである必要があります。 URIにフラグメントコンポーネントを含めることはできません。クエリコンポーネントは含めないでください。ただし、1つ以上のクエリパラメータを使用してアプリケーションへのリクエストのスコープを設定する場合など、クエリコンポーネントをリソースパラメータの有用かつ必要な部分にする場合があることが認識されています。 「リソース」パラメーターのURI値は、リソースのIDを表す識別子であり、ターゲットリソースがホストされているネットワークでアドレス可能な場所に対応するロケーターである場合があります。複数の「リソース」パラメータを使用して、要求されたトークンが複数のリソースで使用されることを意図していることを示すことができます。
The parameter value identifies a resource to which the client is requesting access. The parameter can carry the location of a protected resource, typically as an https URL or a more abstract identifier. This enables the authorization server to apply policy as appropriate for the resource, such as determining the type and content of tokens to be issued, if and how tokens are encrypted, and applying appropriate audience restrictions.
パラメータ値は、クライアントがアクセスを要求しているリソースを識別します。パラメータは、保護されたリソースの場所を、通常はhttps URLまたはより抽象的な識別子として運ぶことができます。これにより、許可サーバーは、発行されるトークンのタイプと内容の決定、トークンの暗号化の方法と方法、適切なオーディエンス制限の適用など、リソースに適切なポリシーを適用できます。
The client SHOULD provide the most specific URI that it can for the complete API or set of resources it intends to access. In practice, a client will know a base URI for the application or resource that it interacts with, which is appropriate to use as the value of the "resource" parameter. The client SHOULD use the base URI of the API as the "resource" parameter value unless specific knowledge of the resource dictates otherwise. For example, the value "https://api.example.com/" would be used for a resource that is the exclusive application on that host; however, if the resource is one of many applications on that host, something like "https://api.example.com/app/" would be used as a more specific value. Another example is when an API has multiple endpoints, e.g., when System for Cross-domain Identity Management (SCIM) [RFC7644] has endpoints such as "https://apps.example.com/scim/Users", "https://apps.example.com/scim/Groups", and "https://apps.example.com/scim/Schemas". The client would use "https://apps.example.com/scim/" as the resource so that the issued access token is valid for all the endpoints of the SCIM API.
クライアントは、完全なAPIまたはアクセスする予定のリソースのセットに対して提供できる最も具体的なURIを提供する必要があります（SHOULD）。実際には、クライアントは、対話するアプリケーションまたはリソースのベースURIを知っています。これは、「リソース」パラメーターの値として使用するのに適しています。クライアントは、リソースの特定の知識が他に指示しない限り、APIのベースURIを「リソース」パラメーター値として使用する必要があります（SHOULD）。たとえば、値「https://api.example.com/」は、そのホスト上の排他的なアプリケーションであるリソースに使用されます。ただし、リソースがそのホスト上の多くのアプリケーションの1つである場合、「https://api.example.com/app/」のようなものがより具体的な値として使用されます。別の例は、APIに複数のエンドポイントがある場合です。たとえば、クロスドメインID管理（SCIM）[RFC7644]のシステムに「https://apps.example.com/scim/Users」、「https:/ /apps.example.com/scim/Groups」、「https://apps.example.com/scim/Schemas」。クライアントは "https://apps.example.com/scim/"をリソースとして使用するため、発行されたアクセストークンはSCIM APIのすべてのエンドポイントで有効です。
The following error code is provided for an authorization server to indicate problems with the requested resource(s) in response to an authorization request or access token request. It can also be used to inform the client that it has requested an invalid combination of resource and scope.
次のエラーコードは、承認サーバーが承認要求またはアクセストークン要求に応答して要求されたリソースの問題を示すために提供されています。また、リソースとスコープの無効な組み合わせを要求したことをクライアントに通知するためにも使用できます。
invalid_target The requested resource is invalid, missing, unknown, or malformed.
invalid_targetリクエストされたリソースは無効、欠落、不明、または不正な形式です。
The authorization server SHOULD audience-restrict issued access tokens to the resource(s) indicated by the "resource" parameter. Audience restrictions can be communicated in JSON Web Tokens [RFC7519] with the "aud" claim and the top-level member of the same name provides the audience restriction information in a Token Introspection [RFC7662] response. The authorization server may use the exact "resource" value as the audience or it may map from that value to a more general URI or abstract identifier for the given resource.
承認サーバーは、「resource」パラメーターで指定されたリソースへのオーディエンス制限付きのアクセストークンを発行する必要があります（SHOULD）。オーディエンス制限は、JSON Webトークン[RFC7519]で「aud」クレームを使用して通信でき、同じ名前の最上位メンバーがトークンイントロスペクション[RFC7662]応答でオーディエンス制限情報を提供します。認可サーバーは、正確な「リソース」値をオーディエンスとして使用するか、その値から、より一般的なURIまたは指定されたリソースの抽象識別子にマップすることができます。
When the "resource" parameter is used in an authorization request to the authorization endpoint, it indicates the identity of the protected resource(s) to which access is being requested. When an access token will be returned directly from the authorization endpoint via the implicit flow (Section 4.2 of OAuth 2.0 [RFC6749]), the requested resource is applicable to that access token. In the code flow (Section 4.1 of OAuth 2.0 [RFC6749]) where an intermediate representation of the authorization grant (the authorization code) is returned from the authorization endpoint, the requested resource is applicable to the full authorization grant.
承認エンドポイントへの承認リクエストで "resource"パラメータが使用されている場合、それはアクセスがリクエストされている保護されたリソースのIDを示します。暗黙のフロー（OAuth 2.0 [RFC6749]のセクション4.2）を介して認証エンドポイントから直接アクセストークンが返される場合、リクエストされたリソースはそのアクセストークンに適用されます。承認エンドポイントから承認付与（承認コード）の中間表現が返されるコードフロー（OAuth 2.0 [RFC6749]のセクション4.1）では、リクエストされたリソースは完全な承認付与に適用されます。
For an authorization request sent as a JSON Web Token (JWT), such as when using the JWT Secured Authorization Request [JWT-SAR], a single "resource" parameter value is represented as a JSON string while multiple values are represented as an array of strings.
JWTセキュア認証リクエスト[JWT-SAR]を使用する場合など、JSON Webトークン（JWT）として送信される認証リクエストの場合、単一の「リソース」パラメーター値はJSON文字列として表され、複数の値は配列として表されます文字列の。
If the client omits the "resource" parameter when requesting authorization, the authorization server MAY process the request with no specific resource or by using a predefined default resource value. Alternatively, the authorization server MAY require clients to specify the resource(s) they intend to access and MAY fail requests that omit the parameter with an "invalid_target" error. The authorization server might use this data to inform the user about the resources the client is going to access on their behalf, to apply policy (e.g., refuse the request due to unknown resources), and to determine the set of resources that can be used in subsequent access token requests.
クライアントが許可を要求するときに「resource」パラメーターを省略した場合、許可サーバーは特定のリソースなしで、または事前定義されたデフォルトのリソース値を使用して要求を処理できます（MAY）。あるいは、認可サーバーは、クライアントがアクセスするリソースを指定することをクライアントに要求する場合があり、「invalid_target」エラーでパラメーターを省略したリクエストを失敗させる場合があります。承認サーバーは、このデータを使用して、クライアントがユーザーに代わってアクセスするリソースについてユーザーに通知し、ポリシーを適用（たとえば、不明なリソースのために要求を拒否）し、使用できるリソースのセットを決定します。後続のアクセストークンリクエスト。
If the authorization server fails to parse the provided value(s) or does not consider the resource(s) acceptable, it should reject the request with an error response using the error code "invalid_target" as the value of the "error" parameter and can provide additional information regarding the reasons for the error using the "error_description".
許可サーバーが提供された値の解析に失敗した場合、またはリソースを受け入れ可能と見なさない場合は、エラーコード「invalid_target」を「error」パラメーターの値として使用し、エラー応答でリクエストを拒否する必要があります。 「error_description」を使用して、エラーの理由に関する追加情報を提供できます。
An example of an authorization request where the client tells the authorization server that it wants an access token for use at "https://api.example.com/app/" is shown in Figure 1 below (extra line breaks and indentation are for display purposes only).
「https://api.example.com/app/」で使用するアクセストークンが必要であることをクライアントが承認サーバーに通知する承認リクエストの例を以下の図1に示します（余分な改行とインデントは表示目的のみ）。
GET /as/authorization.oauth2?response_type=token
&client_id=example-client
&state=XzZaJlcwYew1u0QBrRv_Gw
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
&resource=https%3A%2F%2Fapi.example.com%2Fapp%2F HTTP/1.1
Host: authorization-server.example.com
Figure 1: Implicit Flow Authorization Request
図1：暗黙的なフロー承認リクエスト
Below in Figure 2 is an example of an authorization request using the "code" response type where the client is requesting access to the resource owner's contacts and calendar data at "https://cal.example.com/" and "https://contacts.example.com/" (extra line breaks and indentation are for display purposes only).
以下の図2は、クライアントが「https://cal.example.com/」と「https：/」でリソース所有者の連絡先とカレンダーデータへのアクセスを要求している「コード」応答タイプを使用した承認要求の例です。 /contacts.example.com/ "（余分な改行とインデントは表示専用です）。
GET /as/authorization.oauth2?response_type=code
&client_id=s6BhdRkqt3
&state=tNwzQ87pC6llebpmac_IDeeq-mCR2wLDYljHUZUAWuI
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
&scope=calendar%20contacts
&resource=https%3A%2F%2Fcal.example.com%2F
&resource=https%3A%2F%2Fcontacts.example.com%2F HTTP/1.1
Host: authorization-server.example.com
Figure 2: Code Flow Authorization Request
図2：コードフロー承認リクエスト
When the "resource" parameter is used on an access token request made to the token endpoint, for all grant types, it indicates the target service or protected resource where the client intends to use the requested access token.
トークンエンドポイントに対して行われたアクセストークンリクエストで「resource」パラメーターが使用される場合、すべての付与タイプで、クライアントがリクエストされたアクセストークンを使用する予定のターゲットサービスまたは保護されたリソースを示します。
The resource value(s) that is acceptable to an authorization server in fulfilling an access token request is at its sole discretion based on local policy or configuration. In the case of a "refresh_token" or "authorization_code" grant type request, such policy may limit the acceptable resources to those that were originally granted by the resource owner or a subset thereof. In the "authorization_code" case where the requested resources are a subset of the set of resources originally granted, the authorization server will issue an access token based on that subset of requested resources, whereas any refresh token that is returned is bound to the full original grant.
認可サーバーがアクセストークンリクエストを実行する際に許容できるリソース値は、ローカルのポリシーまたは構成に基づいて独自の裁量で決定されます。 「refresh_token」または「authorization_code」の付与タイプのリクエストの場合、そのようなポリシーは、受け入れ可能なリソースを、リソース所有者またはそのサブセットによって最初に付与されたリソースに制限する場合があります。リクエストされたリソースが最初に付与されたリソースセットのサブセットである「authorization_code」の場合、認可サーバーはリクエストされたリソースのそのサブセットに基づいてアクセストークンを発行しますが、返される更新トークンは元の完全なトークンにバインドされます付与。
When requesting a token, the client can indicate the desired target service(s) where it intends to use that token by way of the "resource" parameter and can indicate the desired scope of the requested token using the "scope" parameter. The semantics of such a request are that the client is asking for a token with the requested scope that is usable at all the requested target services. Effectively, the requested access rights of the token are the cartesian product of all the scopes at all the target services. To the extent possible, when issuing access tokens, the authorization server should downscope the scope value associated with an access token to the value the respective resource is able to process and needs to know. (Here, "downscope" means give fewer permissions than originally authorized by the resource owner.) This further improves privacy as a list of scope values is an indication that the resource owner uses the multiple various services listed; downscoping a token to only that which is needed for a particular service can limit the extent to which such information is revealed across different services. As specified in Section 5.1 of [RFC6749], the authorization server must indicate the access token's effective scope to the client in the "scope" response parameter value when it differs from the scope requested by the client.
トークンを要求するとき、クライアントは、「リソース」パラメーターを使用して、そのトークンを使用する予定の目的のターゲットサービスを示し、「スコープ」パラメーターを使用して、要求されたトークンの目的のスコープを示すことができます。このような要求のセマンティクスは、クライアントが、要求されたすべてのターゲットサービスで使用できる要求されたスコープを持つトークンを要求することです。事実上、トークンの要求されたアクセス権は、すべてのターゲットサービスのすべてのスコープのデカルト積です。可能な限り、アクセストークンを発行するとき、認証サーバーは、アクセストークンに関連付けられたスコープ値を、それぞれのリソースが処理でき、知る必要がある値にダウンスコープする必要があります。 （ここで、「downscope」は、リソース所有者によって最初に承認されたよりも少ないアクセス許可を与えることを意味します。）スコープ値のリストは、リソース所有者がリストされた複数のさまざまなサービスを使用していることを示すため、これによりプライバシーがさらに向上します。特定のサービスに必要なトークンのみにトークンをダウンスコープすると、そのような情報がさまざまなサービスにわたって公開される範囲を制限できます。 [RFC6749]のセクション5.1で指定されているように、認証サーバーは、クライアントからリクエストされたスコープと異なる場合、「スコープ」応答パラメータ値でクライアントにアクセストークンの有効なスコープを示す必要があります。
Following from the code flow authorization request shown in Figure 2, the below examples show an "authorization_code" grant type access token request (Figure 3) and response (Figure 4) where the client tells the authorization server that it wants the access token for use at "https://cal.example.com/" (extra line breaks and indentation are for display purposes only).
図2に示されているコードフロー承認リクエストに続く例は、「authorization_code」許可タイプのアクセストークンリクエスト（図3）とレスポンス（図4）を示し、クライアントが承認サーバーにアクセストークンを使用することを伝えます。 "https://cal.example.com/"（余分な改行とインデントは表示のみを目的としています）。
POST /as/token.oauth2 HTTP/1.1
Host: authorization-server.example.com
Authorization: Basic czZCaGRSa3F0Mzpoc3FFelFsVW9IQUU5cHg0RlNyNHlJ
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb &code=10esc29BWC2qZB0acc9v8zAv9ltc2pko105tQauZ &resource=https%3A%2F%2Fcal.example.com%2F
grant_type = authorization_code＆redirect_uri = https％3A％2F％2Fclient.example.org％2Fcb＆code = 10esc29BWC2qZB0acc9v8zAv9ltc2pko105tQauZ＆resource = https％3A％2F％2Fcal.example.com％2F
Figure 3: Access Token Request
図3：アクセストークンリクエスト
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-cache, no-store
{
"access_token":"eyJhbGciOiJFUzI1NiIsImtpZCI6Ijc3In0.eyJpc3MiOi
JodHRwOi8vYXV0aG9yaXphdGlvbi1zZXJ2ZXIuZXhhbXBsZS5jb20iLCJzdWI
iOiJfX2JfYyIsImV4cCI6MTU4ODQyMDgwMCwic2NvcGUiOiJjYWxlbmRhciIs
ImF1ZCI6Imh0dHBzOi8vY2FsLmV4YW1wbGUuY29tLyJ9.nNWJ2dXSxaDRdMUK
lzs-cYIj8MDoM6Gy7pf_sKrLGsAFf1C2bDhB60DQfW1DZL5npdko1_Mmk5sUf
zkiQNVpYw",
"token_type":"Bearer",
"expires_in":3600,
"refresh_token":"4LTC8lb0acc6Oy4esc1Nk9BWC0imAwH7kic16BDC2",
"scope":"calendar"
}
Figure 4: Access Token Response
図4：アクセストークンの応答
A subsequent access token request, using the refresh token, where the client tells the authorization server that it wants an access token for use at "https://contacts.example.com/" is shown in Figure 5 below with the response shown in Figure 6 (extra line breaks and indentation are for display purposes only).
次の図5に、クライアントが「https://contacts.example.com/」で使用するアクセストークンを要求することを承認サーバーに通知する、更新トークンを使用した後続のアクセストークンリクエストを示します。図6（余分な改行とインデントは表示のみを目的としています）。
POST /as/token.oauth2 HTTP/1.1
Host: authorization-server.example.com
Authorization: Basic czZCaGRSa3F0Mzpoc3FFelFsVW9IQUU5cHg0RlNyNHlJ
Content-Type: application/x-www-form-urlencoded
grant_type=refresh_token &refresh_token=4LTC8lb0acc6Oy4esc1Nk9BWC0imAwH7kic16BDC2 &resource=https%3A%2F%2Fcontacts.example.com%2F
grant_type = refresh_token＆refresh_token = 4LTC8lb0acc6Oy4esc1Nk9BWC0imAwH7kic16BDC2＆resource = https％3A％2F％2Fcontacts.example.com％2F
Figure 5: Access Token Request
図5：アクセストークン要求
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-cache, no-store
{
"access_token":"eyJhbGciOiJFUzI1NiIsImtpZCI6Ijc3In0.eyJpc3MiOi
JodHRwOi8vYXV0aG9yaXphdGlvbi1zZXJ2ZXIuZXhhbXBsZS5jb20iLCJzdWI
iOiJfX2JfYyIsImV4cCI6MTU4ODQyMDgyNiwic2NvcGUiOiJjb250YWN0cyIs
ImF1ZCI6Imh0dHBzOi8vY29udGFjdHMuZXhhbXBsZS5jb20vIn0.5f4yhqazc
OSlJw4y94KPeWNEFQqj2cfeO8x4hr3YbHtIl3nQXnBMw5wREY5O1YbZED-GfH
UowfmtNaA5EikYAw",
"token_type":"Bearer",
"expires_in":3600,
"scope":"contacts"
}
Figure 6: Access Token Response
図6：アクセストークンの応答
An audience-restricted access token that is legitimately presented to a resource cannot then be taken by that resource and presented elsewhere for illegitimate access to other resources. The "resource" parameter enables a client to indicate the protected resources where the requested access token will be used, which in turn enables the authorization server to apply the appropriate audience restrictions to the token.
リソースに正当に提示されたオーディエンス制限付きアクセストークンは、そのリソースによって取得され、他のリソースへの不正なアクセスのために他の場所に提示されることはありません。 「resource」パラメーターを使用すると、クライアントは、要求されたアクセストークンが使用される保護されたリソースを示すことができます。これにより、認証サーバーは適切な対象ユーザー制限をトークンに適用できます。
Some servers may host user content or be multi-tenant. In order to avoid attacks where one tenant uses an access token to illegitimately access resources owned by a different tenant, it is important to use a specific resource URI including any portion of the URI that identifies the tenant, such as a path component. This will allow access tokens to be audience-restricted in a way that identifies the tenant and prevents their use, due to an invalid audience, at resources owned by a different tenant.
一部のサーバーは、ユーザーコンテンツをホストするか、マルチテナントである場合があります。 1つのテナントがアクセストークンを使用して別のテナントが所有するリソースに不正にアクセスする攻撃を回避するには、パスコンポーネントなど、テナントを識別するURIの任意の部分を含む特定のリソースURIを使用することが重要です。これにより、テナントを識別し、オーディエンスが無効であるために別のテナントが所有するリソースでの使用を防ぐ方法で、アクセストークンをオーディエンスに制限できます。
Although multiple occurrences of the "resource" parameter may be included in a token request, using only a single "resource" parameter is encouraged. If a bearer token has multiple intended recipients (audiences), then the token is valid at more than one protected resource and can be used by any one of those resources to access any of the others. Thus, a high degree of trust between the involved parties is needed when using access tokens with multiple audiences. Furthermore, an authorization server may be unwilling or unable to fulfill a token request with multiple resources.
「resource」パラメーターの複数のオカレンスをトークン要求に含めることができますが、単一の「resource」パラメーターのみを使用することをお勧めします。ベアラートークンに複数の対象受信者（オーディエンス）がある場合、トークンは複数の保護リソースで有効であり、それらのリソースのいずれかが他のリソースにアクセスするために使用できます。したがって、複数の対象者でアクセストークンを使用する場合は、関係者間の高度な信頼が必要です。さらに、承認サーバーは、複数のリソースを使用してトークン要求を実行することを望まないか、実行できない場合があります。
Whenever feasible, the "resource" parameter should correspond to the network-addressable location of the protected resource. This makes it possible for the client to validate that the resource being requested controls the corresponding network location, reducing the risk of malicious endpoints obtaining tokens meant for other resources. If the "resource" parameter contains an abstract identifier, it is the client's responsibility to validate out of band that any network endpoint to which tokens are sent are the intended audience for that identifier.
可能な限り、「resource」パラメータは、保護されたリソースのネットワークでアドレス可能な場所に対応している必要があります。これにより、クライアントは、要求されているリソースが対応するネットワークの場所を制御していることを検証でき、悪意のあるエンドポイントが他のリソース用のトークンを取得するリスクを軽減できます。 「リソース」パラメータに抽象識別子が含まれている場合、トークンの送信先のネットワークエンドポイントがその識別子の対象ユーザーであることを帯域外で検証するのはクライアントの責任です。
In typical OAuth deployments the authorization sever is in a position to observe and track a significant amount of user and client behavior. It is largely just inherent to the nature of OAuth, and this document does little to affect that. In some cases, however, such as when access token introspection is not being used, use of the resource parameter defined herein may allow for tracking behavior at a somewhat more granular and specific level than would otherwise be possible in its absence.
典型的なOAuthデプロイメントでは、認証サーバーは、かなりの量のユーザーとクライアントの動作を監視および追跡する立場にあります。これは主にOAuthの本質に固有のものであり、このドキュメントはそれに影響を与えることはほとんどありません。ただし、アクセストークンイントロスペクションが使用されていない場合など、場合によっては、ここで定義されているリソースパラメータを使用すると、そうでない場合に可能であるよりも、より細かく特定のレベルで動作を追跡できる場合があります。
This specification updates the following value in the IANA "OAuth Parameters" registry [IANA.OAuth.Parameters] established by [RFC6749].
この仕様は、[RFC6749]によって確立されたIANA "OAuth Parameters"レジストリ[IANA.OAuth.Parameters]の次の値を更新します。
Parameter name: resource Parameter usage location: authorization request, token request Change controller: IESG Specification document(s): RFC 8707
パラメーター名：リソースパラメーターの使用場所：承認要求、トークン要求変更コントローラー：IESG仕様書：RFC 8707
This specification updates the following error in the IANA "OAuth Extensions Error Registry" [IANA.OAuth.Parameters] established by [RFC6749].
この仕様は、[RFC6749]によって確立されたIANA "OAuth Extensions Error Registry" [IANA.OAuth.Parameters]の次のエラーを更新します。
Error name: invalid_target Error usage location: implicit grant error response, token error response Related protocol extension: resource parameter Change controller: IESG Specification document(s): RFC 8707
エラー名：invalid_targetエラー使用場所：暗黙の付与エラー応答、トークンエラー応答関連プロトコル拡張：リソースパラメーター変更コントローラー：IESG仕様ドキュメント：RFC 8707
[IANA.OAuth.Parameters] IANA, "OAuth Parameters", <https://www.iana.org/assignments/oauth-parameters>.
[IANA.OAuth.Parameters] IANA、「OAuthパラメータ」、<https://www.iana.org/assignments/oauth-parameters>。
[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>。
[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, <https://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月、<https：/ /www.rfc-editor.org/info/rfc3986>。
[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] Hardt、D。、編、「The OAuth 2.0 Authorization Framework」、RFC 6749、DOI 10.17487 / RFC6749、2012年10月、<https://www.rfc-editor.org/info/rfc6749>。
[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>。
[JWT-SAR] Sakimura, N. and J. Bradley, "The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR)", Work in Progress, Internet-Draft, draft-ietf-oauth-jwsreq-20, 21 October 2019, <https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20>.
[JWT-SAR]崎村直人、J。ブラッドリー、「OAuth 2.0 Authorization Framework：JWT Secured Authorization Request（JAR）」、Work in Progress、Internet-Draft、draft-ietf-oauth-jwsreq-20、10月21日2019、<https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20>。
[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]ジョーンズ、M。およびD.ハート、「OAuth 2.0 Authorization Framework：Bearer Token Usage」、RFC 6750、DOI 10.17487 / RFC6750、2012年10月、<https://www.rfc-editor.org/info/ rfc6750>。
[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。、ブラッドリー、J.、N。崎村、「JSON Web Token（JWT）」、RFC 7519、DOI 10.17487 / RFC7519、2015年5月、<https://www.rfc-editor.org / info / rfc7519>。
[RFC7644] Hunt, P., Ed., Grizzle, K., Ansari, M., Wahlstroem, E., and C. Mortimore, "System for Cross-domain Identity Management: Protocol", RFC 7644, DOI 10.17487/RFC7644, September 2015, <https://www.rfc-editor.org/info/rfc7644>.
[RFC7644] Hunt、P。、編、Grizzle、K.、Ansari、M.、Wahlstroem、E。、およびC. Mortimore、「クロスドメインID管理：プロトコル」、RFC 7644、DOI 10.17487 / RFC7644 、2015年9月、<https://www.rfc-editor.org/info/rfc7644>。
[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。、編、「OAuth 2.0トークンイントロスペクション」、RFC 7662、DOI 10.17487 / RFC7662、2015年10月、<https://www.rfc-editor.org/info/rfc7662>。
Acknowledgements
謝辞
This specification was developed within the OAuth Working Group under the chairmanship of Hannes Tschofenig and Rifaat Shekh-Yusef with Eric Rescorla, Benjamin Kaduk, and Roman Danyliw serving as Security Area Directors. Additionally, the following individuals contributed ideas, feedback, and wording that helped shape this specification:
この仕様は、Hanes TschofenigとRifaat Shekh-Yusefの議長の下、OAuthワーキンググループ内で開発されました。EricRescorla、Benjamin Kaduk、Roman Danyliwがセキュリティエリアディレクターを務めています。さらに、次の個人がこの仕様を形作るのに役立つアイデア、フィードバック、および表現を提供しました。
Vittorio Bertocci, Sergey Beryozkin, Roman Danyliw, William Denniss, Vladimir Dzhuvinov, George Fletcher, Dick Hardt, Phil Hunt, Michael Jones, Benjamin Kaduk, Barry Leiba, Torsten Lodderstedt, Anthony Nadalin, Justin Richer, Adam Roach, Nat Sakimura, Rifaat Shekh-Yusef, Filip Skokan, Éric Vyncke, and Hans Zandbelt.
ヴィットリオベルトッチ、セルゲイベリョーキン、ローマンダニーリウ、ウィリアムデニス、ウラジミールズビノフ、ジョージフレッチャー、ディックハード、フィルハント、マイケルジョーンズ、ベンジャミンカドゥック、バリーレイバ、トルステンロダーステッド、アンソニーナダリン、ジャスティンリチャー、アダムローチ、ナトサック-Yusef、Filip Skokan、ÉricVyncke、Hans Zandbelt。
Authors' Addresses
著者のアドレス
Brian Campbell Ping Identity
ブライアンキャンベルピンアイデンティティ
Email: brian.d.campbell@gmail.com
John Bradley Yubico
ジョンブラッドリーユビコ
Email: ve7jtb@ve7jtb.com
Hannes Tschofenig Arm Limited
Hannes Tschofenig Arm Limited
Email: hannes.tschofenig@gmx.net