IdP vs SP: Identity Provider and Service Provider Explained

IdP vs SP: Identity Provider and Service Provider Explained. IdP vs SP explained: the identity provider checks credentials and signs an assertion, the service provider trusts it. Where each role lives in Keycloak.

An identity provider (IdP) checks the user’s credentials and issues a signed statement about who they are: a SAML assertion or an OpenID Connect ID token. A service provider (SP) is the application that trusts that statement and starts a session instead of checking a password itself. Keycloak plays both roles at once: it is the IdP for the applications registered under Clients, and it becomes an SP toward the upstream providers you add under Identity providers, which Keycloak calls identity brokering.

If you met the two terms this week in a vendor’s SSO guide or on a customer’s security questionnaire, this post tells you which side you are configuring. It explains what each role does, how the SAML names map to the OIDC names, where the roles live in the Keycloak admin console, and how to run both in one realm. It also answers the “SSO IdP vs SP” question about who starts the login, briefly, and hands you to the post that covers it in depth.

Key Takeaways

• The IdP is the party that “creates an assertion for the subscriber and transmits the assertion to the RP” (NIST SP 800-63-4); the SP is the party that relies on it.
• OIDC keeps the same split under new names: OpenID Provider for the IdP, Relying Party for the SP, ID token for the assertion (OpenID Connect Core 1.0).
• If a partner asks for your metadata, ACS URL or redirect URI, you are the SP. If you serve the login page, you are the IdP.
• In Keycloak, Clients is the IdP side and Identity providers is the SP side, and both run in the same realm.

What does an identity provider do?

The identity provider is the system that actually verifies the user and vouches for them. In the OASIS technical overview of SAML 2.0 the IdP is the “asserting party”, the entity that produces assertions, and an assertion is a signed statement that this person authenticated with the IdP, when, how, and what the IdP knows about them (SAML 2.0 Technical Overview, section 3.1). NIST’s glossary says the same thing in one line: the IdP is “the party in a federation transaction that creates an assertion for the subscriber and transmits the assertion to the RP” (NIST SP 800-63-4).

An assertion carries more than a yes or a no. The same OASIS overview lists three kinds of statements it can hold: authentication statements (this user authenticated, at this time, by this method), attribute statements (facts such as email, name or group memberships) and authorization decision statements (whether the subject may access a given resource) (SAML 2.0 Technical Overview, section 4.3). Around them sit the subject, the conditions (a validity window and the intended audience) and the issuer, and the IdP’s signature over all of it is what makes the assertion worth anything.

Everyday IdPs are Okta, Microsoft Entra ID and Google Workspace, and Keycloak whenever your applications send users to it for login. The Keycloak admin guide puts it plainly in its glossary: “An identity provider (IDP) is a service that can authenticate a user. Keycloak is an IDP” (Keycloak Server Administration Guide, Core concepts and terms).

What does a service provider do?

The service provider is the application the user wanted in the first place. In SAML’s words it is the “relying party”: it uses the assertions it receives to decide whether to let the user in, and its “willingness to rely on information from an asserting party depends on the existence of a trust relationship with the asserting party” (SAML 2.0 Technical Overview, section 3.1). Without that trust relationship, the SP will not accept the login.

That trust is set up through metadata, which the overview describes as “a way to express and share configuration information between SAML parties”: each party’s entity ID, the roles it plays, the bindings and endpoint URLs it supports, and the keys it signs and encrypts with (SAML 2.0 Technical Overview, section 4.1). When a partner asks you to “exchange metadata”, this is the document they mean. To see what an IdP actually sends at login, paste a SAML response into our SAML decoder, which decodes Base64 or deflate-encoded SAML requests, responses and assertions in your browser.

The SP’s job at runtime is deliberately small. It redirects a user who has no session to the IdP, validates what comes back (the signature, the conditions and the audience), and starts a session. It never sees the user’s password, and that is the point of the whole arrangement.

How does a login pass between the two?

The clearest way to see the split is to follow one login. An employee opens your expense tool, the tool notices there is no session and redirects the browser to the company’s IdP, the IdP checks the password and the second factor, and then sends back a signed assertion. The tool verifies the signature and the audience, starts a session, and the user is in. The IdP did all of the credential work, and the SP did all of the trusting.

