X.509 Certificate Bearer Profile for OAuth 2.0 Client Authentication and Authorization Grants

Status of This Memo

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 6 March 2027.¶

Copyright Notice

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

Table of Contents

1. Introduction

JSON Web Token (JWT) [RFC7523] and Security Assertion Markup Language (SAML) 2.0 [RFC7522] bearer assertion profiles allow a client that already holds a security token, issued by a trusted party, to present that token directly to an OAuth 2.0 [RFC6749] authorization server (AS) -- either as an authorization grant or as a client authentication mechanism -- without minting a purpose-built, single-use assertion for every request. This specification is motivated primarily by workload identity systems: infrastructure that automatically issues and rotates short-lived X.509 certificates [RFC5280] to software workloads -- services, processes, or automated agents, as distinct from human end users -- as their means of cryptographic identity, typically as part of a service mesh or zero-trust network architecture. SPIFFE and its SPIRE runtime [SPIFFE-X509-SVID] and Athenz [ATHENZ-X509] are two examples of such systems in current production use; both issue workloads an X.509 certificate carrying a URI Subject Alternative Name (SAN), commonly using the "spiffe://" URI scheme, as the workload's primary identifier (see Section 1.2). A workload that already holds such a certificate, and that already uses it to authenticate over mutual TLS to its peers, benefits from being able to use that same certificate and trust relationship directly with an OAuth 2.0 authorization server, instead of provisioning and operating a separate JWT issuer solely to obtain OAuth tokens. This specification is not limited to workload identity deployments, but they are its primary motivating use case, and are referenced throughout as running examples.¶

This specification profiles the OAuth Assertion Framework [RFC7521] to define an extension grant type that uses an X.509 certificate to request an OAuth 2.0 access token, as well as for use as a client authentication credential. The format and processing rules defined here are intentionally similar, though not identical, to those in [RFC7523] and [RFC7522]; the differences arise from the structure and semantics of X.509 certificates, which were designed to bind a public key to a subject identity for use across many contexts and over comparatively long lifetimes, and not to express single-transaction claims such as an intended audience or an issuance time for one specific request.¶

This specification is related to, but distinct from, "OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens" [RFC8705]. RFC 8705 authenticates a client using the certificate presented during the TLS handshake with the authorization server itself, and does not define a way to use a certificate as an authorization grant. This specification instead carries a reference to (or, when necessary, a copy of) an X.509 certificate as an assertion value within the token request, which allows the same underlying PKI-issued identity to also be used as an authorization grant, and accommodates deployments in which TLS is terminated in front of the authorization server's application logic (for example, by a load balancer or reverse proxy) and the verified client certificate is forwarded to the token endpoint by a trusted intermediary. Because a certificate, unlike a private key, is not itself a secret, Section 3 of this document requires that proof of possession of the associated private key be corroborated by one of these mechanisms as part of processing every request; see also Section 6 (Security Considerations). Once a grant has been obtained or a client authenticated under this profile, Section 3.3 recommends carrying that same proof-of-possession property forward into the issued access token by reusing RFC 8705's certificate-bound access token mechanism, so that PKI possession is required consistently across the whole exchange rather than only at the token endpoint.¶

The process by which the client obtains its X.509 certificate, prior to using it with the authorization server, is out of scope of this document.¶

2. HTTP Parameter Bindings for Transporting X.509 Certificate Assertions

The OAuth Assertion Framework [RFC7521] defines generic HTTP parameters for transporting assertions (a.k.a. security tokens) during interactions with a token endpoint. This section defines specific parameters and treatments of those parameters for use with X.509 Bearer Certificates.¶

POST /token.oauth2 HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ax509-bearer
&assertion=MIIDXTCCAkWgAwIBAgIJAKrX1234abcd
[...omitted for brevity...]

POST /token.oauth2 HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&
code=n0esc3NRze7LTCu7iYzS6a5acc3f0ogp4&
client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3A
client-assertion-type%3Ax509-bearer&
client_assertion=MIIDXTCCAkWgAwIBAgIJAKrX1234abcd
[...omitted for brevity...]

POST /token.oauth2 HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&
code=n0esc3NRze7LTCu7iYzS6a5acc3f0ogp4&
client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3A
client-assertion-type%3Ax509-bearer&
client_assertion=x5t%23S256%3AkOpPSFiF3aL3tqsXOu72sHNitAB75QQLs6R81Q
_yX6g

