SAML fails when teams assume a federated identity assertion can also solve delegated access design. That creates blurry ownership for session creation, overly broad trust in the upstream identity provider, and weak separation between authentication and authorisation. The result is governance drift, not a protocol flaw. Teams should keep the control boundary explicit and review it separately from application integration work.
Why SAML breaks when you treat it like an OAuth authorisation flow
SAML is built to carry an identity assertion from an identity provider to a service provider, then let the application decide what that assertion means. OAuth is built to delegate access to protected resources. When teams blur those jobs, they often let a login assertion stand in for scope, consent, resource audience, and delegated authority, which creates integration shortcuts that look convenient until ownership and enforcement need to be audited.
The cleanest way to see the mismatch is to compare the two protocols at the control boundary. SAML can authenticate a user, but it does not express the same access model as OAuth grants and tokens. That is why implementation details around audience, session establishment, and downstream authorisation need to stay in the application design, not be assumed away by federation alone. For the underlying OAuth mechanics, the RFC 6749: The OAuth 2.0 Authorization Framework is the right baseline, and OpenID Connect shows how identity and authentication are layered separately on top of OAuth in modern designs, as in OpenID Connect Core 1.0.
Practically, the failure appears when a team says, “We already have SSO, so we also have delegated access.” That leap encourages overreliance on the upstream identity provider, ambiguous session creation rules, and weak separation between who proved identity and who may act on data or perform actions. The protocol usually works as designed, but the operating model becomes sloppy.
Where the control boundary gets blurred in real implementations
The most common failure point is session ownership. If the application accepts a SAML assertion and then quietly creates a long-lived application session without a separate authorisation decision, the IdP starts to look like the real policy engine. That is risky because the IdP may not know the application’s resource model, consent model, or step-up requirements.
A second failure point is audience and delegation confusion. SAML asserts that an authenticated subject is trusted for a relying party, but that is not the same as saying the subject can call arbitrary APIs, act on behalf of another user, or reuse the same session in another system. When teams need those behaviours, they should design explicit delegation flows rather than stretching federation beyond its purpose. If the integration really needs OAuth-style delegated access, the application should use an access-token model that can express audience and scope, such as the OAuth controls in the RFCs above and the token-bound patterns in RFC 9700: Best Current Practice for OAuth 2.0 Security.
A third failure point is trust expansion. Teams sometimes treat the IdP as proof that every downstream action is safe, so they underinvest in application-level checks, consent boundaries, and privileged operations review. That is how a federation decision becomes a governance shortcut instead of a security control.
Why governance drift matters more than the protocol label
The real issue is not whether SAML “supports” access. The issue is whether the system preserves a clear division between authentication, authorisation, and operational ownership. When that division is absent, developers, IAM teams, and application owners all assume someone else is enforcing the boundary, which creates blind spots in review, incident response, and exception handling.
That drift often shows up as brittle exceptions, overbroad trust relationships, and poor traceability for who approved what. In large environments, the problem compounds because federation becomes the default answer for every integration, even when the application needs a tighter, resource-specific control model. For teams that are moving toward more explicit machine or service delegation patterns, the Ultimate Guide to NHIs helps distinguish identity material from access design, while the OAuth 2.0 and OpenID Connect Guide for Identity Teams clarifies where authentication ends and delegated authorisation begins.
The better pattern is to treat federation as an input to the application, not as the application’s authorisation system. Once you do that, session creation, token handling, privilege checks, and user-to-resource mapping stay visible where they can be tested and governed.
Risk and Threat Considerations
When SAML is used as if it were an OAuth replacement, the main risk is not a broken assertion format. The risk is that applications start trusting a login event as if it also authorised downstream action, which widens the blast radius of IdP compromise, misconfiguration, or overly permissive federation trust.
Failure mechanism: A valid SAML assertion is accepted as sufficient proof for creating broad or durable application access, so the application skips its own delegation, audience, and privilege checks.
Impact: Attackers who obtain or replay trusted identity assertions, or defenders who misconfigure trust boundaries, can gain access that is much broader than the original authentication event justified.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V10 — OAuth and OIDC | The question concerns the boundary between authentication federation and delegated authorization in web systems. |
| Recommendation — Verify that authentication federation is separated from authorization design and token handling. | ||
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Access decisions must remain enforceable at the application boundary, not implied by federation alone. |
| IA-2 — Identification and Authentication (Organizational Users) | SAML participates in authenticating users, but authentication is distinct from access control. | |
| Recommendation — Enforce application-level access checks after identity federation. Authenticate users separately from deciding what actions they may perform. | ||
Practitioner Guidance
What to verify: Check whether the application makes a separate authorisation decision after SAML login, or whether it converts assertion acceptance directly into access. If the latter is true, the integration is already carrying OAuth-like delegation pressure without OAuth-like controls.
Decision rule: If the system needs consent, scoped API access, or on-behalf-of delegation, design an explicit delegated-access flow instead of widening the SAML trust relationship. If it only needs user authentication, keep the SAML boundary narrow and keep privilege decisions local to the application.
Common mistake: Treating “single sign-on works” as proof that the trust model is sound. In practice, the control that fails is usually the handoff between login and action, not the federation handshake itself.
Practitioner takeaway: SAML should establish who the user is, but the application must still decide what that user may do, because delegated access and authentication are not the same security problem.