DEV Community: Akash Devdhar

Authentication vs Authorization: Why Most AI Apps Get It Wrong

Akash Devdhar — Sat, 22 Aug 2026 15:14:02 +0000

Here is the failure mode I am seeing over and over in AI app reviews. The app checks who you are exactly once, at login, and after that it treats the agent as if it has a blank check for the rest of the session. Read a file, sure. Send an email, sure. Delete a record, why not, you logged in twenty minutes ago only. That is not an authorization model, that is a login screen pretending to be one.

Authentication and authorization are not the same question asked twice, they are two entirely different questions, and most AI apps are answering the first one and quietly skipping the second, forever, for the whole session.

The one question that gets asked, and the one that doesn't

Authentication happens once, at the door: who is this. The app checks a password, a session cookie, an SSO token, whatever, and it is satisfied. Fine so far, this part most teams actually get right.

Authorization is supposed to happen continuously, at every door inside the building: now that we know who this is, should this specific action, on this specific resource, right now, be allowed. This is the part that AI apps are skipping basically. Traditional web apps got away with checking authorization loosely because a human was the one clicking buttons, slowly, with natural friction built into every step. An AI agent has no such friction. It can chain fifteen tool calls in three seconds, and if your authorization model is "well, they logged in," every single one of those fifteen calls just inherited the same blank check.

What this actually looks like when it breaks

Say your AI assistant is authenticated as a support engineer who can read customer tickets. Somewhere in its tool list, there is also a "run_sql_query" tool, because someone needed it for a debugging session six months ago and nobody removed it. The authentication layer sees a valid, logged-in support engineer. It has no concept of "this specific tool call, on this specific table, for this specific reason, right now." So the agent runs the query. Not because anyone decided the support engineer should have that access for that task, but because nobody built the layer that would have stopped it.

This is exactly the gap that RBAC and, better, scoped OAuth tokens are supposed to close, and it is also exactly the gap that gets silently reintroduced when a team wires an agent up with one long-lived service account "to keep things simple."

What continuous authorization actually looks like

The difference is not exotic. Every tool call the agent makes should carry a scope, and something on the other end should actually check that scope before doing anything, every single time, not just once at session start. This is what OAuth 2.0 scopes were built for, and it is what the newer Rich Authorization Requests spec (RFC 9396) extends further, letting you express authorization at the level of "read tickets in this one project" rather than a flat "read tickets, all of them, everywhere."

A quick code example

Here is roughly what the one-time-gate version looks like, which is unfortunately close to what a lot of agent frameworks default to:

# Checked once, at session start, then trusted for everything after
def handle_tool_call(session, tool_name, args):
    if session.is_authenticated:
        return execute_tool(tool_name, args)
    raise PermissionError("not logged in")

And here is the per-action version, where the token's scope is actually checked against what the specific tool call is trying to do:

def handle_tool_call(session, tool_name, args):
    token = session.access_token  # short lived, scoped, from the OAuth flow
    required_scope = TOOL_SCOPE_MAP[tool_name]  # e.g. "tickets:read"

    if required_scope not in token.scopes:
        raise PermissionError(f"token lacks scope: {required_scope}")

    if not resource_matches_scope(args, token):
        # e.g. token is scoped to project_id=42, but the call targets project_id=17
        raise PermissionError("resource outside token's authorized scope")

    if token.is_expired():
        raise PermissionError("token expired, re-authorize")

    return execute_tool(tool_name, args)

The second version has more code, I know, but every one of those checks is answering a question the first version never even asked. Which tool, on which resource, under which still-valid grant.

Standards worth reading

RFC 6749, The OAuth 2.0 Authorization Framework, for the base scope model.
RFC 9396, OAuth 2.0 Rich Authorization Requests, for expressing authorization at a finer grain than a flat scope string.
NIST SP 800-207, Zero Trust Architecture, for the broader principle this post is really just a specific case of: never trust a request just because it came from an already-authenticated session, verify it again for the specific action being taken.

The takeaway

Logging someone in, or logging an agent in, answers exactly one question and that question is not "should this happen." If your AI app's entire authorization model is "well, the session is valid," you do not have authorization at all, you have authentication wearing a bigger hat. Check the action, not just the actor, and check it every time, not just at the door.

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.

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

Akash Devdhar — Sat, 15 Aug 2026 18:19:56 +0000

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

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.

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.

