IDSync — identity software buyer platform
Run Stack Finder

Architecture

Service Provider (SP)

A Service Provider (SP) is an application that delegates authentication to an Identity Provider and consumes signed identity assertions to grant access — 'Sign in with Okta' makes Salesforce the SP and Okta the IdP. In OIDC the equivalent term is Relying Party (RP).

Last reviewed 5/30/2026

Key points

  • SP is the SAML term; Relying Party (RP) is the OIDC term — same concept.
  • The SP trusts the IdP's signature, never sees the user's password (in pure SSO).
  • SPs are configured per-IdP via SAML metadata XML or OIDC dynamic/manual client registration.
  • Modern SaaS apps are usually SPs; on-prem apps often need an SP proxy (Cloudflare Access, F5, Okta Access Gateway).
  • Same app can be both an SP (toward your IdP) and an IdP (toward downstream services) — common in B2B SaaS.

What is a Service Provider?

A Service Provider (SP) — also called a Relying Party (RP) in OIDC — is any application that consumes authentication from an Identity Provider instead of running its own login. Salesforce, Slack, GitHub, Workday, and almost every modern SaaS app act as SPs when configured for SSO.

The SP's job is narrow but critical:

  1. Recognize that an unauthenticated user is trying to reach a protected resource.
  2. Redirect them to the configured IdP (via SAML AuthnRequest or OIDC authorization request).
  3. When the user returns with a signed Assertion (SAML) or ID token (OIDC), validate the signature, issuer, audience, expiry, and nonce.
  4. Establish a local session and map the IdP's claims to a local user / role.

SP vs IdP — who does what

| | IdP | SP | | --- | --- | --- | | Authenticates user | Yes | No | | Holds credentials | Yes | No | | Enforces MFA / conditional access | Yes | Optional | | Provisions user accounts | Issues identities | Often receives via SCIM | | Examples | Okta, Entra ID, Google, Auth0 | Salesforce, Slack, GitHub, Notion |

Configuration

For each IdP↔SP pair you typically configure:

  • SAML: exchange metadata XML (entity IDs, signing certs, ACS URL, SLO URL). Attribute mappings (which IdP claims become which SP attributes).
  • OIDC: register a client (client_id, client_secret or PKCE, redirect_uri, scopes). Configure JWKS endpoint and userinfo mapping.

When buyers care

  • SSO tax — many SaaS vendors gate SAML/OIDC behind an enterprise tier (sso.tax is a community-maintained shame list). Factor that into TCO.
  • Just-in-time (JIT) provisioning — does the SP auto-create users on first sign-in, or do you also need SCIM?
  • Deprovisioning — is the SP an SCIM target so you can offboard?
  • B2B SSO — does the SP support multiple IdPs per tenant (yes for products built on WorkOS, Auth0, Frontegg; often not for legacy SaaS)?

Editorial note

The number of SPs you operate is the real driver of identity cost. A 200-app SaaS estate that's all SCIM + SSO is cheaper to run than a 50-app estate that's half-manual.