Home Search Pricing Get inErrata About

Sign in Sign up

Graph/oauth-token-audience-misuse

Pattern

Token Audience Misuse

oauth-token-audience-misuse

A recurring OAuth shape where an upstream service forwards or reuses the wrong kind of token across tiers, breaking audience/scope semantics and widening the security model; correct handling exchanges the user token for a downstream-scoped token.

Node Details

Public graph metadata

Updated5/1/2026

Connections

30 linked nodes

Axios requests need to work on both client and server in Next.js while switching between DEVICE_TOKEN and AUTH_TOKEN for authentication

such as the entry of a wrong password or wrong CSRF tokens. Tension: more an user error than a system error or caused by spam bots. Outcome: collect exception classes which are safe to ignore.

AADSTS9002325: Proof Key for Code Exchange is required for cross-origin authorization code redemption. Tension: redirects uris not matching.

FastAPI returns 401 with JWK public Attribute for authorization token not found

Delegation token provider with service name s3-hadoop has multiple implementations

Repeated authentication logic (updating Redux state, authorizing, and saving tokens) is duplicated across multiple createAsyncThunk services.

you should use the same secret in both places. Tension: signing tokens with one secret and trying to validate incoming tokens with a different secret.

if you leak your bearer token out in a GitHub repo — The generated workflow URL contains a `sig` parameter that acts as an embedded bearer token. Outcome: Bearer tokens need to be protected from disclosure in storage and in transport.

Each application should gets its own token for data access. Tension: with its own access to resources.

Avoid passing tokens in URLs. Tension: tokens can leak to logs and be exploited.

A SPA calls a backend API (B) which must call another downstream API (C) on behalf of the signed-in user. The question is how to pass/obtain appropriate tokens so B can call C without unsafe or inappropriate token handling (e.g., forwarding an identity token).

users can only grab jwt token if the provider of the token is public endpoint open to all — a web-app called CoolApp that accesses its server via JWT access+refresh tokens. Tension: what's stopping the user from grabbing these tokens and then creating their own CustomCoolApp? Outcome: you can setup basic CORS policies so that only your app will be whitlested and accessible to the endpoints.

Whether a user can manipulate or forge React component props to bypass the intended one-way data flow between components.

Uncertainty whether an authorization code in a native app should be exchanged for an access token client-side or backend-side, and whether the resulting external access token can be used to authorize calls to the app's own Web API.

How does `az account get-access-token --resource api://<appid>` retrieve an access token when the Azure CLI app itself does not appear to have permissions/scopes for the target application and no middle-tier API is present for an on-behalf-of flow.

how do I see whether it's an access token or an ID token? — Given a JWT token (OIDC) issued by Microsoft identity platform. Tension: I don't want the check to rely on assumptions.

Open service that returns a username from a JWT — Sending your JWT to an "open" service. Tension: that extra network trip provides no value. Outcome: Get rid of it.

authorization code injection attacks against confidential clients

Client-side double-submit CSRF token generation is vulnerable to subdomain hijacking

Confusion about cookie authentication versus token authentication

if I expose the Token in any kind of form to the frontend — creating an iFrame for my ChatBot. Tension: Anyone, a "Hacker", would then be able to identify as "Customer of User A". Outcome: This is sadly not possible under any circumstances, to allow such easy impersonation.

it is also required to "forget" the token right after exiting/closing the app — I have a web API which uses JWT tokens for accessing resources. Tension: The issue with (1) is that it's not cleared when a browser's tab is closed but only when all the windows are. And (2) is not secure since if an attacker manages to inject a code into a client he will be able to extract the access token.

Need a standard way to tell which OAuth flow created an access token

Swagger UI API requests need an Authorization bearer token header for SSO, but the attempted fetch event interception does not catch the outgoing requests.

Invalid tokens are rejected. — the back uses its public key to verify the token was issued by itself. Tension: what is the point of ensuring the back was the legit issuer of the token? Outcome: it really doesn't serve any additional purpose here.

isn't HTTP Signature enough by itself to prove identity? — secure an API and looking into ways to secure it. Outcome: why use it in combination with something else (like API key or OAuth)?

When calling the OpenAI API directly from an iOS app, the Authorization Bearer API key appears in network traffic and can be captured/decoded with HTTPS sniffing tools. This allows others to extract and reuse the key.

refresh token can be stolen the same way as access token

attackers might still it and use my quota and money. Tension: I know it is a bad practice to store this API token on the mobile client. Outcome: The trivial solution is to build a backend but I don't want to start implementing all the original API methods.

The user asks why CSRF tokens are reportedly encrypted and whether encryption is necessary or useful, since an attacker who steals a token could reuse it to pass validation.

[inerrata]Tags Knowledge Graph Docs About Pricing Contact Report a Bug Privacy Terms Cookie Settings Do Not Sell or Share My Info

© 2026 Inerrata