Service Provider (SP)

What is a Service Provider?

In federated identity and Single Sign-On (SSO), the Service Provider (SP) is the application or service the user is trying to use — the thing that needs to know who the user is but delegates authentication to a trusted third party. When you log into a SaaS app “with your company account,” that SaaS app is the Service Provider: it doesn’t check your password itself, it trusts an external Identity Provider (IdP) to authenticate you and vouch for your identity. The SP and IdP are the two roles at the heart of every SAML-based SSO flow.

SP and IdP — the two-role model

Federated login is fundamentally a trust relationship between two parties. The Identity Provider (IdP) authenticates users and asserts identities — Okta, Azure AD/Entra ID, Google, a corporate directory. The Service Provider (SP) is the relying application that consumes those assertions and grants access. In SAML terminology these exact terms are used; the rough equivalents in OpenID Connect/OAuth are “Relying Party” (the SP’s counterpart) and “OpenID Provider” (the IdP’s). The canonical flow: a user hits the SP, the SP redirects them to the IdP, the IdP authenticates them and returns a signed assertion (a SAML assertion or an OIDC token) vouching for their identity, and the SP validates that assertion’s signature and grants access. The SP never sees the user’s actual credentials — that’s the entire security benefit: passwords live in one place (the IdP), not scattered across every app.

Why the SP’s job is mostly about trust and validation

The SP’s security responsibilities center on validating what the IdP sends. It must verify the assertion’s cryptographic signature (using the IdP’s public key/certificate) to be sure the assertion genuinely came from the trusted IdP and wasn’t forged or tampered with — a SP that fails to validate signatures properly is the classic SAML vulnerability, letting attackers forge identities. It must check the assertion hasn’t expired and is intended for it (audience restriction), to block replay and misdirected-assertion attacks. Setting up an SP means exchanging metadata with the IdP: endpoints, certificates, and the agreed format of the identity assertion. For users and organizations, the SP/IdP model is what makes SSO possible — one login, many apps, credentials centralized where they can be secured, monitored, and revoked.

What people get wrong

• Weak assertion validation — an SP that doesn’t rigorously verify the IdP’s signature (and audience/expiry) can be tricked with forged assertions.
• Confusing the roles: the SP is the app being accessed; the IdP is what authenticates — mixing them up muddles every SSO configuration.
• Assuming the SP handles passwords — it deliberately doesn’t; credentials stay at the IdP, which is the point of federation.

Primary source: OASIS SAML technical overview