Skip to main content
Version 0.3Draft

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 state and code_challenge before the redirect.
  • Validate state on callback to prevent CSRF.
  • Exchange the code for tokens server-side (never in the browser).
  • Create or update the user's local session using the ID token claims.

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.

note

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 acr claim in the ID token to confirm the assurance level was met.
  • If acr does not match the required level, reject the session and redirect to /mga/sps/oauth/oauth20/authorize again.

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.

Important

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:

ParameterRequiredDescription
client_idYesYour 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​

JourneyTriggers re-auth?Consent screen shown?MFA shown?App controls?
First-time sign-inYes (new user)Yes (always)If enrolled + requiredscope, acr_values
Returning sign-in (session)NoNo (if previously consented)Noprompt, max_age
MFA challengeYesIf first visitYes (required by app or risk)acr_values
LuxID VerifiedYesYes (includes verified claims)Yes (LuxTrust)scope, acr_values
LuxID Pro (federation)Yes (via org IdP)If first visitVia org IdPlogin_hint (domain)
Account linkingN/A (account mgmt)N/AYes (re-auth required)None
LogoutN/AN/AN/Aclient_id (user-driven via /auth/logout)
Updated 2026-07-03
On this page