The user opens the application (1), which has no session and redirects to the identity provider (2). The user signs in there (3), the IdP returns a signed assertion or ID token (4), and the application verifies the signature and audience and starts a session (5). The password never reaches the application.

Why are the roles split at all?

Because credentials are a liability, and the split keeps them in one place. When every application authenticates users itself, every application stores passwords, implements MFA and handles offboarding on its own schedule. Centralise 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 applications 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, because if the IdP is down nobody logs in anywhere, and that is usually a trade worth making.

How do the SAML roles map to OIDC?

OpenID Connect keeps exactly the same division of labour and renames all of it. The IdP becomes the OpenID Provider (OP), which the specification defines as an “OAuth 2.0 Authorization Server that is capable of Authenticating the End-User and providing Claims to a Relying Party about the Authentication event and the End-User”. The SP becomes the Relying Party (RP), an “OAuth 2.0 Client application requiring End-User Authentication and Claims from an OpenID Provider” (OpenID Connect Core 1.0, section 1.2). The assertion’s counterpart is the ID token, which the specification represents as a JSON Web Token (JWT) and requires to be signed (OpenID Connect Core 1.0, section 2).

Once this table clicks, vendor documentation gets a lot less confusing, because “configure your RP” and “set up the SP integration” are the same request in two dialects. If you are debugging on the OIDC side, our JWT token analyzer decodes a JWT such as an ID token and shows its claims.

SSO IdP vs SP: who starts the login?

People also search “IdP vs SP” when they mean the two SSO flows, so here is the short answer. In SP-initiated SSO the user starts at the application, which redirects them to the IdP and gets an assertion back that answers its own request. In IdP-initiated SSO the user starts at the IdP’s portal of app tiles, and the IdP pushes an assertion to the SP that the SP never asked for: in the OASIS overview’s IdP-initiated example, no authentication request from the SP to the IdP is involved (SAML 2.0 Technical Overview, section 5.1.4). SP-initiated is the safer default because the application can match the response to a request it made, and IdP-initiated needs extra checks on the SP side because nothing ties the assertion to a user action. The trade-offs, the checks, and what to tell a customer who wants a portal tile are in IdP-initiated vs SP-initiated SSO, and if your application only speaks OIDC, bridging IdP-initiated SAML to OIDC with Keycloak shows how a broker absorbs that flow for you.

Where do IdP and SP live in the Keycloak admin console?

Keycloak is an IdP out of the box, and it becomes an SP the moment you add an upstream provider. The admin guide describes brokering as Keycloak being “configured to delegate authentication to one or more IDPs”, whether that is a social login or “any other OpenID Connect or SAML 2.0 IDP” (Keycloak Server Administration Guide, Core concepts and terms). The two roles map onto two sections of the realm’s left menu:

• Clients is Keycloak wearing its IdP hat. Every entry is an application that relies on Keycloak for login, and a SAML client is a service provider that receives Keycloak’s assertions. The realm’s own IdP metadata, the document a partner’s SP needs to trust you, is published at /realms/{realm}/protocol/saml/descriptor, and you can create a SAML client by importing the SP’s entity descriptor file through the Import client option instead of filling the form by hand (Keycloak Server Administration Guide, Using an entity descriptor to create a client).
• Identity providers is Keycloak wearing its SP hat. Every entry is an upstream IdP that Keycloak relies on, and for a SAML v2.0 entry the admin guide’s first field is the Service Provider Entity ID, “the SAML Entity ID that the remote Identity Provider uses to identify requests from this Service Provider”, which by default “is set to the realms base URL” (Keycloak Server Administration Guide, SAML v2.0 Identity Providers).

Both can be live in the same realm at the same time, and that is the broker pattern working as designed. The chained login runs as the admin guide’s identity broker flow describes it: the application redirects the user to Keycloak, Keycloak issues an authentication request to the external IdP and redirects the user there, the user authenticates, the external IdP sends a response back, Keycloak validates it and either imports a new user or links the identity to an existing one, and finally Keycloak “issues its token to client applications” (Keycloak Server Administration Guide, Brokering overview).

