Skip to main content
Version 0.2Draft

Universal Login UX

What is Universal Login​

Universal Login is the LuxID hosted login page at https://login.luxid.lu where every authentication step happens; your application redirects users to it and receives them back with an authorisation code.

Universal Login is the hosted login page at https://login.luxid.lu. Every authentication flow - password entry, multi-factor challenge, account creation, and recovery - happens on this page. Your application redirects users to Universal Login and receives them back with an authorisation code once authentication is complete.

Universal Login is not an embedded SDK or a set of form components you add to your own page. It is a fully managed, fully hosted experience operated by POST Luxembourg.

For the technical details of the redirect flow, see Add Login and Universal Login.

Why redirect-based is safer than embedded login​

Some older identity integrations embed a username and password form directly inside the partner application. Universal Login takes the opposite approach: the user leaves your application, authenticates on login.luxid.lu, and returns. This redirect architecture has significant security and UX advantages.

Your Application never sees the password​

With an embedded login form, the application intercepts the user's keystrokes and forwards credentials to the identity provider. A compromised application - or a malicious extension injected into it - can capture those credentials silently.

With Universal Login, the password is entered only on login.luxid.lu. Your application receives an authorisation code, which it exchanges for tokens. It never handles the password at any point in the flow.

Password managers work better​

Password managers and browsers autofill credentials on the domain where they were saved. Because all LuxID users authenticate on login.luxid.lu, a user's password manager will offer to autofill LuxID credentials on that domain - across every partner application. An embedded form on yourapp.lu would require users to save a separate entry per application, or autofill would not work at all.

Phishing is harder to execute​

A phishing attack on an embedded login form is straightforward: create a replica of the partner application's sign-in page and capture credentials entered there. Universal Login raises the bar significantly: the attacker must convincingly replicate login.luxid.lu, including its TLS certificate, HSTS headers, and evolving security features. Browser address bar verification - "Am I on login.luxid.lu?" - is a reliable trust signal users can learn once and apply everywhere.

MFA and recovery are built in​

Universal Login handles every stage of authentication, including multi-factor challenges, device registration, and account recovery flows. If LuxID adds a new MFA method (for example, a new passkey variant), all partner applications benefit automatically with no integration changes required.

Future-proof by design​

Authentication standards evolve. LuxID can update Universal Login - adding step-up flows, bot detection, new MFA methods, session security improvements - without requiring partner application updates. An embedded form would require each partner to update independently.

What the LuxID login page guarantees​

When a user is on https://login.luxid.lu, they can rely on the following guarantees:

GuaranteeDetail
HTTPS with valid certificateThe page is always served over TLS. The certificate is issued to login.luxid.lu and verifiable in the browser address bar
No partner application sees the passwordThe credential form exists only on LuxID's domain
Consistent UX across all partnersThe user learns the login pattern once and recognises it across every LuxID-enabled service
MFA methods always availableOTP (SMS/voice), TOTP (authenticator app), passkeys, and LuxTrust are offered as configured by the user's account
Recovery paths embedded"Forgot password" and "I can't access my 2FA device" links are always present
Responsive layoutThe page adapts to mobile and desktop without requiring a separate mobile URL

Branding boundaries: what you can and cannot change​

Universal Login is intentionally conservative about what partner applications can customise. This keeps the page trustworthy and recognisable.

What your Application can configure​

These settings are pinned per Application on the LuxID side (today via a request to LuxID; via the planned LuxID Console in future):

Configurable elementDetail
Application nameDisplayed on the consent screen as "Sign in to [Your Application Name]"
Application logoDisplayed on the consent screen; must meet the LuxID logo placement guidelines
Post-login redirect URIsWhere the user lands after authentication
Claim TemplateThe set of claims released to your Application. Determines what appears on the consent screen. Changes require a request to LuxID.

What your Application cannot change​

Fixed elementWhy it is fixed
The login form layoutConsistency is a trust signal; a customisable form creates a phishing opportunity
LuxID colours and typography on the login pageBrand consistency across all partners
The LuxID logo placement on the login pageRequired for recognition; cannot be removed or moved
The URL (login.luxid.lu)The domain itself is the trust anchor
MFA challenge screensStandardised for security and accessibility
Error message wording on the LuxID pageControlled by LuxID to ensure accuracy and compliance

