Generic OIDC setup
When to use this page
Use this page when your tool asks for "OpenID Connect provider details" or "OIDC IdP configuration" and is not covered by a dedicated guide in Tool-specific integrations.
This page is also useful as a reference tab while working through any tool-specific guide.
Discovery URL (recommended first step)
Most modern tools support auto-configuration via a discovery URL. Paste this into any field labelled "Discovery URL", "Well-Known Configuration URL", "OIDC Issuer", or "OpenID Configuration Endpoint":
https://login.luxid.lu/.well-known/openid-configuration
The discovery document returns all endpoint URLs, supported scopes, supported claims, token signing algorithms, and JWKS location in a single JSON response. Tools that support auto-configuration will populate every other field automatically.
UAT (sandbox) discovery URL:
https://login-uat.luxid.lu/.well-known/openid-configuration
Use the UAT URL during testing. Switch to the production URL before going live.
Issuer
The LuxID issuer value is:
https://login.luxid.lu
Some tools use "Issuer" and "Discovery URL" interchangeably. If the tool asks for both, enter https://login.luxid.lu as the issuer and the full discovery URL (https://login.luxid.lu/.well-known/openid-configuration) as the configuration endpoint.
Individual endpoints
Use these if your tool does not support discovery or requires manual endpoint entry.
| Endpoint | URL |
|---|---|
| Authorisation | https://login.luxid.lu/mga/sps/oauth/oauth20/authorize |
| Token | https://login.luxid.lu/mga/sps/oauth/oauth20/token |
| UserInfo | https://login.luxid.lu/mga/sps/oauth/oauth20/userinfo |
| JWKS (public keys) | https://login.luxid.lu/mga/sps/oauth/oauth20/jwks/OIDC-LUXID |
| Introspection | https://login.luxid.lu/mga/sps/oauth/oauth20/introspect |
| Revocation | https://login.luxid.lu/mga/sps/oauth/oauth20/revoke |
What each endpoint does
- Authorisation - the URL the user's browser is redirected to. LuxID renders the login page here
- Token - your tool's back-end calls this to exchange the authorisation code for ID token, access token, and optionally a refresh token
- UserInfo - your tool's back-end calls this (with the access token) to retrieve user claims that were not included in the ID token
- JWKS - your tool fetches the public keys from here to verify the signature on ID tokens
- Introspection - allows your back-end to check whether an access token is still active (requires client credentials)
- Revocation - allows your back-end to invalidate an access token or refresh token before it expires
UAT equivalents: replace login.luxid.lu with login-uat.luxid.lu in every URL above.
Scope parameter
The released set of claims is pinned in your Application's Claim Template on the LuxID side, not driven by the scope parameter at runtime. The scope parameter is still required by the OIDC spec (you must include openid), but LuxID does not gate claim release on it. To add a new claim, request a Claim Template update from LuxID. See Tokens and Claims - Requesting claims for the full explanation.
Send openid profile email (plus offline_access for a refresh token) in the "Scopes" or "Requested Scopes" field:
| Scope | Effect on LuxID |
|---|---|
openid | Required by OIDC. Without it the request is rejected. |
profile | No effect on claim release. Send for spec compatibility. |
email | No effect on claim release. Send for spec compatibility. |
phone | No effect on claim release. Send for spec compatibility. |
offline_access | Has effect: issues a long-lived refresh token. Only request this if your tool manages long-lived sessions. |
Recommended minimum: openid profile email. Add offline_access if you need a refresh token.
What you receive is whatever the Claim Template assigned to your Application releases. If phone_number is missing and you expect it, the fix is a Claim Template update, not a scope change.
Supported response types and grant types
| Parameter | Supported values |
|---|---|
response_type | code, none |
grant_type | authorization_code, refresh_token |
code_challenge_method | S256 (PKCE) |
LuxID uses the authorisation code flow (response_type code). Tools that support PKCE should send code_challenge and code_challenge_method=S256 in the authorisation request. This is recommended for public clients (browser-based tools without a secure back-end).
Token lifetimes
| Token | Lifetime |
|---|---|
| ID token | ~1 hour |
| Access token | Short-lived |
| Refresh token | Long-lived |
Some tools display a "token expiry" or "session refresh interval" field. Set it to match the ID token lifetime (3600 seconds / 1 hour) unless your tool manages refresh independently.
ID Token signing
LuxID signs ID tokens using:
- Algorithm: RS256 (RSA with SHA-256)
- Key location: JWKS endpoint above
Your tool should fetch and cache the JWKS and rotate its cached keys when it encounters an unknown kid in a token header. Do not hardcode a public key.
Supported claims
These are the claims LuxID can release. Which claims are actually sent to your application depends on your Claim Template - configured by LuxID during onboarding.
| Claim | Scope required | Description |
|---|---|---|
sub | openid | Stable unique identifier for the user. Opaque string, not an email address |
email | email | User's email address |
email_verified | email | Boolean. true if LuxID has verified the email |
given_name | profile | First name |
family_name | profile | Family name / surname |
name | profile | Full display name (typically given_name + family_name) |
birthdate | profile | Date of birth in YYYY-MM-DD format |
updated_at | profile | Unix timestamp of last profile update |
phone_number | phone | Phone number in E.164 format |
phone_number_verified | phone | Boolean. true if LuxID has verified the phone number |
age_over_16 | profile | Boolean. Defined in the schema but not currently offered by LuxID |
Claim not arriving? The claim may be absent from your Claim Template. Contact us to request a Claim Template update.
Typical field mapping table
The following table shows how LuxID values map to the fields most tools expose in their OIDC configuration screen.
| Typical tool field label | Value to enter |
|---|---|
| OIDC Issuer URL / Provider URL | https://login.luxid.lu |
| Discovery / Well-Known URL | https://login.luxid.lu/.well-known/openid-configuration |
| Client ID | From LuxID Console |
| Client Secret | From LuxID Console |
| Redirect / Callback URL | Your tool's callback URL (must be whitelisted in LuxID Console) |
| Scopes | openid profile email |
| Response type | code |
| Grant type | authorization_code |
| Username claim / User identifier | sub (stable) or email (human-readable; use only if the tool allows email changes) |
| First name claim | given_name |
| Last name claim | family_name |
| Display name claim | name |
| Email claim | email |
| Email verified claim | email_verified |
| Token signing algorithm | RS256 |
| JWKS URI | https://login.luxid.lu/mga/sps/oauth/oauth20/jwks/OIDC-LUXID |
sub vs email as user identifier
Use sub as the primary user identifier if your tool supports it. sub is a stable, opaque identifier that does not change if the user updates their email address. If you use email as the identifier and a user later changes their email in LuxID, your tool may create a duplicate account.
Verification checklist
After configuring the tool, run through this checklist before going live.
- Discovery URL returns a valid JSON document when opened in a browser
- Redirect URI configured in the tool exactly matches the URI whitelisted in LuxID Console (no trailing slash difference, correct scheme)
- Test login with UAT (
login-uat.luxid.lu) completes without error - The following claims arrive in the tool after login:
sub,email,given_name,family_name - If
offline_accessis requested, a refresh token is issued and the tool uses it correctly - Switching from UAT to production (
login.luxid.lu) requires updating only the issuer and endpoints - Client ID and Client Secret remain the same (if you used the same Console application for both environments) or are swapped for production credentials - JWKS endpoint is reachable from the tool's server (check firewall rules if the tool is self-hosted)
Related pages
- Before you start - for prerequisites including Console registration
- Tool-specific integrations - per-tool field mapping
- Redirect URIs and domains - whitelisting callback URLs
- Client credentials - Client ID and Secret management
- Redirect and domain issues - troubleshooting common OIDC errors