Concepts and fundamentals
Developers and architects before writing integration code; security officers reviewing the trust model, assurance levels and token semantics; product owners who need the shared vocabulary - especially Privacy and consent, which frames the consent friction your users will see.
About this section
This section is the vocabulary layer of the LuxID developer documentation. Before writing a single line of integration code, every architect, developer, and security engineer on your team should share the same understanding of:
- what LuxID is and is not (a shared sovereign identity service that Partners federate to, not a CIAM platform on which each customer operates their own tenant),
- the entities that make up the LuxID ecosystem (Users, Partners, Applications, Spheres, Subscriptions),
- the open standards that govern every protocol interaction (OIDC, OAuth 2.0, SAML 2.0, WebAuthn/FIDO2), and
- the trust and privacy obligations that come with requesting user data.
Nothing here is implementation-specific. You will find concrete code, endpoints, and library guidance in later sections. This section gives you the conceptual foundation those sections assume.
What LuxID is
LuxID is a shared sovereign identity service: one identity authority used by many Relying Parties (LuxID Partners), who integrate with it but do not operate their own tenant.
LuxID is a Luxembourgish digital identity provider operated by POST Luxembourg under delegation from a LuxID E.I.G. whose members are POST Luxembourg, RTL, Cactus, and CFL. It provides secure, standards-based authentication and identity assertion to services - LuxID Partners, in any sector - that integrate with it via OIDC, OAuth 2.0, or SAML 2.0.
LuxID is a shared sovereign identity service: one identity authority used by many Relying Parties. The closest architectural analogues are consumer-style hosted identity services - one provider, many integrating applications, no tenant customisation. This is fundamentally different from CIAM platforms on which each customer configures and operates their own identity stack. LuxID Partners integrate with LuxID; they do not need to manage tenants, authentication policies, MFA orchestration, signing keys, or login UX - LuxID does the heavy lifting and exposes a standards-based integration surface.
See LuxID onboarding for an executive overview of the integration journey.
Pages in this section
Identity fundamentals
Covers authentication, authorisation, and auditing (the AAA triad); the distinction between federation and delegation; why sessions and tokens are different kinds of trust artefact; why LuxID uses open standards; and a practical introduction to JSON Web Tokens (JWT).
Read this if: you are new to identity or need a refresher on the terminology that appears throughout the rest of the docs.
Roles in the ecosystem
Defines every entity in the LuxID domain model: User, Organisation, Partner, Application, Sphere, Subscription, Group, Claim Template, Consent, and Federation. Includes an entity-relationship diagram and worked examples of Sphere-based pseudonymisation.
Read this if: you are designing an integration, planning your application's data model, or need to understand how LuxID isolates user identities across partners.
Authentication levels
Defines LuxID's auth_level scale (LuxID's own authentication-strength classification), how it maps informally to the eIDAS framework (Commission Implementing Regulation (EU) 2015/1502, CELEX:32015R1502 (opens in a new tab)), and how eIDAS LoA values from qualified upstreams (LuxTrust, federated IdPs, future EUDIW) are relayed and mapped to auth_level. Explains the acr_values request mechanism and when your application should require each level.
Read this if: your application handles sensitive operations or needs a specific authentication strength for certain actions - for example, age verification or requiring a stronger factor before a protected action.
Tokens and claims
Deep treatment of the ID Token, Access Token, and Refresh Token: purpose, structure, signing algorithm, validation rules, storage guidance, and expiry handling. Covers every claim in LuxID's claims_supported list with format and example values. Explains acr and amr values and includes a decoded JWT example.
Read this if: you need to understand what LuxID returns after a successful authentication and what you are permitted to do with it.
Privacy and consent
Covers LuxID's privacy posture: data minimisation, explicit user consent, the consent lifecycle, the relationship between Spheres and user correlatability, GDPR alignment, and the transparency obligations that fall on your application as a LuxID Partner.
Read this if: you are a security officer, data protection officer, or architect responsible for GDPR compliance.
Mapping identities to your application
Explains how to connect LuxID to your application: link users on the stable sub, keep your own internal user ID, choose an onboarding strategy (just-in-time, pre-provision by email, or invitation code), and design the IdP as a pluggable, interchangeable component.
Read this if: you are designing or building a LuxID Partner application and need to decide how LuxID users map to your own user records.
Key terms
The following terms appear throughout the LuxID developer documentation. Each is defined in full in the page listed above.
| Term | Brief definition | Defined in |
|---|---|---|
| User | A person with a LuxID Account, identified by their email address | Roles |
| Identity | The set of verified attributes LuxID can assert about a User | Identity fundamentals |
| Partner | A unit of API access; holds client credentials; one Organisation may have multiple Partners | Roles |
| Application | A concrete software product (website, mobile app, kiosk) belonging to a Partner | Roles |
| Sphere | A pseudonymisation domain; Applications in the same Sphere share the same sub for a given User | Roles |
| Subscription | A User's connection to an Application, created on first consent and terminated on revocation | Roles |
| Group | An authorisation grouping inside a Partner that conveys roles to Applications | Roles |
| Claim | A single piece of user data (e.g. email, given_name) asserted by LuxID in a token | Tokens and claims |
| Consent | A User's explicit agreement to release specific claims to a specific Application | Privacy and consent |
Authentication Level (auth_level) | LuxID's numeric authentication-strength scale (2/3/4/8/9). The acr claim in the ID Token conveys this classification; it is not a formal eIDAS LoA assertion. | Authentication levels |
| ID Token | A signed JWT asserting the User's identity; consumed by the Application, not APIs | Tokens and claims |
| Access Token | A credential authorising calls to the UserInfo endpoint; short-lived | Tokens and claims |
| Refresh Token | A long-lived credential used to obtain new Access Tokens silently | Tokens and claims |
| Federation | A trust relationship allowing a corporate IdP (via LuxID Pro) to sign Users into LuxID | Roles |
| LuxID Pro | The enterprise federation service for organisations whose users authenticate via their corporate IdP | Roles |
| LuxID Verified | Identity attribute verification via LuxTrust, confirming name and date of birth. Reaches Substantial (the LoA is issued by LuxTrust and relayed by LuxID). | Authentication levels |