SAML Authentication

SAML (Security Assertion Markup Language) is an XML-based open standard used to securely exchange authentication and authorization data between identity providers and service providers.
It enables Single Sign-On (SSO), allowing users to authenticate once and access multiple applications without repeated logins.

Uses standardized XML assertions to share identity and access information securely.
It enables centralized authentication through an Identity Provider (IdP).
Eliminates multiple logins by supporting Single Sign-On across applications.

Example: When you sign in to Google Workspace and access a third-party application like Salesforce, SAML enables Single Sign-On between Google (IdP) and Salesforce (SP). SAML is a framework that enables this seamless experience, allowing your single login to act as a passport across different applications.

The Core Components in SAML

SAML works by defining clear roles for the parties involved in an authentication request:

The User (Principal): The person trying to access a service.
The Identity Provider (IdP): The system that manages and authenticates the user's identity. It is the "source of truth" for who the user is. Examples: Google, Okta, Microsoft Azure AD, Auth0.
The Service Provider (SP): The application or service that the user wants to access. The SP trusts the IdP to handle the authentication. Examples: Salesforce, Slack, Gmail.

SAML Authentication Workflow

The most common SAML workflow is initiated by the Service Provider (SP). Here’s a step-by-step breakdown:

The SAML Authentication

User Accesses Service: The user navigates to the Service Provider (e.g., gmail.com).
SP Crafts SAML Request: The SP sees that the user is not logged in. It generates an XML-based SAML authentication request.
Browser Redirect to IdP: The SP redirects the user's browser to the Identity Provider (e.g., accounts.google.com), sending the SAML request along with the redirect.
IdP Authenticates User: The IdP receives the request and prompts the user to log in with their credentials (e.g., username, password, MFA). If the user already has an active session with the IdP, this step may be skipped.
IdP Generates SAML Response: After successful authentication, the IdP creates a SAML Response. This is an XML document containing a digitally signed Assertion, which acts as proof of the user's identity and any relevant attributes (like their email or role).
Browser Sends Response to SP: The IdP sends the encoded SAML Response back to the user's browser, which then automatically forwards it to the Service Provider's Assertion Consumer Service (ACS) URL.
SP Verifies and Logs In: The SP receives the SAML Response. It uses a pre-configured public key from the IdP to verify the digital signature on the Assertion. If the signature is valid, the SP trusts the information, creates a local session for the user, and grants them access.

Key Elements of a SAML Request

A SAML request contains important data, such as:

ID: A unique identifier for the SAML authentication request, used to match the request with the response.
Issuer: The name of the Service Provider (SP) that is initiating the request.
NameID: The User's identifier , often their email address or phone number.
AssertionConsumerServiceURL: The endpoint URL on the Service provider where the IdP sends the authentication response.

These elements work together to ensure that the correct user is authenticated and granted access to the right resources.

SAML Response Structure

The SAML response is divided into two main parts:

Assertion: This is an XML document that contains the details of the user, such as the login event's timestamp and the method of authentication used (e.g., 2-Factor Authentication or Kerberos).
Signature: The Signature is a Base64 encoded string that ensures the integrity of the assertion. If an attacker tries to modify the SAML response, such as changing the username to impersonate a victim, the signature will prevent the modification from going undetected.

Key Generation in SAML Authentication

The process of signing and verifying the SAML response involves key generation:

Private Key: The Identity Provider (IdP) generates a private key, which is used to sign the SAML assertion.
Public Key: The Service Provider (SP) Receives the IdP's public key, which is used to verify the authenticity of the SAML response before granting access.

This ensures that only valid, signed responses are accepted, providing an additional layer of security.

Securing SAML: Vulnerabilities and Best Practices

While SAML is a mature and secure protocol, misconfigurations can lead to vulnerabilities.

Improper Signature Validation:

Vulnerability: An SP might not check the digital signature at all, or only check it if it's present. This allows an attacker to modify the NameID in a captured SAML response, remove the now-invalid signature, and impersonate another user.
Best Practice: Always require and validate the signature. The SP must be configured to reject any SAML assertion that is not signed or whose signature does not match the IdP's public key.

SAML Replay Attacks:

Vulnerability: An attacker could intercept a valid SAML response and "replay" it later to gain unauthorized access.
Best Practice: The SP must strictly enforce the Conditions of the assertion, especially the NotOnOrAfter timestamp, to ensure that expired assertions are rejected.

XML Comment Injection:

Vulnerability: Some poorly implemented XML parsers can be tricked by comments. For example, an attacker could try to sign up with a NameID of user@victim.com to bypass controls and be logged in as user@victim.com.
Best Practice: Use up-to-date, secure XML parsing libraries that correctly handle comments and other XML complexities.

SAML vs. OAuth/OIDC

It's common to confuse SAML with other modern protocols like OAuth and OpenID Connect (OIDC). They serve different primary purposes:

SAML: SAML is an authentication protocol used to verify a user’s identity and enable Single Sign-On (SSO) across multiple web applications.

Primary purpose: Authentication (Who is the user?)
Data format: XML-based assertions.
Typical use case: Enterprise SSO for internal or SaaS applications.
Flow style: Browser-based redirects.
Common environments: Corporate IT, legacy enterprise systems.

Example:
An employee signs in once to the company’s Identity Provider (IdP) and gains access to applications like Salesforce, Jira, and Workday without logging in again.

OAuth 2.0: OAuth 2.0 is an authorization framework, not an authentication protocol. It allows an application to access a user’s resources without knowing the user’s password.

Primary purpose: Authorization (What is the app allowed to access?).
Data format: JSON tokens (access tokens).
Typical use case: API access delegation.
Flow style: Token-based.
Common environments: APIs, mobile apps, third-party integrations.

OAuth Flow:

The user tries to access a feature in the application that requires permission.
The application redirects the user to the Authorization Server, requesting access to specific permissions (scopes).
The user logs in and approves the requested permissions.
The Authorization Server redirects the user back to the application with a temporary authorization code.
The application exchanges this code with the Authorization Server for an access token.
The application uses the access token to securely access the user’s data from the Resource Server.

Example:
A photo printing app requests permission to access your Google Photos library without asking for your Google password.

OpenID Connect (OIDC): An identity layer built on top of OAuth 2.0. It adds the authentication piece that OAuth lacks, providing a lightweight, JSON-based alternative to SAML that is very popular for mobile and modern web applications.OIDC provides login functionality using IdPs like Google, Microsoft, or Meta, while also enabling access to APIs via OAuth.

OIDC flow:

Login initiated: User initiates login on an app (the client).
Redirect to IdP: Redirected to the identity provider (e.g., Google).
Sign in and consent: The User signs in and grants permission.
Tokens returned: ID token and access token are returned to the app.
App engages tokens: App employs the ID token to confirm identity and the access token to call APIs.

When should you use SAML, OIDC, or OAuth?

SAML and OAuth allow SSO, which are crucial in keeping today’s employee workflows productive. They’re not exactly alternatives, more like technologies that can work together.

For example, If the Google environment opens in a new tab, OAuth handles authorization, and SAML handles authentication. You could use the two simultaneously to grant access (via SAML) and allow access to a protected resource (via OAuth).

OIDC extends OAuth 2.0 to include authentication. It not only tells you what the user can access, but also who the user is, combining identity and permissions. It’s ideal for modern web and mobile apps that need login and secure API access.