What is SAML authentication and how does SAML work? A comprehensive guide

You want to lower costs, enhance usability and boost security in your authentication processes, right?

Not all types of authentication are created equal. For most, looking for a solution that is smart, smooth and secure is a top priority. It’s a win-win that makes things easier for you and your end user.

That’s where SAML authentication comes in. It’s a standardized language that works alongside Single Sign-On (SSO) tech to fast-track user logins, tighten security and make memorizing stacks of complex unique passwords a thing of the past.

Authentication is all about figuring out if someone is who they say they are. But what if there was a standardized way to confirm a user’s identity across all kinds of services and apps?

That’s exactly what Security Assertion Markup Language (or SAML, for short) enables. It’s also what makes single sign-on (SSO) a reality. Rather than authenticating yourself time and time again, SAML and SSO work hand-in-hand to authenticate you once and unlock access to multiple apps.

Many of the SaaS tools you’re already using are harnessing the power of SAML. Instead of creating new sets of login credentials for each platform, you can use your email or social media logins to gain access.

It’s also a secure method of authentication, safeguarding an app’s security while streamlining the login experience for users.

Currently, the latest version of SAML available is SAML 2.0. (but more on the later).

If SAML is the universal language or access card that enables you to use multiple apps with one set of credentials, SSO is the tech that makes it happen.

Here’s how SSO works: when you sign into an SSO service an authentication token is created that remembers who you are. When you try to log in to an app using SSO, your token will be the key that grants you access.

Whether you’re signing up to a new platform or logging back in, SSO fast-tracks the process of confirming your identity. You’ve likely used it already, whether that’s signing into Spotify through your Facebook account or using your Gmail logins to gain access to Hubspot.

Ease and efficiency are some of the biggest draw cards for users, removing the need to confirm your identity repeatedly across multiple platforms. On the app side, SSO boosts security and lowers costs (with the ability to outsource the legwork of building and maintaining authentication systems in-house).

So, what makes SAML a universal language? It’s an XML-based open standard that enables identity data to be transferred between two parties: identity providers and service providers.

There are actually three key players that make SSO possible:

• The Principal (sometimes known as the “subject”): the user trying to access an app.
• Identity provider (IdP): the service that performs authentication, stores and confirms a user’s identity.
• Service provider (SP): the app or service the user wants to access who trusts the identity provider and authorizes access.

The authentication process looks like this: users log in once (using SSO) with an IdP. Then, the IdP is able to share these SAML attributes with an SP every time a user tries to gain access.

By speaking the same language (SAML), IdPs and SPs can communicate easily and ensure users only need to enter their login credentials once.

Often it’s easier to understand how SAML works by diving into an example workflow. In the real world, SAML works like this:

• A user wants to log in to their Slack account using their existing Gmail credentials.
• Slack requests authentication from the user’s identity provider (in this case, Gmail).
• Gmail sends a SAML assertion to Slack, which allows the user to seamlessly log in to Slack without creating a new password or entering new login credentials.
• Now, the user can access Slack.

A key part of the feedback loop that makes SAML authentication possible is this: a SAML assertion. It’s a message created by IdPs that are sent to SPs to confirm that a user is signed in.

Browser redirects are key to SAML assertions, allowing them to be sent from IdPs to SPs and enabling a fast-tracked login experience for users.

You’ll find a bunch of important authentication details contained in this message (shared as standardised XML documents), including:

• The source of the assertion
• The time the assertion was issued
• The conditions that make this assertion valid

The role of SAML assertions is to share details about a user’s identity, authentication and authorization status.

Things can be broken down even further into the three types of SAML assertions:

1. Authentication assertion: this is all about confirming that a user has been authenticated, including the time, method and user being authenticated.
2. Attribute assertion: this is about linking the user with the specific attributes needed to authenticate access. It involves sharing a defined piece of information (such as login credentials).
3. Authorization decision: this is all about confirming whether a user’s login request has been approved or declined.

SAML authentication needs two key providers to work effectively: an identity provider (IdP) service provider (SP).

These providers are systems that allow the authentication process to take place and ensure users gain access to the apps, platforms and software they need.

SAML providers are building blocks that allow this type of authentication to happen. Plus, it gives apps the flexibility to decide how SSO takes place, too.

There are two types of ways to initiate SSO:

• IdP-initiated SSO: users need to log into an IdP’s SSO page, and then they’ll be redirected to the app or platform.
• SP-initiated SSO: users need to log in directly to an app’s login screen. This will send an authorization request to the app’s IdP. Once the user’s identity is authenticated, they’ll be able to log in and access the app.

Users have grown to expect fast, convenient experiences from the tools they use. Digging up lengthy passwords and creating unique credentials for every site they use adds friction, slows users down and can decrease engagement with a platform.

On the app side, traditional methods of authentication (like one-factor authentication) can be tedious, resource-intensive and expensive to maintain. That’s because you need to wear the hats of both IdP and SP, and cover the costs of keeping a user’s information safe and secure.

