Request a trial
Menu
Products
Solutions
ERP
Authentication
Apps
LearnDocsWhy SSOGENRequest a trial

SSOGEN / Learn / IdP vs SP: The Two Sides of Federated Sign-In

Learn

IdP vs SP: The Two Sides of Federated Sign-In

The identity provider proves who a person is and signs a statement; the service provider is the application that checks that statement and decides what to allow.

Updated

Request More Info
IdP vs SP comparison: the identity provider vouches for a person and the service provider application relies on it
Same product can play both parts.

IdP vs SP comes down to who vouches and who relies. The identity provider (IdP) authenticates a person and sends a signed statement about them. The service provider (SP) is the application the person wants to use. It checks that statement and decides what to allow.

SAML uses exactly these two names. OpenID Connect and OAuth use other terms for the same two roles, which causes most of the confusion.

This page covers three things:

  • Vocabulary. The same two roles under each protocol’s names.
  • Holdings. What each side holds.
  • Worked example. Adding one application to an IdP, with the settings split by side.

The same two roles under different names

The terms change with the protocol; the two roles stay the same.

Seat SAML 2.0 OpenID Connect OAuth 2.0
Vouches for the person Identity provider (IdP), an asserting party OpenID Provider (OP) Authorization server
Relies on the answer Service provider (SP), a relying party Relying party (RP) Client (and the resource server that accepts its tokens)
What travels Assertion (XML, signed) ID token (JWT) Access token
Where the person lands afterwards Assertion consumer service (ACS) URL Redirect URI Redirect URI
Name of the app in the other side’s records SP entity ID Client ID Client ID

Each protocol’s own text defines its terms:

  • The OASIS SAML glossary describes a service provider as “a role donned by a system entity where the system entity provides services to principals or other system entities”, and an identity provider as “a kind of service provider” that manages identity information and provides authentication to other service providers.
  • OpenID Connect Core defines the OP as an OAuth 2.0 authorization server that can authenticate the end user and provide claims to a relying party, and the RP as an OAuth 2.0 client application that needs that authentication.
  • RFC 6749, section 1.1 defines the authorization server as the server issuing access tokens to the client after authenticating the resource owner, and the resource server as the one hosting protected resources and accepting access tokens.

The SAML glossary wording has a consequence: an IdP is not the opposite of an SP but a specialized SP. The pair names the two roles in one sign-in, not two kinds of product.

For protocol-level differences, see SAML vs OIDC. For OAuth against OIDC, see OIDC vs OAuth.

What each side holds

Identity provider side Service provider side
Identifier IdP entity ID (OIDC: issuer) SP entity ID (OIDC: client ID)
Endpoint it exposes Single sign-on URL (OIDC: authorization and token endpoints) ACS URL (OIDC: redirect URI)
Keys Private signing key; publishes the public certificate (OIDC: jwks_uri) Trusts the IdP’s public certificate; may hold its own key to sign requests
Metadata IdP metadata (OIDC: discovery document) SP metadata
Knows Who the person is, their groups and attributes Which of its own accounts that person maps to, and what they may do
Trusts the other side for Nothing about the person; it is the source The identity, attributes and authentication strength it asserts
Other side trusts it for Telling the truth about the person Keeping the assertion private and sending nothing to the wrong place

Sources for the table:

  • SAML metadata lets an entity describe its roles, endpoints and keys. Each entityID must be unique across a deployment (SAML V2.0 Metadata, section 2.2.1 and 2.3.2).
  • An SP can state WantAssertionsSigned and AuthnRequestsSigned in its metadata; an IdP can state WantAuthnRequestsSigned.
  • In OIDC, an OP publishes a JSON document at the issuer address plus /.well-known/openid-configuration with issuer, authorization_endpoint, token_endpoint and jwks_uri. The jwks_uri holds the signing keys the RP uses (OpenID Connect Discovery 1.0).
  • The OIDC redirect_uri must exactly match a value pre-registered at the OP.

Each value is owned by one side and entered by the other. If an exact-match value such as the ACS URL or entity ID differs, the sign-in is refused.

ACS URL, entity ID and audience covers which one belongs where. The free SAML metadata checker shows what a metadata file declares, including whether it describes an IdP, an SP or both.

One product can be both

Because an IdP is a specialized SP, the same system often takes both roles. A broker, or any IdP that accepts upstream sign-in, is an SP toward the upstream identity system and an IdP toward the applications behind it.

  • Sign-in. The person signs in once at the upstream system.
  • Conversion. The broker converts that sign-in into its own assertion or token for each application.
  • Separate values. Each direction has its own entity ID, keys and endpoints.
  • Several roles. One SAML metadata entity may act in several roles (SAML V2.0 Metadata, section 2.3.2).

