On OAuth, SAML and all things auth

When I first had to implement a proper Single Sign-On (SSO) solution, I kind of had no idea what I was getting into. I’d heard of things like Oauth, and OIDC, and other acronyms, and I had a sense of it all, but as with a lot of things, once I dived into the detail I found it to be complex and confusing.

That said, these technologies are crucial when it comes to authentication and authorisation, especially in large applications or SaaS platforms. So what do these terms really mean, and how do they fit together? In this article, I’ll break down the basics of SSO, with a focus on two of the most commonly utilised protocols, OAuth, and Security Assertion Markup Language (SAML). This will hopefully help you understand how they work and when you might use them in your projects.

What is Single Sign-On (SSO)?

It’s all in the name. Single Sign-On refers to a number of different protocols for allowing a user to authenticate once and gain access to multiple applications or services without having to log in again for each one. SSO simplifies the user experience and makes it easier for both users and developers to manage authentication. Importantly, it’s considered to be a preferred option for securing authentication. We’ll dive into each one below.

Oauth misconceptions

Firstly, it should be noted that, unlike SAML, OAuth is not an authentication protocol. OAuth is all about authorization—granting applications permission to access specific resources on behalf of a user. While authorization and authentication are closely related, they are fundamentally different concepts.

The reason why OAuth is often used in an authentication context is that it can facilitate the retrieval of user information (e.g., profile data or email) from another system. This retrieved data can then be used by your application to authenticate the user. However, this usage is indirect—OAuth itself does not verify the user’s identity; it simply enables access to data that might help with authentication.

This distinction was a key point of confusion for me for a long time, as OAuth flows like “Sign in with Google” often look like authentication but are, in fact, authorization processes combined with other mechanisms like OpenID Connect.

SAML: Security Assertion Markup Language

SAML (Security Assertion Markup Language) is another widely used protocol for SSO. Unlike OAuth, which focuses on authorizing access to resources, SAML is primarily used for authentication. It’s an XML-based framework used to exchange authentication and authorization data between services.

Here’s how it works:

1. The user tries to access an application (called the Service Provider, or SP).
2. The SP checks if the user is already authenticated. If not, the user is redirected to an Identity Provider (IdP).
3. The IdP authenticates the user (for example, through a login page), and upon successful login, sends an authentication assertion (a kind of digital ID card) back to the SP.
4. The SP uses this assertion to grant the user access without requiring them to log in again.

SAML is often used in enterprise environments where centralized authentication is needed across multiple applications. For instance, if you’re working in a company with many internal tools, they might use SAML to ensure that employees can sign into all tools with one login.

SAML vs. OAuth

SAML focuses on authenticating the user, while OAuth deals with delegated access (authorization). Although both are used for SSO, they cater to different needs:

• SAML is used in more traditional, enterprise-focused applications where users need to log in once and access several tools within the organization.
• OAuth is more common in modern web and mobile applications, especially those that need to allow users to grant access to third-party services without sharing their passwords.

When Should You Use Each?

• Use OAuth if you’re building an app that needs to interact with third-party services and allow users to grant access to their data without exposing their credentials. OAuth is ideal for cases where you’re enabling delegated access or integrating social logins (like “Sign in with Google” or “Sign in with Facebook”).
• Use SAML if you’re working in an enterprise environment or building apps that require a centralized identity management system. SAML is widely adopted for internal SSO in organizations, allowing employees to access multiple internal tools with one set of credentials.
• Use SSO generally when you want to provide users with the ability to sign in once and access multiple apps seamlessly. Depending on your specific needs, SSO might rely on OAuth, SAML, or other protocols to function.

Wrapping Up

While these terms—OAuth, SAML, and SSO—are often used interchangeably, each has its distinct purpose. SSO is the overarching goal of simplifying authentication across multiple applications. OAuth and SAML are protocols used to achieve that goal, with OAuth focusing on delegated access to resources and SAML focused on authentication.

Understanding these concepts is important when you’re working on user authentication and access control in your apps. Whether you’re building a SaaS platform, integrating with third-party APIs, or managing internal tools, knowing the differences and when to use each will help you provide a better and more secure user experience.