What Is JWT Confused Deputy?
A JWT confused deputy flaw is an authorization problem, not necessarily a token forgery problem. The service, API, or backend acts as the “deputy” and is confused into using its privileges based on a token that should not authorize that action there.
A JWT confused deputy issue happens when a service accepts a valid token in the wrong context. The JSON Web Token may be real, properly signed, and unmodified, but the receiving system makes the wrong authorization decision. In practice, that usually means the service trusts a token meant for another audience, another API, or another purpose.
How the Problem Works
The term confused deputy comes from a classic security pattern: a trusted system with real privileges is tricked into using those privileges on behalf of the wrong party.
In JWT-based systems, this often means:
- a token is validly issued
- the signature checks out
- the issuer may be trusted
- but the token is accepted by the wrong service or for the wrong operation
The result is that authentication looks fine, but authorization is flawed.
Where JWT Confused Deputy Issues Appear
JWT confused deputy issues often show up in environments with: - multiple APIs - microservices - federated identity - shared identity providers - OAuth or OIDC-based integrations
A token may include claims such as:
- iss for issuer
- aud for audience
- sub for subject
- scopes or permissions
- roles
- expiration-related claims
The problem appears when a service validates only part of that context.
A Simple Example
Imagine an identity provider issues an access token for Service A. The token is correctly signed and completely legitimate.
Now imagine Service B also accepts that token because it checks the signature and issuer but does not verify:
- whether the aud claim is intended for Service B
- whether the token type is appropriate
- whether the scopes apply to Service B
- whether this endpoint should trust that token at all
In that case, Service B becomes the confused deputy. It is trusted and capable of doing something meaningful, but it is confused about who the token was really meant for.
Why Signature Validation Is Not Enough
This is the key point.
A valid JWT signature proves that: - the token came from a trusted issuer - the token was not altered after issuance
It does not prove that: - the current service is the intended audience - the token was meant for this API instead of another one - the token is an access token rather than an ID token - the request is authorized for this action - the trust boundary is correct
That is why “the token is valid” is not the same as “the request should be allowed.”
For a deeper foundation, see: - How JWT Validation Actually Works - What Is the Difference Between an ID Token and an Access Token?
Common Causes
Missing Audience Validation
This is one of the most common causes. A service accepts any token from a trusted issuer instead of checking whether the aud claim matches that service.
Confusing ID Tokens and Access Tokens
An ID token is usually meant to tell a client application who the user is. An access token is meant to authorize access to a resource. If an API accepts an ID token as if it were an access token, the service may grant access it should not.
Weak Scope or Role Enforcement
A service may verify the token but fail to confirm that the scopes, claims, or roles actually authorize the requested action.
Over-Trusting Internal Tokens
Some teams assume any token issued inside their own environment is safe to accept broadly. That creates lateral trust problems between APIs and internal services.
Shared Trust Without Clear Boundaries
If many services share the same issuer or signing keys but do not enforce strict audience and purpose checks, token misuse becomes easier.
Why It Matters
JWT confused deputy flaws matter because they can turn a legitimate token into unauthorized access across service boundaries.
That may lead to: - API authorization bypass - cross-service data exposure - privilege misuse - unintended backend actions - broader identity security issues in distributed systems
In a modern app environment, one weak trust decision can affect more than one service.
How To Prevent JWT Confused Deputy Issues
Validate the Full Token Context
Do not stop at signature verification. Check: - issuer - audience - expiration - not-before - token type - scopes or permissions - any service-specific claims required by the endpoint
Enforce Strict Audience Binding
Each API should accept only tokens explicitly meant for it. If the token was issued for another audience, reject it.
Separate Token Purposes
Do not treat ID tokens, access tokens, refresh tokens, and internal service tokens as interchangeable.
Apply Least Privilege
Scopes and roles should authorize only the minimum actions needed. Broad token permissions increase the impact of misuse.
Limit Trust Between Services
Even if services share the same identity provider, each one should make its own strict trust decision based on purpose and audience.
Review Authorization Logic Carefully
Many implementations focus on whether the token can be parsed and verified. The more important question is whether the service makes the correct authorization decision after validation.
A Useful Mental Model
Think of a JWT like a signed visitor badge.
The badge may be genuine.
But if the finance office accepts a badge meant only for the shipping dock and grants payroll access, the badge is not the problem. The receiving system made the wrong trust decision.
That is the confused deputy pattern.
Common Misconceptions
“If the JWT is valid, the request is safe.”
False. A valid signature confirms integrity and issuer trust, not that the token is appropriate for this service or action.
“This is a JWT format problem.”
Usually not. The flaw is more often in how the service validates and uses the token.
“Only external attackers can exploit this.”
False. Internal services, partner integrations, and cross-application trust paths can all create confused deputy conditions.
“Any token from our identity provider should work across our APIs.”
That assumption is what often causes the issue. Tokens should be constrained by audience, scope, and purpose.
Final Takeaway
A JWT confused deputy issue happens when a service accepts a real token in the wrong context. If you validate only the signature and ignore audience, scope, token type, and service boundaries, you can end up authorizing requests the token was never meant to permit.
Disclaimer: This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.