They often treat OAuth and OIDC as the authorization system itself. In reality, they provide identity context and delegated trust, while the application still needs a policy layer to decide whether a request is allowed. Without that separation, token claims become a proxy for governance rather than a controlled input.
Why This Matters for Security Teams
OAuth and OIDC are often treated as if they decide access on their own, but they do not. They establish delegated trust, identity context, and token exchange patterns; they do not replace an application policy engine. That misunderstanding becomes expensive when teams use token claims as a stand-in for governance, because claims can confirm who or what presented the token without proving the request should succeed.
This is especially risky for NHIs and SaaS-to-SaaS integrations, where third-party connectors can accumulate broad, durable permissions. NHIMG research shows that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which makes hidden trust chains a practical exposure rather than a theoretical one. The issue is not just authentication design, but authorization drift across apps, scopes, and tenant boundaries. NIST Cybersecurity Framework 2.0 reinforces the need to manage identity, access, and continuous oversight as separate functions, not one merged control.
In practice, many security teams encounter OAuth abuse only after a connected app has already been over-permissioned or used outside its intended business purpose.
How It Works in Practice
The clean design pattern is simple: OAuth and OIDC answer who is making the request and how trust was established, while the application decides whether the request is allowed. OIDC provides authentication context through identity tokens, and OAuth provides delegated authorization through access tokens and scopes. Neither one should be treated as a full authorization policy.
In a mature design, the application evaluates token contents alongside runtime context such as user role, device posture, tenant, resource sensitivity, action type, and request origin. That policy layer may live in application code, a central policy engine, or a policy-as-code system. The key point is that token claims are inputs, not final decisions.
- Use OIDC to establish identity assertions, not to grant business permissions directly.
- Map OAuth scopes to coarse capabilities only, then refine decisions with local policy.
- Validate audience, issuer, expiration, and nonce as baseline token checks.
- Separate authentication, delegated consent, and authorization logic into distinct control points.
- Prefer short-lived credentials and narrow scopes for integrations that call sensitive APIs.
This separation matters because the same token can be valid and still inappropriate for a specific action. A token may prove the caller is an approved app, but not that it should delete records, export data, or act across customer boundaries. The risk grows in distributed environments where downstream services assume upstream scope checks are sufficient. NHIMG guidance on the Ultimate Guide to NHIs emphasizes that visibility, rotation, and offboarding must be part of the identity lifecycle, not an afterthought.
These controls tend to break down when teams accept broad consent grants for third-party SaaS apps because the authorization decision is then pushed outside the application boundary.
Common Variations and Edge Cases
Tighter token validation often increases integration overhead, requiring organisations to balance developer velocity against exposure. That tradeoff is real, especially in environments that rely on app marketplaces, customer-managed integrations, or cross-tenant automation.
One common edge case is overloading scopes with business meaning. Current guidance suggests keeping scopes coarse and using a separate policy layer for fine-grained rules, because scope inflation quickly turns OAuth into a pseudo-RBAC system that is hard to audit. Another edge case is treating OIDC claims as proof of authorization for downstream APIs. That is a design smell unless the API independently validates the request against its own policy.
For agentic and automated workflows, the problem becomes sharper because the caller may chain multiple tools and requests unpredictably. In those environments, the safer model is intent-aware authorization with short-lived, least-privilege delegation rather than static permission grants. Incidents such as the Salesloft OAuth token breach and the Dropbox Sign breach show why delegated access must be constrained, monitored, and revocable. There is no universal standard for how much consent is enough across every SaaS integration, so the practical answer is to minimize standing trust and re-evaluate permissions continuously.
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, OWASP Agentic AI Top 10 and CSA MAESTRO define the specific risk controls and attack patterns relevant to this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | OAuth tokens act like long-lived NHI credentials when over-scoped or unrevooked. |
| OWASP Agentic AI Top 10 | A6 | Delegated tokens become dangerous when autonomous tools chain actions beyond intent. |
| CSA MAESTRO | GOV-02 | Maestro governs agent and workload trust boundaries that OAuth alone does not enforce. |
Separate identity proof from authorization and enforce least privilege at each trust boundary.
