IdP vs SP: The Difference, and How Keycloak Plays Both Roles

Last updated: July 2026

An identity provider (IdP) authenticates users and produces signed statements, called assertions, about who they are. A service provider (SP) is the application that consumes those statements instead of checking passwords itself. Keycloak plays both roles at the same time: it acts as the IdP for your applications while acting as an SP toward external IdPs through identity brokering.

What does an identity provider actually do?

In SAML’s vocabulary, the IdP is the asserting party. It’s the system that actually checks credentials, then produces an assertion: a signed statement saying “this person authenticated with me, and here’s what I know about them” (SAML 2.0 Technical Overview, OASIS).

An assertion is more than a yes or a no. Per the same OASIS overview, it can carry three kinds of statements:

• Authentication statements: this user authenticated, at this time, by this method.
• Attribute statements: facts about the user, like email, name, or group memberships.
• Authorization decision statements: whether the subject is permitted to access a given resource.

Wrapped around those statements are a subject (who this is about), conditions (constraints like validity windows and intended audience), and the issuer (who is making the claim). The signature over all of it is what makes the assertion worth anything.

Everyday IdPs you’ve met: Okta, Microsoft Entra, Google Workspace. And Keycloak, whenever your apps send users to it for login.

Concretely: an employee opens your expense tool. The tool bounces them to Entra, Entra checks the password and the MFA prompt, then sends back a signed assertion. The expense tool verifies the signature and starts a session. That’s the whole division of labor, visible in a single login.

What does a service provider do?

The SP is the relying party: the application or service that consumes assertions and grants access based on them. The SAML spec is blunt about the foundation here. The relying party’s reliance “depends on the existence of a trust relationship with the asserting party” (SAML 2.0 Technical Overview, OASIS). No trust relationship, no login.

That trust isn’t a handshake and good vibes. It’s established through metadata: a document describing each party’s entity ID, its role (IdP or SP), the bindings it supports, its endpoint URLs, and the signing and encryption keys to use. When a partner asks you to “exchange metadata,” this is the file they mean. If you’re staring at one and want to see what’s actually inside, paste it, or a full SAML response, into our SAML decoder.

The SP’s runtime job is deliberately small: redirect unauthenticated users to the IdP, validate whatever comes back (signature, conditions, audience), and start a session. It never sees the user’s password. That is the entire point of the arrangement.

Why the roles are split

Because credentials are a liability, and the split concentrates them in one place. When every app authenticates users itself, every app stores passwords, implements MFA, and handles offboarding on its own schedule. Centralize authentication in an IdP and the picture flips: passwords live in exactly one system, MFA policy is enforced once, and disabling one account cuts access to every connected SP at the next login.

The apps get simpler too. An SP that only validates assertions has a much smaller security surface than one running its own credential store. The trade-off is a single point of dependence: if the IdP is down, nobody logs in anywhere. That’s the deal you’re signing, and it’s usually a good one.

How do the SAML roles map to OIDC?

OpenID Connect keeps the exact same division of labor and renames all of it. The IdP becomes the OpenID Provider (OP): an OAuth 2.0 authorization server that authenticates the end user and provides claims about them. The SP becomes the Relying Party (RP). The assertion’s equivalent is the ID Token, a signed JWT (OpenID Connect Core 1.0).

Once this table clicks, vendor documentation gets a lot less confusing. “Configure your RP” and “set up the SP integration” are the same request in two dialects. And if you’re debugging on the OIDC side, our JWT token analyzer decodes ID tokens the way the SAML decoder handles assertions.

What’s the difference between SP-initiated and IdP-initiated SSO?

The OASIS technical overview describes two ways a login can start, and the names just tell you where the user began.

SP-initiated: the user goes straight to the application. The SP sees there’s no session, redirects the browser to the IdP, the user authenticates there, and returns to the SP carrying the assertion. This is what happens when someone bookmarks your app and shows up cold.

IdP-initiated: the user starts at the IdP’s own portal, the classic dashboard full of app tiles, clicks through to an application, and the IdP pushes the response to the SP without the SP asking first.

