]>

emelia@brandedcode.com https://thisismissem.social

Security Web Authorization Protocol oauth This specification defines a new OAuth 2.0 Authorization Server Metadata parameter, dpop_bound_access_tokens_required, which allows an authorization server to indicate that it always issues DPoP-bound access tokens and requires DPoP for all requests made to it to obtain access tokens, including pushed authorization requests. This complements the metadata parameter of the same name defined in OAuth 2.0 Protected Resource Metadata. 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 Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction An OAuth 2.0 client can determine from the dpop_signing_alg_values_supported authorization server metadata parameter () whether an authorization server supports DPoP, but not whether the authorization server requires it. Without this information, a client can only discover that DPoP is required by sending a request without DPoP, receiving an error, and retrying the request with DPoP. does not define a specific error for a request that is missing a required DPoP proof, so the client cannot reliably distinguish this case from other failures. Additionally, a client that does not support DPoP has no way to determine in advance that it cannot complete an authorization flow with the authorization server, and may only discover this after the user has completed the authorization request. OAuth 2.0 Protected Resource Metadata registered a dpop_bound_access_tokens_required parameter in the IANA "OAuth Protected Resource Metadata" registry established by that specification; however, no similar parameter was added to the "OAuth Authorization Server Metadata" registry established by OAuth 2.0 Authorization Server Metadata . This specification defines that metadata parameter for authorization servers.

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.

Authorization Server Metadata The metadata parameter dpop_bound_access_tokens_required is an optional Boolean value specifying whether the authorization server always issues DPoP-bound access tokens , and requires DPoP for all requests made to it to obtain access tokens. The default value is false. If the metadata parameter dpop_bound_access_tokens_required is true:

• the authorization server MUST NOT issue access tokens that are not DPoP-bound, and MUST reject token requests that do not include a DPoP proof ().
• the authorization server MUST also publish the dpop_signing_alg_values_supported metadata parameter ().
• the client MUST include a DPoP proof in token requests ().
• if the client uses pushed authorization requests , including when the authorization server requires them (require_pushed_authorization_requests, ), the client MUST bind them to a DPoP key (), and the authorization server MUST reject pushed authorization requests that are not bound to a DPoP key.

A client that does not support DPoP SHOULD NOT initiate an authorization request with an authorization server that advertises a value of true. This metadata parameter applies to all clients of the authorization server. A requirement that a specific client always uses DPoP is instead expressed using the dpop_bound_access_tokens client metadata parameter (). Unlike the metadata parameter of the same name for protected resources , which indicates that a protected resource only accepts DPoP-bound access tokens, this metadata parameter also covers the requests a client makes to the authorization server to obtain access tokens. Since access tokens issued by such an authorization server are DPoP-bound, clients present them using the DPoP authentication scheme (). As a result, these access tokens can only be used with resource servers that support DPoP; a resource server that does not support DPoP will reject such requests.

Example The following is a non-normative example of authorization server metadata that includes the dpop_bound_access_tokens_required metadata parameter:

Security Considerations The security considerations of apply to this specification. The dpop_bound_access_tokens_required parameter informs clients of the authorization server's requirements; it does not enforce them. Requests from clients that ignore or do not retrieve the authorization server metadata are rejected by the authorization server, as described in . A DPoP-bound access token only provides protection against token replay if the resource server verifies the binding. An attacker that obtains a DPoP-bound access token may attempt to present it using the Bearer authentication scheme to a resource server that does not verify the cnf claim of the access token. Resource servers that support both the Bearer and DPoP authentication schemes need to reject DPoP-bound access tokens presented using the Bearer authentication scheme, as described in Section 7.2 of . This specification does not change those requirements.

IANA Considerations

OAuth Authorization Server Metadata Registry The following authorization server metadata value is defined by this specification and registered in the IANA "OAuth Authorization Server Metadata" registry established in OAuth 2.0 Authorization Server Metadata .

• Metadata Name: dpop_bound_access_tokens_required
• Metadata Description: Boolean value specifying whether the authorization server always issues DPoP-bound access tokens and requires DPoP for all requests to its pushed authorization request endpoint and token endpoint
• Change Controller: IETF
• Specification Document: This document

References Normative References 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. 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. 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. 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 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] This specification defines a metadata format that an OAuth 2.0 client or authorization server can use to obtain the information needed to interact with an OAuth 2.0 protected resource.

Acknowledgments The author would like to thank Max Gerber (Twilio) for identifying the gap in OAuth Authorization Server Metadata that this document addresses.

Document History (This appendix to be deleted by the RFC editor in the final specification.)

-00 Initial draft