Is Keycloak an IdP? Clarifying the Terminology

If you ask a developer, "Is Keycloak an Identity Provider?", they will likely say yes. If you ask a protocol engineer, they will pause. The confusion arises because marketing terms and protocol specifications use "Identity Provider" differently. In the context of modern architecture, Keycloak is not just an IdP. It is an Authorization Server, an Identity Provider, and an Identity Broker, all running in the same process. Understanding the distinction is critical because misidentifying Keycloak’s role leads to incorrect security configurations, broken Single Sign-On (SSO) flows, and flawed trust models.

This post clarifies the mechanism-level differences between these roles and maps them to specific Keycloak features.

The Terminology Trap: OAuth 2.0 vs. OpenID Connect

To understand Keycloak, we must first separate the terminology used in two protocols that are often conflated: OAuth 2.0 and OpenID Connect (OIDC).

OAuth 2.0 is an authorization framework. It delegates access to resources. The core actor here is the Authorization Server (AS). The AS issues access tokens. It does not inherently care about who the user is, only that they have permission to act.

OpenID Connect is an identity layer built on top of OAuth 2.0. It adds an id_token (a signed JWT containing user claims) and a /userinfo endpoint. The core actor here is the Identity Provider (IdP). The IdP asserts "who" the user is.

Keycloak implements both. When a client requests an access_token, Keycloak acts as an Authorization Server. When a client requests an id_token or user claims, Keycloak acts as an Identity Provider. Treating them as the same entity ignores the distinct security boundaries and data flows involved.

Keycloak as an Authorization Server

In the OAuth 2.0 flow, Keycloak’s primary job is to validate the client and issue an access token. This is the mechanism of authorization.

Consider a React application (client_id: my-app) attempting to access a protected API. The app redirects the user to Keycloak. Keycloak authenticates the user (checking credentials against its database or a social provider). Once authenticated, Keycloak issues an access_token.

Crucially, the access_token is opaque to the user but signed by Keycloak. The resource server (the API) validates this token by checking Keycloak’s public key (JWKS). Keycloak, in this role, is making an authorization decision: "This client is allowed to access these scopes."

This is distinct from identity. The access token does not necessarily contain the user’s name or email. It contains scopes and audience information. If you configure Keycloak to only issue access tokens for API access without enabling OIDC, it is purely an Authorization Server. Most modern setups enable both, but the mechanisms are separate.

Keycloak as an Identity Provider

When Keycloak acts as an IdP, it is responsible for aggregating and asserting user attributes. This happens via the id_token and the /userinfo endpoint.

The id_token is a JSON Web Token (JWT) that contains standard claims like sub (subject), iss (issuer), and exp (expiration). It is signed by Keycloak’s private key. The Relying Party (RP) verifies this signature to ensure the identity assertion came from Keycloak and hasn’t been tampered with.

The /userinfo endpoint is where Keycloak retrieves additional attributes (e.g., email, preferred_username) from its internal user store or user federation providers. This endpoint is protected by the access token issued in the previous step.

Here is the key distinction: An IdP asserts identity. It does not necessarily authenticate the user directly if it is federated. However, in Keycloak’s local realm, it does both. It stores the password hash (using PBKDF2 or argon2) and verifies it. This local authentication capability is what makes Keycloak feel like a traditional IdP.

But Keycloak goes further. It can act as an IdP for other systems by exposing its own discovery document (/.well-known/openid-configuration). Other applications can treat Keycloak as the source of truth for user identity, trusting its id_token.

The Missing Role: Identity Broker

The most confusing aspect of Keycloak is its ability to aggregate identities from multiple sources. This is called Identity Brokerage.

Imagine a user wants to log in using their Google account. Keycloak does not store the Google password. Instead, it redirects the user to Google. Google authenticates the user and returns an OAuth 2.0 code to Keycloak. Keycloak exchanges this code for a Google access token and retrieves user profile data.

Keycloak then creates a local account in its database (if it doesn’t exist) and links it to the Google identity. This local account becomes the canonical identity for that user within Keycloak’s realm.

In this scenario, Keycloak is an Identity Broker. It sits between the user and the identity source (Google), translating and aggregating identities. It is not just passing through the identity; it is normalizing it, mapping attributes, and managing the lifecycle of the local account.

This is distinct from being an IdP. A pure IdP asserts identity for a specific set of users it manages. A broker aggregates identities from multiple sources and presents a unified view. Keycloak does both. It can be the IdP for your internal apps (using local or LDAP users) while acting as a broker for external social logins.

Why This Distinction Matters

Confusing these roles leads to architectural errors:

1. Security Misconfiguration: As noted in the OAuth 2.1 draft, scope validation is critical. If you treat Keycloak only as an IdP, you might overlook the importance of scope validation in the access token. The IdP role handles id_token, but the AS role handles access_token. Both must be validated correctly.
2. Federation Complexity: If you don’t recognize Keycloak as a broker, you may struggle to understand how user attributes flow from social providers to your application. The mapping happens in the broker layer, not the IdP assertion layer.
3. Trust Boundaries: The AS and IdP roles have different trust implications. The AS trusts the client to hold the access token securely. The IdP trusts the RP to handle user claims appropriately. Mixing these up can lead to leakage of sensitive identity data in access tokens.

Conclusion

Keycloak is not just an Identity Provider. It is a comprehensive IAM platform that implements the Authorization Server role (OAuth 2.0) for access control, the Identity Provider role (OIDC) for identity assertion, and the Identity Broker role for federating external identities.

When you configure Keycloak, you are configuring three distinct mechanisms. Recognizing this allows you to leverage its full power: using OAuth 2.0 for secure API access, OIDC for user identity, and brokerage for simplified social login integration. Stop thinking of Keycloak as just an IdP. Think of it as the trust anchor for your entire identity infrastructure.

FAQ

Is Keycloak an IdP or Authorization Server?

Keycloak is both. It functions as an Authorization Server when issuing OAuth 2.0 access tokens for resource access, and as an Identity Provider when issuing OpenID Connect ID tokens for user identity assertion.

What is an Identity Broker?

An Identity Broker aggregates identities from multiple external sources (like Google, GitHub, or LDAP) and presents a unified identity to internal applications. Keycloak acts as a broker by federating these external providers into a single realm.

Can Keycloak act as both?

Yes. Keycloak seamlessly integrates these roles. It can authenticate users against local databases or social providers (Broker/IdP) while simultaneously managing granular access permissions for APIs (AS).

Takeaways

• Keycloak implements three distinct roles: Authorization Server, Identity Provider, and Identity Broker.
• OAuth 2.0 handles authorization (access tokens), while OpenID Connect handles identity (ID tokens).
• Confusing these roles can lead to security misconfigurations and broken federation flows.

Pitfalls

• Assuming the IdP role handles access token validation; this is the AS role.
• Ignoring scope validation in access tokens, leading to over-permissive access.
• Misunderstanding federation boundaries, causing issues with attribute mapping from external providers.