If your application has specific branding requirements that appear to conflict with these boundaries, contact LuxID to discuss options. Some configuration is available on the LuxID side that is not documented publicly.

Mobile vs desktop experience​

Universal Login is a responsive web application. No separate mobile URL or mobile-specific integration is required.

On desktop​

  • The login form is presented in a centred card layout, typically at 400-480 px width.
  • The application name and logo (if configured) appear above the form.
  • Password managers and browser autofill work normally.

On mobile​

  • The form adapts to full viewport width with appropriate touch target sizing.
  • The keyboard is triggered automatically on the email/password field on focus.
  • Passkey authentication uses the device's native biometric prompt (Face ID, Touch ID, fingerprint reader) without leaving the browser.
  • OTP codes arriving via SMS can be autofilled from the notification on iOS (Safari) and most Android browsers.

Native app considerations​

If your application is a native iOS or Android app, you must open Universal Login using the system browser or an in-app browser tab (ASWebAuthenticationSession on iOS; Custom Tabs on Android). Do not use a WebView or WKWebView.

Using a system browser component means:

  • The user's saved LuxID session cookie is available (session reuse works).
  • Password managers and autofill work correctly.
  • The platform's security model applies (certificate pinning, Safe Browsing).
danger

Using a WebView breaks all three of these properties and is a violation of the LuxID Agreement.

On iOS, the system shows a one-time "YourApp Wants to Use login.luxid.lu to Sign In" dialog the first time the app opens the session. That prompt comes from iOS, not from LuxID, and it is what enables single sign-on. It is explained in full - including the prefersEphemeralWebBrowserSession trade-off and an Android comparison - in Add Login - Native and mobile apps.

Autofill and input assistance​

The Universal Login page is built to cooperate with the autofill machinery on every platform, so users type as little as possible. This is part of why the hosted page is more convenient than an embedded form, not only safer.

Password manager autofill​

The email and password fields carry the standard autocomplete hints (username, current-password) and are served from the single login.luxid.lu origin. Password managers - Passbolt, Bitwarden, the platform keychains (iCloud Keychain, Google Password Manager), 1Password, and browser built-in managers - therefore offer to fill saved LuxID credentials directly, and offer to save them on first sign-in. Because every partner authenticates on the same origin, the user keeps one LuxID entry that works across all LuxID-enabled apps and sites.

One-time-code (SMS OTP) autofill​

When LuxID sends a one-time code by SMS, the code-entry field is marked with autocomplete="one-time-code" (and the iOS oneTimeCode content type). On iOS and Android the keyboard then surfaces the just-received code as a one-tap suggestion directly above the keyboard, so the user fills the OTP field without leaving the page or copying from the Messages app. This works on the hosted page with no app-side integration.

Passkeys and biometrics​

Where the user has a passkey, the platform's native passkey sheet (Face ID, Touch ID, Android biometric or screen lock) is invoked directly from the page. See Passwordless and passkey UX.

Session reuse: when the user is already signed in​

LuxID maintains a session cookie on login.luxid.lu. When a user who is already authenticated visits Universal Login again - from the same browser - they do not need to re-enter their credentials.

What the user experiences​

If an active LuxID session exists and the application has not requested re-authentication:

  1. The user clicks "Sign in with LuxID" in your application.
  2. They are redirected to login.luxid.lu.
  3. LuxID detects the existing session.
  4. The user sees the consent screen only (if they have not previously consented to this application), or is redirected back immediately.
  5. The authorisation code is delivered to your application's redirect URI.

The user's experience is a single click to sign in - no password entry required.

Controlling re-authentication​

Your application can override session reuse in specific situations:

ParameterBehaviour
prompt=loginForces the user to re-enter their credentials even if a session exists. Use for high-security actions (changing payment method, deleting account)
max_age=<seconds>Requires re-authentication if the user's last authentication was more than the specified number of seconds ago. Example: max_age=900 for a 15-minute inactivity threshold
prompt=consentForces the consent screen to be shown even if the user has previously consented. Useful if your application has updated its requested scopes

These parameters are passed as query parameters on the authorisation request. See Add Login for the full parameter reference.

Session lifetime​

LuxID sessions are valid for a configurable period. The session is invalidated on explicit logout (via the /logout endpoint).

Updated 2026-06-02
On this page