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 PingOne Identity Provider: OIDC Setup

Introduction

Ping Identity has two main products: PingOne (cloud SaaS) and PingFederate (on-premise or self-hosted). This guide covers PingOne as the primary path and PingFederate in a dedicated section at the end.

Both products support OIDC. Keycloak acts as the relying party, federating authentication upstream to Ping. Keycloak doesn't have a built-in Ping provider type — you use the generic OpenID Connect v1.0 provider.

How identity brokering works

The login flow goes: user clicks "Sign in with PingOne" → Keycloak redirects to PingOne → user authenticates → PingOne 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 PingOne is:

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

The alias pingone in the URL matches the alias you set in Keycloak. PingOne identifies environments by an Environment ID — a UUID that appears in all PingOne API endpoints and discovery URLs.

Prerequisites

Keycloak 24+ running on HTTPS
A Keycloak realm with admin access
A PingOne account with an environment set up at pingone.com
Admin access to the PingOne environment

Step 1 — Find your PingOne Environment ID

In the PingOne Admin Console:

Go to your environment (visible in the URL bar)
Note the Environment ID — it appears in the browser URL as a UUID: https://console.pingone.com/.../#/env/YOUR_ENV_ID/...
Alternatively: Environment → Properties — the Environment ID is listed there

PingOne Admin Console Environment Properties page showing the Environment ID as a UUID string — The Environment ID appears in every PingOne API URL — you need it for the discovery URL and redirect URI

Your PingOne region determines the base domain:

North America: auth.pingone.com
Europe: auth.pingone.eu
Asia-Pacific: auth.pingone.asia
Canada: auth.pingone.ca

The discovery URL format is:

https://auth.pingone.com/YOUR_ENV_ID/as/.well-known/openid-configuration

Replace auth.pingone.com with your region's domain if needed.

Step 2 — Create an OIDC application in PingOne

In the PingOne Admin Console:

Applications → Applications → click + (Add Application)
Application name: keycloak
Application type: OIDC Web App
Click Save

PingOne Add Application dialog showing Application name set to keycloak and OIDC Web App selected as the application type — OIDC Web App creates a confidential client — the correct type for server-side applications like Keycloak

On the Configuration tab:

Redirect URIs → Add: https://keycloak.example.com/realms/YOUR_REALM/broker/pingone/endpoint
Response Type: leave Code checked (authorization code flow)
Token Endpoint Authentication Method: CLIENT_SECRET_BASIC
Click Save

PingOne application Configuration tab showing Redirect URIs with the Keycloak broker endpoint added, Response Type set to Code, and Token Endpoint Authentication Method set to CLIENT_SECRET_BASIC — CLIENT_SECRET_BASIC is how Keycloak sends credentials to the token endpoint by default

Step 3 — Grant required resources/scopes

PingOne requires you to explicitly grant scopes to applications:

Application → Resources tab → click + (Add Resource)
Select openid from the available resources
Also add profile and email scopes under the openid resource or as separate entries
Click Save

PingOne requires explicit scope grants per application — the OIDC standard scopes won't work unless granted here first

Step 4 — Enable the application

New PingOne applications are disabled by default:

On the application list or settings page
Toggle the Enable switch to ON

PingOne application list showing the keycloak app with an Enable toggle set to ON — Disabled applications return an error during the OAuth flow — enable before testing

Step 5 — Copy the Client ID and Client Secret

In the application's Configuration tab (or Overview tab):

Client ID — visible in the configuration section
Client Secret — click the eye icon or expand to see the value, then copy

PingOne application Configuration tab showing the Client ID and Client Secret fields with visibility toggle buttons — Copy both values to use in Keycloak — the secret is generated by PingOne and can be rotated from this page

Step 6 — Configure the Identity Provider in Keycloak

In the Keycloak admin console:

Select your realm
Identity Providers → Add provider → OpenID Connect v1.0
Alias: pingone
Display name: PingOne
Discovery Endpoint: https://auth.pingone.com/YOUR_ENV_ID/as/.well-known/openid-configuration
Client ID: paste from Step 5
Client Secret: paste from Step 5
Default Scopes: openid profile email

Click Add.

Keycloak admin console Identity Providers page showing the OpenID Connect v1.0 provider with Alias set to pingone, Discovery Endpoint containing the PingOne environment discovery URL, and Client credentials filled in — Keycloak fetches the discovery document on save — if it fails, check the Environment ID and the region base domain

Step 7 — Configure attribute mappers

PingOne issues these OIDC claims by default:

PingOne claim	Description
`sub`	Unique PingOne user ID
`preferred_username`	Username
`name`	Display name
`given_name`	First name
`family_name`	Last name
`email`	Email address
`address`	Address object (if population profile includes it)

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

Identity Providers → pingone → 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

