SAML Authentication & SSO Explained: Integration and How It Works

Intro

Each of us has been in a situation where we need to confirm our identity to receive some service: get admission to a closed event, board a plane, open a bank account, rent a house, and other common activities. To do this, we need to have a document proving our identity, which is government-issued. To issue such a document, the authority needs to collect some attributes that help to establish your identity, like your full name, photo, date of birth, fingerprints – so that it is deemed trustworthy and valid.

In the same way, to be able to access certain digital services, resources, or data that are not publicly available, users need to prove they are authorized to have this access. One way to do this is to create a digital identity with every service you need to access, giving the service provider your personal data and confirming your personal set of credentials each time you need to use the service. However, today, the number of digital services users access daily can be counted in dozens, so this approach does not look practical at all. 

Thus, a modern way of accessing digital resources mimics the physical ID document approach: by relying on a trusted entity that can prove that our digital identity is genuine and can be trusted too. This entity is called an Identity Provider, the resources we need to access – Service Provider, and the process of identity verification – SAML 2.0 Authentication. Further in this article, we explain what SAML is, how it works, and how it can be implemented for your application. 

What Is SAML Authentication?

SAML stands for Security Assertion Markup Language. SAML Authentication is the process of user authentication and authorization data exchange between identity providers (IdP) and service providers (SP) using SAML to authenticate and authorize that user to access a service. 

In this communication, the Identity Provider is the system that performs authentication and passes data about the user's identity and authorization level to the service provider. The Service Provider is the system that receives the identity confirmation from the identity provider and authorizes a user to access the resource.

SAML transactions are based on XML (Extensible Markup Language) for encoding messages (security assertions) between the SP and IdP, hence the naming.

What is SAML Used For?

As an open standard for transferring identity data, the first SAML specification was officially announced by OASIS (The Organization for the Advancement of Structured Information Standards) in 2002. This resulted from prior attempts to develop an SSO (Single-sign-on) solution that could be standardized and applicable to different domains.

Single-sign-on is the method of authentication that allows a user to log in once on a system that functions as an identity provider and have access to other multiple applications (service providers), without the need to create and re-enter another pair of credentials for each application separately. This solution became sought-after back in the late 1990s when enterprises were adopting more and more computer systems in day-to-day operations, overwhelming employees and IT departments with password handling. Today, SSO is one of the golden standards in application security.

What is SAML SSO?

SSO implementation may rely on different protocols, such as SAML, OAuth 2.0, and OpenID Connect (OIDC). However, large organizations and B2B applications mostly prefer SAML for authentication as the one specifically designed for enterprise security and compliance. Here’s what this means:

• It is highly secure, supporting digital signatures, encryption, and strong access control policies.
• It meets the requirements for compliance with common security regulations like HIPAA, GDPR, and SOC 2.
• It describes full authentication with strong identity verification and richer authentication data (roles, permissions, attributes).
• It enables SSO across different company web domains.
• It allows users to authenticate with multiple independent B2B service providers through a single identity provider (federated authentication).
• It is mature and well-tested.
• It is widely supported by major enterprise applications, including on-premise legacy systems.

While this article focuses on SAML SSO discussion and implementation, you can also check other articles on our blog to learn how to implement SSO using the OAuth protocol.

SAML Components

Now that we’ve got the relationship between SSO and SAML explained, you're halfway through understanding SAML SSO authentication. Next, let’s take a closer look at SAML itself and its components.

In the SAML framework, there are four basic components: the protocols, bindings, profiles, and flows.

SAML Protocols

The main point of SAML lies in sharing an authentication assertion – an XML document that contains information about a user and acts as proof of authentication. SAML protocols define the structure of this assertion and the rules for requesting and sending it by the communicating systems.

SAML Bindings

SAML bindings are the methods of message delivery in the SAML authentication process. They describe how authentication requests and responses get transported based on this or that communication protocol (HTTP, SOAP, or Redirect). For example, messages can be encoded into a URL and sent via an HTTP redirect, embedded in an HTML form and sent via HTTP POST, sent over SOAP using XML-based web services, etc.

