The 3 best alternatives to SAML SSO

Despite SAML being extremely popular as the SSO protocol of choice for enterprise apps over the last few decades, it has a few significant drawbacks — it’s complex to implement, struggles in mobile and API-centric environments and doesn’t support modern authentication methods like social logins.

SAML alternatives like OAuth, OIDC, and WS-Fed, however, are more flexible and developer-friendly.

In this article, we’ll compare these 3 SAML alternatives and explore how they address some of the disadvantages of using SAML.

Why look for a SAML alternative?

Key reasons to explore SAML alternatives include:

It’s complex to implement securely

SAML relies on XML for data exchange, which is hard to read and parse especially compared to more concise formats like JSON used in other protocols like OIDC.

SAML’s reliance on XML also introduces potential vulnerabilities specific to XML, such as XML Signature Wrapping and XML External Entity Injections that you’ll need to safeguard against in your implementation. You’ll need a thorough understanding of XML digital signatures and how to validate them. Beyond this, your app must also validate SAML responses against the SAML spec and the schema you expect from the IdP.

Solution: Use OIDC, it’s more developer-friendly and far easier to secure.

It’s not great for mobile app or APIs

SAML was designed in the early 2000s, an era when desktop browsers were the primary means of accessing web apps. As such, its flow is not optimized for mobile apps or APIs.

For instance, the heavy XML payloads are not ideal for mobile networks, where speed is key and the redirect-based flows common in SAML are less suited to the stateless nature of APIs.

Solution: Use OIDC for lightweight authentication tokens in your mobile apps or stateless APIs.

It doesn’t support alternative forms of authentication like social logins

These days, users expect a variety of authentication methods, including social logins (like Google, Facebook, or Twitter).

SAML, by design, does not natively support these alternative forms of authentication, focusing instead on enterprise scenarios where traditional credential-based or multi-factor authentication (MFA) methods are more popular.

Solution: Use OIDC for social authentication.

The 3 best SAML alternatives

Below are some of SAML alternatives:

• OAuth 2.0: A protocol designed for access delegation though it’s often misused for SSO.
• OpenID Connect (OIDC): An easy to use SAML alternative that builds on top of OAuth.
• WS-Fed: An SSO protocol commonly used in Microsoft-based environments.

#1: OAuth 2.0

OAuth 2.0 is an authorization framework designed to grant permissions from one party (the resource owner) to another (the client/application) to access specific resources on the owner's behalf, without sharing the owner's credentials. However, while it’s fundamentally about authorization (granting permission to use resources), it’s sometimes used in scenarios that mimic SSO by issuing tokens that grant access to multiple services or applications, provided those services accept the OAuth 2.0 tokens as valid for both authorization and authentication.

This misuse for SSO stems from conflating authorization with authentication. OAuth 2.0 provides tokens to access resources but doesn't inherently verify the identity of the user to the applications. This led to improvised, non-standardized methods of using access tokens as a proxy for authentication. Each application or service using OAuth 2.0 for SSO had to devise its own method to extract or assume identity information from the authorization process.

This lack of a standard way to obtain or convey the authenticated user's information led to the development of OIDC.

#2: OpenID Connect (OIDC)

OpenID Connect (OIDC) is an authentication layer that extends OAuth 2.0. It allows you to verify user identity and obtain basic profile information in a REST-like manner.

OIDC introduces the ID token, a JSON Web Token (JWT) that contains claims about the end-user's authentication status. This token serves as proof of the user's identity, standardizing how applications can securely authenticate users.

Here’s a simplified overview of how the OIDC SSO flow works:

1. The user attempts to access a protected resource or service (your application) that requires authentication.
2. The app recognizes that the user is not authenticated and redirects them to the IdP for authentication.
3. The user is presented with a login screen from the IdP where they authenticate (if they haven’t logged in already).
4. Upon successful authentication, your app receives a single-use authorization code. It then requests the ID token and access token from the IdP providing both the authentication code and its own credentials to the IdP.
5. The IdP validates the authentication code, the application's credentials, and issues the ID token and access token to the application.
6. Your app can then validate the ID token and set up a local session.

