Keycloak GitHub Identity Provider
You set up a keycloak github identity provider by linking an OAuth app in GitHub to your realm. This link lets developers log in to internal tools with their GitHub accounts. Engineering teams often use this setup to keep all user accounts in one place. When teams assign broad default roles during login, every developer gets too much power. One shared role can let any user read or write sensitive data across systems. How the keycloak github identity provider flow works The login flow relies o
Keycloak + Identity Provider Integration: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up a keycloak github identity provider by linking an OAuth app in GitHub to your realm. This link lets developers log in to internal tools with their GitHub accounts. Engineering teams often use this setup to keep all user accounts in one place. When teams assign broad default roles during login, every developer gets too much power. One shared role can let any user read or write sensitive data across systems.
How the keycloak github identity provider flow works
The login flow relies on standard OAuth token exchange between the two systems. First, you register a new OAuth app inside your GitHub account settings. GitHub gives you a client ID and a client secret for your realm. You copy these two keys into your Keycloak realm settings. You also copy the redirect URL from your realm back into GitHub.
When a developer tries to log in, the realm sends them to GitHub. The developer approves the request on the GitHub login page. GitHub then sends an authorization code back to the redirect URL. The realm swaps this code for a token and reads the user profile. If the user is new, the system creates a local account right away.
Mapping GitHub teams to local roles
Logging a user in is only the first step for your platform team. You also need to decide what each developer can do after they log in. Most teams map GitHub group memberships to local realm roles during the login step. You can set up mappers that read profile data or group claims from GitHub. The mapper then attaches a matching local role to the user token.
If you skip this mapping step, every GitHub user gets the same default role. Teams often make the default role too broad so new hires can work fast. That choice gives every developer wide permissions across your connected databases and servers. You should keep the default role empty and grant specific roles through mappers. You should also restrict login to members of your own GitHub team.
Keycloak + Identity Provider Integration: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What native identity brokering leaves open
A linked login setup solves the problem of managing separate passwords for every developer. When someone leaves your GitHub team, they lose login access on the next token refresh. It also gives you one place to check who logged in and when.
Still, the login step only decides who gets through the front door. Once a developer gets a valid token, the identity tool steps out of the way. It cannot see what queries or commands the developer runs inside a database session. It cannot pause a dangerous delete statement and ask a manager for approval. It also cannot rewrite sensitive fields like emails, phone numbers, card numbers, or national IDs in query results. Teams that need control over live commands must inspect traffic after the login step.
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 I restrict login to a single GitHub team?
Yes, you can restrict access so random public GitHub users cannot log in. You must check group membership during the login flow and block users outside your team.
What happens when a user already has a local account?
The system detects the matching email address during the first GitHub login attempt. It prompts the user to verify their existing account before linking the two profiles together.
Does revoking a user in GitHub end their active sessions right away?
No, active sessions keeps the session active until the current local token expires. You must revoke the active session in your realm if you need an instant cutoff.