Skip to main content
Version 0.6Draft

Advanced security options

Overview​

The standard LuxID integration uses PKCE-based Authorization Code flow with a client secret for confidential clients. For most Partners, this provides an appropriate level of security.

This page documents the additional security mechanisms available to Partners with elevated requirements - typically organisations operating at High assurance level, handling particularly sensitive data, or subject to specific regulatory requirements.

PAR and JAR are not currently implemented

PAR and JAR are described here for completeness, but they are not currently implemented by LuxID (the production discovery document advertises neither a pushed_authorization_request_endpoint nor request_object_signing_alg_values_supported). Do not build against them. If your integration needs them, contact LuxID so the requirement can be assessed.

These options address two categories of risk beyond the baseline:

  • Operational security - rate limiting, incident handling, and abuse protection (available today)
  • Stronger authorization request integrity - ensuring the authorization request cannot be tampered with in transit (PAR, JAR - not currently implemented, covered at the end of this page)

Baseline first. Use the baseline security controls documented in Protect your Application and Session management before exploring the options on this page. Advanced mechanisms are an addition to baseline controls, not a replacement.

Client authentication​

Confidential clients authenticate to LuxID's token endpoint using Client ID and Client Secret (client_secret_basic or client_secret_post). Both are advertised in the discovery document under token_endpoint_auth_methods_supported and are confirmed working:

https://login.luxid.lu/.well-known/openid-configuration
MethodUse case
client_secret_basicConfidential web server applications
client_secret_postConfidential applications where Basic auth is inconvenient

No mTLS client authentication. Only Client Secret authentication is provisioned for Partners today. Some endpoints advertised in the discovery document may not be provisioned for your integration - confirm with LuxID before relying on any optional endpoint or authentication method.

For guidance on securing and rotating Client Secrets, see Client credentials and Protect your Application.

Transport security and credential handling​

Every request to LuxID - browser redirects, token-endpoint calls, UserInfo, revocation - must travel over HTTPS. Treat the points below as hard requirements, not options.

Transport (TLS)​

  • Always connect over HTTPS using TLS 1.2 or higher. TLS 1.0 and 1.1 are deprecated (RFC 8996 (opens in a new tab)); do not let your HTTP client negotiate them, and prefer TLS 1.3 where your platform supports it.
  • Never put credentials or tokens in a URL. Client secrets, authorization codes, access tokens, and refresh tokens belong in request bodies or headers, never in query parameters - URLs end up in server logs, browser history, and proxies. Use POST, not GET, for the token, revocation, and introspection endpoints.
  • Validate the server certificate. Let your platform's trust store verify LuxID's certificate chain; never disable certificate validation, not even in testing.
Avoid pinning the leaf certificate

LuxID's TLS certificate is rotated periodically. If you pin the exact leaf certificate, your integration will break the next time it rotates. If you pin at all, pin to the issuing Certificate Authority or the public key, and keep a tested fallback. For most Partners, relying on the system trust store with automatic updates is the right choice.

Credential handling​

The Client Secret is the key to your application's identity. Handle it like a production password:

  • Never hardcode it in source code, and never commit it to a repository, public or private.
  • Load it from a secrets manager or an environment variable at startup; do not write it to disk in plaintext, and do not bake it into a build artifact or a mobile binary.
  • Never expose it in a browser or mobile app. An application that cannot keep a secret is a public client - use PKCE without a secret instead (see below).
  • Rotate it on a schedule, and immediately if you suspect exposure. See Client credentials.
  • Keep it out of logs. Scrub secrets, tokens, and authorization codes from your application and access logs.

Public clients vs confidential clients​

Understanding this distinction is important when choosing a security configuration.

Public clients​

A public client is an application that cannot securely store a client secret. This includes:

  • Mobile applications (binary can be extracted and analysed)
  • Browser-based SPAs (JavaScript source is visible)
  • Desktop applications where the secret would be embedded in the binary

Public clients use PKCE without a client secret. The client_authentication_method is effectively none - LuxID identifies the client by client_id only (which is not secret) and relies on PKCE for code binding.

PKCE is required for all clients (public and confidential) per RFC 9700 (opens in a new tab).

Confidential clients​

A confidential client is an application that can securely store credentials - typically a server-side application where the credential lives in a secrets store outside the browser or device.

Confidential clients authenticate to the token endpoint using Client ID and Client Secret (client_secret_basic or client_secret_post). Confidential clients must also use PKCE.

Choosing the right configuration​

ScenarioClient TypeRecommended Auth Method
SPA with no backendPublicPKCE, no secret
Mobile applicationPublicPKCE, no secret
Server-side web applicationConfidentialPKCE + client_secret_basic or client_secret_post
Backend service (API)ConfidentialPKCE + client_secret_basic
High-assurance or regulated integrationConfidentialPKCE + client_secret_basic or client_secret_post

Rate limiting and abuse protection​

LuxID applies rate limits to its OAuth 2.0 and OIDC endpoints to protect against brute-force attacks, credential stuffing, and abusive automated traffic.

Affected endpoints​

