Login

We’re sporting a new look

Our web refresh reflects the fact that Auth0 is part of Okta and better than ever. If you’re looking for developer content, you’re in the right place. If you want info about Okta Customer Identity Cloud which is powered by Auth0, head to okta.com/customer-identity.

What is SAML 2.0?

How SAML Authentication Works, and Why It’s Still Relevant for Enterprise Customers

SAML 2.0 (Security Assertion Markup Language) is an open standard created to provide cross-domain single sign-on (SSO). In other words, it allows a user to authenticate in a system and gain access to another system by providing proof of their authentication.

Overview of SAML

While SAML has been in use since 2005, it remains popular for identity federation in B2B and B2E applications. This wide adoption has led to its self-perpetuating success. Generally, if you want to provide seamless SSO between businesses and enterprises, you need to be able to handle SAML. In fact, the SAML 2.0 protocol is mainly used for Enterprise and Government applications.

SAML uses XML to represent the user’s identity data and simple HTTP for data transport mechanisms.

In this article, we’ll go over what SAML is and what distinguishes it from other identity standards; we will also look at how an identity management partner such as Auth0 fits into the equation.

How SAML Works?

SAML is an XML-based authentication protocol in which Identity Providers (IdP) -- entities that manage and store user credentials -- exchange digitally signed XML documents ( SAML Assertions ) allowing an end-user to access a **Service Provider **(SP), such as the collection of apps that you use every day at work or a website.

The service requesting and receiving data from the Identity Providers (IdP) is known as the Relying Party (RP) and the user identity data, encapsulated in the SAML Assertion, is in the form of attributes, e.g,. email address, name, phone, etc.

A real-world analogy would be the international traveling scenario. Think of a traveler wishing to come from their home country to the USA. When they arrive at the border, they are asked for their passport in order to authenticate and possibly authorize their access. If the traveler has no passport, they are redirected to their home country's government to get one.

Once the traveler has their passport, they can prove their identity to the officers at the border. These check the passport validity and the identity data on it and decide to let the traveler come in or not.

In this scenario:

  • the traveler's home country is the Identity Provider
  • the officers at the border, representing the USA government, are the Relying Party,
  • the USA as a country is the Service Provider
  • the passport is the SAML Assertion
  • Consider that the USA accepts passports only from countries with which it has made preliminary agreements.

    You can replicate this real-world scenario in a computer system.

    Let's say you work in a company that has multiple applications, but a centralized point for user authentication. Let's say that a company partner has a similar organization, and for a specific project, a few partner's employees need to access one or more of your company's applications. Using SAML, after a preliminary configuration that establishes trust between the two systems, you can replicate the international traveling scenario.

    The partner's employee tries to access one of your company's applications. Since that user doesn't belong to your company, your company's system redirects the user to the partner's system to get proof of identity. The partner's system authenticates the user and provides them with a SAML Assertion. Your company's system checks that assertion and lets the user access.

    SAML and Single Sign-On (SSO)

    With SAML, the authentication workflow can be initiated by either the Service Provider or the Identity Provider. IdP-initiated authentication might occur if an employee is logged into their corporate dashboard and wants to use a company-purchased tool on an external site. In this case, the IdP would send a SAML assertion via the web browser to automatically log them in.

    SP-initiated authentication occurs if an employee tries to log into that external site - the SP- and the site redirects them to their corporate Single Sign On (SSO) login page to enter their credentials and authenticate. After authentication, the employee is redirected back to the external site with a SAML assertion proving their identity.

    SAML 2.0 Benefits and Use Cases

    Developers occasionally question why they should implement the SAML protocol. What makes SAML worth your time? As mentioned in this more technical tutorial , benefits include:

    Standardization: Being an open standard, SAML makes systems interoperability possible.

    User Experience: Users can access multiple Service Providers by signing in just once, without additional authentication, allowing for a faster and better experience at each Service Provider. This also centralizes password management issues such as reset and recovery.

    Loose Coupling of Directories: SAML doesn't require user information to be maintained and synchronized between directories.

    Increased Security: SAML provides a single point of authentication, which happens at a secure IdP. Avoiding credentials replication ( shadow accounts ) and synchronization, SAML reduces the points of attack for identity theft.

    Reduced Costs for Service Providers: With SAML, you don't have to maintain account information across multiple services. The Identity Provider bears this burden.

    Increased compliance: In the Data Privacy Era , the ability to receive attributes on the fly and forget them when they’re no longer needed reduces your organization’s liability — you no longer need to create shadow accounts to get work done

    Where Does Your Identity Platform (IdP) Fit with SAML 2.0 and Single Sign-On?

    Developers can attest that attempting to implement SAML 2.0 in-house can be tricky, and it’s easy to inadvertently leave cracks in an XML signature and encryption that leave an app vulnerable to attackers. However, an identity partner like Auth0 can make SAML authentication both simple and secure.

    Using Auth0 Universal Login , you can quickly configure SAML and offer it to your enterprise customers. When you use Auth0, you’re getting all the benefits of SAML but offloading the burden and risk of being the sole Identity Provider.

    Auth0 can connect to any language or API . It can act as the Identity Provider , Service Provider , or both .