Why API Keys Are Not an Identity Strategy

Akash Devdhar — Mon, 10 Aug 2026 20:20:57 +0000

Every team building AI agents right now is basically doing the same thing: they generate a long random string, put it in an environment variable, call it “authentication,” and move on. I am seeing this pattern in almost every AI infrastructure discussion I am part of, and I want to say clearly: an API key is a secret, not an identity. Treating it as the same thing is a disaster waiting to happen.

The confusion, explained simply

A secret answers one question: do you know this string or not? An identity answers a completely different set of questions. Who are you, actually? What are you allowed to do? Who granted you that permission, and for how long? When an API key is your whole security model, you have answered the first question and quietly skipped the other three.

This was tolerable when the caller was a predictable backend service that your own team wrote and deployed. It is not tolerable when the caller is an AI agent that is making autonomous decisions, chaining tool calls, and sometimes acting on behalf of a human user it has never directly authenticated. The agent is not “your service” anymore in the old sense. It is closer to a semi-independent actor that needs its own verifiable identity, its own scoped permissions, and its own audit trail.

Where the API key model actually breaks

Let me list where I am seeing the cracks, without pretending this is some neat universal law:

No delegation. An API key cannot say “I am acting on behalf of user X, with X’s consent, for the next 15 minutes.” It is a flat, all-or-nothing credential.
No expiry that means anything. Most API keys live forever until someone remembers to rotate them, which basically means never.
No audience or scope binding. The same key that reads a customer record can usually also delete it. There is no built-in concept of “this token is only valid for this one resource server, for this one action.”
Terrible audit story. When three different AI agents share the same key—and in practice, they often do—your logs cannot tell you which agent actually did what. You get a name in a log line, not a proof.
Revocation is a blunt instrument. You cannot revoke “this one agent’s access to this one tool” without breaking everything else that shares the key.

None of this is a new problem, actually. Enterprise software went through this exact argument fifteen years ago when everyone moved off shared static credentials toward OAuth-based delegated access. What is different now is that the caller on the other end is not a human clicking “allow” on a consent screen; it is an autonomous agent, and the whole flow needs to happen without a human sitting there approving each step.

What an identity-based model looks like instead

In the API key model above, there is nothing to reason about. The key either works or it does not, and once it is compromised, everything behind it is compromised also. Now compare this to what a proper identity flow looks like for an agent.

The important shift here is that the agent is not holding a permanent secret that grants everything. It is holding a token, and that token is a claim about identity, scope, and time. The resource server does not trust the token because it is hard to guess; it trusts the token because it is signed by an identity provider it already trusts, and it can inspect exactly what the token is allowed to do before it does anything.

This is where OAuth 2.0 client credentials grant, or better, OAuth 2.0 token exchange (RFC 8693), becomes relevant for agent-to-agent and agent-to-tool calls. Token exchange in particular is built for exactly this situation: an agent that holds one token needs to call a downstream service with a narrower, more specific token, possibly acting on behalf of the original user. That is delegation done properly, not a shared secret pretending to be delegation.

A quick code comparison

Here is roughly what the API key version looks like. Simple, and also the whole problem in one snippet:

# The "identity strategy" most agents ship with today
import requests

response = requests.get(
    "https://api.internal-service.com/v1/customer-records",
    headers={"X-API-Key": "sk_live_9f8a7...never_rotated"}
)
# No subject, no scope, no expiry, no way to tell which agent called this.

Now compare with a token acquired through client credentials and passed as a bearer token, where the token itself carries claims:

import requests

token_response = requests.post(
    "https://idp.example.com/oauth/token",
    data={
        "grant_type": "client_credentials",
        "client_id": "agent-invoice-reader",
        "client_secret": AGENT_SECRET,  # short lived, rotated, scoped to this one agent
        "scope": "invoices:read",
        "audience": "https://api.internal-service.com",
    },
)
access_token = token_response.json()["access_token"]

response = requests.get(
    "https://api.internal-service.com/v1/customer-records",
    headers={"Authorization": f"Bearer {access_token}"},
)
# The token carries sub, scope, aud, and exp claims.
# The resource server can verify all four before doing anything.