3. X.509 Certificate Format and Processing Requirements

In order to issue an access token response as described in OAuth 2.0 [RFC6749] or to rely on an X.509 certificate for client authentication, the authorization server MUST validate the certificate and the request according to the criteria below. Throughout this section, "the certificate" refers to the X.509 certificate conveyed by the "assertion" or "client_assertion" value, whether encoded directly as described in Section 2.1 and Section 2.2 or identified by a thumbprint reference as described in Section 2.3. Application of additional restrictions and policy are at the discretion of the authorization server.¶

1. The certificate MUST be well-formed and valid under [RFC5280], MUST chain to a trust anchor configured at the authorization server (either directly or via a configured set of intermediate CA certificates), and MUST NOT be revoked, as determined per the authorization server's configured revocation-checking mechanism (for example, CRLs or OCSP [RFC6960]).¶

2. The Issuer field of the certificate identifies the Issuing CA, which fills a role equivalent to the "iss" claim in [RFC7523]. The authorization server MUST have a pre-established trust relationship with the Issuing CA, and MUST NOT accept certificates from CAs outside its configured set of trust anchors.¶

3. The Subject field and/or the subjectAltName extension of the certificate identifies the principal that is the subject of the certificate, filling a role equivalent to the "sub" claim in [RFC7523]. Two cases need to be differentiated:¶

   A. For the authorization grant, the subject typically identifies an authorized accessor for which the access token is being requested (i.e., the resource owner or an authorized delegate).¶

   B. For client authentication, the subject, or a specific subjectAltName value designated for this purpose by prior agreement between the client and the authorization server, MUST correspond to the "client_id" of the OAuth client.¶

   The authorization server MUST be configured, per Issuing CA, with the rule used to extract the relevant identifier from the Subject field or subjectAltName extension. For a Workload Identity Certificate (Section 1.2), this identifier is typically a URI SAN, commonly one using the "spiffe://" URI scheme as issued by SPIFFE/SPIRE [SPIFFE-X509-SVID] or Athenz [ATHENZ-X509]; authorization servers supporting Workload Identity Certificates SHOULD extract the subject identifier from the URI SAN in preference to the Subject field, which such certificates often leave empty or unpopulated.¶

4. X.509 certificates as defined in [RFC5280] have no field with semantics equivalent to the JWT "aud" claim. Audience restriction for this profile is therefore established out of band between the Issuing CA (or its operator) and the authorization server, as part of the same agreement that establishes the trust anchor relationship described in item 2 above; see also Section 5. Where the subject identifier is a "spiffe://" URI SAN as described in item 3, the trust domain component of that URI (the authority component immediately following the scheme) MAY additionally be used by the authorization server as an informal, coarse-grained signal for which relying parties a given Issuing CA's certificates are intended for, but doing so is a matter of local policy and does not by itself substitute for the out-of-band trust agreement described above. A future revision of this specification, or a companion specification, MAY define an X.509 certificate extension carrying an explicit, in-band audience restriction for deployments that require it; in the absence of such an extension, the authorization server MUST rely on its out-of-band configuration to determine whether it is an intended relying party for certificates issued by a given Issuing CA.¶

5. The certificate's notBefore and notAfter validity fields fill roles equivalent to the "nbf" and "exp" claims in [RFC7523]. The authorization server MUST reject any certificate that is not currently within its validity period, subject to allowable clock skew between systems. The authorization server MAY reject certificates whose remaining validity period is unreasonably long for use as a bearer assertion under this profile; see Section 5.¶

6. The combination of the Issuer field and the certificate's serialNumber fills a role equivalent to the "jti" claim in [RFC7523] as a unique identifier for the token. The authorization server MAY track (Issuer, serialNumber) pairs it has already processed, within a configured window, to detect and reject replayed requests; see Section 6.¶

