What is Security Assertion Markup Language (SAML)?
SAML stands for Security Assertion Markup Language. It is an open standard that helps users access multiple web applications with one set of login credentials. It uses Extensible Markup Language (XML) to standardize the transfer of identity data between an identity provider and a service provider.
SAML is a core component of single sign-on (SSO) technology and other forms of federated identity that simplify the login process for the user while also unburdening application owners from authenticating users.
SAML 2.0, published in 2005, is the latest version of the standard. The SAML authentication market is projected to grow to $2.8 billion by 2026.
Terms to know
Before getting into SAML specifics, it’s important to know a few terms:
Identity provider (IdP)
The identity provider is the entity that authenticates users and passes on authentication and authorization attributes to the service provider. Azure Active Directory and Okta are common identity providers.
Service provider (SP)
The service provider is the entity that the user is trying to access. The service provider receives trusted authentication and authorization attributes from the identity provider and grants the user access.
Some applications can act as both identity providers and service providers e.g. Salesforce.
A SAML assertion is the XML-based document containing user authentication and authorization data that the identity provider sends to the service provider. There are three types of assertions – authentication, attribute, and authorization decision.
The authentication assertion verifies the identity of the user and provides other details such as the login time and method of authentication (password, MFA, etc.).
The attribution assertion passes SAML attributes from the identity provider to the service provider. These attributes include (but are not limited to) which department the user belongs to, whether the user is part of a “VIP” group, and basic contact information.
The authorization decision assertion provides details about the user’s authorization by passing group membership details from the identity provider to the service provider. The service provider can then enforce authorization controls as and when necessary.
How SAML authentication works
Let’s consider the following example to walk through how SAML works:
The user is an employee working at an organization that uses SAML SSO for workforce applications.
The user is trying to access SpaceBNB, an application meant for renting spots on other planets (why not?). SpaceBNB is the service provider.
The user’s employer uses Authsome to manage user authentication. Authsome is the identity provider.
Here is how authentication would look in this case:
Step 1: The user tries to log in to SpaceBNB from their web browser.
Step 2: SpaceBNB generates a SAML request.
Step 3: The browser redirects the user to an SSO URL from Authsome. Authsome parses the SAML request and authenticates the user (with username-password, social login, PIN, etc.). If the user already has an existing session with Authsome, this step will be skipped.
Step 4: Authsome generates a SAML response and sends it to the browser. This response contains assertions about the user’s authentication and other attributes.
Step 5: The browser sends the SAML response to SpaceBNB for verification.
Step 6: SpaceBNB checks that the response from Authsome is legitimate and that none of the attributes have been modified.
Step 7: SpaceBNB extracts the user’s identity and other relevant attributes from the SAML response and logs the user in.
In the example above, the user is able to log in to SpaceBNB without creating or remembering another set of unique account credentials. Since SpaceBNB delegates user authentication to Authsome, app builders do not have to worry about storing user passwords, managing password reset flows, and other organization overhead.
Benefits of SAML authentication
Using SAML authentication leads to a better user experience, enhanced security, and improved developer focus.
Better user experience
SAML makes the login experience faster and more straightforward for users. Rather than creating and remembering unique passwords for every application, users simply navigate to the desired application and are authenticated by the identity provider. The only credential they need to remember is the one used for the identity provider.
Identity providers that use passwordless authentication further improve user experience by freeing users from password-related problems like maintaining complex passwords and going through password reset flows.
Using SAML authentication reduces the attack surface because service providers no longer need to store user credentials, making app servers less attractive targets for cybercriminals. Since the identity provider specializes in authentication, they have the time, resources, and incentives to implement strong security layers.
By reducing the number of passwords in circulation, SAML reduces the likelihood and impact of attacks like credential stuffing and phishing.
More focused app development
By using SAML, service providers place the burden of authentication and identity management on the identity provider. This means app developers no longer have to expend resources on password management and storage, protecting against password-based attacks, and implementing password reset flows. These resources can now be diverted to the service provider’s area of expertise and focus.
IT teams also benefit by not having to field help desk calls for password resets, freeing up their time to tackle more app-focused support concerns.
SAML vs OAuth
OAuth is an open, token-based authorization framework that allows users to grant access to their private resources on one site to another site without giving away their identity details. SAML and OAuth are both open, interoperable standards that make security improvements over usernames and passwords while also making users’ lives easier. However, while SAML is meant mainly for authentication, OAuth is meant for authorization.
Let’s go through an example to explain the difference between SAML and OAuth. If a person has tickets for Six Flags, the park attendants will check both some form of government-issued ID as well as the ticket before granting the visitor access to the amusement park.
Here, the ID is analogous to the SAML assertion while the ticket is analogous to an OAuth token. The ID authenticates the visitor i.e. it’s used by the park attendants to confirm the visitor is who they say they are. The ticket, however, authorizes the visitor i.e. it provides details on the level of park access the visitor has (fast lane, unlimited rides, VIP pass, etc.).
More SAML resources
Interested in learning more about SAML?
Explore the full SAML 2.0 standard published on the OASIS wiki.
Read SAML SSO documentation from Azure AD and Google Identity Platform.
Learning and debugging SAML can be a complex and time-consuming process. Descope helps developers easily add SAML SSO to their apps with no-code workflows, SDKs, and APIs.
Sign up for Descope and implement SAML without the struggle.