Identity is the cornerstone of security. For human users, identity is well defined and standardized: single sign on, OpenID Connect, and multi factor authentication are widely deployed. For non human identities such as workloads, microservices, and increasingly AI agents, the situation is much less mature. Long lived API keys are copied into configuration files, secrets are scattered through CI pipelines, and revocation is either manual or ignored.
At Riptides, we address this gap directly. Our approach is simple but powerful: every workload in the system receives a unique SPIFFE ID, anchored in strong cryptography and tied to process metadata. This happens inside the Linux kernel and is completely transparent to the application. Applications do not need to be modified. They inherit a secure, short lived identity that proves who they are.
Identity bootstrapping is the foundation. But workloads need to use this identity in existing protocols, and the one of the most important ones is OAuth2.
Over the past decade OAuth2 has become the universal cross-authorization protocol for APIs and services. It is primarily used to let one service access resources from another on behalf of a human, with the user’s identity and consent central to the flow. As systems have evolved, the same model has been extended to cover non-human actors such as workloads, microservices, and autonomous agents, where no human is directly involved in every flow. Still, there is plenty of room for improvement, since secure workload identity and authorization are becoming essential.
This post explores these specifications and drafts, how they connect to SPIFFE, and why they are essential in an agentic AI world.
Why Unique Workload Identity Matters
In human workflows we demand per user identity. Every login is linked to a person, access is logged, scoped, and revocable. Workloads rarely have this property. Instead, they often share a single API key or secret across many services.
The risks are clear:
- Credential sprawl: Keys and tokens get copied across code, configuration, and pipelines
- No provenance: After an API call lands, it is hard to prove which workload generated it
- Replay and lateral movement: A single compromise enables reuse of the same credential elsewhere
- Operational burden: Secret rotation is brittle and disruptive
With SPIFFE based workload identity, each workload has a unique short lived identifier spiffe://trustdomain/workload/path. That identifier is proven cryptographically and can be validated by any peer.
In agentic AI, where autonomous agents instantiate dynamically and invoke APIs across multiple systems, this property becomes critical. Without unique workload identity, agent chains are opaque. With it, they become traceable, auditable, and accountable.
OAuth2 and Workload Identity: The Standards Landscape
OAuth2 was originally designed for user authorization, but it has steadily evolved to support machine and workload use cases. The following RFCs and drafts together form the building blocks for integrating SPIFFE based identities into OAuth2 flows.
Client Onboarding and Dynamic Registration
The first step is how a workload becomes a client of an Authorization Server.
RFC 7591 - Dynamic Client Registration Protocol
Defines a standard way for clients to register themselves dynamically with an Authorization Server by sending configuration such as redirect URIs, grant types, and authentication methods. Instead of manual configuration, the client can request credentials programmatically. This enables scalable onboarding of new clients in distributed systems.
RFC 7592 - Dynamic Client Registration Management Protocol
Extends RFC 7591 by allowing registered clients to read, update, or delete their registration. Management is secured with a registration_access_token issued during registration. This makes client lifecycle management more flexible and automated.
Dynamic Client Registration with Trusted Issuer Credentials - draft
Enhances Oauth2 DCR by using tokens issued by trusted identity systems (such as SPIFFE) as software statements. Authorization Servers can validate these trusted issuer tokens automatically. This allows secure zero-touch client registration at scale.
Client Registration on First Use with SPIFFE - draft
Proposes extending OAuth2 DCR with SPIFFE. Workloads can register on first use by presenting a SPIFFE credential instead of a pre-provisioned secret. This eliminates manual setup for ephemeral workloads.
Client Authentication and Proof of Possession
Once registered, the workload must authenticate at the token endpoint.
RFC 8705 - Mutual TLS Client Authentication and Certificate Bound Access Tokens
Introduces mTLS as a client authentication method at the token endpoint and binds issued access tokens to the client certificate used. This ensures that only the rightful holder of the private key can use the token. It significantly reduces the risk of token replay attacks.
RFC 9449 - Demonstrating Proof-of-Possession at the Application Layer (DPoP)
Provides a way for clients to bind tokens to a public key using signed HTTP requests. Even if an access token is stolen, it cannot be reused without the private key. It is useful in contexts where TLS client authentication is not available.
SPIFFE Client Authentication - draft
Focuses on standardizing SPIFFE-based client authentication for OAuth2. Workloads present their SPIFFE SVID directly as proof of identity at the token endpoint. This provides a consistent method to integrate SPIFFE identities into OAuth2 flows.
These mechanisms replace brittle client secrets with cryptographic proof of possession anchored in SPIFFE.
Resource Scoping and Metadata Discovery
Tokens should be scoped to the correct audience and discovered automatically.
RFC 8707 – Resource Indicators for OAuth 2.0
Defines the resource parameter, allowing clients to request tokens scoped to a specific API or resource server. This avoids issuing broadly scoped tokens valid for multiple services. It supports least-privilege principles in multi-service environments.
RFC 9728 OAuth 2.0 Protected Resource Metadata
Standardizes how a resource server can publish metadata at a .well-known/oauth-protected-resource URI. Metadata includes supported scopes, authorization servers, and token presentation methods. This allows clients to discover how to interact with a resource dynamically.
RFC 8414 Authorization Server Metadata
Specifies how an Authorization Server publishes metadata about its endpoints and capabilities at a .well-known/oauth-authorization-server URI. Clients can discover token endpoints, authorization endpoints, signing keys, and supported features. This reduces manual configuration and improves interoperability.
Together these provide dynamic discovery for both the Authorization Server and the Resource Server.
Context Propagation and Workload Chains
Agentic AI workloads rarely stop after one hop. Requests propagate across multiple services, each adding context. Preserving identity and context through these chains is critical.
Transaction Tokens - draft
Defines short-lived Transaction Tokens (JWTs) that capture identity and context when a request first enters a system. These tokens can be passed along or replaced as requests propagate between workloads. This enables verifiable provenance and prevents unauthorized internal calls.
Why This Matters for Agentic AI
AI agents orchestrate tasks across APIs and services at high speed and scale. Without unique workload identity, these agents are opaque and untraceable. Tokens are reused, provenance is lost, and the attack surface grows. With SPIFFE based identity integrated into OAuth2 flows, each agent is distinct, auditable, and accountable. Tokens are least privilege by default, scoped to resources, and bound to the workload that obtained them. Context can be propagated securely across chains of agents.
This shifts the security model from managing static secrets to verifying dynamic, cryptographically provable identities.
Conclusion
The evolution of OAuth2 shows a clear path from user centric authorization to full support for non human identities. RFCs 7591, 7592, 8705, 8707, 9728, and 8414, together with drafts for transaction tokens, SPIFFE integration, and trusted issuer tokens provide some of the missing pieces.
For this vision to take hold, these specifications must be adopted by the major OAuth2 Authorization Server implementations. When that happens, workload identity will no longer be a bolt-on feature but a native part of the authorization ecosystem. At Riptides, we are committed to supporting these standards in our platform, and we encourage existing OAuth2 platforms to adopt them as well, since only broad implementation will make workload identity truly interoperable and seamless across environments.
This is the next frontier for OAuth2: moving beyond human-centric consent toward a universal model of secure workload identity. As agentic AI grows in scale and autonomy, these capabilities are not optional. They are the foundation for building systems that are secure, auditable, and trustworthy by design.
If you enjoyed this post, follow us on LinkedIn and X for more updates. If you’d like to see Riptides in action, get in touch with us for a demo.
Ready to replace secrets
with trusted identities?
Build with trust at the core.
