Register an Application

Planned - future LuxID Console

Self-service Application registration is on the LuxID roadmap. Today, you submit the fields below to LuxID and LuxID performs the registration. The structure of this page mirrors the future Console UI.

Overview

An Application is how LuxID represents a software product that integrates with it; each Application is registered separately in UAT and Production, with its own credentials and configuration.

Every software product that integrates with LuxID is represented as an Application in LuxID's registry. UAT and Production are completely independent environments - the same Application must be registered separately in each, and each registration has its own credentials and configuration.

Application registration is handled by LuxID. You submit the information described on this page to LuxID, and LuxID creates the Application and returns your Client ID and Client Secret.

For background on the LuxID domain model, see Roles in the ecosystem.

How to request a new client Application

To request a new Application registration in LuxID, submit the following information to LuxID. Required fields gate go-live; optional fields enhance functionality.

Application details (required)

These fields are used on various LuxID pages - the consent screen, the account dashboard, and audit logs.

Field	Used for	Example / constraints
Name	Application display name on consent screen and account dashboard	"My awesome app"
Logo	Visual identity on consent and account screens	Square logo, .png or .jpeg, min 64x64 px, transparent background allowed. Must work in both light and dark mode
Integration	Protocol type	One of OIDC, OAuth2, SAML
Public URL	Application's public landing page	https://www.myawesomeapp.com
Redirect URL(s)	Where LuxID sends the user after sign-in - one or several, exact match enforced	https://private.myawesomeapp.com or mobile schemes like myapp://mobile/callback
Administrative contact(s)	Operational / commercial point of contact	Name + email
Technical contact(s)	Engineering point of contact	Name + email

Redirect URLs are enforced exactly: LuxID will reject any redirect to a URI not on the registered list. Mobile app schemes (custom URI schemes) are supported. Register separate redirect URIs for UAT and Production - they are independent registrations.

Application agreements (optional)

LuxID can track your Application's agreements (Terms and Conditions, Privacy Policy, etc.) and ask the user to accept them at first sign-in. This is optional - if you do not need centralised agreement tracking, skip this section and link to your own T&C / Privacy pages from your application UI instead.

If you opt in, all three fields below are required for every language you want to support. LuxID's UI currently displays agreement prompts in English (EN), French (FR), German (DE), and Luxembourgish (LB).

For each agreement (typically: one T&C entry, one Privacy Policy entry):

Field	Used for	Example
Agreements text	The acceptance text shown above the agreement link, per language	EN: "I agree that I have read and approved the". FR: "Je certifie avoir lu et accepté les". DE: "Ich stimme zu, dass ich folgendes gelesen und akzeptiert habe:". LB: "Ech bestätegen datt ech folgendes gelies an acceptéiert hunn:"
Agreements URL display text	The clickable link label, per language - use the regulator-friendly localised noun	EN: "Terms and Conditions" or "Privacy Policy Statement". FR: "Conditions Générales d'Utilisation" or "termes sur la politique en matière de respect de la vie privée". DE: "die Allgemeinen Geschäftsbedingungen" or "die Datenschutzerklärung". LB: "d'Conditions Générales" or "d'Dateschutz-Bestëmmungen"
Agreements URL link	The actual URL of the agreement page, per language	https://www.myawesomeapp.com/terms?lang=EN or https://www.myawesomeapp.com/privacy?lang=FR

LuxID stores the user's acceptance per agreement version and re-prompts on version change. See Privacy and consent.

Shared user claims (optional)

If your Application requests user information, the user is prompted for consent at first sign-in. That information is then injected into the ID Token as claims. Only claims the user consented to share are present.

LuxID supports a subset of the OIDC standard claims (opens in a new tab):

sub (always injected), name, given_name, family_name, email, email_verified, gender, birthdate, phone_number, phone_number_verified, address, updated_at.

For each claim you want to request, specify:

Field	Used for	Example
Wanted user claims	The list of OIDC standard claims you need	name, email, phone_number
User claim essential / optional	Per OIDC Core 1.0 §5.5 (opens in a new tab), whether the claim is essential or optional	name: essential, gender: optional
User claim hint label	Optional per-claim hint shown on the consent screen, explaining the restriction or usage	phone_number: "MyAwesomeApp is only available for Luxembourg phone numbers"

LuxID reviews and approves each requested claim against data minimisation principles. Requests for sensitive claims (birthdate, address, etc.) require a clearly stated purpose.

Practical note

Request only the claims you will actively use in the first version of your Application. Adding claims after go-live triggers a re-review. At runtime, the scope and claims parameters in your authorisation request can only narrow the approved set - you cannot request claims outside it.

Shared technical claims (optional)

Technical claims carry application-specific data into the token without a user consent prompt. They are invisible to the user. Use cases include internal correlation IDs, partner-side flags, and migration shims.

Field	Used for	Example
Wanted technical claims	The list of custom technical claim names	Custom per Application

Notes:

• All technical claims are always optional - returned only if a value has been set on the Subscription.
• New technical claim definitions require LuxID team review and approval before activation.
• For Partners migrating from legacy PostID: the legacy technical claims you used (such as entityId) are still supported but renamed in LuxID. Coordinate the renaming map with LuxID during migration.

Technical claim values are read and written via the Partner API (PUT/DELETE on /subscribers/{subscriberExtId}/claims/{claimName}).

Access rules (optional)

Access Rules are configured under the Access Rules area for the Application, with three sibling panels - any combination of them can be enabled per Application:

• Auth requirements - the minimum auth_level the user must reach.
• Guard rule - a condition evaluated before the consent and terms screen.
• User rule - a condition evaluated after the user has accepted the consent screen.

All three are optional. Applications without any Access Rule entries accept any authenticated user.

Auth requirements

The minimum auth_level LuxID requires before completing the sign-in to your Application. LuxID assigns every completed authentication a numeric auth_level reflecting the strength of the factors presented - this is LuxID's own classification scale; see Authentication levels for the scale values and their informal comparison with eIDAS strength tiers.

The confirmed scale:

auth_level	Authentication method	Implementation status
0	Unauthenticated (no minimum)	Available as a minimum setting
1	Kerberos / loginless	Not implemented in LuxID
2	Password only	Implemented
3	Password + OTP via SMS / voice	Implemented
4	Password + TOTP (authenticator app)	Implemented
6	MFA fingerprint	Not implemented in LuxID
8	Passkey (WebAuthn / FIDO2)	Implemented
9	LuxTrust	Implemented

Levels 1 and 6 are reserved in the scale but not currently implemented in LuxID.

The Console UI presents these as labelled options rather than raw integers. The numeric value is recorded against each authentication event for audit and analytics, and is also held against the Application in the two configuration fields below.

Default minimum auth_level - the static minimum auth_level any user must achieve to sign in to this Application. If the user's current session was established at a lower level, LuxID steps them up before completing the authorisation. Example: a banking Application sets its default minimum to 9 to force LuxTrust for every sign-in.

Per-action escalation rules - step-up rules attached to specific operations within the Application. Each rule maps a named action to a minimum auth_level. The default minimum still applies to the initial sign-in; per-action rules trigger when your Application explicitly requests step-up at runtime. Example: a payment portal sets the default minimum to 3 (password + OTP for everyday access) plus a per-action rule approve_transfer = 9 (LuxTrust required at the moment of the payment). This keeps everyday sign-in frictionless while enforcing strong authentication only at high-risk moments.

Runtime interaction with acr_values. At runtime you can also request a minimum via the acr_values parameter on the authorisation request. The effective minimum is the higher of the Application's configured default minimum and any acr_values value in the request. You cannot use acr_values to bypass the configured minimum.

Guard rule

A condition evaluated before the consent and terms screen. If the user fails the Guard rule, they are blocked immediately and never see the claim list - the rejection is invisible-by-design. Use this when eligibility must be checked before exposing anything about the Application to the user (for example, "only allow sign-in from the corporate IP range", "only allow phone numbers from a given country").

A Guard rule is built from:

• Base rules - atomic conditions. Examples available out of the box:
  • minimumAge - user must be older than a specified age (based on the birthdate held in LuxID)
  • ipAddressEquals - user must connect from a specified IP address
  • phoneNumberCountry - user must have a phone number of a specified country
  • Group-membership, has-LuxTrust, phone-number-validated, and similar base rules are also supported.
• Composing rules - combine base rules with boolean operators:
  • anyOf - logical OR
  • allOf - logical AND
• A worked example: anyOf of [phoneNumberCountry: LU validated, has LuxTrust, member of the VIP Group].

Requesting additional base rules beyond the available catalogue is possible but subject to LuxID team review and timing.

Custom error message (Optional) - for the Guard rule, you can provide a custom error message shown to the blocked user. Use this to explain why access was denied and what the user can do next. Example: "This service is only available to Luxembourg residents. If you have moved, please update your address at https://account.luxid.lu/ (opens in a new tab)."

User rule

A condition evaluated after the user has accepted the consent screen. Suitable for finer-grained gating once the user has agreed to share their data with the Application - for example, "the consenting user must be a member of the VIP Group, otherwise show an explanatory error". The User rule uses the same base + composing primitives as the Guard rule, and also supports a custom error message.

For the conceptual model behind Access Rules, see Roles in the ecosystem and Learn the Basics / Authorisation.

Application lifecycle states

Applications can be in one of three states:

State	Behaviour
Active	Authentication flows proceed normally.
Suspended	New authentication attempts are blocked. Existing sessions are not terminated. LuxID returns an error to the user. Use during incident response.
Decommissioned	All flows permanently blocked. Application cannot be reactivated. Use when a product is retired.

To change the state of an Application, contact LuxID or use the Status control in the Console Application overview panel if available. Suspension and decommissioning are immediate.

Next steps

• Understand redirect URI rules before submitting: Redirect URIs and domains.
• Store and rotate your Client Secret safely: Client credentials.
• Set up a UAT environment before going live: Environments.
• Customise how your Application appears on the consent screen: Branding configuration.