Keycloak Auth0 Identity Provider: OIDC Setup
Add Auth0 as an identity provider in Keycloak using the generic OIDC provider. Covers Auth0 application creation, allowed callback URL configuration, Keycloak IDP setup, attribute mappers, and first login flow.
KeycloakPro Team
KeycloakPro Team
Introduction
Adding Auth0 as an identity provider in Keycloak lets users authenticate via their Auth0 tenant. A common use case is migrating from Auth0 to Keycloak gradually — Keycloak federates to Auth0 while you move applications over, then you cut the federation once the migration is complete.
Keycloak doesn't have a built-in Auth0 provider, so you use the generic OpenID Connect v1.0 provider with Auth0's well-known discovery URL.
How identity brokering works
The login flow goes: user clicks "Sign in with Auth0" → Keycloak redirects to Auth0 → user authenticates → Auth0 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 Auth0 is:
https://keycloak.example.com/realms/YOUR_REALM/broker/auth0/endpoint
The alias auth0 in the URL matches the alias you set when creating the identity provider in Keycloak.
Prerequisites
- Keycloak 24+ running on HTTPS
- A Keycloak realm with admin access
- An Auth0 account at auth0.com with admin access
Step 1 — Create an application in Auth0
In the Auth0 Dashboard:
- Applications → Applications → Create Application
- Name:
keycloak - Application type: Regular Web Applications
- Click Create
Step 2 — Configure the callback URL
On the application's Settings tab:
- Allowed Callback URLs → add:
https://keycloak.example.com/realms/YOUR_REALM/broker/auth0/endpoint - Allowed Logout URLs → add (optional):
https://keycloak.example.com/realms/YOUR_REALM/protocol/openid-connect/logout - Scroll down → Save Changes
Step 3 — Copy the Client ID and Client Secret
Still on the Settings tab:
- Client ID — visible at the top of the Basic Information section
- Client Secret — visible below it, click the eye icon to show, then copy
Note your Auth0 domain from the top of the Settings page: YOUR_DOMAIN.auth0.com (or your custom domain if configured). This is the domain used in the discovery URL.
Step 4 — Configure the Identity Provider in Keycloak
In the Keycloak admin console:
- Select your realm
- Identity Providers → Add provider → OpenID Connect v1.0
- Alias:
auth0 - Display name:
Auth0 - Discovery Endpoint:
https://YOUR_DOMAIN.auth0.com/.well-known/openid-configuration - Client ID: paste from Step 3
- Client Secret: paste from Step 3
- Default Scopes:
openid profile email
Click Add.
Replace YOUR_DOMAIN with your Auth0 domain. If you use a custom domain like auth.yourcompany.com, use that in the discovery URL instead.
Step 5 — Configure attribute mappers
Auth0's standard OIDC token includes these claims:
| Auth0 claim | Description |
|---|---|
sub | Unique Auth0 user ID (e.g., `auth0 |
name | Display name |
given_name | First name (if set in the profile) |
family_name | Last name (if set in the profile) |
email | Email address |
email_verified | Whether the email is verified |
nickname | Typically the username portion of the email |
picture | Profile photo URL |
Keycloak's generic OIDC provider doesn't add default mappers. Add them:
- Identity Providers → auth0 → 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
5.1 — Using Auth0 Actions to add custom claims
If you need claims beyond the standard OIDC set (e.g., organization ID, roles, metadata), use Auth0 Actions:
- In Auth0 Dashboard: Actions → Flows → Login
- Add a custom action with this pattern:
exports.onExecutePostLogin = async (event, api) => {
const namespace = 'https://YOUR_NAMESPACE.example.com/';
api.idToken.setCustomClaim(namespace + 'org_id', event.organization?.id);
api.idToken.setCustomClaim(namespace + 'roles', event.authorization?.roles);
};
Auth0 requires custom claims to have a namespaced format (a URL prefix) to prevent collisions with standard claims. Add corresponding mappers in Keycloak using the full namespaced claim name.
Step 6 — Configure the First Login Flow
In Identity Providers → auth0 → Settings → First Login Flow, the default first broker login flow handles first-time logins.
For a migration scenario where users exist in both Auth0 and Keycloak with the same email, the flow prompts users to link their accounts. This requires them to know their Keycloak password, which may not be the case if users were only in Auth0. Consider whether account linking is appropriate or whether you should create fresh Keycloak accounts for all Auth0 users.
Step 7 — Test the login
Open a private browser window and go to your Keycloak realm login page. An Auth0 button appears.
After completing Auth0's login, Keycloak creates or links the user. Confirm: Keycloak admin → Users → find the user → Identity Provider Links tab. The external user ID is the Auth0 sub value (e.g., auth0|abc123...).
Troubleshooting common issues
"Callback URL mismatch" from Auth0
The callback URL Keycloak sends doesn't match any entry in the Auth0 application's Allowed Callback URLs. The exact URL is:
https://keycloak.example.com/realms/YOUR_REALM/broker/auth0/endpoint
Copy it from Keycloak: Identity Providers → auth0 → Redirect URI field. Paste it exactly into Auth0's Allowed Callback URLs.
Discovery endpoint returns 404
Check the domain. Auth0 domains are case-insensitive but path-sensitive. The correct format is:
https://YOUR_DOMAIN.auth0.com/.well-known/openid-configuration
For custom domains: https://auth.yourcompany.com/.well-known/openid-configuration. Verify by opening the URL in a browser.
given_name and family_name are missing from the token
These claims are only populated if the user's Auth0 profile has them set. Social connections (Google, GitHub, etc.) may not include them. Use the name claim instead, or use Auth0 Actions to split the name into given and family parts when they're missing.
Auth0 sub value is very long — identity linking fails across re-registrations
Auth0's sub value is stable for a user within an Auth0 database connection but changes if a user deletes their Auth0 account and re-registers. If you're federating a migration scenario, document this so future account-linking issues are diagnosable.
Custom namespaced claims don't appear in Keycloak attributes
The mapper's Claim field must contain the full namespaced claim name including the URL prefix, e.g., https://YOUR_NAMESPACE.example.com/org_id. The claim names in Auth0's token and the mapper's Claim field must match exactly.
Production checklist
- Allowed Callback URL in Auth0 matches the Keycloak broker endpoint exactly
- Client secret stored outside source control
- Discovery URL verified in browser before configuring Keycloak
- Attribute mappers configured for email, firstName, lastName
- Custom claims added via Auth0 Actions if application requires them
- Migration scenario planned: fresh accounts vs linked accounts for existing users
- Sync Mode chosen deliberately
- Auth0 application in the correct Auth0 tenant (dev, staging, production)
Need help integrating Auth0 with Keycloak?
We deliver production-ready Auth0 + Keycloak integrations in 1–3 weeks.
Fixed-price, zero vendor lock-in, full source code ownership.