User journey patterns
Overview
This page documents the end-to-end user journeys for the most common LuxID authentication scenarios. Each journey includes a sequence diagram and a plain-language description of what the user experiences at each step.
Use these diagrams to:
- Communicate the sign-in flow to product teams and designers.
- Identify where your application is responsible for handling state.
- Set correct user expectations in onboarding and help content.
The diagrams use the following actors:
- User - the person signing in
- App - your partner application (browser or native client)
- LuxID - the LuxID authorisation server at
https://login.luxid.lu - AS - your application's server (back-end)
Journey 1: first-time sign-in (account creation)
A user who does not yet have a LuxID Account encounters "Sign in with LuxID" for the first time.
What the user experiences: They click the sign-in button, land on the LuxID page, choose to create an account, verify their email, approve the consent screen, and are returned to your application - signed in and ready to use it.
Your application's responsibilities:
- Generate and store
stateandcode_challengebefore the redirect. - Validate
stateon callback to prevent CSRF. - Exchange the
codefor tokens server-side (never in the browser). - Create or update the user's local session using the ID token claims.
Journey 2: returning sign-in (session cookie present)
A user who already has a LuxID Account and an active session on login.luxid.lu signs in again on a device where they previously authenticated.
What the user experiences: A single click on "Sign in with LuxID" and they are immediately returned to your application - no password entry, no MFA challenge. The entire round-trip takes under two seconds.
If the user has previously consented to your application's requested scopes, the consent screen is also skipped. The flow is entirely transparent.
Journey 3: sign-in with MFA challenge
A user signs in with a password, then faces a second-factor challenge - either because your application requested acr_values=urn:luxid:acr:level:substantial or because LuxID's risk engine triggered a step-up. (The canonical acr_values form is urn:luxid:acr:level:low|substantial|high; the accepted request values are agreed per Partner during onboarding.)
What the user experiences: They enter their password, then complete a second verification step (confirm an SMS code, enter a TOTP code, or use a passkey). The extra step is framed by LuxID as "Verify it's you."
Your application's responsibilities:
- Check the
acrclaim in the ID token to confirm the assurance level was met. - If
acrdoes not match the required level, reject the session and redirect to/mga/sps/oauth/oauth20/authorizeagain.
Journey 4: sign-in with LuxID Verified identity
A user who has completed LuxID Verified (identity proofing via LuxTrust) signs in to an application that requires a verified identity.
What the user experiences: A standard sign-in flow with their LuxTrust second factor. They may see additional claims on the consent screen (verified name, date of birth) that were obtained during identity proofing.
For the full feature reference, see LuxID Verified.
Journey 5: sign-in via LuxID Pro (enterprise federation)
A user whose organisation has federated access configured via LuxID Pro. They sign in with their organisational identity, which is mapped through LuxID.
What the user experiences: They enter their work email address. LuxID recognises the domain as a federated organisation and redirects them to their organisation's identity provider. After authenticating there (possibly with their organisation's MFA), they are returned to your application via LuxID. The partner application always receives a LuxID-issued token - it does not interact with the organisation IdP directly.
Journey 6: account linking (adding a second authentication method)
An existing user adds a passkey to their LuxID Account. This happens at https://account.luxid.lu/ - outside your application - but the result affects how the user signs in to your application on future visits.
What the user experiences: They manage their authentication methods in their LuxID Account, not inside any particular partner application. The change applies across all partner applications automatically.
Your application's responsibilities: None - this journey is entirely within LuxID. If you want to nudge users to add a second factor, link them to https://account.luxid.lu/ > Security with a brief explanation.
Journey 7: logout and POST-logout redirect
A user signs out of your application. Your application always clears its own session; the user can additionally choose to end the shared LuxID session.
What the user experiences: they click "Sign out", the application clears its local session, and LuxID presents a confirmation screen naming the application. If the user confirms, the shared LuxID session ends and any subsequent sign-in requires re-entering credentials. If they do not, only the application session was cleared.
Clearing your application's own session is not enough to end the LuxID session - and LuxID does not expose an OIDC end_session_endpoint, so you cannot terminate the LuxID session silently on the user's behalf. As the shared SSO authority for many Partners, LuxID puts the decision to end the global session in the user's hands via the /auth/logout confirmation screen.
Parameters:
| Parameter | Required | Description |
|---|---|---|
client_id | Yes | Your Application's OIDC client_id. LuxID uses it to display your application name on the confirmation screen |
See Session management for the full discussion of why LuxID does not offer silent RP-initiated logout.
Journey summary table
| Journey | Triggers re-auth? | Consent screen shown? | MFA shown? | App controls? |
|---|---|---|---|---|
| First-time sign-in | Yes (new user) | Yes (always) | If enrolled + required | scope, acr_values |
| Returning sign-in (session) | No | No (if previously consented) | No | prompt, max_age |
| MFA challenge | Yes | If first visit | Yes (required by app or risk) | acr_values |
| LuxID Verified | Yes | Yes (includes verified claims) | Yes (LuxTrust) | scope, acr_values |
| LuxID Pro (federation) | Yes (via org IdP) | If first visit | Via org IdP | login_hint (domain) |
| Account linking | N/A (account mgmt) | N/A | Yes (re-auth required) | None |
| Logout | N/A | N/A | N/A | client_id (user-driven via /auth/logout) |
Related pages
- Add Login - OIDC parameters and token exchange
- Universal Login UX - session reuse and
prompt=login - Multi-factor UX - per-method MFA UX
- Passwordless and passkey UX - passkey flows in detail
- LuxID Verified - identity verification feature