Identity Provider (IdP) vs Service Provider (SP)

In this article we will separate the parties in federated login: the user, the identity provider (IdP), and the service provider (SP).

Once you know which system authenticates the user and which application relies on that result, SAML and OpenID Connect become much easier to follow. A product is not permanently an IdP or an SP. Its role depends on which connection you are looking at. For broader IAM vocabulary, see What is IAM?.

IdP vs SP at a Glance

Federated login has three participants:

• The IdP says: “I authenticated this user.”
• The SP says: “I trust this IdP’s result and will decide what this user can access in my application.”

Service Provider is mainly a SAML term. In OpenID Connect, the matching application role is a Relying Party (RP) or OIDC client. When this page talks about IdP and SP, it means the SAML-style relationship. Where OIDC uses different names, those names appear next to the SAML ones.

SAML:  IdP  →  SP
OIDC:  OP   →  RP / client

Authentication happens at the IdP (or OpenID Provider). After the application validates that result, it decides what the user may access. See Authentication vs authorization for that second question.

SP-initiated and IdP-initiated describe where the login starts. They do not redefine IdP and SP:

• SP-initiated: the user starts at the application, then goes to the IdP
• IdP-initiated: the user starts at the IdP portal, then lands in the application

What Is an Identity Provider?

An identity provider verifies the user’s credentials or other authenticators, then issues a digitally signed statement about that login.

What an IdP does:

• Present a login or MFA challenge (or run a passwordless / delegated authenticator)
• Check passwords, passkeys, certificates, or external authenticators
• Issue a SAML assertion or, for OIDC, an ID token (and often an access token)
• Sign that message so the application can verify it came from a trusted IdP

Common IdP examples:

• Keycloak for your organization’s apps
• Microsoft Entra ID, Okta, Google Workspace, or ADFS
• A corporate directory fronted by a SAML or OIDC gateway

When applications send users to Keycloak to sign in, Keycloak is acting as the IdP.

What Is a Service Provider?

A service provider is the application that trusts an IdP’s authentication result, then grants or denies access to its own screens and APIs.

What an SP does:

• Redirect unauthenticated users to the IdP
• Validate the signed assertion (SAML) or complete the OIDC client flow and validate tokens
• Create or update a local session for the application
• Enforce its own authorization (roles, entitlements, feature flags)

From the user’s point of view, the SP is the application: HR portal, wiki, or customer dashboard. It is not an internet service provider (ISP).

The SP may still keep a local user record, map attributes into its database, or create a first-login account. That does not make it the IdP. The IdP authenticated the person; the application decides how to treat that login inside its product.

In OIDC, the application plays the same general role but is called a relying party or OIDC client. It relies on the OpenID Provider to authenticate the user.

How IdP and SP Work Together

A common browser SSO flow starts at the application. In SAML this is called SP-initiated SSO; in OIDC the application is the relying party (RP), so you may also see it described as RP-initiated login. The overall idea is similar, but SAML and OIDC return the authentication result differently.

  User              Application (SP / RP)             IdP / OP
   │                         │                            │
   │ 1. Open app             │                            │
   ├────────────────────────►│                            │
   │                         │ 2. Redirect to login       │
   │                         ├───────────────────────────►│
   │                         │                            │
   │              3. User authenticates                   │
   │                         │                            │
   │                         │ 4. Browser returns         │
   │                         │    protocol response       │
   │                         │◄───────────────────────────│
   │                         │                            │
   │                         │ 5. Verify response /       │
   │                         │    exchange code           │
   │                         │                            │
   │ 6. App session/access   │                            │
   │◄────────────────────────┤                            │

What happens in this flow:

• The user opens a protected page in the application.
• The application redirects the browser to the IdP/OP.
• The user authenticates there using a password, MFA, passkey, or another method.
• After authentication, the browser returns to the application. In SAML, this normally carries a SAML Response. In OIDC Authorization Code flow, it carries an authorization code.
• The application verifies the protocol response. A SAML SP validates the SAML assertion. An OIDC client exchanges the authorization code at the token endpoint and validates the ID token.
• The application then creates its session or grants access according to its own authorization rules.

How step 4 and 5 differ by protocol:

• SAML: The IdP sends a SAML Response containing an authentication assertion to the SP, usually through the browser. The SP verifies its signature and other conditions before trusting it.
• OIDC Authorization Code: The OpenID Provider redirects the browser back with an authorization code. The client exchanges that code at the token endpoint for an ID token and access token. For server-side clients this exchange normally happens directly between the application and the token endpoint; public clients such as SPAs typically use PKCE.

The IdP/OP authenticates the user. The application still verifies the returned assertion or tokens before creating a session or granting access.

How IdP and SP Establish Trust

