SAML stands for Security Assertion Markup Language. It is an open standard that lets trusted systems exchange security information, including information about authentication and user attributes.
In a common SAML single sign-on (SSO) flow, a person signs in once with their organization’s identity provider, then opens connected work applications without re-entering the same password. The application relies on a SAML response from the trusted IdP instead of receiving the user’s IdP password itself.
Key Takeaways
- SAML enables federated authentication: Security Assertion Markup Language (SAML) lets trusted identity providers (IdPs) and service providers (SPs) exchange authentication information using a standard format.
- SAML is commonly used for SSO: Users can authenticate through their organization’s IdP and access connected applications without repeatedly entering separate passwords.
- The IdP and SP have distinct roles: The IdP authenticates the user and issues a SAML response, while the SP validates it and determines whether to create a user session.
- SAML is different from OAuth and OIDC: SAML is widely used for enterprise web SSO, OAuth 2.0 focuses on delegated authorization, and OpenID Connect (OIDC) provides an identity layer built on OAuth 2.0.
- Secure implementation depends on configuration: Trust settings, certificates, signatures, attribute mappings, endpoints, and validation requirements need to be configured correctly between the IdP and SP.
- Scalefusion OneIdP supports SAML-based SSO: Organizations can use OneIdP as an identity provider for SAML-enabled work applications and manage authentication and supported access policies around the sign-in experience.
That matters when a team uses a growing set of cloud and internal tools. Rather than maintaining separate sign-in experiences for every application, the organization can centralize authentication and give users a simpler path to the tools they need.
This guide explains what SAML is, how SAML authentication works, how SAML supports SSO, and what to consider before setting up an integration.
SAML at a glance
SAML can feel technical because it involves several systems that need to trust one another. The core roles are straightforward:
| Term | What it means | Example |
|---|---|---|
| User (or principal) | The person trying to access an application | An employee opening a work app |
| Identity provider (IdP) | The trusted service that verifies the user’s identity | The organization’s identity service |
| Service provider (SP) | The application the user wants to use | A SaaS application or internal portal |
| SAML assertion | A statement issued by the IdP that can contain authentication information and, depending on the integration, user attributes | Evidence that the user authenticated at the IdP, optionally accompanied by attributes such as a user identifier |
The IdP and SP must be configured to trust one another. Once that relationship is in place, the IdP can send a SAML response containing an assertion that the SP uses when deciding whether to create a session for the user.
The assertion helps establish who the user is. The service provider still decides what that user is allowed to access or do inside the application.
How does SAML work?
At a high level, SAML moves proof of authentication from the identity provider to the service provider. A typical SAML authentication flow looks like this:
- The user opens an application.They visit a service provider, such as a project-management tool or an internal portal.
- The user is sent to the identity provider. If the app does not already have a valid session for that user, it sends them to the trusted IdP to sign in.
- The IdP authenticates the user. The IdP applies the organization’s sign-in policy. That may include a password, multifactor authentication, or another approved method.
- The IdP sends a SAML response. After authentication, the IdP creates a SAML response that can contain an assertion and returns it to the service provider through the browser.
- The SP validates the SAML response. If the response meets the service provider’s validation and access requirements, the application creates a session for the user.
The user experiences one sign-in. Behind the scenes, the IdP is confirming the user’s identity to the application in a standard format the application understands.
Important: SAML deployments commonly use digital signatures to protect the assertion or SAML response. The exact signature requirements depend on the SAML profile, binding, and integration. Encryption can also be configured when needed, but it is not automatic in every SAML deployment. The service provider should validate the SAML response according to its configured trust relationship and security requirements.
What is SAML authentication?
SAML authentication is the process of using a SAML assertion to help a service provider confirm that a user has already authenticated with a trusted identity provider.
This is different from an application checking a password itself. In a SAML setup, the IdP handles the sign-in step and the SP relies on the authentication result it receives. The SP can then decide whether to create a session and what access the user should receive based on its own rules and the information in the assertion.
SAML can carry information about a user, such as an identifier or approved attributes. What an application receives and how it uses that information depends on the specific integration. For that reason, teams should review attribute mappings and access rules as carefully as they review the sign-in flow.
What is SAML SSO?
SAML SSO is a common use of SAML that allows a user to sign in once and access multiple connected web applications. Instead of asking the user for a separate password at each application, each service provider trusts the same identity provider.
For users, that reduces repeated login prompts. For IT teams, it provides a more centralized way to apply authentication and sign-in policy across SAML-enabled applications. It does not mean every app automatically has the same permissions; each application still needs its own access rules and configuration.
SP-initiated vs. IdP-initiated SSO
SAML SSO can begin in two common ways:
- SP-initiated SSO: The user starts at an application. The service provider redirects them to the IdP to authenticate, then validates the returned SAML response and the assertion it contains.
- IdP-initiated SSO: The user starts from an identity-provider portal or app launcher. The IdP sends a SAML response containing an assertion to the selected service provider so the user can open the application.
Both approaches can give users a single sign-on experience. The appropriate choice depends on the application, identity provider, and security requirements, so follow the documentation for the specific products involved when configuring the flow.
Common SAML use cases
SAML is most useful when an organization needs to share a trusted sign-in across separate web applications or domains. Common examples include:
Workforce access to SaaS applications
Employees often use many hosted applications during a workday. SAML can let them authenticate with the organization’s IdP, then open connected SaaS applications without maintaining a separate password for each one.
Access to internal web applications
An internal portal can use SAML to rely on the organization’s identity system rather than manage an independent password store. This can make the sign-in experience more consistent for employees while keeping access decisions close to the application.
Partner, contractor, or acquired-company access
In some situations, a service provider can be configured to trust an external identity provider. This form of federation can reduce the need for separate authentication credentials when the participating organizations have an appropriate trust relationship and clearly defined access rules.
Centralized authentication policy at the IdP
An organization can evaluate its sign-in policy at the IdP before confirming the user’s authentication to the service provider. For example, the IdP may require multifactor authentication before creating the SAML response used in the SSO flow. SAML carries authentication information between trusted parties; the final security outcome still depends on the IdP, the service provider, and the way both are configured.
What is SAML 2.0?
SAML 2.0 is the widely used version of the SAML standard for exchanging security information between trusted parties. It defines the formats and rules that help identity providers and service providers exchange assertions in a consistent way.
For most readers, the practical point is simple: when an IdP and SP both support SAML 2.0 and are configured correctly, they can establish a trusted SSO flow without building a proprietary sign-in exchange from scratch.
SAML vs. OAuth vs. OpenID Connect
SAML, OAuth 2.0, and OpenID Connect are related identity technologies, but they do different jobs. Treating them as interchangeable can lead to poor design decisions.
| Standard | Primary job | Common use |
|---|---|---|
| SAML | Federated authentication for browser-based enterprise SSO | Workforce access to SaaS and internal web applications |
| OAuth 2.0 | Delegated authorization | Allowing an application to access a resource without sharing a user’s password |
| OpenID Connect (OIDC) | An identity layer built on OAuth 2.0 | Modern web and mobile sign-in flows |
SAML is often a strong fit for browser-based enterprise SSO. OAuth is commonly used when an application needs permission to act on a user’s behalf, while OIDC provides a modern identity layer on top of OAuth 2.0. For a deeper comparison, see SAML vs. OIDC.
Benefits of SAML authentication
When it is configured carefully, SAML authentication can provide meaningful benefits for users and IT teams.
Fewer repeated sign-ins
Users authenticate through a central identity provider instead of repeatedly entering separate application credentials during normal SSO access. This can reduce sign-in friction while leaving account provisioning and application permissions to the systems and integrations responsible for those tasks.
A more consistent access experience
Teams can apply sign-in policy at the IdP and use the same trusted identity across participating applications. That creates a more consistent experience as users move between work tools.
Less duplicate authentication handling
Applications participating in SAML SSO can rely on authentication performed by a trusted IdP instead of maintaining a separate sign-in flow for the same user. SAML does not by itself provision accounts, remove users, or manage application permissions. For a clearer distinction between SAML-based authentication and SCIM-based user provisioning, read SCIM vs. SAML. Those lifecycle and authorization tasks may require separate processes or integrations.
More consistent sign-in policy
Centralizing authentication can give IT teams a more consistent place to manage sign-in policy across connected applications. Access reviews and authorization still depend on how identities, permissions, and application access are managed. SAML alone does not make an organization compliant with any regulation.
What to check before implementing SAML
A working SAML integration depends on more than selecting “SAML” in two product settings. Before rollout, confirm these basics:
- Metadata and endpoints: Exchange and review SAML metadata, including entity IDs and service endpoints.
- Assertion consumer service (ACS) URL: Confirm the URL where the service provider expects the SAML response.
- Issuer, audience, and attribute mappings: Make sure the values each side expects are aligned and that the application receives the identifiers it needs.
- Certificates and signing: Establish what is signed – the assertion, response, or both – how signatures are validated, and who owns certificate rotation.
- HTTPS, time synchronization, and session behavior: Use secure transport, keep participating systems’ clocks synchronized, and understand how sessions, timeouts, and logout behavior work.
- Testing: Test the normal sign-in flow, rejected access, expired or rotated certificates, and changes to user access before a broad rollout.
These checks are not a replacement for vendor documentation or an identity-security review. They are a practical starting point for the conversation between the team that owns the IdP and the team that owns the application.
Using SAML SSO with Scalefusion OneIdP
When employees need access to multiple SAML-enabled work applications, IT teams need a way to centralize authentication while keeping application access under administrative control.
Scalefusion OneIdP supports SAML-based single sign-on for work applications. IT teams can configure OneIdP as the trusted identity provider, define which users are in scope for a configured SSO application, and apply supported conditional-access policies around the sign-in experience.
Before rollout, confirm the applications you need to support, identity sources, user scope, authentication requirements, device prerequisites, and access policies against current OneIdP documentation and the requirements of each service provider.
Make sign-in easier without making access decisions harder
SAML gives organizations a standard way to establish trust between an identity provider and the applications employees use. It can reduce repeated sign-ins while allowing authentication policy to remain centralized. Application permissions still need to be configured and governed separately.
If SAML fits your application environment, assess how your identity provider, service providers, user lifecycle, and access policies need to work together.
FAQs
1. What is a SAML assertion?
A SAML assertion is a statement issued by an identity provider that a service provider can validate. It can communicate authentication information and, depending on the integration, user attributes or other identity details the SP needs to make an access decision.
2. What is the difference between SAML and SSO?
SAML is a standard for exchanging security information between trusted systems and is commonly used to support federated authentication. SSO is the user experience of signing in once and accessing multiple connected applications. SAML is one widely used way to enable browser-based SSO.
3. Is SAML the same as OAuth?
No. SAML is commonly used for federated authentication and enterprise web SSO. OAuth 2.0 is primarily an authorization framework that allows an application to access a resource without receiving the user’s password.
4. Can SAML work with MFA?
Yes. An identity provider can require MFA before completing authentication and creating the SAML response used in the SSO flow. SAML does not perform MFA itself; it carries information about the resulting authentication to the service provider.
5. Is a SAML assertion always encrypted?
No. SAML deployments commonly use digital signatures to protect the assertion or SAML response so the service provider can validate integrity and origin. Whether an assertion is encrypted depends on the integration and its security requirements.
6. What is the difference between IdP-initiated and SP-initiated SSO?
With SP-initiated SSO, the user starts at the application and is redirected to the identity provider. With IdP-initiated SSO, the user starts from an identity-provider portal or app launcher. The IdP sends a SAML response containing an assertion to the service provider for validation.
