]> AWS

Canada jeffsec@amazon.com

IndyKite

Canada alex.babeanu@indykite.com

Web Authorization Protocol security trust This specification defines new claims for JWT profiled access tokens so that resource providers can benefit from more granular information about the client to make better informed access decisions. The proposed new claims include: the client authentication methods, the client OAuth grant flow used as well as the OAuth grant flow extensions used as part of the issuance of the associated tokens. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Web Authorization Protocol mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Resource providers need information about the subject, the action, the resource, and the context involved in the request in order to be able to determine properly if a resource can be disclosed. This decision may also involve the help of a Policy Decision Point (PDP). When accessed with a JWT profiled OAuth2 Access Token presented as a bearer token , a Resource Server (RS) receives information about the subject as claims, such as: - The subject, sub, - Any user profile claim set by the Authorization Server if applicable, - Authenticaton Information claims like the user class of authentication (acrclaim) or user methord of authentication (claim amr ) - Any Authorization Information if applicable On the other hand, the RS has very little information about the client, often only a client_id claim. In particular, the RS lacks any insight about the type of authorization grant flow that the client itself went through, the level of assurance that the client itself may have reached during its own authentication, and in general, lacks any information that would enable it to determine if the client itself can be trusted at all. This document defines 4 new claims for the JWT profile of OAuth access tokens, which describe in detail the interaction between the OAuth client and the Authorization Server (AS) during the flow that resulted in the issuance of the token. The process by which the client interacts with the authorization server is out of scope.

Conventions and Definitions 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 when, and only when, they appear in all capitals, as shown here.

JWT access token:

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

This specification uses the terms "access token", "authorization server", "authorization endpoint", "authorization request", "client", "protected resource", and "resource server" defined by "The OAuth 2.0 Authorization Framework" .

JWT Access Token Client Extensions Data Structure The following claims extend the access token payload data structure:

Client Flow Information Claims The claims listed below reflect the grant type and extensions used by the OAuth client with the Authorization Server during the authorization request. Their values are generated dynamically and consistent across all the tokens generated for the given authorization request.

gty:

REQUIRED - a string that describes the OAuth2 authorization grant type the client requested for the issuance of the access token. The value used as the gty claim MUST comply to existing grant flows described in the following specifications: section 1.3 of , section 2. of , section 2.1 of , and section 4 of . Furthermore since future grants may also be developped, this claim is not limited to existing flows, but should also encompass future innovations. The possible values of this claim are registered with IANA (see below). Non-normative example value: "client_credentials".

cxt:

REQUIRED - defines the list of extensions the client used in conjonction with the OAuth2 authorization grant type used for the issuance of the access token. For example but not limited to: Proof Key for Code Exchange by OAuth Public Clients (or PKCE) as defined in , Demonstrating Proof of Possession (or DPoP) as defined in . The claim value is an array of strings that lists the identifiers of extensions used. Values used in the cxt Claim MUST be valid values registered with the IANA OAuth Parameters registry @TODO. These values reference, without being limited to, values established through section 2 of , and Section 5.1 of . Non-normative example: "[dpop,pkce]".

Client Authentication Information Claims The claims listed in this section MAY be issued and reflect strength of the mechanism used to authenticate the OAuth2 Client client itself as part of the access token issuance flow. 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 obtaining a new access token using a refresh token. Those values may change if an access token is exchanged for another through the Token Exchange procedure, in that case these claims will reflect the details of this new request.

ccr:

OPTIONAL - refers to the authentication context class that the Oauth client achieved with the AS during the authorization flow. The value of this claim must be an absolute URI that can be registered with IANA. It should support present, future or custom values. If IANA registered URIs are used, then their meaning and semantics should be respected and used as defined in the registry. Parties using this custom claim values need to agree upon the semantics of the values used, which may be context specific. Non-normative example: "urn:org:iana:client:assurance:level_1".

cmr:

OPTIONAL - an Identifier String that defines the authentication methods the client used when authenticating to the authorization server. The claim may indicate the usage of private JWT as defined in and or HTTP message signature as defined in , or simple client secret as defined in . The cmr value is a case-sensitive string, which values SHOULD be registered with the IANA OAuth Token Endpoint Authentication Methods Values registry defined by ; parties using this claim will need to agree upon the meanings of any unregistered values used, which may be context specific.

Authorization Server Metadata Not all Authorizartion Servers (AS) may support the claims described in this specification. It is therefore necessary to provide a way for an OAuth Resource Server to determine whether it can rely on the claims described here. This document therefore extends the OAuth2.0 Authorization Server Metadata specification by adding the following metadata value :

support_client_extentison_claims:

Boolean parameter indicating whether the authorization server will return the extension claims described in this RFC.