Before SSO works, both sides need matching configuration: the application must trust the IdP, and the IdP must know which application and return URLs are allowed. Without that, signatures fail and redirects are rejected.

SAML metadata is an XML document that publishes identifiers, endpoints, and signing certificates. JWKS is the published set of public keys an OIDC client uses to verify tokens signed by the provider.

  ┌────────────────────┐      metadata / keys / URLs      ┌────────────────────┐
  │ IdP / OP           │ ◄──────────────────────────────► │ Application        │
  │ (authenticates)    │                                  │ (SP / RP)          │
  └────────────────────┘                                  └────────────────────┘

What that diagram shows:

• The IdP / OP is the side that authenticates the user.
• The application (SP / RP) is the side that consumes the login result.
• Before the first successful login, both sides exchange (or configure) matching metadata, keys, and return URLs.
• Until those settings match, federated login will not complete even if the user password is correct.

SP-Initiated vs IdP-Initiated SSO

The IdP and SP roles stay the same. Only the starting point changes.

SAML environments use IdP-initiated flows more often than modern OIDC apps. Modern OIDC applications commonly use an RP-initiated Authorization Code flow rather than an IdP-initiated pattern. IdP-initiated SSO changes only where the login starts; it does not change which system is the IdP or SP.

SAML IdP/SP vs OIDC OP/RP

SAML and OpenID Connect describe the same split with different words.

The ID token carries authentication information for the client. The access token is for calling protected resources and APIs. They are not the same kind of proof.

In SAML, that authentication-side role is called the IdP. In OIDC, it is called the OpenID Provider. Keycloak can act as IdP/OP for your apps (What is Keycloak?) and as a broker toward an upstream provider.

Where Keycloak Fits

Keycloak’s role depends on which connection you are looking at. The same login journey can put Keycloak in a different role on each side.

Keycloak as IdP / OpenID Provider

• Your web application or OIDC client relies on Keycloak for authentication.
• Users authenticate at Keycloak.
• Keycloak issues tokens or SAML assertions to that app.
• An API may separately act as a resource server that validates Keycloak-issued access tokens. That is not the same as being the OIDC client that starts the user login.

Keycloak as a broker toward an upstream provider

• Users click “Sign in with Entra ID / Okta / Google” (or another external provider).
• Keycloak redirects to that upstream provider and validates the external response.
• Keycloak then issues its own tokens to your application.

With an upstream SAML IdP, Keycloak plays the SP role. With an upstream OIDC provider, Keycloak plays the RP/client role.

  ┌──────────────┐     OIDC/SAML      ┌──────────────┐     OIDC/SAML      ┌─────────────────┐
  │ Application  │ ◄────────────────► │   Keycloak   │ ◄────────────────► │ Upstream IdP    │
  │ (SP / RP)    │   Keycloak = IdP   │ broker + IdP │  Keycloak = SP/RP  │ Entra / Okta /… │
  └──────────────┘                    └──────────────┘                    └─────────────────┘

What that two-hop diagram shows:

• Left hop: your application trusts Keycloak. Toward the app, Keycloak is the IdP / OP.
• Right hop: Keycloak trusts an upstream provider such as Entra ID or Okta. Toward that provider, Keycloak is the SP (SAML) or RP/client (OIDC).
• The user may authenticate at the upstream IdP, then Keycloak issues its own tokens or assertions to your application.
• Keycloak can have both roles, but on different sides of the same login journey. When troubleshooting, identify which hop you are looking at first.

IdP vs SP Examples

When you get stuck, ask:

• Which system actually authenticates the user (password, passkey, MFA, or another method)? That side is the IdP for this hop.
• Which application receives the login result and uses it to let the user in? That side is the SP/RP.
• Are you looking at an upstream broker hop or the hop into the app? The labels can flip between hops.

Summary

An identity provider authenticates the user and sends a signed authentication result to the application. A SAML service provider or OIDC relying party trusts that result and decides what the user may access. IdP and SP describe the roles two systems play in one SSO relationship. The same product can play a different role in another connection.

SP-initiated and IdP-initiated only describe where the browser journey starts. SAML’s IdP/SP pair maps to OIDC’s OpenID Provider and relying party. SAML usually returns a signed Response; OIDC Authorization Code returns a code that the client exchanges for tokens. In OIDC, the ID token is the authentication result for the client; the access token is for calling APIs.

When you point apps at Keycloak, Keycloak is usually the IdP. With identity brokering, Keycloak also acts as SP or RP toward an upstream provider while remaining the IdP your apps trust. When troubleshooting, first identify which connection you are looking at: application ↔ Keycloak, or Keycloak ↔ upstream provider.

References

• Keycloak Server Administration Guide — Identity brokering
• Keycloak Server Administration Guide — SSO protocols
• OASIS SAML 2.0 Technical Overview
• OpenID Connect Core 1.0