This process broadly describes the authorization code flow, popular with server side apps but OIDC defines several other flows to accommodate different types of clients, from web and mobile applications to single-page applications (SPAs).

Like SAML, OIDC supports both authentication and authorization. However, it does so in a more simplified, JSON-based workflow that’s easier to implement. This can be attributed to various reasons:

• JWTs are easier to read and parse and less resource-intensive than SAML’s XML-based assertions.
• It leverages the specialized OAuth flows so you don’t have to use one authentication flow for all your apps.
• It uses a far more simple digital signature scheme than SAML, which eliminates the security vulnerabilities that come with improperly validating signatures in SAML.

Because of this simplicity and support from major enterprise IdPs, OIDC is a great alternative to SAML SSO.

Besides enterprise SSO, you can also use OIDC to enable social logins via providers like Facebook, GitHub, and LinkedIn.

Another area that OIDC shines is stateless authentication since ID tokens can be self-contained i.e contain all the information required to validate their authenticity.

#3: WS-Federation

WS-Federation is part of the larger WS-* (WS-Star) family of SOAP-based specifications for web services. It enables identity federation, allowing users to authenticate once and access services across different network/security zones, thus providing an SSO experience.

Here’s how WS-Fed works for SSO:

• A user attempts to access a protected resource (e.g. your application) which redirects the user to their IdP.
• The IdP authenticates the user (if not already authenticated) and issues a token that encapsulates the user's identity and possibly other attributes. This token is often formatted according to the SAML standard.
• The IdP redirects the user back to the app with the token attacked.
• The app validates the token and grants access based on the identity and attributes it contains, allowing the user to access the service without needing to authenticate again.

Like SAML, WS-Federation is widely used for web-based SSO. However, WS-Fed is limited to enterprise environments where interoperability with existing Microsoft-based infrastructure is essential.

Which SAML alternative is right for me?

The choice of which SAML alternative to use — whether it be OpenID Connect (OIDC), or WS-Fed — depends on the specific needs and preferences of your customer base.

That said:

• If you’re primarily concerned with getting access to user data without validating their identity, use OAuth 2.0.
• If you want an easy to implement and secure way of adding SSO in your app use OIDC.
• If you’re planning on supporting a legacy Microsoft ecosystem, use WS-Fed.

Note: SAML is still a popular choice, especially with corporate IdPs, so you might want to support it too.

FAQs

What is SAML?

SAML (Security Assertion Markup Language) is a standard for exchanging authentication and authorization data between parties, specifically between an identity provider and a service provider, using XML.

What are some common SAML alternatives?

Common alternatives to SAML include OpenID Connect (OIDC), and WS-Fed. OIDC extends OAuth 2.0 to add authentication is by far the easiest to implement while WS-Fed is mostly common in legacy Microsoft-based environments.

What are the advantages of using a SAML alternative?

Alternatives to SAML, such as OIDC, offer greater flexibility, better suitability for mobile and API-based apps, and a more developer-friendly implementation.

Conclusion

Most corporate identity providers support OIDC and SAML SSO. To enable both and get your app enterprise ready, use WorkOS and connect your app to all the major identity providers your customers use (like Okta, OneLogin, and PingFederate) with a single API-based integration.

• Get started fast: With SDKs in every popular language, easy-to-follow documentation and Slack-based support, you can implement SSO in minutes rather than weeks.
• Support every protocol: With OAuth 2.0 integrations to popular providers like Google and Microsoft, compatibility with every major IdP, and full support for custom SAML/OIDC connections, WorkOS can support any enterprise customer out of the box.
• Avoid the back-and-forth: WorkOS’s Admin Portal takes the pain out of onboarding your customers’ IT teams and configuring your app to work with their identity provider.
• Pricing that makes sense: Unlike competitors who price by monthly active users, WorkOS charges a flat rate for each company you onboard - whether they bring 10 or 10,000 SSO users to your app.

Explore Unified SSO by WorkOS.