What Keycloak version do you use?

We deploy Keycloak 26.x (latest stable) for all new projects. For existing deployments, we offer migration paths from Keycloak 18+ (including the legacy WildFly-based versions) to the modern Quarkus-based distribution.

How long does a typical project take?

Simple implementations (passkeys, theming) take 5-10 business days. Multi-tenancy and HA clusters typically take 2-3 weeks. Full CIAM overhauls run 4-6 weeks. We provide exact timelines in our fixed-price proposals.

Can you migrate us from Okta, Auth0, or Firebase Auth?

Yes. We have battle-tested migration playbooks for Okta, Auth0, Firebase Auth, AWS Cognito, and Azure AD B2C. We handle user migration, session continuity, and social login re-linking with zero downtime.

What does 'fixed price' mean? Are there hidden costs?

Our quotes are all-inclusive. The price covers discovery, architecture, implementation, testing, deployment, documentation, and 30-day warranty support. Infrastructure costs (cloud hosting) are separate and transparently estimated upfront.

Do you offer ongoing managed services?

Yes. Our Managed Keycloak-as-a-Service starts at $1,800/month and includes 24/7 monitoring, patching, scaling, security updates, and incident response. Think of it as your dedicated Keycloak ops team without the hiring overhead.

Is Keycloak really enterprise-ready?

Absolutely. Keycloak is backed by Red Hat (IBM), powers thousands of enterprise deployments globally, and is the upstream for Red Hat SSO. It supports SAML 2.0, OIDC, LDAP/AD federation, and every enterprise SSO protocol you need.

What about vendor lock-in?

Zero. Keycloak is 100% open source (Apache 2.0). You own your deployment, your data, and your configuration. Everything we build is yours — full source code, Terraform configs, and documentation included in every project.

Do you work with our existing DevOps team?

Yes. We integrate seamlessly with your existing CI/CD pipelines, cloud infrastructure, and DevOps workflows. We provide Terraform/OpenTofu IaC, Helm charts, and comprehensive runbooks so your team can maintain the deployment independently.

Keycloak Okta Identity Provider: OIDC Setup

Introduction

Adding Okta as an identity provider in Keycloak lets users sign in with their Okta credentials. Keycloak acts as the OIDC relying party — it redirects users to Okta for authentication and receives back a user identity it can map to a local account.

Keycloak doesn't have a built-in Okta provider type, so you use the generic OpenID Connect v1.0 provider with Okta's authorization server discovery URL. The setup takes about 15 minutes.

How identity brokering works

The login flow goes: user clicks "Sign in with Okta" → Keycloak redirects to Okta → user authenticates → Okta sends an authorization code to Keycloak's broker endpoint → Keycloak exchanges it for tokens → Keycloak creates or links the user → user lands in your application.

The redirect URI you register in Okta is:

https://keycloak.example.com/realms/YOUR_REALM/broker/okta/endpoint

The alias okta in the URL matches the alias you set when creating the identity provider in Keycloak.

Prerequisites

Keycloak 24+ running on HTTPS
A Keycloak realm with admin access
An Okta account with admin access — Developer Edition works

Step 1 — Create an OIDC application in Okta

In the Okta Admin Console:

Applications → Applications → Create App Integration
Sign-in method: OIDC — OpenID Connect
Application type: Web Application
Click Next

Okta Admin Console Create App Integration page showing OIDC OpenID Connect selected as the sign-in method and Web Application selected as the application type — Web Application type is correct — it creates a confidential client with a client secret

App settings:

App integration name: keycloak
Sign-in redirect URIs: https://keycloak.example.com/realms/YOUR_REALM/broker/okta/endpoint
Sign-out redirect URIs: optional — add https://keycloak.example.com/realms/YOUR_REALM/protocol/openid-connect/logout if you want back-channel logout coordination
Assignments: Limit access to selected groups (recommended) or Allow everyone in your organization

Click Save.

Okta app integration settings form showing the App integration name as keycloak, Sign-in redirect URIs containing the Keycloak broker endpoint, and Assignments section — Limit access to specific groups during testing — expand to everyone once the integration is confirmed working

Step 2 — Copy the Client ID and Client Secret

After saving, the app settings page shows:

Client ID — always visible
Client secret — click Show to reveal, then copy

Okta app integration settings page showing the Client ID and Client secret fields with a Copy to clipboard button for each — The client secret is a long URL-safe string — copy it with the copy button to avoid truncation

Note your Okta domain (shown in the top-right of the admin console): YOUR_DOMAIN.okta.com. This goes into the discovery URL.

Step 3 — Choose an authorization server

Okta has two types of authorization servers:

Org Authorization Server — https://YOUR_DOMAIN.okta.com — issues tokens that contain Okta user profile claims. Available on all plans.
Custom Authorization Servers — https://YOUR_DOMAIN.okta.com/oauth2/SERVER_ID — the default server is https://YOUR_DOMAIN.okta.com/oauth2/default. More configurable, supports custom claims.

For most setups, use the default custom authorization server. The discovery URL for it is:

https://YOUR_DOMAIN.okta.com/oauth2/default/.well-known/openid-configuration

If you have a specific custom authorization server, replace default with its ID.

Step 4 — Configure the Identity Provider in Keycloak

In the Keycloak admin console:

Select your realm
Identity Providers → Add provider → OpenID Connect v1.0
Alias: okta
Display name: Okta
Discovery Endpoint: https://YOUR_DOMAIN.okta.com/oauth2/default/.well-known/openid-configuration
Client ID: paste from Step 2
Client Secret: paste from Step 2
Default Scopes: openid profile email

Click Add.

Keycloak admin console Identity Providers page showing the OpenID Connect v1.0 provider form with Alias set to okta, Display name set to Okta, and the Discovery Endpoint containing the Okta authorization server discovery URL — After saving, Keycloak fetches the discovery document and auto-populates the authorization, token, and userinfo endpoints

Step 5 — Configure attribute mappers

The Okta default authorization server issues these claims:

Okta claim	Description
`sub`	Unique Okta user ID
`preferred_username`	Okta login (usually email)
`name`	Display name
`given_name`	First name
`family_name`	Last name
`email`	Email address
`groups`	Group memberships (if configured in the authorization server)

Keycloak's generic OIDC provider doesn't add default mappers. Add them:

Identity Providers → okta → Mappers → Add mapper

Email mapper:

Mapper type: Attribute Importer
Name: email
Claim: email
User Attribute Name: email

First name mapper:

Mapper type: Attribute Importer
Name: firstName
Claim: given_name
User Attribute Name: firstName

Last name mapper:

Mapper type: Attribute Importer
Name: lastName
Claim: family_name
User Attribute Name: lastName

5.1 — Optional: map Okta groups

If you need Okta group memberships in Keycloak, configure the Okta authorization server to include a groups claim, then add a mapper in Keycloak.

In Okta:

Security → API → Authorization Servers → default → Claims → Add Claim
Name: groups
Include in token type: ID Token → Always
Value type: Groups
Filter: Matches regex .* (all groups) or a specific group name pattern
Include in: Any scope

In Keycloak, after saving the IDP:

Mappers → Add mapper
Mapper type: Hardcoded Role (to grant a role) or create a custom mapper via Advanced Claim to Group (if available) or use a script mapper for group-based RBAC

The exact approach depends on how your Keycloak RBAC is structured. For simple role assignment based on an Okta group, the Hardcoded Role mapper is the quickest path.

Okta Authorization Server Claims configuration page showing a groups claim with Value type set to Groups and Filter set to match all groups — Configure the groups claim in Okta before adding a groups mapper in Keycloak — the token must include the claim for Keycloak to map it

In Identity Providers → okta → Settings → First Login Flow, the default first broker login flow handles new users on their first Okta login to Keycloak.

Set Sync Mode:

import — copy attributes from Okta on first login only
force — overwrite Keycloak attributes from Okta on every login

Use force if Okta is the authoritative directory for user attributes.

Keycloak Okta Identity Provider Settings showing First Login Flow set to first broker login and Sync Mode dropdown — If your organization uses Okta as the user directory, force sync keeps Keycloak in sync without manual admin action

Open a private browser window and go to your Keycloak realm login page. An Okta button appears.

Keycloak login page showing the standard form with an Okta button below — The button label matches the Display Name you set when creating the provider — Okta in this guide

After completing Okta's login flow, Keycloak creates or links the user. Confirm: Keycloak admin → Users → find the user → Identity Provider Links tab. The external user ID is the Okta sub value.

Keycloak User detail page Identity Provider Links tab showing an okta row with the Okta sub value as the external user ID — The alias in the Provider column is okta — matching the alias set during provider creation

Troubleshooting common issues

The discovery URL doesn't point to an existing authorization server. Check that YOUR_DOMAIN.okta.com is correct and that the authorization server name (default or your custom server ID) is right. Open the discovery URL in a browser to confirm it returns JSON.

"error: invalid_client" during token exchange

The client secret is wrong. Okta auto-generates a new client secret when you click Rotate in the app settings. Copy the current secret and update it in Keycloak. The client ID doesn't change when the secret rotates.

Users get "You do not have permission to access this app"

The Okta app's Assignments settings restrict access. The user trying to log in isn't assigned to the app individually or via a group. Go to the app's Assignments tab and add the user or their group.

Decode the ID token at jwt.io to see exactly which claims Okta is sending. If given_name and family_name are missing, the user's Okta profile may not have these fields set, or the Okta authorization server's profile scope doesn't include them. You can add custom claims in the Okta authorization server to include specific profile attributes.

Check that the groups claim was added to the Okta authorization server (Step 5.1) and that it includes ID Token. Groups claims don't appear unless the claim is configured to include them. After adding the claim, log in again — Keycloak caches tokens per session.

"discovery_document_error" in Keycloak logs

Keycloak can't fetch the discovery document during the login flow. Check that Keycloak's server can reach Okta's domain on port 443 (outbound HTTPS). Also verify there's no proxy blocking the connection.

Production checklist

App assignments configured — avoid "Allow everyone" unless that's the intent
Client secret stored outside source control
Authorization server chosen deliberately: org server vs custom default server
Attribute mappers configured for email, firstName, lastName
Groups claim configured in Okta if group-based RBAC is needed
Discovery URL verified by opening in browser before configuring Keycloak
Sync Mode chosen deliberately
Client secret rotation process documented — Okta doesn't auto-rotate secrets

Need help integrating Okta with Keycloak?

We deliver production-ready Okta + Keycloak integrations in 1–3 weeks.

Fixed-price, zero vendor lock-in, full source code ownership.

See integration packages