The biggest mistake is treating them as interchangeable login methods. SAML handles authentication, OAuth handles delegated authorisation, and OIDC adds authentication to OAuth for modern login flows. When teams blur those roles, they create brittle integrations, unclear ownership, and access models that are difficult to audit or explain.
Why mixing SAML, OAuth, and OIDC breaks the security model
SAML, OAuth, and OIDC solve different problems, so the first mistake is collapsing them into one generic “SSO” bucket. SAML is an authentication federation protocol, OAuth is an authorization framework, and OIDC layers identity on top of OAuth for modern login. When teams treat them as interchangeable, they usually misplace trust, choose the wrong token type, and create flows that are hard to reason about during incident response or audit.
The practical consequence is that the architecture stops matching the security claim. A system may look like “login” in the UI, but underneath it may be granting delegated access, asserting an identity, or both. That matters because the wrong protocol choice changes who is authoritative for the identity, what the token can do, and which side is responsible for session, consent, and revocation behavior. For a deeper treatment of protocol roles, the OAuth 2.0 and OpenID Connect Guide for Identity Teams is the cleanest starting point.
Another common failure is mixing flows in a way that hides the real trust boundary. Teams often build a SAML bridge into an OAuth/OIDC app, or accept an access token where an ID token should be used, because the integration “works.” That kind of shortcut creates brittle dependencies between the identity provider, the client application, and downstream APIs, which is exactly where security ownership becomes unclear. Where teams need a protocol-grounded reference, OpenID Connect Core 1.0 and RFC 6749: The OAuth 2.0 Authorization Framework make the separation explicit.
Where teams usually get the tokens, audiences, and trust relationships wrong
The most damaging implementation errors are usually not in the sign-in screen, but in token handling. Teams confuse bearer access tokens with identity assertions, over-trust assertions across systems, or fail to bind tokens to the intended audience and client. Once that happens, a stolen token or misrouted assertion can be replayed, accepted in the wrong place, or used to reach data the original design never meant to expose.
That risk grows when teams centralise many integrations behind one identity provider but do not define which protocol is authoritative for each hop. SAML may be appropriate for one enterprise app, OAuth for API delegation, and OIDC for user authentication, but the decision has to be made per trust relationship, not per vendor preference. The protocol choice should also match the object being protected: user session, delegated API access, or federated login. For token audience controls and sender-constrained designs, RFC 8707: Resource Indicators for OAuth 2.0 and RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP) are useful guardrails.
A related mistake is using OAuth as if it proves who the user is. OAuth does not authenticate the end user by itself; it authorizes a client to access a resource under a particular grant. OIDC adds the identity layer, but only if the application validates the ID token correctly and keeps it separate from API authorization. When that line is blurred, teams end up with “logged in” states that are not actually trustworthy, or with APIs that accept the wrong token class. For NHI and service-to-service cases, the same discipline applies to machine credentials and delegated access paths, which is why NHI Authentication Guide is relevant where non-human actors are part of the design.
How to separate protocol roles before the design becomes unauditable
The cleanest way to avoid these mistakes is to assign one primary job to each protocol and write it down in the design review. Use SAML when the business requirement is enterprise federation into a browser-based application and the trust model is built around assertions. Use OIDC when you need modern user authentication on top of OAuth. Use OAuth when an app or client needs delegated access to an API or resource server.
Decision rule: if the question is “Who is this user?”, OIDC or SAML is the right conversation; if the question is “What can this client access?”, OAuth is the right conversation. If a design needs both, document the boundary between authentication and authorization explicitly so reviewers can test the token type, audience, and validation logic independently.
What to verify: teams should be able to show which token is used for login, which token is used for API access, which system issues each token, and which validation rules apply at each hop. If the answer is “the app just accepts whatever the IdP sends,” the design is already too ambiguous to trust. For broader identity governance and role clarity, IAM and IGA Basics helps teams keep authentication, authorization, provisioning, and access review distinct.
Practitioner takeaway: the best integration is not the one with the fewest moving parts, it is the one where every token, assertion, and flow has a single, defensible purpose that auditors and operators can trace end to end.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V10 — OAuth and OpenID Connect | The question is about separating OIDC login from OAuth authorization flows. |
| Recommendation — Validate that login uses OIDC and API access uses OAuth with the correct token checks. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | SAML and OIDC mistakes often start with incorrect user authentication design. |
| IA-9 — Identification and Authentication (Non-Organizational Users) | Federated SSO and external identity providers are central to SAML and OIDC integrations. | |
| AC-3 — Access Enforcement | OAuth is fundamentally about enforcing delegated access to protected resources. | |
| Recommendation — Require explicit authentication assurance and token validation for user sign-in flows. Verify federated authentication trust and constrain accepted assertions and tokens. Enforce access decisions at the resource server based on scoped, validated authorization. | ||
| NIST CSF 2.0 | PR.AA-01 — Identity Management, Authentication and Access Control Policies and Processes | The topic is about keeping authentication and authorization roles separate. |
| Recommendation — Define protocol-specific identity and access policies for SAML, OAuth, and OIDC. | ||
Related resources from NHI Mgmt Group
- What mistakes do teams make when they treat SCIM and SAML as interchangeable?
- What mistakes do teams make when they treat OpenID and OAuth as interchangeable?
- What mistakes do teams make when they treat password managers as optional convenience tools?
- What mistakes do teams make when they try to document SOC procedures?