Client credentials

Planned - future LuxID Console

Self-service credential management is on the LuxID roadmap. Today, Client Secret rotation and certificate updates are performed by LuxID when you submit a request to LuxID. The procedures below describe the zero-downtime sequence to coordinate with LuxID.

Overview

LuxID issues credentials to each Application so that the LuxID authorisation server can verify the identity of the calling client. This page covers:

• Understanding the Client ID.
• Generating, viewing, and rotating the Client Secret.
• Zero-downtime secret rotation.
• SAML SP certificate management.
• Anti-patterns to avoid.

The type of credential your Application uses depends on the client type.

Client type	Credential
Confidential web server	Client ID + Client Secret
Public client (SPA, native mobile)	Client ID + PKCE (no secret)
SAML Service Provider	SP signing certificate

The client ID

The Client ID is a permanent, non-secret identifier assigned when you create an Application. It identifies your Application in every authorisation request, token request, and log entry.

The Client ID is:

• Safe to include in source code and client-side JavaScript.
• Stable - it does not change when you rotate secrets or update configuration.
• Unique within LuxID.

You can view the Client ID at any time by selecting your Application in the Console and opening the Credentials tab.

The Client ID is used as the client_id parameter in OIDC and OAuth 2.0 requests:

https://login.luxid.lu/mga/sps/oauth/oauth20/authorize
  ?response_type=code
  &client_id=YOUR_CLIENT_ID
  &redirect_uri=https%3A%2F%2Fapp.example.lu%2Fcallback
  &scope=openid+profile+email
  &state=RANDOM_STATE
  &code_challenge=CODE_CHALLENGE
  &code_challenge_method=S256

The client secret

What it is

The Client Secret is a high-entropy random value that confidential clients send to LuxID when exchanging an authorisation code for tokens (the token endpoint). It proves that the token request comes from the registered application and not from a third party who intercepted the authorisation code.

The Client Secret is:

• A secret - treat it like a password.
• Never logged by LuxID.
• Shown only once, immediately after Application creation or after you generate a new secret.

Viewing the client secret

LuxID does not display the Client Secret after initial creation. If you need to verify which secret is currently active, the Console shows only the creation date and a masked hint (last four characters).

If you do not know the current secret - for example, because a team member set it up and did not record it - generate a new one. See Rotating the Client Secret below.

Rotating the client secret

You should rotate the Client Secret:

• As part of a regular credential rotation schedule (for example, every 90 days for high-sensitivity Applications).
• Immediately if you suspect the secret has been compromised.
• When an employee with access to the secret leaves the team.
• When migrating your Application from one hosting environment to another.

LuxID supports zero-downtime rotation by allowing two active secrets simultaneously. The procedure is:

1. In the Console, navigate to your Application > Credentials tab.
2. Select Generate New Secret.
3. Copy the new secret immediately. It is shown only once.
4. Add the new secret to your application's secrets manager or environment configuration.
5. Deploy the new configuration to your application servers. Do not remove the old secret yet - during the rollout window, some instances may still be using the old secret.
6. Once all instances have been restarted with the new secret and you have confirmed successful token requests, return to the Console.
7. Select the old secret entry and choose Revoke.

The old secret becomes invalid the moment you revoke it. Any instance still configured with it will fail at the next token request. Ensure the rollout is complete before revoking.

Client secret storage anti-patterns

The following practices introduce serious security risks and must be avoided:

Never commit secrets to version control

Client Secrets in .env files, application.properties, appsettings.json, or any other configuration file that is committed to a repository expose the secret to everyone with repository access, including CI/CD pipelines, and to any future history scans.

Use a secrets manager:

• HashiCorp Vault
• AWS Secrets Manager
• Azure Key Vault
• Kubernetes Secrets (with encryption at rest enabled)
• Your hosting platform's native secret injection mechanism

Never embed secrets in mobile or SPA client-side code

Client Secrets embedded in Android APKs, iOS binaries, or JavaScript bundles can be extracted. Mobile apps and SPAs must be registered as public clients (no secret) and use PKCE. See Add login to your Application for the public client flow.

Never log secrets

Ensure your application code does not log the client_secret parameter, the token endpoint request body, or the authorisation header that carries the secret. Review your request logging middleware before enabling verbose logging in production.

Never share secrets across environments

Your Production and UAT Applications have separate Client IDs and separate secrets. Do not copy a production secret into UAT configuration, and do not use UAT secrets in production. Keep each environment's credentials isolated.

SAML SP signing certificates

For Applications using SAML 2.0, the Service Provider (SP) - your application - signs the AuthnRequest and may sign other SAML messages. LuxID verifies these signatures using the SP's public certificate registered in the Console.

Registering the SP certificate

1. Navigate to your Application > Credentials > SAML Certificate.
2. Upload the PEM-encoded SP signing certificate.
3. Select Save.

This certificate is also included in your SP metadata document if you export it from the Console.

SAML certificate rotation

SAML certificate rotation requires coordination because the IdP (LuxID) must have the new certificate registered before the SP begins signing with it.

Procedure:

1. Generate a new key pair and self-signed certificate (or request one from your CA).
2. Upload the new certificate to the Console alongside the existing one. LuxID will accept signatures from either certificate.
3. Update your SP to sign with the new certificate.
4. Verify that authentication flows continue to work.
5. Remove the old certificate from the Console.
6. Update your SP metadata shared with LuxID.

If only one certificate can be active at a time on your side, coordinate a maintenance window for the switchover.

Credential audit

Every credential creation, rotation, and revocation event is recorded in the Audit log in the Console. See Logs and audit trails for how to retrieve these records.

If you suspect a credential has been compromised, revoke it immediately and review the authentication logs for unusual activity before issuing a new one.