Understanding Keycloak OIDC vs Standard OIDC

When people talk about “OIDC,” they usually mean the OpenID Connect specification: an identity layer built on top of OAuth2 that standardizes how applications authenticate users using ID tokens, user info endpoints, scopes, and claims.

But when you work with Keycloak long enough, you start to realize something important:

There is OIDC as written in the spec, and then there is OIDC as Keycloak implements it.

They’re aligned, but not identical. And understanding the difference is the key to building clean integrations, avoiding broken flows, and actually controlling the user experience the way you want.

This article breaks down the exact differences based on how Keycloak handles OIDC in the real world.

1. OIDC Is a Standard. Keycloak Implements It.

OIDC defines the following at a high level:

• How a client app redirects a user to authenticate
• How tokens are issued (ID, access, refresh)
• How claims are formatted
• Endpoints like /.well-known/openid-configuration
• How the app exchanges authorization codes for tokens
• The structure of the ID token (JWT)
• The lifecycle rules around tokens

On paper, every OIDC provider should behave the same.

In reality, they don’t.

Keycloak, Auth0, Okta, Google, Cognito, each one implements OIDC with its own defaults, extensions, constraints, and interpretations of the spec.

That’s why developers get confused. You integrate one OIDC provider and assume the next one will behave the same. It never does.

2. What Makes Keycloak’s OIDC Implementation Different

Keycloak is more flexible than most commercial OIDC providers, but it also exposes more complexity. Here are some differences:

2.1 Authentication Flows Are Fully Customizable

Standard OIDC assumes:

• The user is redirected
• They authenticate
• An authorization code is issued

Keycloak allows you to redefine every step of that journey using custom flows. You can insert:

• Conditional executions
• Scripted authenticators
• Step-up MFA
• Alternative or required steps
• User attribute checks
• Identity brokering logic

This is not standard OIDC. This is Keycloak extending the spec to give you absolute control.

Most platforms can’t do this without hacking or enterprise add-ons.

2.2 Keycloak Implements Realms, Not Tenants

OIDC itself has no concept of realms.

Keycloak does.

A realm is a full identity domain with:

• Its own keys
• Its own clients
• Its own users
• Its own MFA policies
• Its own token settings

This means two “OIDC providers” inside the same Keycloak instance can behave completely differently. You won’t see that in the OIDC spec.

2.3 Token Customization Goes Far Beyond the OIDC Spec

Standard OIDC gives you a defined set of claims.

Keycloak lets you:

• Add custom claims
• Map roles into tokens
• Inject user attributes
• Use script-based mappers
• Change signing algorithms
• Control token lifetimes globally or per client

Most OIDC providers restrict this. Keycloak exposes all of it.

2.4 Keycloak Supports Identity Brokering Natively

OIDC does not define identity brokering. It only defines how one provider behaves.

Keycloak allows you to broker:

• Google
• Apple
• Azure AD
• Okta
• Any OIDC or SAML provider

And then rewrite the claims, remap attributes, and insert them into your local token. This is a Keycloak-specific extension that goes far beyond the core spec.

2.5 The Admin API Is Deep and Granular

OIDC doesn’t define how you manage the provider.

Keycloak exposes a full admin REST API to manage:

• Realms
• Clients
• Users
• Roles
• Sessions
• Policies
• Flows
• Themes

This matters because integrating with Keycloak at scale often means you’re using OIDC for auth and the Admin API for automation.

This is where people confuse “Keycloak OIDC” with “Keycloak Admin.”

3. What Keycloak Gets Strict About (Where People Break Things)

Keycloak generally follows the OIDC spec tightly, but it enforces several things people don’t expect:

3.1 PKCE Enforcement

Many hosted providers let you skip PKCE in certain cases. Keycloak does not. Modern versions enforce PKCE for public clients whether you like it or not.

3.2 Redirect URI Matching

Keycloak is extremely strict:

• Full match required
• No wildcards unless explicitly enabled
• No fragments allowed
• No scheme mismatch

This breaks most first-time integrations.

3.3 CORS and Web Origins

OIDC does not define CORS rules. Keycloak enforces them. If Web Origins are not configured properly, browsers block everything.

3.4 HTTPS Requirements

Keycloak rejects insecure redirect URIs unless running in development mode.

This is correct OIDC behavior, but many hosted providers relax it for convenience.

4. Still confused?

Here’s the simple way to think about it:

OIDC is the protocol. Keycloak is a full Identity Provider built on top of that protocol.

OIDC defines the rules. Keycloak gives you the entire ecosystem around those rules:

• Realms
• MFA policies
• Authentication pipelines
• Token customization
• Identity brokering
• User federation
• Scripted extensions
• Full automation APIs

That difference is why companies outgrow “checkbox OIDC providers” and move to Keycloak once authentication becomes a real part of the product architecture.

If you’re building serious identity, you need both:

• The consistency of OIDC
• The control of Keycloak’s implementation

And that’s exactly where Keycloak stands out.

Need help with your Keycloak instance? Reach out!

Like and share this post please!