Note that the non presence of support_client_extentison_claims is sufficient for the client to determine that the server is not capable and therefore will not return the extension claimns described in this RFC. This ensures backward compatibility with all existing AS implementations.

Requesting a JWT Access Token with Client Extensions An authorization server supporting the claims described in this document MUST issue a JWT access token with client extensions claims described in this RFC in response to any authorization grant defined by , as well as subsequent extensions meant to result in an access token.

Validating JWT Access Tokens with Client Extensions This specification does not change any of the requirements for validating access tokens, as defined in section 4 of the JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens specification .

Security Considerations The JWT access token data layout described here is the same as the struture of the JWT access token as defined by the JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens specification . The Best Current Practice for OAuth 2.0 Security is still applicable.

IANA Considerations

OAuth Grant Type Registration This specification registers the following grant type in the OAuth Grant Type registry.

authorization_code grant type

Type name:

authorization_code

Change controller:

IETF

Specification document(s):

section 2. of

implicit grant type

Type name:

implicit

Change controller:

IETF

Specification document(s):

section 2. of

password grant type

Type name:

password

Change controller:

IETF

Specification document(s):

section 2. of

client_credentials grant type

Type name:

client_credentials

Change controller:

IETF

Specification document(s):

section 2. of

refresh_token grant type

Type name:

refresh_token

Change controller:

IETF

Specification document(s):

section 2. of

jwt-bearer grant type

Type name:

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

Change controller:

IETF

Specification document(s):

section 2. of and section 6 of

saml2-bearer grant type

Type name:

urn:ietf:params:oauth:grant-type:saml2-bearer

Change controller:

IETF

Specification document(s):

section 2. of

token-exchange grant type

Type name:

urn:ietf:params:oauth:grant-type:token-exchange

Change controller:

IETF

Specification document(s):

section 2.1. of

device_code grant type

Type name:

urn:ietf:params:oauth:grant-type:device_code

Change controller:

IETF

Specification document(s):

section 3.4. of

ciba grant type

Type name:

urn:openid:params:grant-type:ciba

Change controller:

IETF

Specification document(s):

section 4. of

OAuth Grant Extension Type Registration This specification registers the following grant extension type in the OAuth Grant Extension Type registry.

pkce grant extension type

Type name:

pkce

Change controller:

IETF

Specification document(s):

This RFC as a reference to

dpop grant extension type

Type name:

dpop

Change controller:

IETF

Specification document(s):

This RFC as a reference to

wpt grant extension type

Type name:

wpt

Change controller:

IETF

Specification document(s):

This RFC as a reference to section 4.2 of

rar grant extension type

Type name:

rar

Change controller:

IETF

Specification document(s):

This RFC as a reference to

par grant extension type

Type name:

par

Change controller:

IETF

Specification document(s):

This RFC as a reference to

jar grant extension type

Type name:

jar

Change controller:

IETF

Specification document(s):

This RFC as a reference to

OAuth Token Endpoint Authentication Methods Registration This specification registers additional token endpoint authentication methods in the OAuth Token Endpoint Authentication Methods registry.

jwt-bearer token endpoint authentication method

Type name:

jwt-bearer

Change controller:

IETF

Specification document(s):

This RFC as a reference to and

jwt-svid token endpoint authentication method

Type name:

jwt-svid

Change controller:

IETF

Specification document(s):

This RFC as a reference to SPIFFE JWT-SVID

wit token endpoint authentication method

Type name:

wit

Change controller:

IETF

Specification document(s):

This RFC as a reference to

txn_token token endpoint authentication method

Type name:

txn_token

Change controller:

IETF

Specification document(s):

This RFC as a reference to

Claims Registration Section X.Y of this specification refers to the attributes gty, cxt, ccr, and cmr to express client metadata JWT access tokens. This section registers those attributes as claims in the registry introduced in .

gty claim definition

Claim Name:

gty

Claim Description:

OAuth2 Grant Type used

Change Controller:

IETF

Specification Document(s): Section X.Y of this document

cxt claim definition

Claim Name:

cxt

Claim Description:

Client Extensions used on top of the OAuth2 Grant Type

Change Controller:

IETF

Specification Document(s):

Section X.Y of this document

ccr claim definition

Claim Name:

ccr

Claim Description:

Client Authentication Class Reference

Change Controller:

IETF

Specification Document(s):

Section X.Y of this document

cmr claim definition

Claim Name:

cmr

Claim Description:

Client Authentication Methods Reference

Change Controller:

IETF

Specification Document(s):

Section X.Y of this document

