What is SAML?

🔐 Overview of SAML

SAML enables secure login between systems by exchanging authentication data called assertions.

Key Components

• 📌 IdP (Identity Provider): Handles the actual login and authenticates the user.
• 📌 SP (Service Provider): The web service or app the user wants to access.
• 📌 Assertion: An XML document that conveys the authentication result from the IdP.

🔁 SAML Communication Flow

SAML flows through the browser between SP and IdP using SAMLRequest and SAMLResponse messages.

Main Steps

• ➡️ User accesses the SP (e.g., internal portal).
• ➡️ SP generates a SAMLRequest and redirects the user to the IdP.
• ➡️ User logs in to the IdP.
• ➡️ IdP generates a SAMLResponse and sends it back to the SP via browser.
• ➡️ SP validates signatures with trusted keys, issuer, recipient, expiry, request correlation and replay protection before establishing login.

📨 SAMLRequest

During authentication, SAMLRequest carries AuthnRequest. The same parameter also carries other requests, such as LogoutRequest. Encoding depends on the binding.

Overview

• 🔍 Sent from SP to IdP (AuthnRequest) via Redirect or POST.
• 🔍 POST uses Base64 XML; the standard Redirect encoding applies raw DEFLATE, Base64 and URL encoding in that order.
• 🔍 Signature may be required depending on IdP policy.

Example

Minimal AuthnRequest (signature/encryption omitted).

<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
    ID="_req123" Version="2.0" IssueInstant="2024-01-01T00:00:00Z"
    Destination="https://idp.example.com/sso" AssertionConsumerServiceURL="https://sp.example.com/acs">
  <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://sp.example.com/metadata</saml:Issuer>
</samlp:AuthnRequest>

Base64 / Redirect example

The standard Redirect encoding applies raw DEFLATE, Base64 and URL encoding. The schematic below requires a generated parameter value in place of the placeholder.

https://idp.example.com/sso?SAMLRequest={URL_ENCODED_BASE64_RAW_DEFLATE}

📄 SAMLResponse

Response from IdP to SP. Usually signed; assertions may be encrypted.

Overview

• 🔍 Sent from IdP to SP; usually signed (and often includes encrypted Assertion).
• 🔍 Base64-encoded XML, typically delivered via POST.
• 🔍 For SP-initiated login, correlate InResponseTo with the request. IdP-initiated responses omit it and require a separately supported validation flow.

Example

Unsigned structural example only. Production requires signatures, unique IDs, current timestamps and correct endpoints. Do not accept this example for login.

<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" Version="2.0" ID="_res123"
    IssueInstant="2024-01-01T00:00:05Z" Destination="https://sp.example.com/acs" InResponseTo="_req123">
  <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://idp.example.com/metadata</saml:Issuer>
  <samlp:Status><samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" /></samlp:Status>
  <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Version="2.0" ID="_assert123" IssueInstant="2024-01-01T00:00:05Z">
    <saml:Issuer>https://idp.example.com/metadata</saml:Issuer>
    <saml:Subject>
      <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">user@example.com</saml:NameID>
      <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
        <saml:SubjectConfirmationData Recipient="https://sp.example.com/acs" InResponseTo="_req123"
          NotOnOrAfter="2024-01-01T00:05:05Z" />
      </saml:SubjectConfirmation>
    </saml:Subject>
    <saml:Conditions NotBefore="2024-01-01T00:00:05Z" NotOnOrAfter="2024-01-01T00:05:05Z"><saml:AudienceRestriction><saml:Audience>https://sp.example.com/metadata</saml:Audience></saml:AudienceRestriction></saml:Conditions>
    <saml:AuthnStatement AuthnInstant="2024-01-01T00:00:00Z"><saml:AuthnContext><saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef></saml:AuthnContext></saml:AuthnStatement>
  </saml:Assertion>
</samlp:Response>

Base64 / POST example

HTTP-POST binding sends a Base64-encoded response in a form (example data is shortened).

<form method="post" action="https://sp.example.com/acs">
  <input type="hidden" name="SAMLResponse" value="PHNhbWxwOlJlc3BvbnNlIHhtbG5zOnNhbWxwPSJ1cm4... (Base64 response)..." />
  <input type="submit" value="Send" />
</form>

🌐 Where SAML is Used

Typical scenarios where SAML shines, especially for enterprise SSO between different services.

Common Use Cases

• ✅ Single sign-on between internal systems and cloud apps.
• ✅ Connecting Google Workspace or Microsoft 365 to external tools.
• ✅ Using IdP authentication to establish independent sessions at each SP.

Specifications and related guides

OASIS SAML core / OASIS SAML bindings / OASIS SAML profiles
Related SAML guide