7. The authorization server MUST corroborate that the party presenting the certificate possesses the private key corresponding to the certificate's public key. This corroboration MUST be established by one of the following means:¶

   A. The certificate presented as the "assertion" or "client_assertion" value is the same certificate the client presented during mutual TLS authentication of the connection to the token endpoint, per [RFC9846], thereby directly proving possession as part of the TLS handshake; or¶

   B. The certificate was forwarded to the authorization server by a trusted intermediary (for example, a TLS-terminating reverse proxy or load balancer situated directly in front of the authorization server) over a channel the authorization server trusts, together with an attestation from that intermediary that the certificate was successfully used to authenticate a TLS client during the connection now being forwarded.¶

   A certificate presented as an "assertion" or "client_assertion" value without either form of corroboration MUST be rejected. See Section 6. When the "assertion" or "client_assertion" value is a thumbprint reference per Section 2.3, mechanism (A) is satisfied directly: the authorization server computes the comparison thumbprint from the certificate it obtained via its own TLS handshake with the client, rather than from a certificate encoded in the request itself.¶

8. The authorization server MUST reject a certificate that is not valid in all other respects per [RFC5280], including but not limited to key usage and extended key usage constraints applicable to this use, where such constraints are configured by the authorization server.¶

HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store

{
 "error":"invalid_grant",
 "error_description":"Certificate chain did not validate to a
  trusted root"
}

4. Authorization Grant Example

The following example illustrates what a conforming certificate and an access token request would look like.¶

The example shows a Workload Identity Certificate (Section 1.2) issued to a "billing" workload by the Issuing CA identified as "CN=Example Workload CA, O=Example Corp, C=US". The subject of the certificate is identified by a "spiffe://" URI SAN, "spiffe://example.org/ns/prod/sa/billing", per [SPIFFE-X509-SVID], and is valid for one hour, consistent with automatic rotation by the issuing workload identity control plane. The authorization server "https://authz.example.net" has been configured, out of band, to trust certificates issued by this CA, and to treat the trust domain "example.org" as identifying an intended relying party, as described in Section 5. The client presents the certificate over a mutually authenticated TLS connection to the authorization server's token endpoint at "https://authz.example.net/token.oauth2".¶

Below is a summary of the relevant fields of the certificate:¶

Issuer: CN=Example Workload CA, O=Example Corp, C=US
Subject: (empty)
Subject Alternative Name: URI = spiffe://example.org/ns/prod/sa/billing
Validity:
    Not Before: 2026-08-19T12:00:00Z
    Not After:  2026-08-19T13:00:00Z
Serial Number: 4096

To present this certificate as part of an access token request, the client -- having already established the connection above via mutual TLS using this same certificate -- might make the following HTTPS request (with extra line breaks for display purposes only):¶

POST /token.oauth2 HTTP/1.1
Host: authz.example.net
Content-Type: application/x-www-form-urlencoded

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ax509-bearer
&assertion=MIIDXTCCAkWgAwIBAgIQEBAAAAAAAAAAAAAAAAAAADANBgkqhkiG9w0B
AQsFADBAMQswCQYDVQQGEwJVUzEUMBIGA1UEChMLRXhhbXBsZSBDb3Jw
[...omitted for brevity...]

5. Interoperability Considerations

Agreement between system entities regarding trust anchors, identifiers, and endpoints is required in order to achieve interoperable deployments of this profile. Specific items that require agreement are as follows: the set of trust anchors and Issuing CAs recognized by the authorization server, the rule used to map a certificate's Subject field or subjectAltName extension to a resource owner identity or "client_id", which Issuing CAs' certificates the authorization server considers itself an intended relying party for (in lieu of an in-band "aud" equivalent, per item 4 of Section 3), the revocation-checking mechanism to be used, the mechanism by which proof of possession is corroborated (direct mutual TLS to the authorization server versus a trusted forwarding intermediary, per item 7 of Section 3), whether the authorization server accepts the thumbprint reference form of Section 2.3 in addition to, or instead of, a fully encoded certificate, and any maximum certificate lifetime the authorization server will accept for use under this profile. The exchange of such information is explicitly out of scope for this specification. Where the Issuing CA is a workload identity control plane, some or all of this agreement may be established and kept current automatically, for example by having the authorization server obtain and refresh its set of trust anchors from a SPIFFE trust bundle endpoint [SPIFFE-X509-SVID] or an equivalent mechanism, rather than through static, manually configured trust anchors; this specification does not define such a mechanism and treats it as an implementation detail of how the out-of-band agreement above is kept up to date.¶