References Normative References The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK] JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. 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. This specification defines mechanisms for dynamically registering OAuth 2.0 clients with authorization servers. Registration requests send a set of desired client metadata values to the authorization server. The resulting registration responses return a client identifier to use at the authorization server and the client metadata values registered for the client. The client can then use this registration information to communicate with the authorization server using the OAuth 2.0 protocol. This specification also defines a set of common client metadata fields and values for clients to use during registration. This specification defines a protocol for an HTTP- and JSON-based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation. The OAuth 2.0 device authorization grant is designed for Internet- connected devices that either lack a browser to perform a user-agent- based authorization or are input constrained to the extent that requiring the user to input text in order to authenticate during the authorization flow is impractical. It enables OAuth clients on such devices (like smart TVs, media consoles, digital picture frames, and printers) to obtain user authorization to access protected resources by using a user agent on a separate device. This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities. IANA In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport. [STANDARDS-TRACK] This specification provides a framework for the use of assertions with OAuth 2.0 in the form of a new client authentication mechanism and a new authorization grant type. Mechanisms are specified for transporting assertions during interactions with a token endpoint; general processing rules are also specified. The intent of this specification is to provide a common framework for OAuth 2.0 to interwork with other identity systems using assertions and to provide alternative client authentication mechanisms. Note that this specification only defines abstract message flows and processing rules. In order to be implementable, companion specifications are necessary to provide the corresponding concrete instantiations. 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. The "amr" (Authentication Methods References) claim is defined and registered in the IANA "JSON Web Token Claims" registry, but no standard Authentication Method Reference values are currently defined. This specification establishes a registry for Authentication Method Reference values and defines an initial set of Authentication Method Reference values. OAuth 2.0 public clients utilizing the Authorization Code Grant are susceptible to the authorization code interception attack. This specification describes the attack as well as a technique to mitigate against the threat through the use of Proof Key for Code Exchange (PKCE, pronounced "pixy"). This document specifies a new parameter authorization_details that is used to carry fine-grained authorization data in OAuth messages. This document defines the pushed authorization request (PAR) endpoint, which allows clients to push the payload of an OAuth 2.0 authorization request to the authorization server via a direct request and provides them with a request URI that is used as reference to the data in a subsequent call to the authorization endpoint. The authorization request in OAuth 2.0 described in RFC 6749 utilizes query parameter serialization, which means that authorization request parameters are encoded in the URI of the request and sent through user agents such as web browsers. While it is easy to implement, it means that a) the communication through the user agents is not integrity protected and thus, the parameters can be tainted, b) the source of the communication is not authenticated, and c) the communication through the user agents can be monitored. Because of these weaknesses, several attacks to the protocol have now been put forward. This document introduces the ability to send request parameters in a JSON Web Token (JWT) instead, which allows the request to be signed with JSON Web Signature (JWS) and encrypted with JSON Web Encryption (JWE) so that the integrity, source authentication, and confidentiality properties of the authorization request are attained. The request can be sent by value or by reference. This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens. This document describes OAuth client authentication and certificate-bound access and refresh tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization server using mutual TLS, based on either self-signed certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client's mutual-TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token. This document describes a mechanism for creating, encoding, and verifying digital signatures or message authentication codes over components of an HTTP message. This mechanism supports use cases where the full HTTP message may not be known to the signer and where the message may be transformed (e.g., by intermediaries) before reaching the verifier. This document also describes a means for requesting that a signature be applied to a subsequent HTTP message in an ongoing HTTP exchange. This document describes best current security practice for OAuth 2.0. It updates and extends the threat model and security advice given in RFCs 6749, 6750, and 6819 to incorporate practical experiences gathered since OAuth 2.0 was published and covers new threats relevant due to the broader application of OAuth 2.0. Further, it deprecates some modes of operation that are deemed less secure or even insecure. Okta Independent This specification provides a mechanism for an application to use an identity assertion to obtain an access token for a third-party API using Token Exchange [RFC8693] and JWT Profile for OAuth 2.0 Authorization Grants [RFC7523]. Ping Identity Venafi SPIRL Intuit The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from the most basic ones up to complex multi-service, multi-cloud, multi- tenant deployments. This document defines the simplest, atomic unit of this architecture: the protocol between two workloads that need to verify each other's identity in order to communicate securely. The scope of this protocol is a single HTTP request-and-response pair. To address the needs of different setups, we propose two protocols, one at the application level and one that makes use of trusted TLS transport. These two protocols are compatible, in the sense that a single call chain can have some calls use one protocol and some use the other. Workload A can call Workload B with mutual TLS authentication, while the next call from Workload B to Workload C would be authenticated at the application level. SGNL Capital One SPIRL Transaction Tokens (Txn-Tokens) enable workloads in a trusted domain to ensure that user identity and authorization context of an external programmatic request, such as an API invocation, are preserved and available to all workloads that are invoked as part of processing such a request. Txn-Tokens also enable workloads within the trusted domain to initiate transactions with protected user identity an authorization context throughout the call chain of the workloads required to complete the request. IANA IANA

Acknowledgments TODO acknowledge.