TL;DR

SAML (Security Assertion Markup Language) is an XML-based standard for exchanging authentication and authorization data between an identity provider (like Okta or Azure AD) and a service provider (like Greenhouse or Workday). It's the enterprise standard that enables Single Sign-On across corporate applications. When a recruiter at a large company logs into their ATS using their company credentials without a separate username and password, SAML is usually what's making that work.

How SAML Works

SAML transfers proof of identity between two parties via a digitally signed XML document called an assertion. The identity provider (IdP) - the system that actually authenticates the user, like Okta or Microsoft Azure Active Directory - issues an assertion that says "this user is who they claim to be, and here are their attributes." The service provider (SP) - the application being accessed, like Lever or Greenhouse - trusts the IdP's assertion and grants access accordingly, without performing its own password check.

The flow for a browser-based SAML login works like this: a user navigates to their ATS login page and clicks "Log in with SSO." The ATS (service provider) generates a SAML authentication request and redirects the user's browser to the identity provider's endpoint. The user authenticates with the IdP - entering their corporate password, completing MFA, whatever the IdP requires. The IdP generates a signed SAML assertion and posts it back to the ATS via the user's browser. The ATS validates the signature, parses the assertion, and creates a session for the user. The user never saw a separate ATS password prompt.

Attributes packed into the SAML assertion carry more than just identity. Most enterprise deployments include the user's email, name, department, job title, and group memberships. ATS platforms use these attributes to automate provisioning - when a new recruiter joins and their Okta account is added to the "Recruiting" group, the SAML assertion the first time they log in can automatically create their ATS account with the correct role. This is called just-in-time (JIT) provisioning, and it removes the manual step of creating accounts in every tool.

SAML is XML-based and verbose by design - enterprise reliability over developer ergonomics. Configuring SAML typically involves exchanging metadata files between the IdP and SP, copying certificate fingerprints, and setting up attribute mappings. Most enterprise ATS platforms have step-by-step SAML setup guides for Okta, Azure AD, and Google Workspace. The configuration is done once, and once it's working, it requires minimal maintenance unless certificates expire.

Why It Matters in Recruitment

For enterprise recruiting teams and large staffing agencies, centralized identity management is not optional - it's a compliance and security requirement. SAML enables the IT security team to enforce authentication policies (MFA, password complexity, conditional access) centrally in the IdP, with those policies automatically applying to every connected application. When a recruiter is terminated, deactivating their account in Okta immediately revokes access to the ATS, the sourcing tool, the background check platform, and everything else connected via SAML - in one action.

Without SAML, offboarding is a checklist problem. HR or IT has to manually revoke access in every individual system, relying on a list that's often incomplete. The typical enterprise uses between 200 and 300 SaaS applications. Expecting IT to hit every one of them correctly every time someone leaves is unrealistic. SAML SSO with a well-maintained IdP collapses that risk significantly.

For staffing agencies that provide client portal access to hiring managers, SAML also enables clients to use their own corporate credentials to log into the agency's ATS portal. A hiring manager at a client company can access the portal using their Microsoft 365 credentials, without the agency creating and managing a separate password for that person. This reduces friction during candidate review and eliminates a category of support tickets.

SAML in Practice

A 500-person professional services firm is rolling out Greenhouse as their ATS and needs SSO configured before go-live. Their IT team uses Azure Active Directory as the IdP. The Greenhouse admin downloads the Greenhouse SAML metadata XML and uploads it to a new Enterprise Application in Azure AD. Azure AD generates a federation metadata URL that Greenhouse needs. The IT team enters the Azure metadata URL in Greenhouse's SSO settings, maps the email attribute from Azure to the Greenhouse user identifier, and enables JIT provisioning so new recruiters don't need manual account creation.

They test with a pilot user. The recruiter navigates to Greenhouse, clicks "Sign in with SSO," is redirected to the Microsoft login page, authenticates with their corporate credentials and MFA, and lands in Greenhouse with an automatically created account. The configuration took about two hours. Every recruiter who joins the company going forward gets Greenhouse access automatically when IT adds them to the correct Azure AD group.

Key Considerations