OAuth SPIFFE Client Authentication#

Stian Thorgersen, Scott Rose, Pieter Kasselman, Arndt Schwenkschuster (individual draft, OAuth WG venue discussion)

• Why: Sits exactly at the intersection of workload identity and OAuth: workloads acting as OAuth clients today authenticate with manually provisioned, long-lived client secrets; this profiles OAuth client auth to consume SPIFFE SVIDs instead.
• What: Profiles RFC 7521/7523 so OAuth clients authenticate to authorization servers using JWT-SVIDs or X.509-SVIDs — no client secrets — with trust established via SPIFFE Bundle Endpoints (JWKS) for key distribution, and discussion of RFC 8705 (mTLS) handling for X509-SVIDs.
• How: The draft explains precisely why vanilla RFC 7523 doesn't fit: its requirement that the assertion subject equal the client_id, and SPIFFE's subject-as-authority key-discovery model (spiffe:// URIs vs. https:// metadata). Evidence of real momentum: Keycloak 26.4 shipped a preview implementation, multiple community authenticators exist, and SPIFFE is already in production at Uber, Netflix, ByteDance, Google, and others. Open questions for the WG: venue, SPIFFE-ID vs. client-ID semantics, and registration/trust-establishment requirements.
• Where applicable: Any environment where SPIFFE/SPIRE infrastructure and OAuth coexist — which is most enterprise service meshes. Early individual draft, but with shipping implementation evidence rather than slideware.