Auth for Agent Builders: A Crash Course

Are you building AI agents that call APIs, act on behalf of users, or coordinate with other agents? Then you’ll need to understand auth. MCP and A2A won’t save you: they assume you’ve figured it out. Because the problem is: you’re inheriting decades of infrastructure, none of it designed with agents in mind. This article is a starting point for understanding what exists and where the gaps are.

Centralized Identity and Credential Madness (Pre-2007)

Early on, every application managed its own credentials.

Enterprises solved this with LDAP for directory services, Kerberos (1988) for authentication and SSO via tickets, and Active Directory combining both. SAML (2005) extended this to web applications and cross-domain federation. All still in heavy use today.

But these solved human login, not API access. Early API auth was static API keys: include a secret in every request, the server checks it. Simple, but the key represents the application, not any particular user.

The Delegation Problem (2007-2012)

As platforms opened up, third-party apps wanted to access user resources. Enterprises needed applications to act on behalf of employees. Consumer platforms needed apps to access user data. The problem: how do you grant access without sharing the user’s password?

OAuth 1.0 appeared in 2007, followed by OAuth 2.0 in 2012. Instead of sharing passwords, the user approves access at the provider, the app receives a token with limited scope, and that token can be revoked anytime without changing the user’s password.

Different flows for different clients: Authorization Code for web apps, Client Credentials for machine-to-machine, Refresh Tokens for staying logged in.

OAuth 2.0 won. Combined with JWT access tokens, it’s the foundation of modern API authorization.

The “OAuth for Login” Hack (2008-2014)

Here’s where it gets messy.

OAuth is authorization (“what can this app access?”), not authentication (“who is this user?”). But developers wanted login functionality.

The hack: get an OAuth token, call /me or /userinfo, use the response as identity.

Facebook Connect (2008), Twitter Sign-in, and others all did variations of this. It worked, mostly. But it had problems. Tokens could be swapped between apps. Every provider’s /me response looked different. And fundamentally, the token proved access, not identity.

OIDC: Standardizing the Hack (2014)

OpenID Connect took the “OAuth for login” pattern and made it secure and interoperable.

OIDC layers identity on top of OAuth. The key addition is the ID Token: a signed token containing claims about who the user is (their ID, email, name). The token format is JWT, which means the claims are right there in the token itself, signed by the issuer. An API can verify the signature without calling back to the authorization server.

That self-containment is a first step toward decentralization: you don’t have to phone home every time. But it comes with a trade-off. If you revoke someone’s access, they can keep using the token until it expires. The workaround: short-lived tokens and revocable refresh tokens.

OIDC also standardized discovery (.well-known/openid-configuration) and a UserInfo endpoint for additional profile data.

Today, “Login with Google/Microsoft/Apple” is OIDC. The consumer identity problem OpenID 2.0 failed to solve? OIDC solved it by building on OAuth’s success.

But OIDC didn’t solve workload-to-workload trust. That needed something else.

Workload Identity (2017+)

OAuth’s Client Credentials flow handles machine-to-machine auth, but it has a bootstrapping problem: you still need to provision and manage shared secrets (client IDs and secrets) for each service. In a world of containers and serverless functions spinning up dynamically, that doesn’t scale.

SPIFFE (Secure Production Identity Framework for Everyone) emerged in 2017 from work at Google, Netflix, and others. Instead of shared secrets, identity comes from attestation: proving what the workload is based on its environment (which Kubernetes pod, which cloud instance). SPIFFE issues short-lived certificates automatically. No secrets to rotate, no keys to leak.

WIMSE (Workload Identity in Multi-System Environments) is the IETF working group building on SPIFFE concepts, standardizing workload identity tokens for cross-system scenarios.

Workload identity bridges traditional service-to-service auth and agent identity. An AI agent is, in many ways, just another workload: it needs to prove its identity and get scoped access. The SPIFFE patterns of automated issuance, short-lived credentials, and attestation apply directly.

The Decentralization Question (2019+)

While OAuth and OIDC centralized identity around big providers (Google, Microsoft, Okta), a parallel track emerged: decentralized identity.

Verifiable Credentials (VCs) and Decentralized Identifiers (DIDs) flip the model. Instead of “ask Google who this person is,” it’s “the person presents cryptographic proof of their claims.”

The W3C specs are mature (VC Data Model 1.0 in 2019, DID Core in 2022). OID4VCI and OID4VP bridge OIDC with VCs, letting existing OAuth/OIDC infrastructure issue and verify credentials. Real adoption is happening. The EU Digital Identity Wallet ships in 2026. Mobile driver’s licenses are rolling out across US states. Universities are issuing diplomas as VCs.

The model inverts. Instead of your app calling an IdP to verify identity, users present credentials directly. You verify cryptographic signatures, not API responses.

It’s not replacing OIDC tomorrow. But it’s the first serious alternative to the centralized identity model since… ever.

The Agentic Era (2024+)

AI agents are creating gaps that neither OAuth nor VCs were designed to fill.

An agent usually acts on behalf of a user, but creates its own intent. It calls APIs, spawns sub-agents, makes decisions. Current protocols assume either human-in-the-loop (OAuth: user clicks “Approve”) or direct machine-to-machine (Client Credentials: no user context). Agent delegation is neither. The user approved once, then the agent operates autonomously. Delegation becomes abdication. Who’s accountable? How do you audit the chain?

Solutions are arising. OAuth On-Behalf-Of (OBO) extends OAuth with delegation tracking. TSP (Trust Spanning Protocol) enables trust verification without a shared authority: agents can sign, encrypt, and address messages to parties they’ve never met. Research like Nicola Gallo’s PIC Protocol explores continuous authorization: agents only proceed if policies allow.

The Stack Keeps Growing

Each layer exists because the previous one didn’t solve a specific problem. The legacy you’re maintaining today will be joined by new layers tomorrow.

Understanding why each layer exists, and where it falls short, helps you know when to use it, when to extend it, and when something new is actually needed. The patterns often repeat: a real problem emerges, solutions proliferate, then standards consolidate the best approaches.

For agentic identity, we’re still in the exploration phase. Agents are already being deployed, so the infrastructure better catch up.

For more on agent identity patterns, see AI Agents Beyond POCs: IAM Emerging Patterns. For interactive deep-dives into these protocols, check out the Explainers.