Blog

What is SAML and How Does it Work?

In this article, you’ll learn more about what SAML is, how you can set it up, and what other options you have to provide similar functionality and support SSO for your customers.


As an organization grows in size, managing access to their estate of software and systems becomes an increasingly difficult problem. At the enterprise level, most employees need to use a whole ecosystem of apps and services for their day-to-day work. 

Large companies use Single Sign-on (SSO) to manage authentication, authorization and access at scale. To enable this, corporate IT departments use Identity Providers (IdPs), like Okta, Google Workspace or Microsoft Entra ID (Formerly known as Azure Active Directory). 

These IdPs centrally manage user logins. When a user logs into an app with SSO, the IdP authenticates that user’s details, then shares authorization data back to the app which made the request - For example, confirming a user is authorized to access the system and which level of permissions they have.

That’s great for IT admins, but if your company is creating software which you sell to lots of different enterprise-grade companies, then your auth stack can become unwieldy fast: you need to support multiple identity providers and their intricacies, while still keeping your user management system clean, secure and performant.

That’s where SAML comes in. 

SAML is an XML-based standard used to enable SSO by allowing an identity provider to provide authentication across multiple services with a single login. As an established standard, SAML is supported by every major IdP in use today.

In this article, you’ll learn more about what SAML is, how you can set it up, and what alternatives you have to provide similar functionality and support SSO for your customers.

What Is SAML and What Does It Stand For?

SAML stands for Security Assertion Markup Language. It's an open standard for exchanging authentication data between parties, such as between an identity provider and a service provider. Data is exchanged using assertions.

SAML allows you to sign in once (using single sign-on or SSO) and access multiple applications without signing in again. It does this by passing information about a user between a SAML service provider (your SaaS app) and an identity provider (like Okta or Ping). 

The basic process is:

  • When a user tries to access a service, the service provider redirects them to the identity provider.
  • The identity provider authenticates the user and generates SAML assertions containing information about the user.
  • The SAML assertions are passed to the service provider, which verifies them and logs the user in.

SAML is an alternative to other authentication standards like OAuth or OIDC and allows different applications to share authentication data. This eliminates the need for users to sign in separately to access connected systems and applications.

How SAML Authentication Works

SAML uses XML documents called assertions to pass information about a user between domains. These are sent from the IdP to the Service Provider, as shown above.

The service provider then uses the assertion to confirm the user’s identity and determine what resources the user has access to. This is what allows single sign-on (SSO) and grants users access to multiple applications with one login.

SAML assertions can include Authentication, User Attributes and Authorization Decisions. Here’s an example of one:



<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="_8e8dc5f69a98cc4c1ff3427e5ce34606fd672f91e6" Version="2.0" IssueInstant="2014-07-17T01:01:48Z" Destination="http://sp.example.com/demo1/index.php?acs" InResponseTo="ONELOGIN_4fee3b046395c4e751011e97f8900b5273d56685">
  <saml:Issuer>http://idp.example.com/metadata.php</saml:Issuer>
  <samlp:Status>
    <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
  </samlp:Status>
<saml:Assertion xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema" ID="pfxa099680e-6fc0-2c7a-90fa-4202bb29faa4" Version="2.0" IssueInstant="2014-07-17T01:01:48Z">
  <saml:Issuer>http://idp.example.com/metadata.php</saml:Issuer><ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
  <ds:SignedInfo><ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
    <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
  <ds:Reference URI="#pfxa099680e-6fc0-2c7a-90fa-4202bb29faa4"><ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/><ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/></ds:Transforms><ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/><ds:DigestValue>YOCfzMPwhVQibcTRRyuCb5vlTDU=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>VXQGwtQsc/rTuCFspZwD6k4i6fKr4ymYfCiI5Ve9JO5LYRG7VNPzIq5Mr/JW/0btpui4cmQVK//wA89nLe+g2wxDizx32CnOBsshoF3YTDOs586SJt+Ty/h/X886Xhqu8XsdMiD/spyU8rGhIQP2OL65k6HoSFxtPqKt1+KOdkE=</ds:SignatureValue>