SAML Profiles

In other words, SAML profiles are real-world use cases for SAML in applications. Each SAML profile is a specific, predefined combination of protocols, assertions, and bindings that is readily available for the system to be used. SAML protocols are useful as they standardize SAML implementation in similar scenarios, avoiding confusion and complexity. SAML profiles include Web SSO, Single Logout (SLO), Enhanced Client or Proxy (ECP), Identity Provider Discovery.

SAML Flows

SAML flows are the different step sequences needed to complete an authorization and authentication process. They vary depending on the party that initiates the process and the SAML profile involved. Thus, SAML flows can be SP-initiated SSO, IdP-initiated SSO, SLO, etc.

The Role of SAML in Secure Authentication

Authentication is the process of verifying a user’s identity before they can gain access to a computer system, ensuring they are who they claim to be. In software systems, to prove their identity, a user needs to provide the system with a valid pair of credentials (e.g., an email address and a password) that only they know. These credentials can be created by the users themselves at the registration stage when they use a piece of software for the first time or can be provided to users by the system administrator. The latter is more common for enterprise business environments, e.g., when a new employee onboards the corporate ecosystem of apps. 

In either case, for secure authentication, it is important that a series of security guidelines and policies be kept:

• Password security: a user’s passwords must be complex, regularly changed, never reused, and remain only known to the user (cannot be shared with third parties, even system administrators);
• Multi-factor authentication: for enhanced security, modern policies encourage the use of multiple authentication factors in addition to passwords (something you know), such as hardware tokens or mobile authenticators (something you have), and biometrics – fingerprints, face recognition, etc. (something you are).
• Encryption: for secure transmission of the credentials over the network, this data must be encrypted and never sent in URLs, logs, or plain text.
• Session security: to avoid storing passwords in user sessions (and creating the risk of password leaks and session highjacking attacks), secure authentication must rely on tokens – system-generated temporary access credentials sent to the user’s browser or app used instead of passwords.
• Brute force attack protection: to eliminate bot activity and automated login attempts, the mechanisms of rate limiting, CAPTCHA, bot detection, and account lockout should be in place.
• Phishing prevention: to reduce the risk of users being tricked into entering credentials on fake websites, secure authentication practices tend to rely on SSO, passwordless authentication (with biometrics, hardware security keys, or device-based credentials), and email verification.
• Secure logout: to prevent unauthorized access and session highjacking, security policies require the implementation of automatic logout, single logout, and re-authentication for high-risk actions like password change or money transfers.

How does SAML work in the context of secure authentication? Taking into account the above security requirements, SAML ensures a range of characteristics that can guarantee secure authentication, especially in enterprise environments:

• SAML assertions can be encrypted and digitally signed using public-key cryptography, establishing trust between IdPs and SPs.
• SAML messages cannot be intercepted due to TLS (Transport Layer Security) encryption and HTTP Redirect, HTTP POST, and SOAP bindings.
• SAML messages include timestamps, unique identifiers, and one-time use assertions, preventing login replay attacks.
• SAML-enabled federated identity mechanism ensures that SPs can accept authentication data only from trusted and supported IdPs.

How Does SAML Authentication Work?

To explain how SAML authentication works in simple terms, let’s use an example. Say, a user wants to log in on their corporate Trello, Notion, and some other apps using their Google Workspace account. They go to the login feature on these apps, and, from the suggested login methods, they choose login with Google. They get redirected to the Google login page, where they enter their email address and password. If the login credentials are correct, the system accepts them, and the user logs into the app. 

Thus, the user doesn’t need to create a separate account on each app or even register there – just use a single account (Google) to log in everywhere. Now, to understand what happens behind the curtains in this authentication process, let’s quickly recap the key “agents” in this workflow.

Identity Provider (IdP)