The second version has more moving parts; I am not denying that. But those moving parts are exactly what let you answer “which agent did this, was it allowed to, and for how long” without guessing. If you decode that access token (it is typically a JWT, RFC 7519), you get a sub claim identifying the client, a scope claim limiting what it can do, an aud claim binding it to one resource server, and an exp claim that makes the whole thing self-expiring. An API key gives you none of these.

Standards worth actually reading

If you are designing this for real, three documents are worth your time and not just a skim:

RFC 6749, The OAuth 2.0 Authorization Framework, for the base grant types including client credentials.
RFC 8693, OAuth 2.0 Token Exchange, which is basically the spec that AI agent architectures keep re-inventing badly when they do not use it.
RFC 7519, JSON Web Token (JWT), for how claims-based tokens are structured and verified.

OpenID Connect is also worth knowing here, though it solves a slightly different problem: authenticating a human end user. Most agent-to-service calls are closer to pure OAuth client credentials or token exchange territory.

The takeaway

An API key tells you that a caller knows a string. It does not tell you who the caller is, what it is allowed to do, or when that permission runs out. AI agents are autonomous enough now that this gap is not theoretical anymore; it is showing up as real incidents. If your agent’s entire security model is one static header value, you do not have an identity strategy—you have a shared password with extra steps.

Treat your agents like the semi-independent actors they are: give them real, scoped, expiring identity, not a key copied into a config file three deployments ago.

OAuth Was Designed for Humans. AI Agents Change the Rules.

Akash Devdhar — Tue, 04 Aug 2026 18:18:52 +0000

I will say it plainly. OAuth 2.0, as good as it is, was never built with the idea that the “user” on the other end could be a software agent taking fifty decisions a minute without anybody watching. We have been bending the spec to fit agents, when actually the spec was assuming a human sitting in front of a browser, clicking “Allow.” That assumption is now breaking, and most teams building AI agents have not fully understood how much.

Let me explain what I mean.

The human assumption baked into OAuth

Classic OAuth 2.0 authorization code flow goes something like this. A user clicks login, gets redirected to an identity provider, sees a consent screen, clicks “Allow,” and comes back with an authorization code that the app exchanges for a token. Every single step in this flow assumes a human is present to look at a screen and make a judgment call.

Now put an AI agent in that loop. There is no browser session waiting on the agent’s side. There is no human eyeball reading “This app wants to access your calendar and email.” The agent is not clicking “Allow”; it is calling an API, and it needs to do this at 2 AM, unattended, sometimes chaining five or six calls to different services in a matter of seconds.

The three-legged OAuth dance was built for exactly one thing: a human giving informed consent, in the moment, for a specific access grant. Agents break this in at least three ways.

Where it actually breaks

1. No human present for consent at request time. Consent has to be captured upfront, or delegated in advance, because the agent cannot pause mid-task and wait for someone to click a button. This changes consent from an interactive, moment-of-request thing into a policy that has to be defined beforehand.

2. Identity gets layered, not singular. In classic OAuth, the token represents “this user, authorized this app, for this scope.” With agents, you actually have three identities stacked together: the human who initiated the task, the agent that is executing it, and sometimes a sub-agent that the first agent spawned to do a smaller piece of work. Standard OAuth tokens were not built to carry this chain.

3. Session lifetime assumptions do not hold. A human session might last an hour, a day at most, with natural boundaries like closing the laptop. An agent’s “session” could span a long-running workflow, spin off parallel sub-tasks, and outlive any reasonable human-session pattern, while still needing the same scoped, revocable access a human would get.

Here is the classic flow first, stripped down to its four essential hops:

One human decision point, right at the start, and one hop from app to resource. Simple.

Now look at what an agent delegation chain actually needs. The human still decides only once, upfront, but everything downstream has to be carried and enforced through tokens instead of another click:

Same one human decision at the top. But underneath it, two extra hops that a human never sees or approves in real time, and each one has to answer for itself through the token it is carrying, not through a person watching a screen.

What actually helps here

The good news is, we are not starting from zero. RFC 8693, the OAuth 2.0 Token Exchange spec, already gives us a pattern for “on-behalf-of” tokens, where one party can exchange a token for a narrower, downstream token while preserving a chain of who is acting for whom. This maps almost perfectly onto agent delegation, if teams actually use it instead of just minting a fresh static key for every agent.

A rough version of what this looks like in practice:

# Agent requests a narrower, short-lived token to call a downstream API,
# on behalf of the user who originally delegated the task.