Because certificates issued for general-purpose PKI use are typically valid for periods far longer than is typical for a JWT or SAML bearer assertion, deployments SHOULD either issue certificates intended for use under this profile with comparatively short validity periods, or have the authorization server apply a locally configured maximum acceptable remaining lifetime, or both. Workload Identity Certificates (Section 1.2) issued by systems such as SPIFFE/SPIRE [SPIFFE-X509-SVID] or Athenz [ATHENZ-X509] already follow this practice by design, typically being valid for periods on the order of minutes to hours and rotated automatically well before expiry; deployments using such certificates under this profile satisfy this recommendation without additional configuration, and this is the expected deployment pattern this specification is primarily designed around; see also Section 6.¶

RSA with SHA-256, and ECDSA with curve P-256 and SHA-256, are RECOMMENDED baseline certificate signature algorithms for this profile, to maximize interoperability.¶

6. Security Considerations

The security considerations described within the following specifications are all applicable to this document: "Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants" [RFC7521], "The OAuth 2.0 Authorization Framework" [RFC6749], and "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" [RFC5280].¶

Unlike a JWT or SAML assertion, whose bearer semantics rely on the issuer's signature over a short-lived, narrowly scoped set of claims, an X.509 certificate is designed to be shared openly: it is routinely sent in the clear during TLS handshakes, may be logged by intermediaries, and, for publicly trusted CAs, may be published in Certificate Transparency logs. A certificate is therefore not a secret, and a copy of one proves nothing about who is presenting it. For this reason, this specification requires, in item 7 of Section 3, that possession of the certificate's private key be corroborated for every request, either through the TLS handshake to the authorization server itself or through an attestation from a trusted intermediary. Implementations MUST NOT grant access, and MUST NOT authenticate a client, solely on the basis that a syntactically and cryptographically valid certificate was presented as an "assertion" or "client_assertion" value; doing so would allow trivial impersonation by any party that obtained a copy of the certificate, without needing the associated private key.¶

Authorization servers SHOULD track recently processed (Issuer, serialNumber) pairs, within a window derived from the certificate's validity period or a locally configured limit, to reduce the impact of a request being replayed even when proof of possession corroboration per item 7 of Section 3 is somehow satisfied more than once (for example, by a compromised or overly permissive forwarding intermediary).¶

For general-purpose, longer-lived certificates, revocation checking is particularly important under this profile, since certificate validity periods can be much longer than the lifetime of a JWT or SAML bearer assertion; a compromised private key can otherwise remain usable under this profile for a much longer window than would be typical of the analogous JWT or SAML bearer profiles. For Workload Identity Certificates (Section 1.2), whose short validity periods and frequent, automatic rotation are themselves the primary mitigation against a compromised private key remaining usable for long, revocation checking is a useful defense-in-depth measure but is less load-bearing than certificate lifetime, and authorization servers deployed against such certificates MAY choose not to perform revocation checking at all, provided the configured maximum acceptable certificate lifetime (see Section 5) is short enough that the risk is otherwise acceptable.¶

Authorization servers configured to trust more than one Issuing CA MUST ensure that identifiers extracted from a certificate issued by one CA are not confused with, or allowed to impersonate, identifiers meant to be asserted only by a different CA.¶

The thumbprint reference form defined in Section 2.3 is only as trustworthy as the source the authorization server checks it against. An authorization server MUST compute the comparison thumbprint from a certificate it obtained itself, either from its own TLS stack or from a trusted intermediary via a channel the client cannot influence; it MUST NOT accept a thumbprint together with a client-supplied certificate purporting to match it, since a client able to influence both values could reference an arbitrary certificate it does not hold the private key for.¶

7. Privacy Considerations

An X.509 certificate typically contains more identifying information than the minimal set of claims a deployment would choose for a JWT or SAML bearer assertion, and, being a long-lived, widely presented credential, can act as a stable identifier that enables correlation of a subject's activity across the multiple relying parties the certificate is presented to. To prevent disclosure of such information to unintended parties, an X.509 Bearer Certificate should only be transmitted over encrypted channels, such as those provided by TLS [RFC9846].¶

Deployments should determine the minimum amount of information necessary in the Subject field and subjectAltName extension to complete the exchange, should consider issuing purpose-specific certificates rather than reusing a single general-purpose certificate across unrelated relying parties, and should consult the guidance in [RFC6973] when designing the identifiers a certificate exposes.¶

8. IANA Considerations

9. References

Acknowledgments

This profile follows the pattern established by [RFC7523] and [RFC7522], which share a common lineage back to the OAuth Assertion Framework [RFC7521]. TODO acknowledge reviewers and contributors.¶

Author's Address