SAML authentication (powered by SSO) makes these pain-points obsolete. It saves time, lowers costs and reduces security risks for all involved.

The big draw cards of SAML authentication include:

• Improved user experience: smoother login processes are what will make users pick your platform (and keep them coming back time and time again). By leveraging one set of credentials your user already knows, you can streamline the login experience and remove the need for individuals to remember a long list of complex passwords.
• Increased security: with a single point of authentication, SAML transfers user information securely from IdPs to SPs directly. For companies, this removes the need for multiple login details among employees and consolidates access to one set of credentials. Plus, it dramatically reduces the risk of identity theft, phishing attacks and outside intruders invading secure platforms, too.
• Loose coupling directories: a big benefit of SAML is that it removes the need for users’ information to be maintained and synchronized between directories. Talk about unlocking operational efficiencies.
• Reduced costs for service providers: plus SAML lowers expenses for SPs by removing the need to maintain account information across multiple services. Instead, this expense sits with IdPs.

While these processes are interconnected, authentication and authorization play distinct roles. In the case of SAML, it only comes into the picture during user authentication (not authorization).

Here’s a quick refresher on the differences between authentication and authorization:

• Authentication relates to a user’s identity and whether they are who they say they are.
• Authorization relates to a user’s level of access and permissions (such as what documents or resources they can access in a platform).

Let’s say a new employee joins a company. With SAML authentication set up, this new starter can use one set of credentials to log in to their company’s employee portal. From here, authorization is what will decide which apps, documents and files they are able to access.

SAML isn’t the only secure protocol used to share identity data. OAuth is the other key player, which offers greater ease of use and flexibility when it comes to how it’s used.

Also known as OAuth (a.k.a. “Open Authorization”), this framework has been around since 2012. It allows a third-party app or site to access a user’s secure resources, without needing to enter credentials or even their identity.

OAuth offers consented access through Access Token (pieces of data that authorize access to resources on behalf of the user). Unlike SAML, these Access Tokens don’t follow a standardized format, but the JSON Web Token format (JWT) is often used as a way to include data in the token itself.

Already, you can probably tell the big difference between OAuth and SAML: OAuth is all about authorization, while SAML is focused on authentication.

Another key distinction is the naming of roles in OAuth, which include:

• Resource Owner: the owner of the protected resource who controls and grants access.
• Client: the system requesting access to the protected resource. For this to happen, the Client needs the right Access Token.
• Authorization Server: the server that receives requests from the Client for Access Tokens. There are two important endpoints linked with the Authorization Server: the Authorization endpoint (which consents access for the user) and the Token endpoint (which allows for a machine-to-machine interaction).
• Resource Server: the server that receives access requests from the Client. This server validates Access Tokens and unlocks the right resources.

In AuthO, requests are kick-started by the Client (such as a mobile app or website). From there, a flow takes place that allows a token to be requested, exchanged and resources to be unlocked.

But before AuthO can be used, a Client needs to acquire their own credentials from an Authorized Server. When requesting an Access Token, these credentials are what will identify and authenticate the Client.

Generally, this flows looks something like this:

• The Client makes an authorization request from the Authorization Server.
• From here, the Authorization Server checks that the Client has the right permissions to the resources they’re trying to access.
• That involves the Resource Owner communicating with the Authorization Server to approve and grant access.
• Then, the Authorization Server redirects to the Client with either an Authorization Code or Acces Token.
• With their token on hand, the Client can gain access to this resource from the Resource Server.

There are a few technical differences between OAuth and SAML, such as the way encryption happens. SAML uses a complicated encryption process with lengthy exchanged messages and a defined token format.

Instead, OAuth relies on HTTPS and doesn’t use message encryption or require a standardized token format.

What makes OAuth compelling is the flexibility it offers. In fact, it can be used across mobile devices, smart TVs, apps and beyond. The simplicity of its access tokens is especially appealing for consumer apps that don’t require such a sophisticated level of encryption.

In contrast, SAML’s complex design makes it more difficult to use across a range of placements. Instead, it’s more commonly used in traditional web apps as well as SSO in both government and enterprise-level apps.

Currently, the latest version of SAML is SAML 2.0. (replacing SAML 1.1). It’s the most up-to-date version and has been in use since 2005.

While a range of systems do support earlier versions of the protocol (including SAML 1.1), SAML 2.0 is widely accepted as the modern technical standard.

At Kinde, we’re making authentication (such as SAML) simple and powerful to help companies boost security, drive conversion save money - in just a few minutes.

We’ve made getting set up with Kinde as stress-free and easy as possible. With best-in-class security protocols, an intuitive user-friendly UI that’s built for everyone, and powerful and easy-to-use APIs, we’re here to get you up and running in minutes.

See how Kinde compares to other authentication providers.