Frequently asked questions
If you are an account holder rather than an integrator, see the LuxID user help instead.
Onboarding and access
How do I become a LuxID Partner?
Contact LuxID to begin the onboarding process. The LuxID team will walk you through the LuxID Agreement, data processing terms, and technical requirements before issuing credentials. For a full description of the onboarding journey, see Service provider onboarding.
How do I get UAT credentials?
UAT credentials are issued during onboarding alongside, or shortly before, Production credentials. If you already have a Production Client ID but need UAT access for testing a new feature, email LuxID with your Application name and a brief description of what you plan to test. The UAT environment is available at https://login-uat.luxid.lu (opens in a new tab).
Is there a cost to integrating LuxID?
Pricing is determined during the Partner onboarding negotiation and depends on the nature of your Application, expected volume, and the services you enable (for example, LuxID Verified or LuxID Pro). Contact LuxID for details.
Can a small business integrate LuxID?
Yes. LuxID is available to any organisation - large or small - that operates a service relevant to users in Luxembourg and can meet the LuxID Agreement requirements. The onboarding process is the same regardless of organisation size. See Service provider onboarding for eligibility details.
Do I need a separate client ID for each of my Applications?
Yes. Each concrete product (Application) that authenticates users via LuxID requires its own Client ID and redirect URI registration. This also controls which Sphere the user's sub is drawn from, so mixing applications under one Client ID has downstream consequences for pseudonymisation. See Concepts for the Organisation - Partner - Application - Sphere model.
Protocol
Does LuxID support the implicit flow?
No. The implicit flow is deprecated in OAuth 2.0 Security Best Current Practice (RFC 9700) (opens in a new tab) and is not supported. Use the Authorization Code flow with PKCE (code_challenge_method=S256). See OpenID Connect for the recommended flow.
Does LuxID support the client credentials grant?
Not on the user-facing OIDC tenant. The client credentials grant is a machine-to-machine flow that does not involve a user, so it does not apply to the authentication IdP. If you need M2M access to LuxID Partner APIs (for example, Console management APIs), contact LuxID for details on the Partner API.
Does LuxID support pushed authorisation requests (PAR) or JAR?
Not currently. PAR and JAR provide additional security for high-assurance flows, but the LuxID production discovery document advertises neither a pushed_authorization_request_endpoint nor request_object_signing_alg_values_supported, so they are not available today. If your integration needs them, contact LuxID, and re-check the discovery document at https://login.luxid.lu/.well-known/openid-configuration before building against them. See Advanced security options for more detail.
Does LuxID support the device authorisation flow?
Not currently. The production discovery document advertises neither a device_authorization_endpoint nor the urn:ietf:params:oauth:grant-type:device_code grant type, so the device authorisation flow (RFC 8628) is not available today. Contact LuxID if your use case requires it (for example, a smart-TV or CLI application), and re-check the discovery document before building against it. See OpenID Connect for supported grant types.
Which signing algorithm does LuxID use for ID tokens?
LuxID signs ID tokens with RS256 (RSA signature with SHA-256). The public keys are published at the JWKS endpoint (https://login.luxid.lu/mga/sps/oauth/oauth20/jwks/OIDC-LUXID) and rotate periodically. Always fetch keys dynamically from the JWKS endpoint rather than hardcoding them. See Key management for rotation guidance.
What token-endpoint authentication method does LuxID use?
Confidential clients (server-side web applications and backend services) authenticate to the token endpoint using a Client Secret provisioned when the Application is registered. Send it as client_secret_post (body parameter) or client_secret_basic (HTTP Basic Auth header). See Client credentials for rotation guidance.
Does LuxID support SAML 2.0 as well as OIDC?
Yes. LuxID supports SAML 2.0 for integrations with enterprise software that cannot use OIDC. OIDC is preferred for new integrations due to its simpler token model and better support for mobile and SPA use cases. See SAML 2.0 for configuration guidance.
Tokens and sessions
How long do tokens last?
Access tokens are short-lived, ID tokens last about an hour, and refresh tokens are long-lived. You can read the exact access-token lifetime from the expires_in field in the token response and from the exp claim in the access and ID tokens; the refresh-token lifetime is not returned in the response, so ask LuxID if you need the exact value. Do not hardcode lifetimes - drive renewal from the tokens' exp and exchange the refresh token before expiry rather than prompting the user to re-authenticate. See Session management for refresh patterns.
Do refresh tokens rotate on use?
Yes - always. Every refresh exchange returns a new refresh token and immediately revokes the previous one. Your server must store the new refresh token from each response and discard the old one, and you must serialise concurrent refresh attempts: if two requests use the same refresh token in parallel, one succeeds and the other gets invalid_grant, forcing an interactive login. See Session management.
How do I sign a user out?
Always clear your own application session. LuxID does not expose an OIDC end_session_endpoint and does not implement RP-Initiated Logout - as the shared SSO authority for many Partners, it does not let one application terminate the session others rely on. If the user explicitly wants to end their LuxID session too, redirect them to https://login.luxid.lu/auth/logout?client_id=<your_client_id>; LuxID shows a confirmation screen naming your application and the user decides. If you only clear your local session, the user keeps a valid LuxID cookie and may be silently re-authenticated on the next authorisation request. See Session management and Token revocation for full guidance.
What happens after a long idle period?
If the user's LuxID session has expired and your application attempts a silent re-authentication (for example, with prompt=none), LuxID will return an interaction_required error. Your application should then redirect the user to the authorisation endpoint for an interactive login. See Session management for how to handle session expiry gracefully.
Can I store the Refresh Token in browser localStorage?
No. Storing refresh tokens in localStorage exposes them to XSS attacks. In browser-based SPAs, use a backend-for-frontend (BFF) pattern that keeps the refresh token server-side and issues short-lived session cookies to the browser. If a BFF is not feasible, see Protect your Application for token storage best practices.
Can I use the Access Token to call the UserInfo endpoint?
Yes. Present the access token as a Bearer token in the Authorization header when calling https://login.luxid.lu/mga/sps/oauth/oauth20/userinfo. The endpoint returns the claims the user consented to share. Note that some claims (for example, birthdate) are only returned if you requested the relevant scope and the user has completed identity verification. See OpenID Connect for the full UserInfo response reference.
Identity and claims
Can I get the user's national ID number or Luxembourg eID card number?
No. LuxID does not expose national identity numbers or physical document identifiers to Partners. If your use case requires identity proofing at that level, contact LuxID to discuss LuxID Verified and the available assurance levels.
Can I get a verified email address?
Yes. The email_verified claim is included when you request the email scope. A value of true means LuxID has confirmed the address via an activation link. You should still treat email addresses as changeable over time and not use them as a permanent user identifier - use sub instead.
What is sub and why does it differ between my Applications?
sub is a pseudonymous user identifier scoped to a Sphere. LuxID uses Spheres to prevent cross-application user tracking: the same user will have a different sub in each Sphere. Applications that belong to the same Sphere share the same sub for a given user, which allows you to correlate accounts within your Organisation without exposing the user's identity to unrelated Partners. See Roles in the ecosystem for the full model.
Why did the sub change for the same user?
The sub can change in two scenarios. First, the Application was moved to a different Sphere (an administrative change). Second, the user revoked consent for your Application, was the last application in the Sphere with that consent, and later re-consented - in some configurations this may generate a new pairwise sub. If you observe unexpected sub changes in production, raise a ticket at LuxID with the affected Application name and timestamps.
Can I get the user's postal address?
Postal address is available via a Claim Template that your Application must be subscribed to. Contact LuxID during onboarding to request this enrichment. The claim follows the OpenID Connect Core address claim structure (opens in a new tab). See Attribute enrichment for available Claim Templates.
Can I get LuxTrust-verified attributes?
Yes, via LuxID Verified. When a user has completed LuxTrust-based identity verification, additional attributes (for example, verified given_name, family_name, and birthdate) are available if your Application is authorised to receive them and the user consents. See LuxID Verified for the full attribute list and the luxid_verified claim.
What scopes should I request for a basic sign-in?
For a typical "Sign in with LuxID" flow, request openid profile email. Only add offline_access if you need a refresh token. Note that in LuxID the scope parameter does not control which claims you receive (see the next entry).
I requested the profile (or email, phone) scope but a claim is missing - why?
In LuxID, the scope parameter does not gate claim release. What you receive is governed by your Application's Claim Template, configured on the LuxID side. Adding a scope does not unlock a claim that is not in your Claim Template. A claim can be absent for three reasons: it is not in your Claim Template (the most common - request a Claim Template update via contact), the user did not consent to it, or the user simply has not provided that attribute (LuxID uses a progressive profile, so optional attributes are often empty). See Roles in the Ecosystem - Claim Template and Consent and Tokens and Claims - Requesting claims.
MFA
Can I require MFA from my Application?
Yes. Pass acr_values in the authorisation request to require a minimum auth_level. For example, acr_values=urn:luxid:acr:level:substantial requires the user to have completed a second factor; the accepted request values are agreed per Partner during onboarding. If the user's current session does not satisfy the requested level, LuxID will step up authentication before issuing tokens. See OpenID Connect and Authentication levels.
What happens if the user has no second factor enrolled?
If your Application requests a substantial or high assurance level and the user has no eligible second factor enrolled, LuxID will present the user with an enrolment prompt during the authentication flow. The available second factors are One-Time Codes (SMS or voice call), authenticator apps (TOTP), passkeys, and LuxTrust. The user must enrol at least one before they can complete sign-in.
Can I require a specific MFA method (for example, passkeys only)?
Not directly via a standard parameter. LuxID's assurance model is level-based rather than method-based: you request an assurance level and LuxID enforces it using whichever method the user has enrolled. If your Application has a contractual or regulatory requirement for a specific method, discuss it during onboarding. See Authentication levels for the mapping between methods and levels.
Does LuxID support step-up authentication mid-session?
Yes. If a user is already signed in at a low assurance level and navigates to a protected area of your Application that requires a higher level, redirect them to the authorisation endpoint with the appropriate acr_values. LuxID will present the additional factor challenge without requiring a full re-login if the base session is still valid.
LuxID Verified
What does "LuxID Verified" mean?
LuxID Verified indicates that the user has completed an identity proofing step - typically via LuxTrust - that links their LuxID Account to a real-world identity. A verified user has had their legal name, date of birth, and (where applicable) national identity confirmed against an authoritative source. This is distinct from simply having an active LuxID Account.
How do I require a verified identity for my Application?
Request the luxid_verified claim as essential in the claims parameter of your authorisation request:
{
"id_token": {
"luxid_verified": { "essential": true }
}
}
If the user has not yet completed verification, LuxID will prompt them to do so during the authentication flow. See LuxID Verified for the full claims request syntax and returned attributes.
Which assurance level does LuxID Verified imply?
LuxID Verified reaches Substantial - not High. The LoA is declared by LuxTrust (the identity proofing source) and relayed by LuxID to Partners via the luxid_verification_level claim. High assurance (auth_level 9) requires LuxTrust used as an MFA method, not identity proofing alone. See Authentication levels for the full model.
Is LuxID Verified required for all Applications?
No. Most commercial integrations (sign-in, personalisation, subscription management) do not require identity verification and should not request it - doing so creates unnecessary friction for users. LuxID Verified is intended for use cases with a genuine legal or regulatory requirement for identity proofing, such as age-restricted services or financial applications.
LuxID Pro
Can my company's employees sign in with their corporate credentials?
Yes, via LuxID Pro. LuxID Pro is an enterprise federation service that allows your organisation's identity provider (for example, Azure AD or an on-premises Active Directory with ADFS) to be federated with LuxID. Employees authenticate with their corporate credentials and receive a LuxID session. Contact LuxID to begin a LuxID Pro onboarding. See LuxID Pro for the architecture overview.
How do I federate Active Directory via LuxID Pro?
The technical configuration depends on your on-premises setup. LuxID Pro supports SAML 2.0 and OIDC federation. During the LuxID Pro onboarding, LuxID will provide metadata and configuration requirements. You will need to register LuxID as a trusted SAML SP or OIDC RP in your Active Directory Federation Services or Azure AD tenant. See LuxID Pro for prerequisites.
What corporate claims are released via LuxID Pro?
When a user authenticates through LuxID Pro federation, the luxid_federation_realm claim carries the federation realm (the routed email domain, e.g. post.lu) and the luxid_organization claim carries the user's organisational identifier. Standard OIDC claims (email, given_name, family_name) are also released if your corporate IdP provides them. The exact claim mapping is configured during LuxID Pro onboarding. See LuxID Pro.
Can LuxID Pro restrict which Partner Applications employees can access?
Yes. Organisations using LuxID Pro can configure an allowlist of Partner Applications that their employees are permitted to authenticate to. This means an employee attempting to sign in to an Application outside the organisation's approved list will be blocked at the LuxID layer. This feature is managed via LuxID by the organisation's administrator.
Compliance
Is LuxID GDPR-compliant?
Yes. LuxID is operated by POST Luxembourg and processes personal data in accordance with the General Data Protection Regulation (Regulation (EU) 2016/679 (opens in a new tab)). As a Partner, you and POST Luxembourg each have defined roles (controller and/or processor depending on the data flow). See GDPR and data protection and Legal agreements and templates.
Where is user data stored?
User data is processed and stored within the European Union, and LuxID does not transfer personal data outside the EU. Some tasks (such as sending SMS, voice calls and emails) are handled by sub-processors that receive only the data needed for that task - for example a destination number or email address - under a GDPR data-processing agreement, and process it within the EU; LuxID does not store or manage your account on their platforms. See GDPR and data protection for the data residency commitments.
Is LuxID aligned with the eIDAS regulation?
LuxID's auth_level scale is structurally aligned with the eIDAS Low / Substantial / High rationale (Regulation (EU) No 910/2014 (opens in a new tab)). LuxID is not a notified eID scheme and does not issue formal eIDAS LoA assertions - the alignment is a design principle, not legal equivalence. eIDAS LoA values appear in LuxID payloads only when relayed from a qualified upstream (LuxTrust identity verification, a federated IdP, or future EUDIW). The auth_level model and informal comparison with eIDAS tiers is documented in Authentication levels.
Is LuxID ISO 27001 certified?
Contact LuxID for the current certification status and scope. POST Luxembourg operates under a rigorous information security management framework; certification details are available on request during Partner onboarding.
Do I need a separate data processing agreement (DPA) with LuxID?
No. LuxID and the Partner each act as independent data controllers, so there is no Article 28 processor relationship and no separate DPA to sign. The data protection framework is built into the LuxID Agreement itself. See GDPR and data protection and Legal agreements and templates for the controller-to-controller model and why no DPA is required.
Can I use LuxID as the sole means of identity verification for regulated activities?
This depends on the regulatory framework governing your service and the assurance level you request. LuxID Verified reaches Substantial; High requires LuxTrust (auth_level 9). Contact LuxID and your own compliance team to confirm whether LuxID meets your specific regulatory requirements. See Trust framework for LuxID's certification and accreditation status.
Operations
How do I rotate my client secret?
Client secret rotation is managed by LuxID. Contact us to request a rotation; you will have a short overlap window during which both the old and new secrets are valid, so you can deploy the new secret without downtime. See Client credentials for the field reference.
How do I see who has signed in to my Application?
LuxID provides authentication logs for your Application. You can filter by time range, user (by sub), and outcome. Logs are retained for a period defined in the SLA. For programmatic access to authentication events, see Events and Event Hub, which supports webhook delivery and SIEM integration.
How do I subscribe to LuxID events?
LuxID provides an Event Hub. Today it emits a single event type, ClaimValuesChanged, over a pull model - it tells your Application that a user changed one or more of the claims you receive, so you can refresh your stored copy. A broader catalogue (logins, failed attempts, user consent changes, account deletion) and signed-webhook push delivery are planned but not yet available. See Events and Event Hub for the current state and the planned schema.
What do I do if my redirect URI is being rejected?
The most common cause is a mismatch between the URI in your authorisation request and the exact URI registered with LuxID - scheme, host, port, and path must all match exactly, including trailing slashes. Check the Console registration for your Application and ensure your authorisation request sends the exact same string. See OAuth Error Codes for the redirect_uri_mismatch error and resolution steps.
How do I report a security incident?
Email LuxID immediately with the subject line "Security Incident - [your Application name]". Include any on-screen identifiers, timestamps, and a description of the observed behaviour. For vulnerability disclosure in LuxID itself (not your own Application), see Contact and support channels.
What is the support SLA?
Response and resolution SLAs depend on your support tier and incident severity. See SLA and support for the full SLA table including response time commitments per severity level.
How do I check whether LuxID is currently experiencing an incident?
LuxID does not currently operate a public status page. During a declared incident, LuxID notifies the registered Partner technical contacts by email. If you suspect an incident, contact LuxID with the approximate time and any on-screen identifier from the error.