See identity broker for the pattern.

A worked example: adding Acme Expenses

Acme’s directory sign-in runs on an IdP at https://sso.acme.example. IT adds a SaaS app, Acme Expenses, at https://expenses.acme.example. Each side supplies its own values:

Step Acme Expenses (SP) IdP at sso.acme.example
1. SP shows its values Entity ID https://expenses.acme.example/saml/metadata, ACS URL https://expenses.acme.example/saml/acs, optionally an SP metadata file
2. IT registers the SP at the IdP Enters the entity ID and ACS URL (or uploads the SP metadata); picks what the assertion carries, such as email
3. IdP shows its values Entity ID, single sign-on URL, signing certificate (or an IdP metadata file)
4. IT gives those to the SP Enters the IdP entity ID, SSO URL and certificate (or uploads the metadata); turns SAML on
5. Test Starts at the app (SP-initiated) or at the IdP’s app list (IdP-initiated) Signs the assertion for that ACS URL only

SSOGEN takes either side of this exchange:

  • SSOGEN as the IdP. The Register SAML app wizard asks for the application’s service provider entity ID and its ACS URL and matches both exactly. It posts assertions only to that registered URL, and it can read both values from an uploaded SP metadata file (Register a SAML application).
  • SSOGEN as the SP toward another IdP. When you add a SAML provider, SSOGEN shows an SP entity ID, an ACS URL and an SP metadata URL to give to that IdP (Add a SAML identity provider). An OpenID Connect provider gets a redirect URI instead (Add an OpenID Connect identity provider).

For a person who signs in through Entra ID and then opens an application, SSOGEN holds both roles at once. To see which side starts the flow, see SP-initiated vs IdP-initiated SSO.

What is a service provider in SAML?

A service provider in SAML is the application that receives and trusts a signed assertion from an identity provider, then logs the person in to its own session.

It holds three things:

  • Entity ID. Its name in the IdP’s records.
  • ACS URL. The address where assertions arrive.
  • IdP certificate. A copy of the IdP’s public certificate to check signatures.

Typical examples are an expense tool, a wiki or a ticketing system. The term is unrelated to internet or telephone service providers.

Common confusions

  • Service provider as an ISP or telecom company. In SAML it means any application. A telecom carrier would be an SP only if it ran a login-protected app.
  • “SP” as session provider. SP stands for service provider. SAML does have a separate role for keeping session state, the session authority, which the glossary says identity providers often fill. It is distinct from the SP role.
  • IdP as the thing that holds the app. The IdP never hosts the app. The app keeps its own session after it accepts the assertion.
  • SP-initiated vs IdP-initiated. This describes which side starts one sign-in, not which role a product has.
  • Resource server equals SP. In OAuth the resource server accepts access tokens, while the client or RP is the party that signs a person in. One application can be both.

Questions people ask

What's the difference between SSO and federation?
SSO means one sign-in gives access to several applications. Federation is the trust arrangement between separate parties, such as an IdP and an SP, that makes SSO work across organizations. SSO can exist inside one company without federation. Federation is how a partner’s sign-in reaches your application. See federated identity.
What is an IdP server?
An IdP server is the system that authenticates people and issues the signed assertion or token an application trusts. It holds the signing key, the sign-in page and the list of registered applications. Examples are directory-backed sign-in services such as Entra ID, Keycloak and Okta. For the full picture, see what is an identity provider.
What is the difference between SP initiated and IdP initiated?
In SP-initiated sign-in the person starts at the application, which sends an authentication request to the IdP. In IdP-initiated sign-in the person starts at the IdP’s app list, and the IdP sends an unsolicited assertion to the application. The roles stay the same; only the starting point differs. Details are in SP-initiated vs IdP-initiated SSO.
What's the difference between IdP and IAM?
An IdP does one job: it authenticates people and vouches for them to applications. IAM, identity and access management, is the wider discipline: accounts, groups, provisioning, policies and access reviews. An IAM product usually includes an IdP, and the IdP is the part applications talk to at sign-in. IAM also decides who gets access at all.

Where to go next

Sources, all read 2026-10-11: OASIS SAML V2.0 Glossary; OASIS SAML V2.0 Metadata; OASIS SAML V2.0 Technical Overview; OpenID Connect Core 1.0; OpenID Connect Discovery 1.0; RFC 6749.