The Security Assertion Markup Language—or SAML, for short—allows a user to be authenticated once, then have their credentials shared across different domains. In other words, someone can log in to one website to confirm their identity and access other web applications using the same credentials without having to log in again. This trusted, multi-domain standard can be used for both authentication and authorization. As a result, users have a single sign-on (SSO) experience that lets them leverage their identity provider credentials for other applications that support SAML.
The history of SAML
SAML was created to address a common problem—establishing credentials across domains.
If a user is staying within one domain, cookies can be used to maintain authentication with SSO. But cookies can’t be transmitted between DNS domains. To address this issue, developers used proprietary SSO systems to establish authentication among domains. But these SSO solutions didn’t communicate with each other, which meant multi-domain authentication would only work if all of the domains were using the same SSO solution from the same vendor.
SAML was created as a way to establish authentication across multiple domains. SAML is an open standard, which means that it’s available for anyone to use. It is overseen by the Organization for the Advancement of Structured Information Standards (OASIS), an industry-based standards group. OASIS first approved a version of SAML in 2002 and adopted the current standard, SAML 2.0, in 2005.
Benefits of SAML
SAML is a widely used solution because it improves security, provides a streamlined user experience, and allows identity and service providers to maintain independence from each other while still enabling access for common users.
Streamlined security and user management
SAML is valuable in large part because it lets admins centrally manage users. With SAML, the user’s credentials are only stored on the identity provider’s system—not the service provider’s system—which means you can manage users, roles, and other data from one environment. This allows identity provider’s systems and apps to be developed and advance independently. In addition, by keeping the credentialing requirements within one environment, SAML encourages those organizations to spend more resources to put comprehensive identity security safeguards in place.
Similarly, IT departments that do not want to have this burden may be able to simply subscribe to a credentialing system rather than trying to manage and maintain credentialing internally.
Better user experience
SAML simplifies the user’s experience by letting them use one sign-in to access multiple domains. Rather than having to remember and then enter their credentials (e.g., username and password) each time, the user simply navigates to the web application. Having one sign-in means it’s much easier for them to manage their passwords and other credentials, which also reduces the need for costly, time-consuming IT support.
More service provider solutions
SaaS providers simply need to implement SAML rather than concern themselves with the nuances of identity security. As a result, users have access to more service-based solutions.
All the benefits of SSO
Single sign-on (SSO) plays a critical role in safeguarding data because it centralizes authentication in one system and allows for more oversight and control of users (including the ability to add, modify, or remove access from one system). SAML SSO extends the usefulness of SSO across domains, which results in a seamless user experience across multiple web applications.
How does SAML work?
Before we get into the transaction flow, let’s talk about a few key terms—providers and assertions.
A SAML provider is a system that is involved in authenticating a user. There are two types of SAML providers:
- Identity providers (IdP) hold the original credential information about the user, typically including the user’s identity and authorization level. The IdP (which is sometimes called the SAML asserting party or SAML authority) performs the authentication then shares the relevant information with the service provider. Microsoft Active Directory is an example of an identity provider.
- Service providers (SP) provide access to the user based on the authentication (and, in some cases, authorization) that the SP receives from the identity provider. Salesforce is an example of a service provider. A service provider is sometimes called the SAML relying party.
The identity provider communicates with the service provider by sending them a SAML assertion. The assertion is simply an XML document that includes statements about the user’s authorization status.
There are three main types of SAML assertions.
- Authentication assertions confirm the user’s identity and include details about the user’s authentication method (2FA, email and password, etc.) and login time.
- Attribution/assigned assertions pass SAML attributes from the IdP to the SP; these attributes provide specific information about the user (e.g., their level of access).
- Authorization decision assertions confirm that the user is authorized to use the service or deny the request based on inadequate rights, password failure, etc.
SAML, step by step
Now that you know what providers and assertions are, you can understand what SAML does: allow SPs to authenticate and authorize users by sharing data between an IdP and one or more SPs, using SAML assertions.
Here’s a step by step breakdown of how SAML extends authentication from the IdP to the SP.
Step 1: Admins for the IdP and SP agree to establish a trusted relationship using SAML and set up the exact configuration through a one-time process; all SAML transactions between the IdP and the SP are configured to use Extensible Markup Language (XML).
Step 2: A user tries to access an SP that relies on an IdP for authentication.
Step 3: The SP sends a SAML request to the IdP; the SP requests information that may include authentication state, logins, and other attributes relevant to authorization and authentication.
Step 4: The identity provider parses the request.
Step 5: If the user is already logged in to the IdP, the IdP authenticates the user’s credentials then passes the credentials to the SP using one or more SAML assertions; if the user is not logged in, the IdP prompts the user for their credentials and then, once it receives them, passes authentication to the SP.
Step 6: The SP allows the user access to the application.
A SAML-fueled road trip
Here’s a real-life example to show you the power of SAML:
- An employee of ABC Corporation needs to rent a car—perhaps because they want to take a scenic road trip from Stytch’s New York office to our San Francisco office.
- ABC Corp. employees rent cars fairly often, so to make it easier for them, ABC Corp. set up SAML between their site and their preferred rental car company, Z-Best Rental Cars.
- The ABC Corp. employee logs in to their main ABC Corp. website using their usual username and password; the employee then navigates to the Z-Best Rental Cars website.
- Z-Best Rental Cars sends a SAML request to the ABC Corp. site, which authenticates the employee, authorizes them as a gold card member with Z-Best Rental Cars, and sends this information to Z-Best through a SAML assertion.
- Z-Best Rental Cars now recognizes the employee as an authenticated, authorized gold card member and allows them to book a convertible for their trip.
See how easy it is with SAML? The employee only has to remember one username and password to perform tasks with commonly used web applications.
SAML vs. OAuth
SAML and OAuth are both protocols that allow SSO access to multiple web applications—but there are some differences. For example, OAuth is a slightly newer technology, is designed for authorizations, and is typically better for mobile applications. Those are a few of the reasons why Facebook, Google, and others use OAuth to let users log in to other websites using their respective credentials.
This table outlines a few of the main differences between SAML and OAuth:
|Uses XML||Uses JSON|
|For authentication, but can also pass along authorization details through SAML assertions||For authorization only|
|Designed for enterprise security and control of SSO logins||Designed to streamline the user experience, especially on mobile|
|Utilizes session cookies, which expire at the end of the session||Relies largely on API calls, making it well-suited to modern web apps, mobile apps, etc.|
As you’ve seen, SAML makes authentication easier for users. Now it’s time to see how Stytch makes authentication easier for everyone with passwordless solutions that let you focus your development efforts on your core product. Sign up today to get started, or contact firstname.lastname@example.org to discuss all things auth.