Keycloak Identity Provider Mappers list showing email, firstName, and lastName attribute importer mappers for the PingOne provider — PingOne user attributes must be configured in the population schema for the claims to appear in tokens — verify in PingOne if claims are missing

In Identity Providers → pingone → Settings → First Login Flow, the default first broker login flow creates or links Keycloak users on their first PingOne login.

Keycloak PingOne Identity Provider Settings showing First Login Flow set to first broker login and Sync Mode dropdown — Force sync is useful when PingOne is the authoritative user directory for your organization

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

Keycloak login page showing a PingOne button below the standard form — The button label uses the Display Name from the provider configuration

After completing PingOne's authentication, confirm the user in Keycloak: Users → find the user → Identity Provider Links tab. The external user ID is the PingOne sub value.

Keycloak User detail page Identity Provider Links tab showing a pingone row with the PingOne sub value as the external user ID — Successful federation creates the identity link on first login — subsequent logins use the cached link

PingFederate (on-premise)

If you run PingFederate instead of PingOne, the setup follows the same pattern but with PingFederate-specific URLs.

PingFederate is a full-featured on-premise federation server that supports both OIDC and SAML. This section covers the OIDC path — SAML is also possible but requires different Keycloak configuration (a SAML identity provider, not OIDC).

PingFederate OIDC app registration

PingFederate manages OIDC clients in the admin console:

OAuth Server → Clients → Create New
Client ID: a string you choose (e.g., keycloak)
Client Secret: generate or set a value
Redirect URIs: https://keycloak.example.com/realms/YOUR_REALM/broker/pingfederate/endpoint
Allowed Grant Types: Authorization Code
OpenID Connect: enable
ID Token Signing Algorithm: RS256

PingFederate OAuth Clients configuration page showing Client ID set to keycloak, Redirect URIs containing the Keycloak broker endpoint, and OpenID Connect enabled — PingFederate's client configuration is in the OAuth Server section — not to be confused with the SP Connections used for SAML

The PingFederate OIDC discovery URL is:

https://YOUR_PINGFEDERATE_HOST/pf-ws/rest/.well-known/openid-configuration

Or, if your PingFederate uses a custom OIDC issuer path:

https://YOUR_PINGFEDERATE_HOST/.well-known/openid-configuration

Check your PingFederate instance's Server Settings → Roles & Protocols to confirm the exact path.

Keycloak IDP configuration for PingFederate

The Keycloak setup is the same as Steps 6-8 above, with these differences:

Alias: pingfederate
Display name: PingFederate
Discovery Endpoint: your PingFederate discovery URL
Client ID: the Client ID you set in PingFederate
Client Secret: the secret you set in PingFederate

PingFederate's token claims depend on the attribute sources and contracts configured in your instance. Add mappers in Keycloak for whatever claims PingFederate issues. Decode a sample token from PingFederate to see the exact claim names.

Troubleshooting common issues

Discovery URL returns 404 (PingOne)

The Environment ID in the URL is wrong, or the region base domain doesn't match. Verify the Environment ID from the PingOne Admin Console → Environment Properties. Also check the region: North America uses auth.pingone.com, Europe uses auth.pingone.eu.

The redirect URI in the PingOne app's Configuration tab doesn't match what Keycloak sends. Copy the Redirect URI from Keycloak's Identity Provider settings page (not from the URL you typed earlier — Keycloak shows the exact URI it will use). Paste that into PingOne.

Scopes are granted but claims are missing from the token

PingOne's user population schema must include the attributes before they appear in tokens. Go to Directory → User Attributes in the PingOne console and verify the attributes you need (given_name, family_name, email) are part of the population schema. Claims only appear if the underlying attribute exists and has a value.

Application is disabled — "Unauthorized" error

PingOne applications are off by default. Confirm the app's Enable toggle is ON. A disabled app returns an authorization error immediately on redirect.

Client secret not accepted

PingOne lets you rotate the client secret from the application configuration page. After rotation, the old secret is invalid immediately. Update the Keycloak IDP config with the new secret.

PingFederate OIDC discovery returns connection refused

PingFederate's OIDC endpoints may be on a different port than the admin console. Check PingFederate's server settings and firewall rules. The OIDC well-known document is typically served from the runtime engine port (default: 9031 for HTTPS), not the admin console port (9999).

Production checklist

PingOne:

Environment ID confirmed from PingOne Admin Console
Region base domain matches the PingOne environment's region
Scopes (openid, profile, email) granted to the application
Application enabled in PingOne
Client secret stored outside source control
Attribute mappers configured for email, firstName, lastName
User population schema includes the required attributes

PingFederate:

OIDC discovery URL accessible from Keycloak's server (firewall/network check)
Attribute contracts include the claims Keycloak needs
Client secret set and not auto-rotated without updating Keycloak
Token signing algorithm matches Keycloak's expectations (RS256 is standard)

Need help integrating PingOne with Keycloak?

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

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

See integration packages