Identity · Identity Providers
Let every user sign in with the identity provider they already have
We connect Keycloak to your customers' and your own corporate IdPs over OIDC and SAML — mapping claims, linking accounts safely and routing each user to the right login without making them pick from a list.
- OIDC & SAML 2.0 brokering
- Email-domain routing with Organizations
- Runs on upstream Keycloak 26.x
Standards & integrations
- OpenID Connect
- SAML 2.0
- Microsoft Entra ID
- Okta
- Google Workspace
- ADFS
- Ping Identity
Overview
Brokering is where identity projects get subtle
Adding one external IdP to Keycloak is quick. Running many of them is different: each sends claims in its own shape, some users already have local accounts, email domains decide where people should be sent, and certificates expire on someone else's schedule. We design the brokering layer so new connections are routine and existing ones don't fail quietly.
What we deliver
- Identity provider configuration as code (Terraform / OpenTofu)
- Claim and attribute mapping matrix per IdP
- First broker login and account-linking flow design
- Organization domain routing and kc_idp_hint guidance
- Customer IdP onboarding checklist
- Certificate and metadata rotation runbook
Capabilities
What Identity Providers covers
Configured, tested and documented on upstream Keycloak — then handed over or operated by us.
OIDC and SAML brokering
Connect any standards-compliant IdP — Entra ID, Okta, Ping, ADFS, Auth0 or a customer's own — while your applications keep talking to a single Keycloak realm.
Mappers that normalise claims
Identity provider mappers import attributes, assign roles and place users in groups, so every IdP produces the same user shape no matter how it names things.
Safe account linking
First broker login flows decide what happens when an external identity matches an existing account: link after re-authentication or email verification, ask the user to review, or refuse.
Routing by email domain
Keycloak Organizations tie domains to identity providers, so a user who enters a work email is sent to their company's IdP. kc_idp_hint covers apps that already know where to send them.
Per-customer IdPs for B2B
Each enterprise customer brings its own IdP, attached to its organization, through an onboarding process your team can repeat without touching application code.
Key and metadata hygiene
JWKS URLs for OIDC key rollover, tracked SAML signing certificates and expiry alerts in your monitoring, so a partner's certificate change doesn't turn into an outage.
How it works
From first call to production
Inventory IdPs and user populations
We list every IdP you need to trust, which users come from each, what claims they send and whether those users already exist in Keycloak.
Configure brokering and linking
Identity providers, mappers, first broker login flows and organization domains are defined as code and tested against each IdP's test tenant.
Make onboarding repeatable
You get a checklist for connecting the next customer IdP, a mapping template to fill in, and monitoring for certificate and metadata changes.
Use cases
Where teams put it to work
Enterprise SSO for B2B SaaS
Each customer signs in through their own Okta, Entra ID or Google Workspace tenant, routed by email domain, with no customer-specific code in your app.
Mergers and multi-directory workforces
Staff from acquired companies keep their existing IdP while reaching shared tools through one Keycloak realm.
Partner and contractor access
External partners authenticate with their own organisation's credentials instead of holding accounts you have to create and remember to remove.
FAQ
Identity Providers questions, answered
Which identity providers can Keycloak broker?
Any IdP that speaks OpenID Connect or SAML 2.0. Keycloak also ships preconfigured providers for common services such as Google, Microsoft and GitHub, which cut down the setup for those.
Can one realm trust many customer identity providers?
Yes. A realm can broker many IdPs, and with Keycloak Organizations each one can be attached to a specific customer and matched by email domain, keeping the login page clean.
What if a user already has a local account with the same email?
The first broker login flow handles it. We usually require the user to prove ownership — by signing in to the existing account or verifying their email — before the identities are linked, rather than linking silently on a matching address.
Can we skip the Keycloak login page entirely?
Yes. Applications can pass kc_idp_hint to redirect straight to a given IdP, and Organizations can redirect automatically once a user enters an email in a matching domain.
Ready to roll out Identity Providers?
Walk us through your requirements on a free strategy call. We'll come back with an architecture, a delivery plan and a fixed scope.