Aller au contenu principal
Version 0.3Brouillon

Consent screen design

Overview​

The consent screen is the moment at which LuxID tells a user what information a partner application is requesting and asks them to approve it. It is the most important privacy touchpoint in the entire flow, and the one place where your application's name and logo appear on the LuxID-hosted interface.

Getting the consent screen right matters for two reasons:

  1. Trust - a consent screen with a clear application name, recognisable logo, and plain-language attribute descriptions gives users the confidence to proceed.
  2. Completion rate - a confusing, jargon-heavy, or visually inconsistent consent screen leads to abandonment.

The consent screen is composed of the following elements, in order:

  1. LuxID header - the LuxID logo and "Sign in to [Application Name]" heading.
  2. Application logo - your application's logo as configured with LuxID (optional but strongly recommended).
  3. Application name - the display name you set with LuxID.
  4. Attribute list - each claim your application has requested, displayed with a human-readable label.
  5. Accept button - "Allow" or equivalent in the user's language.
  6. Cancel link - "Cancel" or "Decline", which returns error=access_denied to your application.

Attribute labels: human-readable, not technical​

LuxID displays each requested claim with a human-readable label, not the raw OIDC claim name.

attention

Users must never see raw claim names like given_name, family_name, or email on the consent screen.

The following table shows the LuxID claim labels:

OIDC claimDisplayed label (EN)
openid(not displayed - required implicitly)
emailYour email address
email_verifiedWhether your email address has been verified
given_nameYour first name
family_nameYour last name
nameYour full name
birthdateYour date of birth
phone_numberYour phone number
addressYour postal address
localeYour preferred language
zoneinfoYour time zone

Optional vs required claims​

Claims fall into two categories:

  • Required claims - the application cannot function without them. The user must grant these or cancel the flow entirely.
  • Optional claims - the application would benefit from them but can function without them. The user may decline optional claims individually.

LuxID displays required and optional claims separately, with optional claims marked as such. Your application receives only the claims the user has approved.

As an application developer, you should request the minimum set of claims your application genuinely needs. Requesting address and birthdate for a service that only needs an email address is visible to users and damages trust.

Application name and logo guidelines​

Application name​

The application name appears prominently in the heading ("Sign in to [Name]") and at the top of the attribute list. Rules:

  • Use your product's public-facing name - the name your users know.
  • Do not use internal code names, technical identifiers, or names that include your parent company's name if it would confuse users (for example, "Auth Module v3" is not acceptable).
  • Maximum length: 64 characters.
  • The name must match your application's name as displayed elsewhere in your product.

The logo appears above the attribute list alongside the LuxID header.

  • Format: SVG preferred (crisp at any size), PNG accepted. Use a transparent background so the logo sits cleanly on either surface.
  • Recommended size: 120 x 40 px (3:1 aspect ratio) or square (100 x 100 px).
  • Make it work in both light and dark mode. The Universal Login, LuxID Account and consent screens follow the user's system colour-scheme preference, so the consent screen may render on a light or a dark background. Supply a logo that is legible on both - ideally an SVG that adapts (for example, using currentColor or a prefers-color-scheme media query), or a colour mark with enough contrast on both surfaces. Avoid a logo that only reads on white.
  • The logo must represent your organisation or product, not LuxID itself.
  • Do not submit a logo that could be mistaken for the LuxID logo.

If no logo is configured, the application name is displayed in text only.

Tone-of-language guidance for your Application description​

Some LuxID configurations allow a short application description to appear on the consent screen. If this feature is available for your integration, apply the following tone guidelines:

Write for the user, not the marketer​

The consent screen is not an advertising surface. Users are making a privacy decision, not reading a product pitch.

DoDon't
"RTL Play uses your name and email to personalise your account.""RTL Play is Luxembourg's #1 streaming platform - sign in to unlock premium content!"
"CFL uses your email address to send you booking confirmations.""CFL leverages your identity data to enhance your rail experience."
"POST uses your email address to manage your account.""POST Luxembourg - connecting people across the Grand Duchy for over 175 years."

Use plain language​

  • Avoid technical terms: no "OAuth", "OIDC", "JWT", "claims", "scopes".
  • Avoid legal language: no "pursuant to", "as per", "aforementioned".
  • Write at an 8th-grade reading level or below.
  • Use active voice: "We use your name to..." not "Your name is used by the application to...".

Be specific​

Vague descriptions are a red flag for users. "We may use your data for various purposes" is not acceptable. Be concrete:

  • "We use your email address to send you booking confirmations and account updates."
  • "We use your name to personalise your account and display it in the app."

The following table contrasts consent screen configurations:

ElementGood exampleBad example
Application name"RTL Play""RTL_OIDC_CLIENT_PROD_V2"
Application logoRTL Play logo, transparent background, correct aspect ratioLuxID logo (prohibited), or missing
Requested claimsemail, given_name, family_name for a streaming serviceemail, given_name, family_name, birthdate, address, phone_number for a streaming service
Optional claims markedBirthdate marked as optional, user can skipAll claims shown as required with no granularity
Description tone"RTL Play uses your name and email to create and manage your account.""By signing in, you agree to share your personal data with RTL Luxembourg SA for the purposes of providing our industry-leading streaming services."
Cancel optionVisible "Cancel" linkCancel link hidden or absent

Handling the cancel / decline flow​

When a user clicks "Cancel" or declines the consent screen, LuxID redirects to your redirect_uri with the following query parameters:

https://yourapp.lu/callback?error=access_denied&error_description=The+user+denied+access

Your application must handle this state gracefully. Recommended behaviour:

  • Return the user to your application's sign-in page or the previous page.
  • Display a brief, non-judgmental message: "Sign-in was cancelled. You can try again at any time."
  • Do not display an error page or imply that something has gone wrong technically.
  • Do not retry the authorisation flow automatically or redirect the user back to LuxID without their action.

For per-language microcopy for this state, see Error and edge-case UX.

The consent screen is shown:

  • Always on the user's first sign-in to your application.
  • Again if your application requests new scopes that were not approved previously.
  • Again if you publish a new version of your Terms and Conditions or Privacy Information (see below).
  • Again if you pass prompt=consent on the authorisation request.
  • Not shown on subsequent sign-ins with the same scope set and the same agreement versions, unless the user has revoked consent (via LuxID Account (opens in a new tab) > Applications).

Users can review and revoke per-application consent at any time from their LuxID Account settings. Applications should acknowledge this in their own data and privacy documentation.

Terms and Privacy versioning​

The consent screen can optionally display links to your application's own Terms and Conditions and Privacy Information, so the user agrees to your terms at the same moment they approve the data sharing. LuxID versions these links: when you tell LuxID that a new version of your Terms and Conditions (or Privacy Information) is available, LuxID re-triggers the consent screen on the user's next sign-in so they acknowledge the updated version. Consent is therefore tied to a specific agreement version, not just to the scope set - which is why a returning user is only skipped past the consent screen when both the scopes and the agreement versions are unchanged.

Mise à jour le 2026-07-03
Sur cette page