Coming from Auth0, Okta or Keycloak
Who this page is for
You have shipped integrations against Auth0, Okta, Keycloak or a similar identity platform, and you are about to integrate LuxID. Most of your knowledge transfers - the protocol is the same standard OIDC. What does not transfer is the operating model, and that difference explains every "where is the setting for X?" question you are about to have.
The mental model shift
Auth0, Okta and Keycloak are identity platforms: you get your own tenant (or realm), you own the user store, and you configure the IdP's behaviour - custom claims, login page branding, upstream connections, token lifetimes.
LuxID is an identity provider: a single, shared, sovereign IdP operated by POST Luxembourg, comparable to Google Sign-In, Facebook Login or Sign in with Apple. There is one LuxID. You do not get a tenant, you do not own the users, and you do not configure the IdP - you integrate with it as a Relying Party (a "LuxID Partner"). Users bring their existing LuxID Account to your application, along with their existing MFA setup, passkeys, and single sign-on session across other LuxID Partners.
When in doubt about whether something is possible, ask "could I do this with Google Sign-In?" rather than "could I do this with Auth0?".
Concept mapping
| Concept you know | LuxID equivalent |
|---|---|
| Tenant / Okta org / Keycloak realm | Not applicable. There is a single LuxID realm shared by all Partners. You register Applications in it; you do not administer it |
| Application / client registration | LuxID Application. Registered by LuxID from the details you submit - see Register an Application. Self-service registration via the LuxID Console is planned; today registration and changes go through Partner support |
| Rules, Actions, Hooks, claim mappers, custom claims | Not available. LuxID has a fixed claim catalogue; which claims your tokens carry is agreed with LuxID at registration through Claim Templates. There is no way to run your code inside the IdP or inject computed claims |
Custom domain (login.yourbrand.com) | Not available. Users always authenticate at login.luxid.lu - the fixed, recognisable domain is part of LuxID's anti-phishing posture (and what makes passkeys work across all Partners) |
| Social connections / upstream identity providers | Not applicable. LuxID is the identity provider - it does not broker to Google or Facebook for you. Corporate-IdP federation exists, but on LuxID's side as LuxID Pro, agreed per organisation, not configured by you |
| Roles, permissions, RBAC, authorization policies | Your responsibility. LuxID authenticates the user and gives you a stable sub; everything about what that user may do in your application lives in your application |
| User management API (create/update/delete users) | Not applicable. Users create and manage their own LuxID Account; you cannot provision users. A scoped Partner API covers Partner-side resources, not the user store |
| Login page customization (templates, CSS) | Not available. Universal Login has a fixed LuxID layout; your Application's name and logo appear on the consent screen, and that is the extent of Partner branding inside the flow. See Universal Login UX |
| MFA policy configuration (which factors, when) | Partially applicable. Users choose their own factors; you can require a minimum authentication level per Application or per request via acr_values - see Authentication levels |
end_session_endpoint / RP-initiated logout | Not available - see the next section |
Logout works differently
This is the difference most likely to surprise you. LuxID does not expose an OIDC end_session_endpoint and does not implement RP-Initiated Logout. This is an architectural decision, not a gap: LuxID is the shared SSO authority for many Partners at once, and one application must not be able to terminate the session that other applications rely on.
What to do instead:
- On logout, end your own application session (clear your session cookie, drop stored tokens).
- Do not redirect to a LuxID logout endpoint expecting the OIDC RP-initiated pattern - there is none.
- If the user explicitly wants to end their LuxID session everywhere, offer a link to the user-driven confirmation flow at
https://login.luxid.lu/auth/logout?client_id=<your_client_id>.
Full discussion and code patterns: Session management and OpenID Connect.
What stays exactly the same
The protocol layer is boring in the best way - your existing OIDC knowledge and libraries work unchanged:
- Authorization Code + PKCE is the flow for every application type - see Add login to your Application.
- Standard discovery at
https://login.luxid.lu/.well-known/openid-configuration. - RS256-signed tokens validated against a standard JWKS endpoint, keys resolved by
kid- see Key management. - Standard ID token validation -
iss,aud,exp,nonce, signature - exactly the five checks you already implement. - Your existing OIDC library (openid-client, Spring Security, NextAuth, AppAuth, ...) works by pointing the issuer at
https://login.luxid.lu- see Platform and framework guides. acr_values/acr/amrstep-up semantics follow the standard OIDC pattern, with LuxID-specific values.
If you migrate an existing Auth0/Okta/Keycloak integration, the code change is typically: swap issuer and credentials, remove the logout redirect, remove any Management-API calls, and re-map your claim expectations to the LuxID claim catalogue.
What you cannot customize - the honest list
Coming from a multi-tenant platform, expect no Partner control over:
- The login and consent page layout, wording, or styling (beyond your Application name and logo)
- The login domain - always
login.luxid.lu - The claim schema - no custom or computed claims; claim release is agreed via Claim Templates at registration
- Password policy, account recovery flows, and MFA enrolment - these belong to the user's relationship with LuxID, not to your Application
- Token signing algorithms and key rotation schedule
- Injecting code into the authentication pipeline (no Rules, Actions, or event hooks inside the IdP)
What you get in exchange: no user store to secure, no MFA support burden, no login page to maintain, users who arrive already verified and MFA-enrolled, and SSO with the rest of the LuxID ecosystem.
Running Keycloak? You can keep it
If Keycloak (or another broker) fronts your applications today, you do not have to rip it out: configure LuxID as an upstream identity provider in your broker and keep your internal architecture. See Keycloak broker integration and the general IdP broker integrations guidance, including the two-hop logout implications.
Next steps
- Learn the basics - LuxID's domain model (Applications, Spheres, Subscriptions)
- Plan and design - the decisions to make before writing code
- Add login to your Application - the 15-minute quickstart