Rate limits are applied at the LuxID infrastructure level to the following endpoints:

  • Authorization endpoint (/mga/sps/oauth/oauth20/authorize)
  • Token endpoint (/mga/sps/oauth/oauth20/token)
  • Revocation endpoint (/mga/sps/oauth/oauth20/revoke)
  • UserInfo endpoint (/mga/sps/oauth/oauth20/userinfo)

The specific limits are not published as they may be adjusted operationally. If your integration generates high volumes of legitimate requests (e.g. batch processing, high-traffic partner application), contact LuxID during onboarding to discuss your expected traffic profile.

HTTP response on rate limit​

When a rate limit is exceeded, LuxID returns HTTP 429 (Too Many Requests). Your integration must handle this gracefully:

  • Implement exponential backoff with jitter for retry logic
  • Do not retry immediately in a tight loop
  • Log rate limit responses for monitoring and alerting

Security signals​

LuxID also applies risk-based controls that may slow down or require a step-up challenge based on contextual security signals. This is transparent to compliant integrations. See Security signals and risk scoring for more detail.

Incident handling and token revocation​

If your application detects or suspects a security incident (credential exposure, token theft, compromised device), the response is:

  1. Revoke all active refresh tokens for the affected user or application via the revocation endpoint. See Revocation
  2. Clear local session state on all affected clients
  3. Force re-authentication by removing any stored tokens
  4. Report the incident to servicedesk@post.lu with subject SECURITY INCIDENT if you believe LuxID credentials or LuxID infrastructure is involved (see Contact and support channels)

In the standard bearer token model, an already-issued access token remains valid until its exp is reached. Access tokens are short-lived, which limits exposure. If your integration needs to invalidate access immediately rather than waiting for the token to expire, discuss the available options with LuxID.

For scenarios where immediate access token invalidation is critical, consider using token introspection on the resource server side to check token validity on each use. See Token introspection.

Pushed authorization requests - PAR (RFC 9126)​

PAR sends the authorization parameters to LuxID over a server-to-server channel first, so they never appear in the browser redirect URL.

What it provides​

Pushed Authorization Requests (RFC 9126 (opens in a new tab)) change how the authorization request is initiated. Instead of including all parameters in the browser redirect URL (visible to the browser, browser history, and any intermediaries), the client first sends the authorization parameters directly to LuxID's PAR endpoint over an authenticated server-to-server channel. LuxID returns a short-lived request_uri. The client then redirects the user to the authorization endpoint with only client_id and request_uri.

Benefits:

  • Authorization parameters (including scope, acr_values, redirect_uri) are not exposed in the browser URL
  • The request is authenticated before the user is redirected, preventing parameter injection attacks
  • Prevents attackers from constructing malicious authorization URLs with modified parameters

Current support status​

PAR is not currently available. The LuxID production discovery document does not advertise a pushed_authorization_request_endpoint, so PAR (RFC 9126) is not available today. Treat the flow below as a target design, not a working endpoint. If your integration needs PAR, contact LuxID, and re-check the discovery document at https://login.luxid.lu/.well-known/openid-configuration (opens in a new tab) for pushed_authorization_request_endpoint before building against PAR.

PAR flow​

When to use PAR​

PAR is recommended when:

  • You are passing sensitive parameters in the authorization request (e.g. claims parameter with specific claim requests)
  • Your security review has identified browser-URL exposure of authorization parameters as a risk

JWT-secured authorization requests - JAR (RFC 9101)​

What it provides​

JWT-Secured Authorization Requests (RFC 9101 (opens in a new tab)) wrap the authorization request parameters in a signed (and optionally encrypted) JWT called the Request Object. The Request Object is either passed by value in the request parameter or by reference via request_uri. LuxID validates the JWT signature before processing the request, ensuring the parameters have not been tampered with in transit.

JAR provides parameter integrity protection. It does not prevent the parameters from being visible in the browser URL (use PAR for that, or combine PAR + JAR).

Current support status​

JAR is not currently available. The LuxID production discovery document does not advertise request_object_signing_alg_values_supported, so JAR (RFC 9101) is not available today. If your integration needs signed request objects, contact LuxID, and re-check the discovery document at https://login.luxid.lu/.well-known/openid-configuration (opens in a new tab) before building against JAR.

When to use JAR​

JAR is relevant when:

  • You are combining it with PAR (PAR + JAR = authorization parameters sent server-to-server in a signed JWT - the strongest authorization request protection)
  • You need cryptographic proof of authorization request integrity for audit purposes

Summary​

FeatureRFCStatusUse When
PKCE (S256)RFC 7636Available (required)All flows
client_secret_basic / _postRFC 6749AvailableStandard confidential clients
PARRFC 9126Not currently availableSensitive parameter protection
JARRFC 9101Not currently availableSigned request integrity

PAR and JAR are not advertised in the discovery document today, so they are not currently available - contact LuxID if your integration needs them. More generally, some endpoints advertised in the discovery document may not be provisioned for your integration. Treat the discovery document as the source for the core endpoint URLs, but confirm with LuxID before relying on any optional endpoint rather than assuming everything advertised is available.

Further reading​

Updated 2026-07-03
On this page