Keycloak Multiple Identity Providers
You set up keycloak multiple identity providers by linking external login systems to one realm. Users then pick their home provider on the login screen or route by email domain. Engineering teams often use this setup to let partners, contractors, and staff share one app. Still, teams often map broad default roles to every outside login source. Those broad roles give users far too much power once they log in. How keycloak multiple identity providers work Keycloak acts as a central hub between
Keycloak + Identity Provider Integration: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up keycloak multiple identity providers by linking external login systems to one realm. Users then pick their home provider on the login screen or route by email domain. Engineering teams often use this setup to let partners, contractors, and staff share one app. Still, teams often map broad default roles to every outside login source. Those broad roles give users far too much power once they log in.
How keycloak multiple identity providers work
Keycloak acts as a central hub between your apps and outside login systems. An admin adds each outside source using standard protocols like OpenID Connect or SAML. Each source gets its own trust keys and redirect links inside the realm. When a user tries to log in, Keycloak shows a list of these linked sources.
Teams can also route users based on their email address domain. If a user types an email from a partner company, Keycloak sends them there. The partner system checks the user and sends a signed token back to Keycloak. Keycloak reads the token and creates or updates a local user record.
Next, identity mappers read claims and groups from the outside token. These mappers attach local Keycloak roles to the user profile during login. Your app then reads those local roles to see what the user can do. This flow keeps login rules in one place instead of inside ten different apps.
How to map roles across different login sources
Every company names its groups and job titles in a different way. One identity source might send a group name while another sends a custom role claim. Admins must build separate mapper rules for each connected login system. A small mistake in a mapper rule can grant admin rights to a guest.
To keep things safe, start every new provider with zero default roles. Build explicit mapper rules that check for exact group names from the source token. Test each login flow with a regular test account before you let real users in. Check the local user profile to make sure old roles drop off when groups change.
Keycloak + Identity Provider Integration: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What identity federation solves and what it leaves open
Setting up multiple login sources solves the first step of user sign-in. You do not need to manage passwords for contractors or partner staff. When a contractor leaves their firm, their home system cuts off their login right away. Your team saves time and avoids stale accounts across your systems.
Still, login checks only decide who gets through the front door. Once a user gets a role, Keycloak steps out of the way. It cannot see what queries an engineer runs on a database after sign-in. It cannot stop a bad command inside a server session or mask live data.
If two providers map to one shared database role, everyone shares the same wide access. Audits only show that a user signed in at a specific time. They do not show what records the user read or changed during that session. Moreover, rawemails, phone numbers, and card numbers return in full to anyone with read rights. Real safety needs controls that check every command and rewrite sensitive fields in results.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
Can one user link accounts from two different identity providers?
Yes, Keycloak can link multiple outside logins to a single local user profile. The system matches users by email or asks them to verify their existing account first.
How do you skip the login screen and route users to their provider?
Your app can pass an identity provider hint in the login request URL. You can also set up an email domain check inside the Keycloak login flow.
What happens when an outside provider changes a user role?
You must set the identity mapper sync mode to update on every login. Otherwise, Keycloak only reads outside groups during the very first login and ignores later changes.