Same trust relationship, same assertion, different starting line. The practical consequence for SP builders: if you support IdP-initiated at all, your app has to accept assertions that arrive unrequested, not just ones it asked for. Plenty of federation bugs live in that gap.

Keycloak as both roles at once

This is where Keycloak earns its keep, and also where the mental model tends to slip. Out of the box, Keycloak is an IdP: your applications register as clients and send users to it for login. Turn on identity brokering and Keycloak simultaneously becomes an SP toward an external IdP, say a customer’s Entra tenant or a partner’s Okta (Keycloak Server Administration Guide).

Why you’d want this: every enterprise customer shows up with their own IdP and expects SSO against it. Without a broker, each one is a new integration in your app code. With Keycloak in the middle, sales can promise “yes, we support your Entra, your Okta, your Google Workspace” and engineering changes nothing, because the app still talks only to Keycloak.

The full chained flow, step by step:

1. The user opens your application.
2. The app redirects them to Keycloak for login. As far as the app is concerned, Keycloak is the one and only IdP.
3. Keycloak redirects the user onward to the configured external IdP. On this leg, Keycloak is the SP.
4. The user authenticates at the external IdP, with whatever that IdP requires.
5. The external IdP redirects the user back to Keycloak with its response.
6. Keycloak validates the response, then runs its First Login Flow: create a new local user from the incoming identity, or link it to an existing account.
7. Keycloak issues its own token to the application, and the user is in.

The detail that matters most: your app never sees the external IdP’s assertion. It only ever receives Keycloak’s token, in the one format it already understands. Ten external IdPs, one integration. The local user Keycloak creates in step 6 is a shadow of the upstream identity, and that shadow has real trade-offs we unpacked in shadow accounts and the broker pattern.

The metadata exchange runs both directions too. You import the external IdP’s metadata into Keycloak’s broker configuration, and you export Keycloak’s own SP descriptor for the partner to load on their side. We have a hands-on walkthrough of that setup in configuring SAML as an SP in Keycloak. And if you’d rather not babysit certificate rotations and metadata swaps yourself, that’s part of what Skycloak’s identity provider brokering handles for you.

Figuring out which role you are configuring

Half of all federation confusion is just “wait, which side am I on.” Quick orientation check:

• A partner asks for your metadata, your ACS URL, or your redirect URI: you’re the SP. They authenticate, you consume.
• You’re serving the login page and issuing tokens or assertions: you’re the IdP.
• In the Keycloak admin console: the Clients section is Keycloak wearing its IdP hat (apps that rely on it), and the Identity providers section is Keycloak wearing its SP hat (upstream IdPs it relies on).

Both directions can be live in the same realm at the same time. That’s not a misconfiguration. That’s the broker pattern doing exactly what it’s for.

Frequently asked questions

Is Keycloak an IdP or an SP?

Both, usually at the same time. Keycloak is the identity provider for the applications registered as its clients, and it becomes a service provider toward external IdPs when you configure identity brokering (Keycloak Server Administration Guide). The two roles run side by side in a single realm.

What is the difference between SP-initiated and IdP-initiated SSO?

In SP-initiated SSO, the user starts at the application, is redirected to the IdP to authenticate, and returns with an assertion. In IdP-initiated SSO, the user starts at the IdP’s portal and the IdP pushes the response to the SP directly (SAML 2.0 Technical Overview). The trust setup is identical; only the starting point changes.

What does a SAML assertion contain?

A SAML assertion can carry authentication statements, attribute statements, and authorization decision statements, wrapped with a subject, conditions such as validity window and audience, and the issuer’s identity. The IdP signs the assertion so the SP can verify nothing was tampered with in transit.

What is the OIDC equivalent of an IdP and SP?

In OpenID Connect, the IdP is the OpenID Provider (OP): an OAuth 2.0 authorization server that authenticates the user and provides claims. The SP is the Relying Party (RP), and the assertion’s counterpart is the ID Token, a signed JWT (OpenID Connect Core 1.0).

Can one system be both an identity provider and a service provider?

Yes. Any system that issues its own tokens to downstream applications while consuming another provider’s assertions upstream is doing both jobs at once. Keycloak’s identity brokering is the textbook case: SP toward the external IdP, IdP toward everything that sits behind it.