Your application, a Client, sends the user to Keycloak, which acts as its IdP (1). Keycloak redirects on to the partner IdP configured under Identity providers, acting as that IdP’s SP (2). The partner’s assertion comes back to Keycloak’s broker endpoint (3), Keycloak validates it and runs the first login flow (4), and your application receives Keycloak’s own token (5).

Your application never sees the partner’s assertion. It receives Keycloak’s token in the one format it already understands, so ten customer IdPs are still one integration. The local user Keycloak creates or links in step 4 is governed by the First login flow setting, which by default “points to the first broker login flow” (Keycloak Server Administration Guide, First login flow), and that local record is a shadow of the upstream identity with trade-offs we unpacked in Keycloak is not your identity store.

How do you set up a real broker in Keycloak?

A brokered SAML connection is a metadata exchange in both directions, and each direction is one of the two roles. Here is the sequence against a partner’s or customer’s IdP, with Microsoft Entra ID as the usual example:

1. Collect the partner’s IdP metadata. The partner’s IdP publishes it as an XML entity descriptor, which you can import as a file or by its URL. It carries the partner’s entity ID, its single sign-on URL and its signing certificate, which is what the admin guide means when it says the Single Sign-On Service URL field’s value “is specified there” if the IdP publishes a descriptor (Keycloak Server Administration Guide, SAML v2.0 Identity Providers).
2. Add a SAML v2.0 identity provider in Keycloak. In the realm, open Identity providers, pick SAML v2.0, give it an alias, and import the partner’s metadata by URL or by file so the SSO URL, the NameID format and the validating certificate are filled in for you. The step-by-step version, with the mappers for email and names, is in configuring Entra ID as a SAML IdP in Keycloak, and the general reference is Keycloak as a SAML service provider.
3. Export Keycloak’s SP descriptor for the partner. Save the provider, then open its Endpoints item, which “contains a SAML 2.0 Service Provider Metadata link which generates the SAML entity descriptor for the Service Provider”. The same document is public at /realms/{realm}/broker/{alias}/endpoint/descriptor, and the guide reminds you to save your changes before you fetch it (Keycloak Server Administration Guide, SP Descriptor). The partner loads this into their IdP, which is how they learn your entity ID, your assertion consumer service URL and the certificate you sign requests with.
4. Register your application under Clients. This side is unchanged by the broker: the application still talks only to Keycloak, with OIDC or SAML, exactly as it did before the partner existed.
5. Test and route. Log in through the application, pick the new provider on the Keycloak login page, and confirm a local user appears with the attributes you mapped. When you have more than one upstream provider, the application can skip the chooser by passing the alias, which is what kc_idp_hint is for.

In the reverse case, where a partner wants to use your realm as their IdP, you stay in Clients: import their SP entity descriptor to create the SAML client, and hand them your realm’s descriptor URL from step 3’s sibling, /realms/{realm}/protocol/saml/descriptor (Keycloak Server Administration Guide, Using an entity descriptor to create a client).

If you run Keycloak on Skycloak, the same two roles sit in the realm’s Connect section of the dashboard as Applications and Identity providers (Skycloak docs, Dashboard), and adding an upstream provider is a one-page setup from a template gallery: copy the redirect URI into the partner’s console, paste their entity ID and SSO URL for SAML or their client ID and secret for OIDC, test the connection, and enable it (Skycloak docs, Identity Providers). The hub pattern that results, one issuer for your applications with every customer IdP connected behind it, is the subject of federated SSO vs a single IdP and of enterprise SSO that survives IdP changes.

Which side am I on? A checklist for any vendor’s docs

Much federation confusion comes down to which side you are on, and you can answer it from the vocabulary the other party uses before you open a console. Apply these checks to whatever page you are reading:

• They ask for your metadata, your entity ID, your ACS URL, your redirect URI or your reply URL. You are the SP. They authenticate, you consume.
• They send you their metadata, a certificate, an SSO URL or an issuer URL and a client ID. You are the SP, and that document is what you import.
• They ask you for a sign-in URL, a signing certificate, a discovery document or a client ID and secret to give their app. You are the IdP. You serve the login page and issue the tokens.
• The page talks about attribute statements, claims or mappers that your side releases. You are the IdP, because only the asserting party decides what goes into the assertion.
• The page talks about validating signatures, checking the audience, or “allowed clock skew”. You are the SP, because only the relying party validates.
• In the Keycloak admin console: if you are editing under Clients, Keycloak is the IdP for that entry; if you are editing under Identity providers, Keycloak is the SP for that entry.
• The page is about where the login starts (portals, tiles, “unsolicited responses”, “third-party initiated login”). That is the flow question, not the role question, and the answer is in IdP-initiated vs SP-initiated SSO.

A system can be on both lists at once. If the same realm imports a customer’s metadata under Identity providers and publishes its own IdP descriptor for a downstream application under Clients, it is an SP to the first and an IdP to the second, and that is the broker pattern rather than a mistake.

What breaks when you get the side wrong?

The failures are predictable because each one is a role mismatch. Here are the ones we see most often, and what they look like:

• You pasted the partner’s SP descriptor into Identity providers, or their IdP metadata into Clients. The metadata describes the wrong role for that screen, so the endpoints Keycloak needs are usually missing and the import or the login commonly fails. Check the metadata’s role before importing: SAML metadata expresses an entity’s operational roles, IdP or SP (SAML 2.0 Technical Overview, section 4.1), and the Identity providers screen expects an IdP entity descriptor, which is where its Single Sign-On Service URL comes from (Keycloak Server Administration Guide, SAML v2.0 Identity Providers).
• The audience does not match. The partner’s IdP issues an assertion for the entity ID it was given, and Keycloak validates against the Service Provider Entity ID in its SAML provider settings, which defaults to the realm URL. If someone typed a different value on either side, the SP rejects a perfectly good assertion. The condition is spelled out in the assertion’s audience restriction, so look there first.
• The certificate on the SP side is stale. The validating certificate Keycloak imported from the partner’s metadata is the partner’s signing key, and when the partner rotates it the assertion signature fails until you re-import. The SP, not the IdP, holds the copy that goes out of date, so the fix is always on the relying side.
• The IdP sends attributes nobody imports. Attributes in an assertion are the IdP’s statements, and they reach a Keycloak user only through a mapper you add on the Identity providers side. When the IdP does not provide mandatory information such as email, first name or last name, the default first login flow’s Review Profile step can show the user a profile page to fill it in (Keycloak Server Administration Guide, Default first login flow authenticators), which teams often misread as a bug in the partner’s IdP.
• IdP-initiated SAML arrives at an application expecting a response to its own request. The application is an SP that was built for SP-initiated login only, so it rejects the unsolicited response. This is where the flow question and the role question meet, and the handling options are in the dedicated flow post.

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 under Identity providers (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 that answers the application’s request. In IdP-initiated SSO the user starts at the IdP’s portal and the IdP sends an assertion to the SP without any request from the SP (SAML 2.0 Technical Overview, section 5.1.4). The trust setup is identical; only the starting point changes, and our flow comparison covers which to pick.

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 a validity window and an audience, and the issuer’s identity (SAML 2.0 Technical Overview, section 4.3). The IdP signs the assertion so the SP can verify nothing was changed in transit.

What is the OIDC equivalent of an IdP and an SP?

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

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: an SP toward the external IdP, and an IdP toward everything that sits behind it.

Where is Keycloak’s SP metadata for a brokered identity provider?

After you save a SAML identity provider, its Endpoints item links to the SAML 2.0 Service Provider Metadata, and the same document is served at /realms/{realm}/broker/{alias}/endpoint/descriptor (Keycloak Server Administration Guide, SP Descriptor). The realm’s own IdP metadata, for applications that rely on Keycloak, is at /realms/{realm}/protocol/saml/descriptor.

What to do next

Work out which side you are on with the checklist above, then act on it. If you are the SP, import the partner’s metadata and hand back your own descriptor. If you are the IdP, publish your descriptor and decide which attributes you release. Paste a SAML response from the partner’s IdP into our SAML decoder to check its issuer, audience and attributes before you touch a console, and if you want both roles in one realm without running the server yourself, add a brokered IdP on Skycloak through identity providers.