<ds:KeyInfo><ds:X509Data><ds:X509Certificate>MIICajCCAdOgAwIBAgIBADANBgkqhkiG9w0BAQ0FADBSMQswCQYDVQQGEwJ1czETMBEGA1UECAwKQ2FsaWZvcm5pYTEVMBMGA1UECgwMT25lbG9naW4gSW5jMRcwFQYDVQQDDA5zcC5leGFtcGxlLmNvbTAeFw0xNDA3MTcxNDEyNTZaFw0xNTA3MTcxNDEyNTZaMFIxCzAJBgNVBAYTAnVzMRMwEQYDVQQIDApDYWxpZm9ybmlhMRUwEwYDVQQKDAxPbmVsb2dpbiBJbmMxFzAVBgNVBAMMDnNwLmV4YW1wbGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDZx+ON4IUoIWxgukTb1tOiX3bMYzYQiwWPUNMp+Fq82xoNogso2bykZG0yiJm5o8zv/sd6pGouayMgkx/2FSOdc36T0jGbCHuRSbtia0PEzNIRtmViMrt3AeoWBidRXmZsxCNLwgIV6dn2WpuE5Az0bHgpZnQxTKFek0BMKU/d8wIDAQABo1AwTjAdBgNVHQ4EFgQUGHxYqZYyX7cTxKVODVgZwSTdCnwwHwYDVR0jBBgwFoAUGHxYqZYyX7cTxKVODVgZwSTdCnwwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQ0FAAOBgQByFOl+hMFICbd3DJfnp2Rgd/dqttsZG/tyhILWvErbio/DEe98mXpowhTkC04ENprOyXi7ZbUqiicF89uAGyt1oqgTUCD1VsLahqIcmrzgumNyTwLGWo17WDAa1/usDhetWAMhgzF/Cnf5ek0nK00m0YZGyc4LzgD0CROMASTWNg==</ds:X509Certificate></ds:X509Data></ds:KeyInfo></ds:Signature>
    <saml:Subject>
    <saml:NameID SPNameQualifier="http://sp.example.com/demo1/metadata.php" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">_ce3d2948b4cf20146dee0a0b3dd6f69b6cf86f62d7</saml:NameID>
    <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
        <saml:SubjectConfirmationData NotOnOrAfter="2024-01-18T06:21:48Z" Recipient="http://sp.example.com/demo1/index.php?acs" InResponseTo="ONELOGIN_4fee3b046395c4e751011e97f8900b5273d56685"/>
    </saml:SubjectConfirmation>
    </saml:Subject>
    <saml:Conditions NotBefore="2014-07-17T01:01:18Z" NotOnOrAfter="2024-01-18T06:21:48Z">
    <saml:AudienceRestriction>
        <saml:Audience>http://sp.example.com/demo1/metadata.php</saml:Audience>
    </saml:AudienceRestriction>
    </saml:Conditions>
    <saml:AuthnStatement AuthnInstant="2014-07-17T01:01:48Z" SessionNotOnOrAfter="2024-07-17T09:01:48Z" SessionIndex="_be9967abd904ddcae3c0eb4189adbe3f71e327cf93">
    <saml:AuthnContext>
        <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml:AuthnContextClassRef>
    </saml:AuthnContext>
    </saml:AuthnStatement>
    <saml:AttributeStatement>
    <saml:Attribute Name="uid" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
        <saml:AttributeValue xsi:type="xs:string">test</saml:AttributeValue>
    </saml:Attribute>
    <saml:Attribute Name="mail" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
        <saml:AttributeValue xsi:type="xs:string">test@example.com</saml:AttributeValue>
    </saml:Attribute>
    <saml:Attribute Name="eduPersonAffiliation" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
        <saml:AttributeValue xsi:type="xs:string">users</saml:AttributeValue>
        <saml:AttributeValue xsi:type="xs:string">examplerole1</saml:AttributeValue>
    </saml:Attribute>
    </saml:AttributeStatement>
  </saml:Assertion>
</samlp:Response>


The key parts of a SAML flow are:

  • The User: Who is trying to access a service.
  • The Service Provider: The application or service the user is trying to access. For example, your SaaS app.
  • The Identity Provider: Authenticates the user and issues SAML assertions. 
  • The Assertion: An XML document containing information about the user’s identity and access rights.
  • Single Sign-on: Allows users to log in once to access multiple applications.

What is SAML Used For?

SAML is commonly used for:

  • Single Sign-on (SSO): Allows users to sign in once to access multiple applications. This allows users to use a single login for all tools provided by an employer and is a key use case for enterprise-scale organizations. SSO is a form of Federated Identity.
  • Attribute Exchange: Passes user attributes (like name, email, role, etc.) between an identity provider and a service provider. This enables personalization and access control in applications.
  • User Provisioning: Automating the creation and management of user accounts across systems, and at scale.

Rather than building their own authentication systems, many organizations use SAML to outsource user authentication to a dedicated identity provider (IdP) like Okta, OneLogin or Auth0. 

SAML lets providers deliver a better user experience, as users spend less time dealing with credentials. This saves on costs for the providers themselves and increases security by reusing the same system.

Features like digital signatures and encryption keep SAML secure and make it much harder for hackers to intercept or spoof the data.

