Service Provider (SP)
An application that relies on an Identity Provider (IdP) for user authentication via SAML assertions or OIDC tokens.
What is Service Provider (SP)?
Service Provider (SP) is an application or service that consumes identity information from an Identity Provider (IdP) to authenticate users and provide services.
The SP:
- Receives assertions/tokens: Accepts SAML assertions or OIDC ID tokens from IdP
- Validates the assertion/token: Verifies signature, expiration, issuer
- Creates a local session: Logs the user in after successful validation
- Provides services: Grants access to application features based on user identity/attributes
Common SPs include Salesforce, Slack, Workday, Concur, and custom web/mobile applications. The SP trusts the IdP to authenticate users and relies on the identity information provided.
Analogy
Think of a Service Provider like a nightclub that trusts the government's passport (issued by IdP). The club (SP) doesn't check your identity itself - it trusts the passport office (IdP) and just verifies the passport is valid and lets you in.
Types and Use Cases
- SaaS Applications: Salesforce, Slack, Workday use Okta/Azure AD as IdP for employee SSO
- Custom Applications: Your web/mobile app uses LoginRadius as IdP for customer authentication
- Partner Portals: Vendor portals allow partners to log in with their corporate IdP (B2B federation)
- Cloud Services: AWS, GCP, Azure use corporate IdP for employee access
How it Works
<!-- SAML SP: Receiving Assertion from IdP -->
<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<saml:Assertion>
<saml:Issuer>https://idp.example.com</saml:Issuer>
<saml:Subject>
<saml:NameID>user@company.com</saml:NameID>
</saml:Subject>
<saml:AttributeStatement>
<saml:Attribute Name="email">user@company.com</saml:Attribute>
<saml:Attribute Name="role">Manager</saml:Attribute>
</saml:AttributeStatement>
</saml:Assertion>
</samlp:Response>
// OIDC SP: Validating ID Token
function validateIdToken(idToken, idpPublicKey) {
const decoded = jwt.verify(idToken, idpPublicKey);
if (decoded.iss !== 'https://idp.example.com') throw new Error('Invalid issuer');
if (decoded.aud !== 'my-client-id') throw new Error('Invalid audience');
if (decoded.exp < Date.now() / 1000) throw new Error('Token expired');
return decoded; // User info: { sub, email, name }
}Service Provider (SP) vs Identity Provider (IdP)
Service Provider (SP)
Identity Provider (IdP)
SP consumes tokens and provides services
IdP authenticates users and issues tokens/assertions
SP trusts the IdP for authentication
IdP is the source of truth for user identity
In SAML: SP receives assertion FROM IdP
In OIDC: SP receives ID token FROM IdP
Best Practices for Service Provider (SP)
- Validate everything: Always validate signature, issuer, audience, and expiration of assertions/tokens
- Use HTTPS only: SAML assertions and OIDC tokens must travel over secure connections
- Map user attributes: Properly map IdP attributes (email, name, roles) to your application's user model
How LoginRadius Powers Service Provider (SP)
LoginRadius CIAM platform provides comprehensive Service Provider capabilities. As an SP, LoginRadius can connect to your corporate IdP (Okta, Azure AD, Ping) via SAML 2.0 or OpenID Connect for employee SSO. We handle the complete SP flow: receiving and validating SAML assertions or OIDC ID tokens, mapping user attributes, and creating local sessions. LoginRadius also provides SP metadata endpoints, certificate management, and detailed SSO logs for troubleshooting.
Resources
FAQs
Yes. Many organizations act as both: (1) As SP: They use Okta/Azure AD as their IdP for employee SSO, (2) As IdP: They act as IdP for their customers (CIAM) to access their applications. LoginRadius can act as IdP for your customers while also connecting to your corporate IdP (Okta/Azure AD) for employee access.
SP-initiated: User tries to access SP (Salesforce), gets redirected to IdP for login, then back to SP. IdP-initiated: User logs into IdP portal (Okta), then clicks on Salesforce icon to access it. SP-initiated is more secure (prevents SSRF attacks) and is the recommended flow for most scenarios.
LoginRadius acts as a Service Provider when connecting to corporate IdPs (Okta, Azure AD) via SAML/OIDC for employee SSO. In this scenario, LoginRadius consumes SAML assertions or OIDC tokens from the corporate IdP to authenticate employees. LoginRadius also provides SP integration guides for popular SaaS applications and custom application integration SDKs.