An IdP is the party responsible for user identity verification that is proving they are who they claim to be. It accepts login requests from the PS and issues security assertions and other authentication responses. This is also the system that the user originally provides all their data to (e.g. username, email, roles). Commonly known identity providers include Microsoft Entra ID, Google Workspace, Okta, OneLogin, Keycloak, etc. In our example above, we used Google Workspace as an example of an identity provider.

Service Provider

An SP is a Software-as-a-Service (SaaS) app, website, or other online service the user needs to log in on. To allow the user to access its data and resources and to know the user’s access level (role), the SP needs the identity provider’s authentication. Upon receiving it, the service provider allows the user to access its data and resources without asking them to provide any personal information or credentials. Some examples of SPs include popular enterprise solutions like Salesforce, Jira, and Zoho, as well as Trello and Notion we used in our sample flow above.

SAML Assertion

A SAML Assertion is an XML document that contains user authorization data, such as the user’s email, username, role, group membership, etc. It is issued by the IdP at SP’s request and is considered by the SP the proof of user identity. A SAML assertion consists of three main parts: 

• An authentication statement, which proves the user’s identity, containing information on the time and method of authentication (e.g., password, biometrics)
• An attribution statement, which contains information helping the SP determine the user’s access level (e.g., role, department membership).‍
• An authorization decision statement, which provides the IdP’s decision as to the access grant (e.g., user is authorized to use the service or assess denied).

Thus, following the SAML process, the moment a user attempts to access an SP, it requests authorization and authentication from the IdP. The user gets redirected to the IdP, logs in once to sign on with the IdP, and in case the log-in is successful, the IdP verifies the session and passes the SAML attributes packed into the SAML assertion to the SP, following the use-case-specific SAML flow and profile, and sends the user back to the service.

This process looks complex, but in reality, it happens within seconds as the IdP and the SP rely on the same standard – SAML, provided it is configured properly for both the identity provider and the service provider.

Step-by-Step SAML Authentication Process

How does SAML SSO work in detail? Here’s a step-by-step breakdown of the SAML SSO flow, describing the above diagram. 

1. User access request: a user tries to access a system, application, or online resource (a service provider). When the SP doesn’t have an active session with this user, it needs to authenticate them (verify their identity) before granting access. So the SP provides the user with the available authentication methods, at least one of which should be authentication via the trusted identity provider.
2. Redirection: if the user chooses the SSO method via the proposed identity provider, the SP generates an XML SAML authentication request and redirects the user to this identity provider with the generated request. 
3. Authentication at IdP: the identity provider parses the SAML request and the user sees a login page or window from the identity provider they chose to authenticate with. 
4. Assertion sent: If the credentials the user provides get verified, the IdP generates a digitally signed SAML assertion which includes user details like email, role, authentication method, etc., and redirects the user back to the SP’s Assertion Consumer Service (ACS) with this assertion. For example, if the authentication takes place on a web app, it comes as an HTTP POST request, embedded in the HTML form.
5. Assertion validation: having received the SAML assertion, the SP verifies the signature, issuer and audience, timestamps, and user attributes.
6. Access grant: after the SP makes sure the assertion is valid, it creates an SSO session and the user remains authenticated, meaning they can access other supported applications (SPs) without the need to enter credentials again.

It’s also important to mention that for SAML authentication to work, both identity provider and service provider have to be configured properly to establish trust. 

How to Implement SAML for Authentication

So we have discussed a common SAML authentication flow from the point of view of a user. But the most common request we get at Axon from clients is for an application to implement SAML integration. So what is SAML integration? 

SAML integration is the implementation of the SAML authentication workflow in an application to enable SSO for its users, making it one of the parties in the process – a service provider. Thus, in this section, we describe the implementation of SAML SSO into a web app for it to function as a service provider supported by an identity provider of choice.

Step 1: Choose Your Identity Provider (IdP)

Decide, which IdP will handle user authentication and issue SAML assertions for your application. Popular IdPs that support SAML include:

• Google Workspace Identity is probably one of the most widely known identity providers, used by thousands of organizations and millions of individual users, especially loved by startups, small companies, and educational institutions for ease of use and a rich ecosystem of built-in applications.
• Microsoft Entra ID is the best choice for companies relying on Microsoft’s ecosystem of apps, as it is deeply integrated with Microsoft 365 and Azure services. Its distinctive feature is support for Active Directory – Microsoft’s on-premise identity management service, so it is also good for managing hybrid cloud environments.
• Okta – a cloud-based platform that offers a range of IAM functions, including identity provider functionality, is a popular choice for enterprise systems, supporting all common authentication protocols. It also markets AuthO – its own identity platform with a developer-oriented approach, tailored for startups and SaaS B2C/B2B applications.
• OneLogin –  another cloud-based IAM provider featuring strong security based on Zero Trust approach and smooth integration.  
• Keycloak is an open-source solution for IAM developed and supported by Red Hat. It provides authentication, authorization, and SSO features for different applications, and, like other IAM platforms, supports all modern authorization protocols. However, as it’s free and open-source, it requires deeper technical expertise in authentication setup and IAM in general.

Note: This and the following steps require domain-specific expertise and knowledge of identity and access management practices. Axon provides software development for small businesses, helping such companies implement technology solutions with high quality and commitment.

Step 2: Select a SAML Library and Configure Your App as an SP

Here are some SAML libraries in different programming languages that can be used:

• Python: python3-saml
• Java: OpenSAML
• Node.js: passport-saml
• .NET: Sustainsys.Saml2

To configure your application as an SP, generate your SP metadata XML file, which should include:

• Entity ID – the unique identifier for your application (e.g., https://yourapp.com/sp).
• An Assertion Consumer Service (ACS) URL where your app will receive SAML responses from the IdP (e.g., https://yourapp.com/saml/acs).
• An X.509 Certificate which will be used to sign requests or encrypt assertions.

Step 3: Exchange the Metadata with the IdP

Share with your IdP administrator the metadata files that contain your metadata file. With this information, the IdP will configure its settings to trust you as an SP. The IdP will then provide its own metadata file to your app in a URL or XML file. Make sure that you get:

• IdP Entity ID (e.g., https://idp.example.com)
• SAML SSO URL (e.g., https://idp.example.com/sso)
• IdP X.509 Public Certificate 

Thus, you can configure your app as SP with IdP metadata to establish trust between the two entities.

Step 4: Implement the SAML Authentication Flow in your App

Make sure your SAML authentication follows the flow:

1. When a user wants to log in, generate a SAML authentication request, and redirect them to IdP’s SSO URL for Authentication.
2. After authentication, the IdP will send a SAML assertion to your Assertion Consumer Service URL. 
3. Check the expiration time and ensure the assertion is valid.
4. Confirm the audience restriction matches your settings.
5. Verify the signature using the IdP’s public certificate.
6. Extract user attributes (such as username, email, role).
7. Create a session and log the user in.

Step 6: Test and Troubleshoot

As any software system, newly implemented SAML authentication will need some testing. To work with SAML, we suggest using several SAML debugging tools:

• SAML Tracer (Browser Extension)
• SSO Circle Test Tool
• SAML Validator in your IdP console

Benefits Of Using SAML

You might be also wondering about the special SAML SSO meaning for applications and how your business can benefit from it. Thus, we will explain the advantages of SAML for companies in this section.

Improves User Experience

It goes without saying that user-friendliness is the golden standard for modern UI and UX. Taking away the headache of multiple account management and creating and remembering multiple passports will be a life-saver for your users and will make them love your software. 

Increases Security

The SAML flow ensures that your users have a single point of authentication and it is trusted and secure. The identity transfer information is also safeguarded by digital signatures, sensitive data encryption, and secure communication protocols. Also, SAML authentication ensures user credentials never leave the boundary of the firewall – a system that defends an internal network from traffic from less secure sources and prevents unauthorized users, devices, and applications from entering the network.

Platform-Agnostic

SAML decouples your security from a vendor’s system or specific platform structures, eliminating the need for you to keep user information synchronized between directories. Therefore, it doesn’t matter which system they’re using, they can log in anyway. This takes off the requirement to adjust the application security system to various structures.

Manages Access Centrally 

SAML doesn’t require synchronization between directories for each application, so there’s no need for the identity provider to ask each service provider to grant, revoke, or change access levels.  Instead, you can manage access centrally for a single service or across the enterprise. Also, due to the centralization of authentication logs, you can conduct an access audit in the same way.

Reduces IT Load

When users have only one pair of credentials to remember and manage, there’s so much less chance they will forget them or store them in an insecure way. Consequently, your IT admins get fewer password reset tickets to deal with and can focus on other business-critical tasks.

Supports Scalability

The centralized nature of SAML-based authentication allows you to add new users, applications, and services to your corporate digital ecosystem quickly and with minimal effort.

Saves Costs

With SAML, authentication is done on the identity provider’s side, which means you don't have to build and maintain complex password storage and security infrastructure to maintain account information from multiple services. It also brings helpdesk efficiency optimization with fewer issue requests, user management automation, and less chance of security breaches.

Interoperable

SAML can work well with a diverse range of platforms, applications, and identity providers due to its XML nature, which is a widely accepted standard. Also, since authorization is handled by the identity provider, service provider compatibility with the underlying authentication method is not an issue. Finally, the availability of multiple binding methods ensures SAML will work across different network architectures.

Difference Between SAML and OAuth

Both SAML (Security Assertion Markup Language) and OAuth (Open Authorization) are authentication and authorization standards and enable SSO, saving users (and IT admins) from multiple account- and password-handling distress. However, in the end, they serve different purposes and thus can be used rather complementary than interchangeably. Let’s break this down.

OAuth is an authorization standard or protocol co-developed by Google and Twitter to enable users to log in to different internet sites using their social media accounts (like Facebook or Google) and without providing the service with their credentials or creating a separate account. At first glance, this looks very similar to SAML, but it’s rather different behind the scenes.

First, in the OAuth flow, there are different agents involved: the user (also the resource owner), an application or service (client), an authorization server, and a resource server. Secondly, the process is also different:

1. When the user attempts to log in on the client using their social media account, for example, they get redirected to the authorization server. 
2. The authorization server authenticates the user (asking for their social media credentials), receives consent to share their identity information, and issues an authorization code to the client, but does not store the user’s authentication data. 
3. Finally, the client exchanges this authorization code for an access token, and uses this token to request data from the resource, needed to create a session and log in the user.

As you can see, in this process a different mechanism is employed, where authentication does take place but user credentials are not stored on the server and they are only needed to authorize data sharing. Also, in SAML flow, the identity provider generates a SAML assertion to prove the user identity, while in OAuth the authorization server generates an access token confirming user authorization

Does this all mean that SAML is a better choice for enterprise solutions than OAuth? Both yes and not exactly. SAML will remain the preferred choice for enterprise SSO implementation with its support of federated authentification, more control and security for SSO, and compliance with common data protection guidelines. At the same time, OAuth can be of great use for integrating third-party applications in enterprise environments by providing an authorization mechanism for granting API access.

For a more in-depth review of the OAuth protocol and its implementation, read our how-to guide on OAuth 2.0 implementation with Passport.js.

Conclusion

Summing up, SAML is a reliable, well-standardized, tried and tested mechanism for implementing the single sign-on feature in integrated systems, particularly valuable for enterprise environments. It follows a simple flow and requires only three agents – a user, a service provider, and an identity provider – for a quick and secure authentication to complete. 

SAML is highly secure and flexible at the same time, ensuring compatibility with a multitude of technologies and applications and allowing companies to choose identity providers and service providers they prefer. It differs from the OAuth protocol, and thus they cannot be used interchangeably, however, they can be implemented along with each other to provide more integration opportunities.

We hope this article was helpful. If you are creating a software application that needs SSO implementation, you have more identity and access management features in your backlog, or even if you haven’t made a decision yet, expert consultants at Axon will be more than happy to assist. All you have to do is let us know your business concern by filling in the contact form below.

FAQ

‍