| Internet-Draft | Additional Hashes for OAuth PoP and PKCE | February 2026 |
| Skokan | Expires 30 August 2026 | [Page] |
This document defines SHA-384 as an additional hash algorithm option for OAuth 2.0 Proof Key for Code Exchange (PKCE), Demonstrating Proof of Possession (DPoP), and mutual-TLS certificate-bound access tokens. These mechanisms currently mandate the use of SHA-256.¶
This note is to be removed before publishing as an RFC.¶
Status information for this document may be found at https://datatracker.ietf.org/doc/draft-skokan-oauth-additional-hashes/.¶
Source for this draft and an issue tracker can be found at https://github.com/panva/draft-oauth-additional-hashes.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 30 August 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Several OAuth 2.0 mechanisms exclusively mandate the use of SHA-256: Proof Key for Code Exchange (PKCE) [RFC7636], Demonstrating Proof of Possession (DPoP) [RFC9449], and mutual-TLS certificate-bound access tokens [RFC8705].¶
Security policies, such as the US Commercial National Security Algorithm (CNSA 2.0) Suite [cnsafaq], prohibit the use of SHA-256 and mandate SHA-384 as the minimum acceptable hash algorithm. This prevents the deployment of these OAuth 2.0 mechanisms in such environments.¶
This document addresses this gap by defining SHA-384 alternatives
for each of these mechanisms. For PKCE, a new S384 code challenge
method is defined. For mutual-TLS certificate-bound access tokens,
a new x5t#S384 confirmation method is defined. For DPoP, this
document defines SHA-384 alternatives for the JWK Thumbprint
confirmation method (jkt#S384) and the access token hash claim
(ath#S384), as well as an extensible framework for DPoP
authorization code binding and access token hash algorithm
negotiation.¶
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.¶
All references to "CNSA 2.0" in this document refer to CNSA 2.0 [cnsafaq], unless stated otherwise.¶
This document defines a new code challenge method for use with PKCE [RFC7636]. The client creates a code challenge derived from the code verifier by using the following transformation on the code verifier:¶
code_challenge = BASE64URL(SHA-384(ASCII(code_verifier)))¶
The server-side verification of the code verifier follows Section 4.6 of [RFC7636], using SHA-384 as the hash algorithm.¶
An Authorization Server that supports the S384 code challenge
method MUST advertise its support by including S384 in the
code_challenge_methods_supported metadata parameter value, as
defined in OAuth 2.0 Authorization Server Metadata [RFC8414] or
OpenID Connect Discovery 1.0 [OpenID.Discovery].¶
A Client intending to use the S384 code challenge method MUST
first confirm that the Authorization Server supports it by checking
the code_challenge_methods_supported metadata value. A Client MUST NOT use the S384 code challenge method if the Authorization Server
does not advertise support for it.¶
RFC 9449 [RFC9449] defines the jkt confirmation method member
for binding access tokens to a DPoP public key using a SHA-256
JWK Thumbprint [RFC7638].¶
This document defines an analogous confirmation method member
jkt#S384 that uses SHA-384 as the hash algorithm:¶
The value is the base64url encoding of the JWK Thumbprint [RFC7638] computed using SHA-384 of the DPoP public key (in JWK format) to which the access token is bound.¶
When using jkt#S384, the Authorization Server computes the
SHA-384 JWK Thumbprint of the DPoP public key and includes the
result as the jkt#S384 member of the cnf claim in the access
token (for JWT access tokens) or associates it with the token
for later retrieval via token introspection.¶
The Resource Server MUST compute the SHA-384 JWK Thumbprint of
the DPoP public key and compare it with the jkt#S384 value in
the cnf claim. If the values do not match, the Resource Server
MUST reject the request.¶
The choice of jkt#S384 over jkt is a deployment decision
based on the Resource Server configuration at the Authorization
Server.¶
RFC 9449 [RFC9449] defines the ath claim in the DPoP proof JWT
as the base64url-encoded SHA-256 hash of the ASCII encoding of the
access token value.¶
This document defines an analogous claim ath#S384 that uses
SHA-384 as the hash algorithm:¶
The value is the base64url encoding of the SHA-384 hash of the ASCII encoding of the associated access token's value.¶
When used, ath#S384 is included in the DPoP proof JWT in place
of ath.¶
A Client that used a dpop_jkt_method value of S384 during the
authorization request MUST use ath#S384 in DPoP proofs sent to
Resource Servers.¶
A Resource Server MAY signal the required access token hash method
by including the ath_method parameter in the WWW-Authenticate:
DPoP challenge. The value of ath_method is the name of the claim
the Client MUST use: ath for SHA-256 or ath#S384 for SHA-384.
When ath_method is absent, the Client MUST use ath.¶
This document defines the dpop_ath_methods_supported Resource
Server metadata parameter [RFC9728]. Its value is a JSON array
containing the access token hash claim names that the Resource
Server supports. Defined values are ath and ath#S384.¶
When this metadata parameter is absent, the Client MUST assume
that the Resource Server supports only ath.¶
RFC 8705 [RFC8705] defines the x5t#S256 confirmation method
member for binding access tokens to a client certificate using a
SHA-256 hash of the DER-encoded X.509 certificate.¶
This document defines an analogous confirmation method member
x5t#S384 that uses SHA-384 as the hash algorithm:¶
The value is a base64url-encoded SHA-384 hash of the DER encoding of the X.509 certificate.¶
When using x5t#S384, the Authorization Server computes the
SHA-384 hash of the client certificate presented during mutual-TLS
and includes the result as the x5t#S384 member of the cnf
claim in the access token (for JWT access tokens) or associates
it with the token for later retrieval via token introspection.¶
The Resource Server MUST compute the SHA-384 hash of the client
certificate presented during mutual-TLS and compare it with the
x5t#S384 value in the cnf claim. If the values do not match,
the Resource Server MUST reject the request.¶
The choice of x5t#S384 over x5t#S256 is a deployment decision
based on the Resource Server configuration at the Authorization
Server.¶
The S384 code challenge method provides the same structural
security properties as S256. It is a one-way transformation of
the code verifier that prevents an attacker who intercepts the
authorization code from computing the code verifier needed to exchange
it for tokens.¶
The jkt#S384 confirmation method, dpop_jkt_method parameter,
and ath#S384 claim provide the same structural security properties
as their SHA-256 counterparts defined in DPoP [RFC9449]. The
authorization code binding via dpop_jkt and the access token
binding via ath remain intact regardless of the hash algorithm
used.¶
SHA-384 provides a 192-bit collision resistance and 384-bit preimage resistance, exceeding the 128-bit and 256-bit levels provided by SHA-256. The use of SHA-384 is suitable for deployments with elevated security requirements.¶
Deployments that do not have specific requirements mandating SHA-384 do not need to migrate away from the established SHA-256 based mechanisms.¶
This document requests registration of the following value in the "PKCE Code Challenge Methods" registry established by Section 6.2 of [RFC7636]:¶
S384¶
IETF¶
Section 3.1 of this document¶
This document establishes the "DPoP Authorization Code Binding
Methods" registry for dpop_jkt_method values.¶
New entries are registered using the Specification Required policy [RFC5226].¶
The initial contents of the registry are:¶
S256¶
IETF¶
Section 10 of [RFC9449]¶
S384¶
IETF¶
Section 4.1 of this document¶
This document requests registration of the following value in the "OAuth Parameters" registry established by [RFC6749]:¶
dpop_jkt_method¶
authorization request¶
IETF¶
Section 4.1 of this document¶
This document requests registration of the following value in the "JSON Web Token Claims" registry established by [RFC7519]:¶
ath#S384¶
The base64url-encoded SHA-384 hash of the ASCII encoding of the associated access token's value¶
IETF¶
Section 5.2 of this document¶
This document requests registration of the following value in the "OAuth Protected Resource Metadata" registry established by [RFC9728]:¶
dpop_ath_methods_supported¶
JSON array containing a list of the access token hash claim names supported by the Resource Server¶
IETF¶
Section 5.3 of this document¶
This document requests registration of the following values in the "JWT Confirmation Methods" registry established by [RFC7800]:¶
x5t#S384¶
X.509 Certificate SHA-384 Thumbprint¶
IETF¶
Section 6.1 of this document¶
jkt#S384¶
JWK SHA-384 Thumbprint¶
IETF¶
Section 5.1 of this document¶
TODO acknowledge.¶