Passwordless and passkeys
What are passkeys?
Passkeys are cryptographic credentials based on the WebAuthn/FIDO2 standard (W3C Web Authentication Level 2 (opens in a new tab), FIDO2 specification (opens in a new tab)).
Instead of a password, a passkey is a public/private key pair. The private key is stored securely in the user's device hardware or a synced credential store; the public key is held by LuxID.
When a user signs in with a passkey, the browser or operating system presents a cryptographic challenge from LuxID (login.luxid.lu). The device signs the challenge with the private key and returns the signature. LuxID verifies the signature against the stored public key. No password is ever typed, transmitted, or stored.
LuxID supports passkeys as both a second factor (password plus passkey) and a primary factor in a fully passwordless flow (passkey only, no password entered).
Public help for users: https://www.luxid.lu/en/resources/passkeys (opens in a new tab).
Availability
Passkey sign-in has been available on LuxID since April 2024. The public help page for end users was launched in July 2024. No Console configuration or partner opt-in is required - passkey support is active for all LuxID Applications.
Why use passkeys?
Phishing-resistant by design. The cryptographic challenge is bound to the origin login.luxid.lu. A phishing site at a different domain cannot trigger a valid passkey assertion - the device will refuse to sign because the origin does not match the credential's binding. This makes passkeys categorically more resistant to phishing than passwords or OTP codes.
No shared secret. Unlike passwords, there is no credential that LuxID "knows" that could be stolen in a server-side breach. The private key never leaves the user's device. LuxID holds only the public key, which is useless without the corresponding private key.
Better user experience. Signing in with a passkey takes seconds: a biometric prompt (Face ID, Touch ID, Windows Hello) or a hardware key tap, and the user is authenticated. No password to remember, no OTP code to copy. This removes friction and reduces support requests related to forgotten passwords.
Multi-device resilience. Platform-synced passkeys (iCloud Keychain, Google Password Manager) are available on all of a user's devices signed in to the same account, without requiring per-device enrolment. Hardware keys (YubiKey) provide device-independent access.
eIDAS Substantial assurance. Passkeys reach Substantial assurance when used as the primary authentication method. LuxID Verified identity proofing (which confirms name and date of birth) also contributes to Substantial assurance when combined with a passkey. High assurance requires LuxTrust as the authentication method. See LuxID Verified: identity verification.
Device binding and authenticator types
Platform authenticators (synced passkeys)
Platform authenticators are built into the user's operating system and sync credentials via a cloud account:
| Platform | Credential store | Sync scope |
|---|---|---|
| Apple (iOS / macOS) | iCloud Keychain | All devices signed in to the same Apple ID |
| Google (Android / Chrome) | Google Password Manager | All devices signed in to the same Google Account |
| Microsoft (Windows) | Windows Hello / Microsoft Authenticator | Windows devices and Authenticator app |
Synced passkeys are convenient for users with multiple devices and are the most common passkey form factor for consumer applications.
Roaming authenticators (hardware keys)
Roaming authenticators are physical devices that connect via USB, NFC, or Bluetooth:
- YubiKey (USB-A, USB-C, NFC variants)
- FIDO2-compliant security keys from other vendors
Hardware keys are device-independent: the user carries the key and can use it on any computer. They are particularly suitable for users who need high assurance without relying on a specific mobile platform, or for enterprise users with strict security requirements.
Hardware keys do not sync; if lost, the user must use another enrolled method or contact LuxID for recovery.
Resident vs. non-resident keys
LuxID uses resident keys (also called "discoverable credentials") by default. A resident key stores the user identifier on the authenticator itself, enabling true passwordless flows where the user is not prompted for an email address before the passkey assertion. The user is identified by the passkey.
Token claims
amr claim
When a user authenticates with a passkey, the ID Token contains:
{
"amr": ["fido"]
}
"fido" is the amr value LuxID emits for a WebAuthn / passkey (FIDO2) authentication. It is used for both platform authenticators (which involve device-bound hardware security elements) and roaming hardware keys.
In a password-plus-passkey flow (passkey as second factor):
{
"amr": ["pwd", "fido"]
}
acr claim
| Flow | acr value |
|---|---|
| Passkey only (passwordless) | "urn:luxid:acr:level:substantial" |
| Password plus passkey | "urn:luxid:acr:level:substantial" |
| Passkey plus LuxID Verified | "urn:luxid:acr:level:substantial" |
Full example ID Token (passwordless passkey)
{
"iss": "https://login.luxid.lu",
"sub": "a3f2c1d8-9b4e-4a2f-8c1d-3e7b9a2f1c4d",
"aud": "app_cfl_prod",
"iat": 1748477000,
"exp": 1748480600,
"auth_time": 1748477000,
"nonce": "p-8Qr3nCvR5",
"acr": "urn:luxid:acr:level:substantial",
"amr": ["fido"],
"email": "utilisateur@example.lu",
"email_verified": true,
"name": "Marie Dupont",
"given_name": "Marie",
"family_name": "Dupont"
}
Fallback behaviour
Passkeys are not yet universally available - some users may be on older devices or browsers without WebAuthn support, and some users may not have enrolled a passkey.
LuxID handles fallback automatically within Universal Login. The sign-in flow is email-first:
- After the user enters their email, LuxID checks whether a passkey is enrolled for that account.
- If a passkey is enrolled and the browser/device supports WebAuthn, LuxID presents a choice screen with "Login with Passkey" as the primary option and "Login with Password" as the secondary option.
- If the passkey ceremony fails (user cancels, device incompatible, user verification unavailable, browser error), LuxID falls back to password plus another enrolled MFA method (OTP or TOTP).
- If no passkey is enrolled, LuxID presents the password entry field directly - no choice screen is shown.
Your application does not need to handle these fallback cases. The amr claim in the resulting token will reflect whichever method actually completed.
amr: "fido"Design your access control around acr (the assurance level reached) rather than the specific method, unless you have a specific regulatory or contractual requirement for a particular factor type.
Enrolment
Users enrol passkeys in their LuxID Account (opens in a new tab) under the Security section. Enrolment is not initiated by Partner applications - it is a user-controlled account setting.
Partners can encourage passkey enrolment by:
- Linking users to https://www.luxid.lu/en/resources/passkeys (opens in a new tab) in their post-login onboarding flow
- Surfacing a banner when a user's session
amrdoes not include"fido", inviting them to enable passkeys
There is no authorisation request parameter that requests passkeys specifically or triggers a passkey-enrolment suggestion. LuxID's assurance model is level-based: requesting acr_values=urn:luxid:acr:level:substantial requires an MFA-level authentication, and LuxID satisfies it with whichever eligible method the user has enrolled (the accepted acr_values are agreed per Partner during onboarding).
Configuration
Passkeys are available to all LuxID users and all LuxID Applications without specific configuration. No Console change is required to allow passkey sign-in.
To encourage or require passkey use:
- Set the Application's minimum assurance level to Substantial with LuxID. This does not mandate passkeys specifically, but ensures any MFA (including passkeys) is required.
- Request
acr_values=urn:luxid:acr:level:substantialon a per-request basis for the same effect at runtime. There is no method-specific hint: LuxID chooses among the user's enrolled methods.
Passkeys cannot be disabled per Application. They are a user-level capability that LuxID exposes uniformly.
Security and privacy notes
User verification is required. LuxID sets userVerification: required in every WebAuthn ceremony. The user must prove ownership of the device via PIN, fingerprint, face scan, or equivalent local authenticator - possession of the device alone is not sufficient. This is stricter than the WebAuthn preferred mode used by some other services.
Consequence: devices that cannot perform user verification are not compatible with LuxID's passkey sign-in. This includes FIDO2 hardware keys that have no PIN configured, and devices where the platform authenticator is disabled or unavailable. Users on incompatible devices fall back to the password flow automatically; see Fallback Behaviour above.
Private key never leaves the device. The passkey's private key is generated and stored on the user's device hardware or synced credential store. LuxID holds only the public key. Even a full compromise of LuxID's database would not expose passkey private keys.
Origin binding prevents phishing. Passkey assertions are cryptographically bound to login.luxid.lu. A passkey registered on LuxID cannot be used to authenticate on any other domain. This is a fundamental security property of the WebAuthn standard, not a configuration option.
Synced passkeys carry cross-device risk. If a user's iCloud or Google account is compromised, an attacker could potentially access synced passkeys. LuxID's risk scoring evaluates device and session signals at sign-in to detect anomalous passkey usage. See Security signals and risk scoring.
amr: "fido" does not distinguish platform from roaming authenticators. The claim does not indicate whether a synced passkey or a hardware key was used. If your application requires hardware-key-only access (for example, for privileged administration), contact LuxID to discuss advanced assurance requirements.
GDPR. The passkey public key is a personal data item (it uniquely identifies the user's credential). LuxID stores it as part of the user account and applies standard data protection controls. Partners do not receive or store passkey public keys.