SAML has been around for over 15 years and remains a popular choice for web-based SSO and federation due to its security, flexibility and wide adoption. While newer standards like OpenID Connect are gaining ground, SAML will likely continue to play an important role in many organizations’ identity architectures.

Alternatives to SAML

While SAML is a popular choice for identity management, there are several alternatives worth considering.

OpenID Connect

What is it: OpenID Connect (OIDC) is an open standard for authentication which is both decentralized and user-centric.

How does it work: Rather than relying on a SAML identity provider, OIDC uses JSON Web Tokens (JWTs) to verify user identity and share information. 

What it’s best for: OIDC may be a good option if you want more control and flexibility over the login process.

Pros: 

  • Flexible implementation provides information in a REST-like format.
  • JSON is human-readable and easier to work with than XML.

Cons:

  • Doesn’t provide authorization data, making it unsuitable when you need granular levels of access. For example granting users of different levels access to different services.

OAuth

What is it: OAuth is an open standard for access delegation, commonly used for authorization. It allows users to grant limited access to their data or accounts without sharing their passwords. 

How does it work: OAuth works with SAML but can also be used as an alternative. 

What it’s best for: OAuth may suit you well if you specifically need to authorize user access rather than authenticate identity.

Pros: 

  • Easier to implement securely than SAML.

Cons:

  • Harder to implement overall than SAML.

Rolling your own SSO Systems

If you aren’t happy with what’s out there, building your own SSO solution is an option. While you’ll have full control over your implementation, like all homegrown solutions it’s going to take significant time to implement and require frequent updates, compatibility upgrades and maintenance, while taking away from engineering time which could be spent on the core value-add of your software.

Pros:

  • Gives you complete control over what’s built.

Cons:

  • High engineering time cost. Developing systems from scratch is a huge investment in engineering hours.
  • Requires frequent maintenance. An SSO system requires continual development involvement to fix bugs, handle outages, support new identity providers and deal with emerging security threats and new methods of access.
  • Unlikely to be as performant or featured as mature systems.

SAML FAQ

Here are some of the most common questions about SAML and their answers:

Is SAML free? 

Yes, SAML is an open standard and free to implement. However, implementing it yourself costs time and money. Using a ready made single-sign on option, such as WorkOS, is a better alternative unless you have an extremely specific use case and need full control over your implementation.

What are the alternatives to SAML? 

  • OpenID Connect uses human-readable JTWs, but doesn’t provide authorization data.
  • OAuth is tricky to implement, but easier to implement securely than SAML.
  • Custom SSO systems let you build everything to your own specs, but are hugely expensive.

How does SAML work? 

SAML uses XML-based assertions to pass user authentication and authorization data between an identity provider and a service provider.

Is SAML secure?

Yes, SAML is a secure standard for identity and access management. Some of the security features of SAML include:

  • Digital Signatures - To verify the identity of the SAML message issuer and ensure message integrity.
  • Encryption - To protect assertions and other SAML messages from eavesdropping.
  • Authentication Context - Information about the authentication method used to identify the subject.
  • Subject Confirmation - Requirements for confirming the subject of an assertion.

SAML has strong security standards and is trusted by many large tech companies and organizations, for example, Microsoft, Amazon and Oracle. However, proper implementation and configuration are required to utilize its capabilities correctly.

What version of SAML should I use?

The current SAML version is 2.0, which has been around since 2005 and is very different from the original version, from 2002. Version 2.0 has new protocols, a different binding system and refactored profiles. You should use the later version unless you need backwards compatibility with an older system. 

What issues can occur with SAML?

There are various potential issues that can occur with SAML. These include attribute errors, signature validation errors and IdP-specific errors. Using an established service makes experiencing these less likely, and provides you with support if you do run into a problem.

Conclusion

SAML makes authentication and authorization easier at scale and lets you implement single sign-on easily. The content of its assertions can be customized, allowing you to control exactly how you use it.

Of course, if you’d rather not wrestle with SAML’s XML-based assertions, you’ll want to look at a done-for-you authentication service like WorkOS:

  • Get Started Fast: With SDKs for every popular platform, and Slack-based support, you can implement SSO in minutes rather than weeks.
  • Avoid The Back-And-Forth: WorkOS’ Admin Portal takes the pain out of onboarding your customers’ IT teams and configuring your app to work with their identity provider.
  • Pricing That Makes Sense: Unlike competitors who price by monthly active users, WorkOS charges a flat rate for each company you onboard - whether they bring 10 or 10,000 users to your app.

Explore Unified SSO by WorkOS.

In this article

This site uses cookies to improve your experience. Please accept the use of cookies on this site. You can review our cookie policy here and our privacy policy here. If you choose to refuse, functionality of this site will be limited.