What Is SAML? How SAML 2.0 Authentication Works

SAML stands for Security Assertion Markup Language. It is an XML-based standard for exchanging statements about a user between an identity provider (IdP) and a service provider (SP). In a common web single sign-on (SSO) flow, the IdP authenticates the user and sends a SAML response to the SP. The SP validates that response before creating its own application session. SAML does not, by itself, decide which customer account or application resource the user may access.

In B2B SaaS, one person can belong to two customer accounts. A valid sign-in for Tenant A cannot become permission to read Tenant B’s data. For the broader user experience, see what SSO is.

What are the IdP, SP and user doing?

The identity provider authenticates a person and issues statements about that authentication. The service provider is the application, or a managed identity layer in front of it, that receives and validates those statements. The user’s browser carries messages between the two in the Web Browser SSO profile. The browser is a transport participant, not a trusted authority simply because it delivered the message.

Consider a SaaS customer whose employees sign in through its corporate IdP. The customer’s IdP may authenticate an employee with its own password and MFA policy. The SaaS SP receives an assertion about that authentication; it does not receive the employee’s password. A subsequent SaaS session and any account membership or resource decision are separate from the SAML exchange.

The OASIS technical overview describes SAML assertions, protocols, bindings and profiles. Those terms have different jobs:

• An assertion contains statements about a subject, such as an authentication event or attributes.
• A protocol defines request and response messages and processing rules.
• A binding maps a SAML message to a transport, such as HTTP Redirect or HTTP POST.
• A profile combines those pieces for a use case. Web Browser SSO is the one most SaaS readers encounter.

How does a typical SAML login work?

In an SP-initiated browser SSO flow, the application begins with an authentication request. The IdP may authenticate the user at that point or reuse an existing IdP session. The browser carries the response back to the SP’s assertion consumer service (ACS) endpoint. The SP must validate the response before it relies on any identity or attribute inside it.

1. The user asks to open the SaaS application. The SP identifies the intended IdP connection and sends an AuthnRequest through the browser.
2. The IdP authenticates the user or checks an existing IdP session, then issues a SAML Response containing an assertion. The response commonly returns to the ACS via the browser’s HTTP POST.
3. The SP confirms the response reports success, then verifies it against its trusted IdP configuration: issuer and signing key, signature over what it consumes, intended audience and destination, timing, subject-confirmation conditions, replay protection and, for an SP-initiated exchange, correlation to the request it sent.
4. After validation and local account/user checks, the SP establishes an application session. The app still checks its own tenant and resource permissions on subsequent operations.

An IdP-initiated flow begins at the IdP. The SP receives an unsolicited response without an earlier AuthnRequest from that app session, so it cannot use the same InResponseTo request correlation. It needs an explicit acceptance policy and other controls. Neither direction turns the browser into a trusted source of identity. The OASIS Web Browser SSO profile describes the profile-level rules.

What is in a SAML response and assertion?

A SAML response is the protocol message delivered to the SP. It can contain one or more assertions; the assertion carries statements and conditions about a subject. People sometimes call the assertion a “SAML token,” but it is an XML security assertion, not automatically a JWT or the application’s API access token.

When reading a response for troubleshooting or security review, separate these fields and checks:

• Response status: the StatusCode must be urn:oasis:names:tc:SAML:2.0:status:Success before the response is treated as a successful sign-in.
• Issuer and trusted key: who issued the response or assertion, and whether the configured signing material is the one trusted for this connection.
• Subject and NameID: which principal the IdP is asserting. The format and stability of that identifier matter to local identity mapping; an email address should not be assumed immutable or unique across all customer accounts.
• AuthnStatement and attributes: an authentication statement records an authentication event; optional attributes may carry email, group or other values. A group attribute is input to an application mapping policy, not universal permission to every object.
• Conditions and audience: a validity window and any AudienceRestriction constrain when and for whom the assertion is intended. A response addressed to another SP must not be accepted here.
• Recipient, destination and request correlation: bearer SubjectConfirmationData can bind an assertion to the ACS recipient and a deadline; the response’s destination and, where applicable, InResponseTo must match the exchange the SP expects.
• Signature and replay controls: the SP must verify the signature on the element it actually uses and reject responses/assertions already consumed under its replay policy. Checking an XML signature somewhere in a document is not enough if the application later reads a different element.