response = requests.post(
    token_endpoint,
    data={
        "grant_type": "urn:ietf:params:oauth:grant-type:token-exchange",
        "subject_token": agent_session_token,
        "subject_token_type": "urn:ietf:params:oauth:token-type:access_token",
        "requested_token_type": "urn:ietf:params:oauth:token-type:access_token",
        "scope": "calendar.read",          # narrower than the agent's own scope
        "audience": "calendar-service",    # explicit downstream target
    },
)

downstream_token = response.json()["access_token"]
# This token should be short-lived, auditable, and traceable
# back to both the agent and the human who delegated the task.

Combine this with JWT-based claims (RFC 7519) carrying an explicit “acting on behalf of” field, and you get tokens that actually answer the question an auditor will ask you six months later: which agent did this, on whose authority, and with what scope?

There is also real movement happening around authentication patterns specifically for MCP servers, since MCP is quickly becoming the way agents talk to tools and data sources. Worth watching this space closely, because whatever pattern wins there will likely become the default for agent-to-tool auth industry-wide.

The takeaway

OAuth is not broken; it is just incomplete for this new kind of actor. The fix is not to throw it out. It is to extend it: upfront consent instead of interactive consent, token exchange for layered identity instead of one flat token, and short-lived scoped grants instead of a static key living in an environment file for six months.

If your agent architecture still treats the agent as “just another OAuth client” with a long-lived key, you are one incident away from finding out the hard way why the humans-only assumptions in OAuth mattered in the first place.

Authentication for AI Agents: Lessons We Can Borrow from Enterprise Identity

Akash Devdhar — Sun, 02 Aug 2026 14:44:24 +0000

Last week I was debugging an issue where our AI agent kept losing its session mid-task. And it struck me: we are basically solving the same problem enterprise IT teams solved 15 years back with SSO and IAM. The only difference is that this time the “user” logging in is not a human—it’s a piece of software making decisions on its own.

Most teams building AI agents right now are treating auth as an afterthought. An API key hardcoded somewhere, one service account shared across ten agents, nobody knowing which agent did what action. I have seen this pattern more than once now, and honestly, it is a disaster waiting to happen.

So let’s talk about what enterprise identity already figured out, and how we can borrow it.

1. Every identity, human or not, needs its own credential

In the enterprise world, we don’t let two employees share one login. The audit trail becomes useless, accountability goes out the window, basically. The same logic applies to agents. If Agent A and Agent B are sharing one API key, and something goes wrong, how will you even trace back which agent did the damage? Each agent should get its own machine identity, full stop.

2. Short-lived tokens over static keys

This one is not new. OAuth2 and SAML taught us this ages ago. A static API key sitting in an environment file for months is a ticking bomb. Agents should be requesting short-lived tokens, refreshing them, and the moment an agent’s task is done, that token should expire. Enterprise IAM tools like Okta or Azure AD do this for humans automatically; we need the equivalent for agents.

3. Least privilege is non-negotiable

I know it’s tempting to give your agent broad access “just in case it needs it later.” But this is exactly the mistake enterprises made in the early days, before RBAC became standard practice. An agent that only needs to read a calendar should not have write access to your entire email account. Scope it down, always.

4. Delegated authority needs to be explicit

This is where it gets interesting, actually. When an agent acts “on behalf of” a user, enterprise identity already has a pattern for this. OAuth’s delegation model, or even the older Kerberos constrained delegation. The agent should carry proof of who it’s acting for, not just its own identity. Otherwise, you can’t even answer the basic question: was this action authorized by the user, or did the agent go rogue on its own?

5. Continuous verification, not one-time login

Enterprises moved from “log in once, trust forever” to Zero Trust. Verify every request, every time, based on context. Agents are even more unpredictable than humans in their behaviour, so this applies double. Don’t authenticate an agent once at session start and forget about it; keep checking.

Honestly, none of this is very new thinking. The identity and access management folks have already fought this battle, made the mistakes, and written the standards for it. We are just now applying the same to a new kind of actor in the system.

What I am noticing is that a lot of AI infra teams are reinventing auth from scratch, when they could simply be adapting what already exists in the IAM world, with some tweaks for the fact that agents can act faster, more autonomously, and sometimes unpredictably compared to a human clicking buttons. Worth thinking about before the AI agent version of a credential leak becomes the next big headline.