Common signs include sending ID tokens to APIs, using them for authorisation decisions, or stuffing them with excessive profile claims. That pattern creates token bloat, increases attack surface, and mixes identity data with access control logic. ID tokens should stay client facing and be read by the OAuth client only. If backend systems depend on them directly, the design is wrong.
How ID token misuse shows up in a SaaS authentication flow
Misuse is usually visible when the ID token stops behaving like a client-facing identity assertion and starts acting like a general-purpose bearer token. A healthy design keeps the ID token inside the OAuth client, while backend APIs receive access tokens. When teams blur that boundary, they often create fragile trust assumptions that are easy to spot in code, logs, and integration patterns.
The most common signal is architectural: the backend is reading the ID token to decide whether a user may call an API, which means authentication and authorisation have been collapsed into one object. Another signal is claim creep, where the token accumulates profile data, roles, or environment context that the client does not need. That usually indicates the token is being stretched beyond its intended audience.
- If an API accepts an ID token directly, the token is being used outside its intended trust boundary.
- If token contents drive permissions, the application is treating identity proof as access control input.
- If the token contains many claims that never influence the UI, the design is probably over-sharing identity data.
What is technically wrong with that pattern
ID tokens are meant to tell the client who authenticated, not to grant downstream resource access. Once a backend starts trusting them for authorisation, the system becomes dependent on audience handling, claim interpretation, and client-side token handling in ways that are easy to get wrong. That is why this pattern often creates token bloat, wider exposure if the token is logged or forwarded, and harder incident response when a token is stolen or replayed.
In SaaS integrations, the failure often appears during federation or SSO plumbing. Teams may reuse the same token across browser flows, API calls, and internal service hops because it is convenient. That convenience removes a clean separation between identity assertion and access delegation, which makes later changes risky. The safer pattern is to use the ID token only at sign-in and rely on the correct access token for API calls.
In practice, this is the point where misuse starts to look like a token design problem rather than a simple implementation bug. NHIMG’s Ultimate Guide to NHIs and Salesloft OAuth token breach both illustrate how token misuse or theft becomes a direct access path when the wrong token is trusted too broadly.
What practitioners should check first
Start by tracing where the ID token is accepted, stored, and forwarded. If the token ever reaches an API gateway, backend service, or job runner, verify whether that system is supposed to validate identity assertions at all. The second check is claim discipline: only keep claims that are needed by the client for sign-in or user display, not claims that quietly substitute for policy decisions.
What to verify:
- The client, not the API, is the only intended consumer of the ID token.
- Authorisation decisions are based on access tokens, session state, or server-side policy, not on ID token claims.
- Token payloads are small, audience-bound, and free of unnecessary profile or entitlement data.
- Logging, tracing, and browser storage controls do not expose tokens to places they do not belong.
Decision rule: If removing the ID token from a backend call would break access, the integration design is wrong and should be refactored before the token is reused or expanded further.
Practitioner takeaway: The cleanest indicator of misuse is not token size alone, but whether the organisation has turned an identity assertion into an access primitive. If that boundary is already blurred, fixing the trust model matters more than trimming a few claims.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | Covers limiting token use to intended access paths and enforcing least privilege. |
| Recommendation — Restrict token handling to intended systems and remove any direct API dependence on ID token claims. | ||
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication, and Access Control | Applies to separating authentication evidence from access decisions in SaaS flows. |
| Recommendation — Use separate controls for authentication assertions and downstream access enforcement. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Identity Sprawl and Overexposure | Relevant where tokens gain excess claims or are accepted beyond their intended audience. |
| Recommendation — Minimise token claims and enforce strict audience boundaries for every identity assertion. | ||
Related resources from NHI Mgmt Group
- What is the difference between opaque session tokens and JSON Web Tokens in an authentication service?
- What are the signs that traditional signer authentication is no longer fit for purpose?
- What are the implications of using OAuth tokens in third-party integrations?
- What makes OAuth tokens risky in NHI environments?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
