SAML

The Bouncer and the Wristband

Imagine you want to get into a VIP section at a music festival.

You walk up to the VIP tent, and a massive bouncer stops you. The bouncer doesn't know who you are, doesn't want to see your driver's license, and definitely doesn't have a giant list of every VIP attendee. The bouncer only cares about one thing: Do you have a shiny, glowing wristband?

To get that wristband, you had to go to the main ticketing office. The ticketing office checked your ID, verified you paid for VIP, and then strapped the un-fakeable wristband to your arm.

When the bouncer sees the wristband, they let you in. Why? Because the bouncer (the VIP tent) explicitly trusts the ticketing office.

This is exactly how SAML (Security Assertion Markup Language) works. It is the underlying technology that powers Single Sign-On (SSO) in the corporate world, allowing you to log into dozens of apps without creating dozens of passwords.

The Password Fatigue Problem

Before SAML, corporate life was a nightmare of passwords. An employee might use Jira for bug tracking, Slack for messaging, Workday for HR, and Salesforce for sales.

That meant four different usernames, four different passwords, and four different password expiration policies. Employees inevitably suffered from password fatigue. They would write passwords on sticky notes, use Password123!, and reuse credentials across platforms.

Worse, when an employee was fired, the IT department had to scramble to manually log into Jira, Slack, Workday, and Salesforce to delete the user's accounts before they could steal company data.

How SAML Solves This

SAML introduces a central authority to handle all logins. In the SAML framework, there are three primary actors:

1. The Principal: That's you, the user trying to log in.
2. The Identity Provider (IdP): The ticketing office. This is the centralized system that knows your username and password (e.g., Okta, Microsoft Entra ID, Auth0).
3. The Service Provider (SP): The bouncer. The app you actually want to use (e.g., Slack, Salesforce, Jira).

The SAML Authentication Flow

When you attempt to log into Slack using SAML, here is what happens behind the scenes:

1. The Request: You navigate to Slack.com and type in your company email.
2. The Redirection: Slack sees you are from a corporate domain. Instead of asking for a password, Slack redirects your browser to your company's Identity Provider (Okta).
3. The Authentication: You arrive at Okta. Okta asks for your username, password, and maybe a 2FA code sent to your phone.
4. The Assertion (The Wristband): If you pass, Okta generates an XML document called a SAML Assertion. This document cryptographically says, "I am Okta, and I verify that this user is Alice." Okta digitally signs this XML with an asymmetric private key so it cannot be forged.
5. The Access: Your browser forwards this XML Assertion back to Slack. Slack validates the digital signature using Okta's public key. Slack trusts Okta, so it instantly logs you in.

Notice the beauty here: Slack never saw your password.

Press enter or space to select a node. You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel.

Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.

algobase.dev

SAML SSO flow: the user navigates to the service provider, is redirected to the identity provider for authentication, receives a digitally signed SAML Assertion, and presents it to the service provider. The service provider trusts the assertion because it was signed by the identity provider's private key. The service provider never sees the user's password.

1 / 10.5×1×2×3×Playground

SAML SSO flow: user is redirected to the identity provider, authenticates, receives a signed assertion, and presents it to the service provider

The Power of Centralization

Because SAML moves all authentication to a single Identity Provider, it solves the massive IT headaches of the past.

• Single Sign-On (SSO): Once you log into Okta in the morning, Okta puts a cookie in your browser. When you try to access Jira 10 minutes later, Jira redirects you to Okta, Okta sees you are already authenticated, and instantly bounces you back to Jira with a new SAML Assertion. You don't have to type your password again.
• Instant Offboarding: When an employee quits, the IT administrator just disables their account in Okta. Suddenly, that user can no longer get SAML assertions for Slack, Jira, or Salesforce. All access is revoked globally in one second.
• Enforced Security: If the company decides they want to mandate biometric Fingerprint scanning for all logins, they don't have to wait for Slack, Jira, and Salesforce to support it. They just turn it on at the Okta (IdP) level.

SAML vs. OAuth / OIDC

It's worth noting that SAML is an older, XML-based protocol built in the early 2000s. It is heavily entrenched in enterprise software and B2B (Business-to-Business) applications.

Modern B2C (Business-to-Consumer) applications, like clicking "Log in with Google" on a random website, typically use newer, JSON-based protocols called OAuth 2.0 and OpenID Connect (OIDC). While the underlying data formats are different, the conceptual architecture (relying on a trusted Identity Provider) is very similar.

Summary

• SAML is an XML-based protocol that allows Identity Providers to pass authorization credentials to Service Providers.
• It is the backbone of enterprise Single Sign-On (SSO), allowing users to log into many apps using one set of credentials.
• The Identity Provider (IdP) acts as the central source of truth that verifies passwords.
• The Service Provider (SP) trusts the IdP and grants access based on digitally signed SAML Assertions.
• SAML drastically improves security by eliminating password fatigue and allowing IT to instantly revoke all access from a single dashboard.