Yes, when they need enterprise login through SAML and resource-level delegation through OAuth. The key is to separate the policy decisions. SAML should control who authenticated, while OAuth should control what access was delegated, for how long, and under what scope.
Why This Matters for Security Teams
Yes, SAML and OAuth are often complementary, but only if each protocol is used for its own job. SAML is best for asserting enterprise authentication and central login, while OAuth is better for delegated access to APIs and downstream services. The risk appears when teams blur those boundaries and let an authentication signal become an authorisation decision.
That mistake shows up in real incidents. oauth token abuse has been central to breaches such as the Salesloft OAuth token breach, where access delegation became the path to data exposure rather than the login itself. Similar patterns appear in the Dropbox Sign breach, where third-party access and token handling widened the blast radius. Current guidance suggests using NIST Cybersecurity Framework 2.0 principles to separate identification, access control, and monitoring, instead of treating one protocol as a complete identity solution.
Only 1.5 out of 10 organisations are highly confident in securing non-human identities, and OAuth-connected third parties remain poorly visible in most environments, which is why mixed SAML and OAuth designs often fail at the seams rather than in the login flow. In practice, many security teams encounter privilege creep only after a token has already been reused, over-scoped, or shared beyond its intended session.
How It Works in Practice
The safest pattern is to let SAML establish the user’s identity at the edge, then let OAuth carry narrowly scoped delegation into applications and APIs. SAML should answer: who authenticated, through which enterprise controls, and under what assurance level? OAuth should answer: what can be done, on which resource, for how long, and with what consent or policy basis?
In practice, that means using SAML for workforce single sign-on, then issuing OAuth access tokens only after policy checks confirm the user, device, application, and session meet the required conditions. The token should be short-lived, scoped to a specific API or data set, and bound to the minimum permissions needed. For higher-risk functions, organisations should add step-up verification or just-in-time elevation rather than expanding the base token scope. This aligns with the operational direction of NIST Cybersecurity Framework 2.0 and the access-control emphasis in modern Zero Trust programmes.
- Use SAML for authentication and session establishment, not for downstream API authorisation.
- Use OAuth scopes to constrain resource access, not to substitute for identity governance.
- Rotate and revoke tokens aggressively, especially where third-party apps are involved.
- Log token issuance, consent, refresh, and revocation events so access paths are reconstructable.
That model is especially important when agents, automations, or service integrations chain multiple tools together, because one over-permissioned token can move laterally across systems faster than a human session ever could. The Hugging Face Spaces breach is a reminder that delegated access in connected environments can become the weakest point, not the strongest control. These controls tend to break down when legacy identity providers issue broad, long-lived tokens to loosely governed integrations because the token outlives the policy context that justified it.
Common Variations and Edge Cases
Tighter token governance often increases integration overhead, requiring organisations to balance user experience against delegation risk. That tradeoff is unavoidable in environments that mix enterprise SSO, customer-facing apps, and machine-to-machine access.
One common edge case is when SAML-authenticated sessions are used to launch apps that then request OAuth tokens on behalf of the user. That can be acceptable, but only if consent, scope, and refresh logic are tightly controlled. Another is service-to-service communication, where SAML usually adds little value and workload identity plus OAuth client credentials, or another machine identity pattern, is often cleaner. Best practice is evolving here, and there is no universal standard for every application stack.
Teams also need to watch for confused-deputy problems, where one app uses a valid token to access data the user never intended to expose. This is where intent-based authorisation, short-lived secrets, and explicit resource scoping matter more than broad RBAC groups. If third-party applications are common, visibility into connected OAuth apps should be reviewed alongside identity governance, because delegated access often persists long after the original business need has ended.
The practical rule is simple: use SAML to prove the session is legitimate, use OAuth to limit what that session can do, and do not let either protocol expand into the other’s role.
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 NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Token rotation and revocation are central to safe OAuth delegation. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions must be constrained when SAML and OAuth coexist. |
| NIST AI RMF | GOVERN | Mixed identity flows need clear accountability and policy ownership. |
Assign ownership for identity policy decisions and review delegated access behaviour continuously.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on May 31, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