The exact required checks depend on the profile, binding and configured trust relationship. Use a maintained SAML implementation and a security review rather than implementing these checks from a short illustrative XML sample. OWASP’s SAML guidance covers signature-wrapping and validation risks.

Do SAML assertions authorize the user?

SAML can express authentication, attribute and authorization-decision statements. In the common web SSO use case, the assertion primarily establishes an authenticated identity for a particular SP under specific conditions. It does not mean “allow this person to access every resource in the SaaS application.” The SP and app still need a local onboarding, membership and authorization model.

A typical SaaS trust boundary: IdP authenticates → SP validates the SAML response → app resolves tenant membership and establishes an active-tenant session → app checks each resource request against tenant ownership and permission. The assertion supplies identity context; it does not itself authorize access to every resource.

For example, the same employee might be a member of Tenant A and Tenant B. A Tenant A SAML connection may establish the person’s identity and active Tenant A context. A later API request for a Tenant B invoice must still be rejected unless a separate, trusted Tenant B context and permission policy authorize that action. Email-domain matching, an IdP group name and a valid signature cannot replace the resource’s tenant-ownership check. Frontegg’s authorization guide explains the downstream decision boundary.

The IdP may later disable the person or change a group. SAML does not define how quickly an already-issued application session or access token is revoked after that change. Treat session lifetime, refresh, group reassignment and revocation as integration-specific behavior to verify, not as a guarantee of the protocol.

Are signing and encryption the same thing?

No. A digital signature lets the SP verify integrity and the configured issuer’s signing key for the signed content. Encryption protects the confidentiality of selected SAML content for an intended recipient. HTTPS protects the transport channel. These controls solve different problems; encrypting an assertion does not replace signature, audience, recipient, timing or replay checks. Not every SAML exchange encrypts the assertion, and the requirement should come from the parties’ configuration and risk model.

IdP signing-certificate rotation is therefore an operational event. The SP needs a way to trust the new certificate at the right time and reject an untrusted one. Whether old and new keys can overlap is implementation-specific; do not promise a seamless cutover without testing the chosen IdP/SP behavior.

How is SAML different from SSO, OIDC and OAuth?

SSO is the user outcome: one authentication at an IdP can let a user enter multiple connected applications without typing credentials for each one. SAML is one standards-based way to carry that authentication information to a web SP. OIDC is another federation/authentication protocol, built on OAuth 2.0. OAuth 2.0 by itself is an authorization framework for delegated access; it does not define a general-purpose user-authentication result.

These terms do not map neatly to “old versus new” or “secure versus insecure.” The right choice depends on the customer’s IdP, the application architecture, the required flows and the integration’s security controls. Use the separate OIDC vs SAML guide for that decision instead of trying to infer it from XML versus JSON alone. Version-to-version differences are a separate question from choosing between SAML and OIDC.

Where does Frontegg fit?

Frontegg documents SAML and OIDC as enterprise SSO connection types in its SSO overview. In a customer-IdP SAML connection, Frontegg acts as the SP: its ACS receives and processes the IdP response. The SAML environment setup and customer self-service connection guide show how a SaaS provider configures the SP side and lets an account admin supply the customer’s IdP details where enabled. Those product docs, not a generic protocol article, are the right place for current ACS, redirect and portal steps.

Using a managed SAML connection can remove the need to implement the upstream XML exchange in your application. Before trusting the resulting Frontegg-issued JWT, your backend must verify its signature and claims, directly or with a Frontegg SDK. The token’s tenantId identifies its tenant context; the application must still check that each requested resource belongs to the active tenant and that the user is permitted to perform the action. For current ACS, redirect and account-connection steps, use the Frontegg SAML setup documentation.