Aller au contenu principal
Version 0.2Brouillon

Secure

What this section covers​

A correct LuxID integration protects the credentials, tokens, and sessions that result from login - not just the login itself.

Building a correct integration with LuxID is not just about getting users logged in - it also means protecting the credentials, tokens, and sessions that result from that login. A vulnerability in your application can undermine the assurance that LuxID's authentication provides.

This section is for developers and security engineers responsible for LuxID-integrated applications. It covers four themes:

  • Application protection - preventing common attacks at the OAuth 2.0 / OIDC layer
  • Session management - persisting and renewing tokens correctly across restarts and reboots
  • Key management - validating signed tokens and rotating signing material
  • Advanced security options - stronger authorization request integrity mechanisms for Partners with stricter requirements

Who should read this​

  • Developers building the authentication and session layer of a LuxID Partner application
  • Security engineers reviewing an existing integration against current best practices
  • Architects evaluating whether standard PKCE-based flows or advanced options (PAR, JAR) are appropriate for a given deployment

Pages in this section​

Protect your Application​

Practical guidance on HTTPS enforcement, PKCE, state and nonce validation, ID Token validation, secure token storage, open-redirect prevention, and the most common anti-patterns - tokens in URLs, tokens in logs, hardcoded secrets.

Applies to all integration types. Start here if you are building or reviewing a new integration.

Session management​

Explains what LuxID does and does not manage, the role of each token type, and how to persist refresh tokens so users are not re-prompted for credentials and OTP on every device reboot. Includes lifecycle sequence diagrams, secure storage guidance per platform, and the canonical answer to the recurring support question: "Why does our app ask for OTP every morning?"

Key management​

Covers RS256 token signing, the JWKS endpoint, key rotation overlap, and how to write a correct key-fetch-and-cache routine. Also covers Client Secret security and rotation guidance.

Advanced security options​

For Partners with elevated security requirements: Pushed Authorization Requests (RFC 9126), JWT-Secured Authorization Requests (RFC 9101), FAPI alignment, and rate-limiting behaviour. Use this page once the standard flow is production-ready and a security review has identified a specific gap.

Token revocation​

Revoke refresh or access tokens via the RFC 7009 revocation endpoint as part of logout and incident response. Covers what revocation does and does not terminate (it does not end the LuxID SSO session), client authentication, and the relationship with Subscription revocation.

Calling LuxID reliably​

Operational guidance for keeping an integration resilient: timeouts, retries and backoff, idempotency (single-use codes, refresh-token rotation), JWKS caching, and how to behave during a LuxID outage.

Security advisories and dependency currency​

Keeping your integration's JWT and OAuth libraries current, monitoring relevant CVEs, and the contact path to follow if your Client Secret is leaked.

Integration security checklist​

A walk-before-go-live self-test: Part 1 is what you must verify in your own integration (state, nonce, ID Token validation, token handling); Part 2 is what LuxID enforces for you, with a clear note not to run active security tests against production. Use it for relying-party approval and security reviews.

Security baseline​

Every LuxID integration must meet this baseline before go-live, regardless of risk level:

  • HTTPS enforced for all redirect URIs and API calls
  • PKCE (S256) used on every Authorization Code flow
  • state validated on every callback
  • nonce validated in every ID Token
  • ID Token validated against all five checks in OpenID Connect Core 1.0 §3.1.3.7
  • Refresh tokens stored in platform secure storage (never in localStorage or plain files)
  • Client secrets never embedded in mobile or SPA code
attention

Meeting the baseline is a requirement for relying party approval. The pages in this section explain how to satisfy each point.

Relationship to other sections​

Mise à jour le 2026-05-26
Sur cette page