Keycloak Azure Identity Provider
You set up a keycloak azure identity provider by linking both login tools with OIDC. This setup lets your team log in to Keycloak using Microsoft directory accounts. Most teams build this trust link to manage all user logins in one place. They map directory groups to broad Keycloak roles so engineers can open internal tools. When those mapped roles grant wide permissions, one login opens too many backend systems. How a keycloak azure identity provider works The trust flow starts when a user t
Keycloak + Azure Privileged Identity Management: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up a keycloak azure identity provider by linking both login tools with OIDC. This setup lets your team log in to Keycloak using Microsoft directory accounts. Most teams build this trust link to manage all user logins in one place. They map directory groups to broad Keycloak roles so engineers can open internal tools. When those mapped roles grant wide permissions, one login opens too many backend systems.
How a keycloak azure identity provider works
The trust flow starts when a user tries to log in to an app. Keycloak sees the request and sends the user over to the Microsoft login page. The user enters their work email, password, and second factor on the Microsoft side. Microsoft checks the user account and sends a signed token back to Keycloak. This token holds basic user details like email, user ID, and directory group names.
You build this link by registering a new app record inside your Microsoft directory. That record gives you a client ID, a secret key, and a discovery URL. Next, you create an OIDC provider entry inside your Keycloak realm and paste those values. You also copy the redirect URL from Keycloak and save it inside Microsoft. Once both sides share these keys and URLs, they can verify signed login tokens.
Mapping directory groups and user claims
After the basic login works, teams need a way to assign permissions to users. By default, Keycloak creates a new local user profile after the first Microsoft login. Without extra rules, that new profile has no special roles inside your realm. Admins fix this by setting up claim mappers inside the Keycloak provider settings. A mapper reads the incoming token and looks for specific group IDs or roles.
When a token holds a matching group ID, Keycloak assigns a local role to the user. Teams often map a single engineering group in Microsoft to a broad admin role. They must also pick a sync mode to keep user roles fresh over time. If the sync mode only runs at first login, old roles stay active forever. Setting the sync mode to update on every login keeps group changes in step.
Keycloak + Azure Privileged Identity Management: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What directory login solves and what it misses
Centralizing logins through Microsoft and Keycloak solves several common problems for growing engineering teams. You only have one place to disable an account when someone leaves the company. You can also enforce strong password rules and multi-factor checks from your main directory. App builders do not have to write custom login code for every new tool. Instead, they trust Keycloak tokens and let Microsoft handle the actual user sign-in.
Still, an identity link only checks who a person is at the front door. Once a user logs in and gets a role, the login provider steps back. It cannot see what queries an engineer runs inside a production database session. It cannot block a risky shell command or require a teammate to approve a change. It also cannot mask emails, phone numbers, card numbers, or national IDs in query results. Directory roles are too coarse to control individual actions inside live databases and servers.
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
Should I use OIDC or SAML to link Keycloak and Azure?
Most teams pick OIDC because it uses compact JSON tokens and simpler web URLs. SAML also works well, especially if your company already runs older enterprise login rules. Both options let you pass user emails and group claims between the two systems.
Why do my Microsoft directory groups not show up in Keycloak?
Microsoft does not include group claims in login tokens unless you turn them on. You must update the token settings in your Microsoft app record to send groups. Then you need a claim mapper in Keycloak that matches those exact group IDs.
What happens when a user is removed from a group in Azure?
The result depends on the sync mode you chose inside your Keycloak provider settings. If you use the force sync mode, Keycloak updates the user roles at next login. Active sessions still keep their current access until the existing token expires or closes.