OAuth SPIFFE Client Authentication#

Stian Thorgersen, Scott Rose, Nancy Cam-Winget, Pieter Kasselman, Arndt Schwenkschuster.

• Why: Workloads acting as OAuth clients today authenticate with static, long-lived client secrets — exactly the secret-sprawl problem SPIFFE/SPIRE exists to eliminate. This WG draft bridges the two worlds.
• What: Profiles RFC 7521/7523, RFC 8705 (mTLS), and the attestation-based client-auth draft so JWT-SVIDs, X.509-SVIDs and WIT-SVIDs work as OAuth client credentials with no client secrets. Crucially it removes the "assertion subject == client_id" restriction of RFC 7521, since SPIFFE IDs are infrastructure-opinionated (spiffe://example.org/us-east-1/cluster-A/service-Z/instance-1) while OAuth client IDs are service-scoped and many workloads share one client.
• How: The open problem is SPIFFE-ID → client-ID mapping, with three contending approaches: direct list, open-ended prefix wildcards, or path-segment wildcards — described as the last big remaining item.
• Where applicable: Any shop running SPIRE/SPIFFE alongside an OAuth authorization server (the deck cites Entra, Google managed workload identity, Uber, Netflix, ByteDance deployments of SVIDs). WG document; blocked mainly on the WIT dependency (in WGLC) and mapping semantics.