An employee signs in successfully through the company’s identity provider but cannot open the application. Another employee gets in but receives the wrong role.
Both problems can occur in the same SSO deployment. Authentication, account matching, and application permissions are separate checks, often managed by different teams.
The SSO IdP vs. SP distinction helps explain who owns each part. The identity provider verifies the user’s identity. The service provider accepts that identity information, establishes an application session, and enforces access permissions.
Understanding this relationship makes SAML integrations easier to configure, troubleshoot, and secure.
What Is SSO?
SSO means single sign-on. It allows users to authenticate through a shared sign-in system and access multiple connected applications without repeatedly entering credentials, subject to session and access policies.
For example, an employee might sign in through the company’s identity portal and then open its expense application and project-management platform.
SSO describes the sign-in experience. It is not a specific protocol. SAML and OpenID Connect are two protocols that can support it.
SSO also does not mean unlimited access. An application may require additional authentication, reject an unassigned user, or restrict particular actions.
For the broader access-control context, see Sennovate’s introduction to identity and access management.
What Do IdP and SP Mean?
An identity provider and a service provider perform different roles within a federated login.
IdP Meaning: Identity Provider
An identity provider, or IdP, authenticates users and supplies identity information to applications that trust it.
Depending on its configuration, the IdP can evaluate passwords, MFA, device conditions, and other sign-in requirements. It may authenticate against an external directory rather than store credentials itself.
Okta and Microsoft Entra ID commonly perform this role in enterprise environments.
SP Meaning: Service Provider
A service provider, or SP, is the application or service the user wants to access.
In a SAML integration, the SP validates information received from the IdP and associates the authenticated identity with an application account. It then applies its own access rules.
An expense-management platform, customer-support application, or employee portal can act as an SP.
These are roles within a particular relationship. A platform can act as an SP toward an upstream identity provider and as an IdP toward downstream applications. Auth0’s SAML overview explains these deployment options.
SSO IdP vs. SP: Key Differences
| Responsibility | Identity Provider | Service Provider |
| Main purpose | Authenticates the user | Provides the application or resource |
| SAML information | Issues identity assertions | Validates and consumes assertions |
| Authentication policies | Evaluates sign-in requirements | Can request authentication requirements and check the result |
| User information | Supplies identifiers and configured attributes | Maps received information to an application account |
| Authorization | Can restrict app assignment and supply role claims | Enforces application permissions |
| Sessions | Maintains the IdP session | Maintains a separate application session |
| Typical troubleshooting | MFA failures, blocked sign-ins, missing claims | Rejected assertions, account mismatches, incorrect roles |
The distinction is useful during support investigations. A successful IdP login confirms only one part of the process. The application still needs to validate the SAML response and decide whether the user can enter.
How SAML Authentication Works
SAML stands for Security Assertion Markup Language. It is an XML-based standard for exchanging security information between systems.
In a common SP-initiated browser flow, the application requests authentication and the IdP returns a response containing an assertion about the user. The user’s password is not passed to the application.
Establish the Trust Configuration
Before anyone signs in, administrators configure the connection on both sides.
Common settings include:
- Entity IDs identifying the IdP and SP
- The IdP’s sign-in endpoint
- The SP’s Assertion Consumer Service, or ACS, URL
- Signing certificates
- The user identifier and required attributes
The ACS URL is where the SP receives the SAML response. The SP entity ID identifies the intended service; these values serve different purposes.
Follow the Login Sequence
- The user opens the application.
- The SP sends an authentication request through the browser to the IdP.
- The IdP authenticates the user or evaluates an existing session against the applicable policy.
- The IdP creates a SAML response containing the assertion.
- The browser submits the response to the SP’s ACS endpoint.
- The SP validates the response, identifies the account, and establishes a session if access is permitted.
Microsoft’s SAML protocol documentation describes the request and response elements used in this exchange.
A signature establishes authenticity and integrity when validated correctly. Encryption protects confidentiality. Signing a SAML message does not automatically encrypt its contents.
IdP-Initiated vs. SP-Initiated SSO
The IdP vs. SP comparison concerns system responsibilities. IdP-initiated vs. SP-initiated SSO concerns how a login begins.
SP-Initiated SSO
The user starts at the application. The SP generates an authentication request and redirects the browser to the IdP.
The returned response can be correlated with that request. This gives the SP context for checking whether the response belongs to a login it initiated.
IdP-Initiated SSO
The user starts at an identity portal and launches an application. In a true IdP-initiated SAML flow, the IdP sends an unsolicited response without a preceding SP authentication request.
Not every portal tile uses this flow. Some tiles simply open the application and trigger SP-initiated authentication.
Because unsolicited responses lack the same request correlation, IdP-initiated SSO requires careful review. OWASP’s SAML security guidance discusses this risk and recommends controls for validating SAML exchanges.
What Is SAML Attribute Mapping?
SAML attribute mapping connects identity information from the IdP to fields the application understands.
An IdP might send an email address, employee identifier, department, or application-specific role. The SP needs the expected names, formats, and values to interpret them correctly.
Consider this illustrative configuration:
| Directory Value | SAML Field | Application Use |
| Persistent employee identifier | NameID | Matches the user to an account |
| Work email address | Populates contact information | |
| Given name | firstName | Displays the user’s first name |
| Assigned application role | appRole | Maps to an approved permission set |
NameID identifies the subject of an assertion; it is separate from ordinary attributes. The exact identifier and attribute names depend on the application.
Microsoft’s SAML claims customization documentation explains how administrators configure identifiers, claim sources, and transformations.
Mapping Errors Can Affect Access
An incorrect identifier may prevent an existing account from matching. Where just-in-time account creation is enabled, it could also produce an unintended new account.
A role-mapping mistake can be more serious. Mapping a broad employee group to an administrator role can grant unnecessary privileges even though authentication worked correctly.
Send only the attributes the application needs. Restrict who can change directory values that influence permissions, and test standard users separately from administrators.
Common SAML Problems and What to Check
Troubleshooting is easier when teams identify the stage that failed.
The User Cannot Authenticate
Start with the IdP’s sign-in logs. Check account status, application assignment, MFA requirements, and access-policy decisions.
Authentication Succeeds, but the Application Rejects Login
Compare the configured entity IDs, ACS URL, signing certificate, and identifier format. Check assertion validity times and clock synchronization.
Use approved diagnostic tools. SAML responses can contain personal information and sensitive authentication material, so avoid uploading production responses to public decoders.
The User Receives the Wrong Permissions
Inspect the attributes the IdP actually sent. Then check the SP’s role mappings and local permissions.
A corrected claim does not necessarily update an already active application session.
A Disabled User Still Has Access
The IdP and SP maintain separate sessions. Disabling an IdP account may prevent new sign-ins without immediately terminating existing application sessions.
Test application session revocation and deprovisioning separately. SAML login alone does not provide complete account lifecycle management; provisioning tools such as SCIM or application APIs may also be required.
Frequently Asked Questions
Is SSO the Same as SAML?
No. SSO is the ability to access multiple applications through a shared authentication experience. SAML is one protocol that supports it.
Does the SP Receive the User’s Password?
In a standard federated SAML flow, the SP receives identity information in a SAML response, not the user’s IdP password.
Does SAML Attribute Mapping Create User Accounts?
Not by itself. An application may use mapped attributes for just-in-time provisioning if that feature is supported and enabled. Otherwise, accounts must exist through a separate process.
Does the IdP Decide Everything a User Can Access?
No. The IdP can restrict application assignment and supply attributes used in access decisions. The SP remains responsible for enforcing permissions within the application.
Can One Application Trust Multiple IdPs?
Yes, if the application supports multiple federation connections. Each connection needs appropriate trust settings and account-matching rules to prevent identities from being confused across organizations.
Make SSO Responsibilities Clear
The SSO IdP vs. SP distinction gives teams a practical way to divide ownership. Identity administrators manage authentication and outgoing claims. Application owners manage account matching, permissions, and local sessions.
Before an integration goes live, test failed logins, incorrect roles, certificate changes, and user removal. A successful sign-in is only the beginning of that validation.
Sennovate’s identity and access management services support federation, application onboarding, and ongoing identity operations.
Talk to a Sennovate identity expert about your SSO configuration and application-access controls.
Related Articles
Zero Trust Network Access Won’t Save You If Standing Privileges Are Still Open
Most zero trust rollouts start in the same place: network segmentation, device posture checks, a...
