What is SAML? SAML, the Security Assertion Markup Language, is an XML-based standard for passing authentication and attribute information between organizations. Its main use is web single sign-on: a user authenticates once at an identity provider and then opens other applications without entering a password again.
The identity provider sends the application a signed XML document called an assertion. The application accepts it because it was configured in advance with the certificate to expect.
The current version, SAML 2.0, was published by OASIS in 2005. The OASIS SAML 2.0 technical overview describes it as a way of exchanging security information between on-line business partners.
The three parties in a SAML sign-in
Section 3.1 of the technical overview defines the participants. Every SAML configuration screen maps to these three roles.
| Party | What it does | Acme Corp example |
|---|---|---|
| Principal | The person (or entity) being described | Maria Lopez |
| Identity provider (IdP) | Signs the person in and creates the assertion | https://sso.acme.example/saml/idp |
| Service provider (SP) | The application that consumes the assertion and lets the person in | https://acme.expensedesk.example/saml/metadata |
Entity ID. The IdP and the SP each have one, usually written as a URL. It is an identifier, not a location, so it does not have to resolve to a web page.
Assertion consumer service (ACS) URL. The SP publishes it: the one endpoint where assertions may be delivered.
Principal. The person or entity the assertion describes.
SAML authentication: how a sign-in flows
The common flow is defined by the Web Browser SSO profile (technical overview, section 5.1). It starts at the application, so it is called SP-initiated.
| Step | What happens | Carried by |
|---|---|---|
| 1 | Maria opens ExpenseDesk. It has no session for her. | Browser request |
| 2 | ExpenseDesk builds an AuthnRequest with its own ID and redirects her browser to the IdP’s sign-on URL. |
HTTP Redirect binding |
| 3 | The IdP signs her in, or sees she already has a session. It checks that she may use ExpenseDesk. | IdP policy |
| 4 | The IdP builds a Response holding a signed assertion and sends her browser back to the ACS URL. |
HTTP POST binding |
| 5 | ExpenseDesk validates the assertion and starts its own session for her. | SP checks |
In the IdP-initiated flow, the user starts at the IdP and selects the application from a portal. The IdP posts an unsolicited response with no AuthnRequest behind it.
The profile requires that response to omit InResponseTo, so the application cannot bind it to a request it issued. For that reason, many teams prefer the SP-initiated flow when the application supports it.
What is inside an assertion
An assertion is a set of statements about the subject. SAML defines three statement types:
- Authentication: how and when the person signed in.
- Attribute: facts like email address or group.
- Authorization decision.
Web sign-in almost always uses the first two. The SAML assertion page annotates a real-format sample line by line; this page covers the concept.
Bindings
A binding defines how a SAML message travels over HTTP. Two cover almost all web sign-in:
- HTTP Redirect encodes the message in the URL, which suits short requests.
- HTTP POST carries it in an HTML form that the browser submits, which suits large signed responses.
The Artifact and SOAP bindings handle back-channel exchanges and are rare in everyday SSO. When a response arrives by HTTP POST, the profile requires its assertions to be signed.
Metadata: how the two sides learn each other’s values
SAML metadata is an XML document that describes one party: its entity ID, endpoints, supported bindings, and the certificates it uses to sign or encrypt.
- Best way. Exchanging metadata is the fastest and least error-prone way to configure a connection, because nobody retypes an entity ID by hand.
- No metadata. If a party publishes no metadata, copy the same values from each side’s settings page.
What to check when a SAML sign-in fails
Most failures are a mismatch between two strings or two clocks. Under the SAML profiles (section 4.1.4.3), a service provider must:
- verify the signatures;
- confirm that
Recipientmatches the ACS URL the response arrived on; - check that
NotOnOrAfterhas not passed, allowing for clock skew; - check that
InResponseToequals the ID of its own request.
When a sign-in fails, check in this order:
- Entity ID or audience mismatch. The value one side sends differs from what the other side registered, often by one character or a trailing slash.
- ACS URL mismatch. The assertion went to an address other than the registered one.
- Signature or certificate. The IdP rotated its certificate and the application still holds the old one.
- Clocks. The server clocks differ by more than the allowed skew, so the validity window appears to have closed.
- No usable NameID. The application matches users by email address, but the IdP sent an opaque identifier.
How SSOGEN handles SAML
SSOGEN is a complete identity provider and can take either SAML role. As the IdP, it shows each registered SAML application’s values on an Integration tab:
- Metadata. The metadata address, entity ID, single sign-on URL, single logout URL and signing certificate.
- Import. You can import the metadata into the application in one step.
- SSOGEN delivers assertions only to the registered ACS URL, never to an address named in a request.
- The default NameID is an opaque
persistentidentifier. For most SaaS products, select the email address instead on the Identity sent to app step. - SSOGEN starts a SAML sign-in only when the application sends a request, so a My Apps tile opens the application’s own SSO sign-in address.
SSOGEN can also act as the SP for your existing SAML identity provider. It requires every assertion from that provider to be signed, and this cannot be turned off. Its test sign-in reports which of the failures above occurred.
Questions people ask
Is SAML the same as SSO?
No. Single sign-on is the goal, and SAML is one protocol that achieves it; OpenID Connect is another. See what is SSO.
Is SAML obsolete?
The 2.0 standard dates from 2005. It is still the usual way enterprise software and SaaS products accept sign-in from an organization’s identity provider. Newer applications often use OpenID Connect instead, and many support both.
What does IdP stand for in SAML?
Identity provider: the system that authenticates the person and issues the assertion.
Does SAML do authorization?
The standard defines an authorization decision statement. In practice, SSO deployments use SAML to establish identity and pass attributes, and the application still decides what that person may do.
Where to go next
- SSOGEN as the IdP. To see it in a SAML sign-in, read SAML IdP.
- Related concepts. See IdP vs SP, SP-initiated vs IdP-initiated sign-in, ACS URL, entity ID and audience and SAML single logout.
- The assertion. Read the annotated SAML assertion.
- OpenID Connect. Compare OpenID Connect.
- Connect one. Follow register a SAML application.
- Upstream provider. See add a SAML identity provider.
- Older applications. SAML sign-in with SSOGEN covers them. Many Windows environments use Active Directory Federation Services as the identity provider for SAML applications.
- Every message. See SAML authentication, step by step.
- Certificate. The signing certificate in the metadata is an X.509 certificate. The certificate decoder shows its expiry and fingerprints.
- SCIM. SAML and SCIM solve different problems: see SCIM vs SAML.
Sources, all read 2026-10-09: SAML 2.0 Technical Overview.