Identity provider vs service provider: the two halves of every SSO login

Every single sign-on login has two sides. One side knows who the user is and vouches for them; the other side accepts that voucher and lets the user in. In SAML they are called the identity provider (IdP) and the service provider (SP). In OpenID Connect the same pair is called the OpenID provider (OP) and the relying party (RP).

The names change with the protocol; the job division does not.

The identity provider

The identity provider is where the account lives and where the user signs in. It:

• stores users, credentials and second factors,
• authenticates the user (password, passkey, MFA),
• issues a signed statement about the user: a SAML assertion, or an OIDC ID token,
• publishes metadata so other systems can trust it,
• can add claims: email, groups, roles, department.

Examples: Okta, Microsoft Entra ID, Google Workspace, Keycloak, Casdoor, Auth0. In a consumer app, "sign in with Google" means Google is acting as the identity provider.

The service provider

The service provider is the application the user wants to use. It:

• redirects the user to the identity provider instead of showing its own login form,
• receives and validates the signed assertion or token,
• maps claims to a local account,
• creates a session and sets its own cookie.

Examples: Salesforce, Slack, Grafana, GitLab, a company's internal admin console, almost any SaaS product with a "single sign-on" setting.

The flow, in SAML terms

1. The user opens the service provider.
2. No session exists, so the SP builds a SAML request and redirects the browser to the IdP.
3. The IdP authenticates the user.
4. The IdP posts a signed assertion back to the SP's assertion consumer service URL.
5. The SP verifies the signature and the conditions (audience, expiry, recipient), then starts a session.

In OIDC the sequence is the same with different nouns: the RP redirects to the OP's authorization endpoint, the OP returns an authorization code, the RP exchanges it for tokens over a back channel, and the ID token carries the user claims. See SAML vs OIDC for the protocol differences.

Where the trust comes from

The two sides do not trust each other by default. They exchange metadata:

• SAML: the IdP publishes an XML metadata file with its signing certificate and endpoints; the SP publishes its assertion consumer service URL and entity ID. Each side imports the other's metadata.
• OIDC: the OP publishes a discovery document at /.well-known/openid-configuration with its endpoints and keys; the RP is registered with the OP using a client ID and a redirect URI.

Most integration failures come from this step: an outdated certificate, a redirect URI that does not match exactly, or a clock skew that makes an assertion look expired.

One system can be both

The roles are per connection, not per product. The same identity provider can be a service provider in another relationship:

• A company runs Casdoor as its IdP for internal apps, and also configures Casdoor to accept "sign in with Google", which makes Casdoor the service provider to Google.
• A SaaS product is a service provider to its customers' Okta tenants, and an identity provider for the apps embedded inside it.

This chaining is normal. It is also where sessions get complicated: signing out of one link does not necessarily end the session at the next. See single logout.

Which side do you build?

• Building an application that should accept enterprise SSO: you are the service provider. Implement SAML and/or OIDC as a client, or use an identity provider that does it for you.
• Running the directory that employees and customers sign in to: you are the identity provider. You need user management, MFA, social and enterprise connectors, and metadata endpoints.

Casdoor is built for the second role: it is an open-source identity provider that speaks OIDC, SAML 2.0, CAS and SCIM, and it can also federate to upstream providers, which makes it a service provider in those connections. That combination is what lets one deployment serve employees, customers and internal tools.

Related reading: what single sign-on is, SAML vs OIDC and OAuth vs SAML.

Casdoor is open source and self-hostable, with a hosted option from $9 per month and no per-user fees.