AAkash Devdhar
Back to writing
OAuth · 10 min read

OAuth, OIDC, SAML, JWT: A Practical Guide for Modern Engineers

Four identity standards, four different jobs. A practical guide to understanding how OAuth, OIDC, SAML, and JWT fit together in modern applications and AI agent systems.

Published August 15, 2026Akash Devdhar

I am asking engineers in interviews to explain the difference between OAuth and OIDC, and half the time I am getting the same answer basically: "they are both for login." That answer is wrong, and it is not a small wrong, it is the exact kind of wrong that is now showing up in how people are wiring up AI agents. Four acronyms, four different jobs, and treating them as one blob is where the actual security bugs come from.

Let me put it plainly. SAML and OIDC answer "who are you." OAuth answers "what are you allowed to do." JWT is not a protocol at all, it is just a format, a container that any of the above can choose to put its output in. If you remember only one sentence from this post, remember that one, full stop.

Authentication versus authorization, actually explained

Every confused conversation I have had on this topic traces back to mixing up two different questions.

Authentication is proving identity. You log into your company's SSO portal, it checks your credentials (maybe with an MFA prompt), and it tells the application "yes, this is genuinely Priya, verified." SAML and OIDC both live here. They are competing standards for the same job, not complements.

Authorization is a separate question that comes after: now that we know it is Priya, what is she actually permitted to do. Can she read this calendar. Can she call this API. Can her AI agent, acting for her, delete a record. OAuth 2.0 lives here, and only here. OAuth was never designed to answer "who is this," which is exactly why bolting OIDC on top of it (which is literally what OIDC is, an identity layer added on top of OAuth 2.0) was necessary in the first place.

JWT (RFC 7519) sits underneath both, as a token format. An OIDC ID token can be a JWT. An OAuth access token can be a JWT, or it can be an opaque reference string, both are valid, people forget this. SAML, being older, uses XML assertions instead of JWT, which is one of the practical reasons SAML feels clunky to work with compared to the newer JSON-based standards.

Where each one actually shows up

  • SAML: enterprise SSO, the classic case being logging into Salesforce or Workday through your company's identity provider. Heavy XML, browser redirect based, still everywhere in large enterprises even though nobody is excited about it anymore.
  • OIDC: modern consumer and enterprise login, "Sign in with Google" being the most familiar example. Built on OAuth 2.0, uses JSON and JWTs, much lighter than SAML.
  • OAuth 2.0: delegated authorization, letting an app or an agent act with limited permission on your behalf, without ever handing over your password. This is the one that matters most once agents enter the picture.
  • JWT: the token format that carries the actual claims (who, what scope, when it expires) in a compact, signable, verifiable way. Not a standard for login or authorization by itself, just the envelope.

Why this confusion gets expensive with AI agents

Four protocols, four different jobs

Here is the pattern I am actually seeing go wrong. A team builds an AI agent, the agent needs to call three internal services, and someone reaches for "let's just use SAML" or worse, "let's just give it a JWT" as if JWT alone was a security model. JWT is not a security model, it is a shipping container, what matters is who signed it, what claims are inside it, and who is checking those claims before trusting the box. An unsigned or unverified JWT is basically a sticky note that says "trust me."

The pattern that actually works: OIDC (or SAML, if you are stuck in an enterprise IdP that has not modernized) authenticates the human who is delegating work to the agent. OAuth 2.0, specifically client credentials or token exchange (RFC 8693) grants, authorizes the agent for a narrow, expiring scope. The resulting access token happens to be encoded as a JWT, so the resource server can verify it without a network round trip back to the issuer.

How the four pieces chain together for an agent request

Notice that JWT is not doing any of the actual security work in that second diagram. It is the format the token happens to travel in. The security work is being done by OIDC establishing who the human is, and OAuth deciding what the agent gets to do on that human's behalf, for how long.

A quick code example

Decoding (not verifying, an important distinction) a JWT to see what is actually inside one:

import jwt  # PyJWT
 
# NEVER trust a token just because you can decode it.
# This only shows you the claims, it proves nothing by itself.
token = "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9..."
claims = jwt.decode(token, options={"verify_signature": False})
print(claims)
# {'sub': 'agent-invoice-reader', 'scope': 'invoices:read',
#  'aud': 'https://api.internal-service.com', 'exp': 1735689600,
#  'iss': 'https://idp.example.com'}

And here is the part people skip, actually verifying it before trusting anything in it:

import jwt
from jwt import PyJWKClient
 
jwks_client = PyJWKClient("https://idp.example.com/.well-known/jwks.json")
signing_key = jwks_client.get_signing_key_from_jwt(token)
 
claims = jwt.decode(
    token,
    signing_key.key,
    algorithms=["RS256"],
    audience="https://api.internal-service.com",
    issuer="https://idp.example.com",
)
# Now the claims are actually trustworthy, because the signature,
# audience, and issuer were all checked, not just the payload read.

That second snippet is the whole point of this post basically. Decoding is free and proves nothing. Verifying against a trusted issuer's public key is the actual work, and it is where most homegrown "just use JWT" implementations quietly skip a step.

Standards worth reading, not just skimming

  • SAML 2.0 (OASIS standard) for the XML assertion based SSO model, still relevant in large enterprises.
  • OpenID Connect Core 1.0 for how identity got layered on top of OAuth 2.0.
  • RFC 6749, The OAuth 2.0 Authorization Framework, for the base delegation model.
  • RFC 7519, JSON Web Token (JWT), for the token format itself.
  • RFC 8693, OAuth 2.0 Token Exchange, for the agent-to-agent delegation case specifically.

The takeaway

Stop treating these four as synonyms with different logos. SAML and OIDC prove who someone is. OAuth decides what they, or their agent, can do. JWT is just the envelope the decision travels in, not the decision itself. The moment you are clear on which of these three jobs you are actually solving for, half the "how do we secure our AI agents" confusion in your team's Slack channel basically disappears on its own.

Akash Devdhar is a Senior Software Engineer specializing in enterprise identity, authentication, authorization, and AI infrastructure. He writes about building secure AI systems using OAuth, OIDC, RBAC, and modern identity architectures.