Choose the protocol based on the access problem you are solving. SAML fits web-based enterprise SSO across multiple applications. OpenID Connect works well for modern authentication in consumer-facing and mobile apps. OAuth is for delegated authorization, not login. LDAP is best for centralized directory lookup and user management, especially in on-premises environments.
How to decide which protocol fits which access problem
The cleanest way to choose is to start with the security function you need, not the protocol name. SAML, openid connect, OAuth, and LDAP solve different problems: federated login for web apps, modern authentication for apps and mobile, delegated authorization for APIs, and directory lookup or identity data access in managed environments. Treat “single sign-on” as an outcome, not a protocol category.
That distinction matters because the wrong protocol can create awkward workarounds, such as using an authorization protocol as if it were an authentication standard, or forcing an older directory protocol into a role it was never designed to fill. The best choice is usually the one that matches your application type, trust model, and integration boundary with the fewest compensating controls.
For enterprise browser SSO across multiple internal applications, SAML remains a strong fit because it is built around browser-based assertion exchange and established identity provider trust. For modern web, SPA, mobile, and API-adjacent login flows, OpenID Connect is usually the better default because it adds an identity layer on top of OAuth 2.0. For internal directory-backed user lookup, LDAP stays useful when you need centralized directory reads, attribute queries, or legacy integration support.
Where OAuth belongs, and where it does not
OAuth is often misused because it is widely deployed alongside login systems, but its purpose is delegation, not user authentication. If the business question is “can this client application act on this resource?” then OAuth is the right family. If the question is “who is the user?” then OAuth alone is insufficient and should be paired with an identity protocol such as OpenID Connect.
This distinction becomes especially important when applications request access on behalf of users or services. OAuth scopes, token audience, and consent handling can be appropriate for API access, but they do not by themselves establish a complete sign-in experience. A sound architecture avoids collapsing authentication and authorization into one token flow just because the integration is convenient.
LDAP, by contrast, is not a federation protocol. It is best viewed as a directory access mechanism for lookup, provisioning support, and attribute retrieval. In modern architectures, it often sits behind the authentication or authorization layer rather than replacing it. For many organisations, it remains relevant because of legacy directories, on-premises estates, and applications that still expect directory-based queries.
Protocol choice should follow application type, trust boundary, and operational lifetime
The practical decision is driven by where the application lives and how long the integration must survive. SAML is usually easiest to justify for browser-centric enterprise SSO, especially where the organisation already has an identity provider and established federation patterns. OpenID Connect is the more future-proof choice for cloud-native applications, consumer identity, and mobile experiences because it aligns more naturally with token-based sessions and modern application design.
OAuth is the right choice when the integration is about access delegation, service-to-service authorisation, or scoped API calls. LDAP is the right choice when the primary need is directory-centric identity data, not federated sign-in. In practice, many organisations use more than one protocol: for example, OpenID Connect for login, OAuth for API access, and LDAP only where the application stack still depends on directory services.
When the architecture spans older and newer systems, protocol selection is often a migration decision as much as a technical one. A protocol may be the right short-term bridge, but not the best long-term identity layer. That is why teams should evaluate maintenance burden, browser support, mobile support, token handling, and how much identity logic must remain in the application versus the identity provider.
Risk and Threat Considerations
Protocol misuse creates real security exposure, especially when teams treat “SSO” as a single interchangeable capability. The main risks are broken authentication, overbroad access grants, token theft, directory overexposure, and brittle integrations that become hard to govern as the estate grows.
Failure mechanism: When OAuth is used as a login substitute, the application may accept delegated access without a clear identity assertion, which can blur user authentication and authorised API access. When LDAP is exposed or over-relied on, sensitive directory data and legacy trust assumptions can expand the attack surface.
Impact: The result can be account confusion, privilege mistakes, replayable tokens, weak session boundaries, or an integration pattern that is difficult to secure consistently across browsers, mobile clients, and backend services.
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 | Covers correct use of OAuth for delegated access and OIDC for authentication. |
| Recommendation — Use V10 to separate login from delegation and require the right token flow for each. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Supports selecting federation and login controls for workforce SSO. |
| IA-8 — Identification and Authentication (Non-Organizational Users) | Relevant when the SSO choice covers consumer or external users. | |
| AC-2 — Account Management | Directory-backed LDAP use affects account lifecycle and centralized identity administration. | |
| Recommendation — Apply IA-2 to ensure workforce sign-in uses a valid authenticated identity. Use IA-8 when external users need federated authentication and identity assurance. Use AC-2 to govern account creation, changes, and removal tied to directory identity. | ||
Practitioner Guidance
What to prioritise: Define the primary access problem before selecting a protocol. If the control objective is user sign-in, start with OpenID Connect or SAML; if it is scoped resource access, start with OAuth; if it is directory lookup, start with LDAP.
What to verify: Confirm that the chosen protocol matches the client type and trust boundary. A browser SSO design, a mobile login flow, and an API delegation flow should not be forced through the same pattern simply to standardise tooling.
Common mistake: Do not let a legacy directory protocol become the default identity architecture, and do not let OAuth become the default answer to authentication questions. Those shortcuts usually shift complexity into the application and increase long-term risk.
Practitioner takeaway: Choose the protocol by the security job it must do, not by what is already familiar in the environment; the best SSO design is the one that keeps authentication, authorization, and directory access cleanly separated.
