Client secrets

SecureAuth provides OAuth client applications with a client ID and a secure client secret. Applications use these credentials to authenticate with the SecureAuth authorization server and request access tokens. To maintain security, manage and protect client secrets carefully.!

What are client secrets?

Client secrets are unique credentials known only to SecureAuth and the client application. They ensure secure authentication during token requests.

Example:

A client application registers with SecureAuth and receives credentials (client ID and secret).
The application uses the client credentials OAuth grant flow to access APIs.
The application sends its credentials to SecureAuth to obtain an access token.
SecureAuth verifies the credentials to prevent unauthorized access by malicious apps impersonating the client.

Best practices for client secret security

Store secrets securely to prevent unauthorized API access.
Use sufficiently random secrets to prevent guessing attacks.
Avoid storing secrets in distributed native or single-page JavaScript apps, as they can be exposed if decompiled.
Rotate secrets regularly to limit exposure risks.
Store secrets as one-way hashes for secure storage.

Client secret rotation

Rotating a secret generates a new one for the application while keeping the previous one active. SecureAuth retains one rotated secret by default. If you rotate again, the oldest secret is revoked, and the new secret replaces it.

Revoke Secrets. Developers must update the application with the new secret to regain API access. See the rotate client secrets Admin API or revoke rotated secrets in the View previously used secrets modal in your application settings.
Custom Limits. For on-premise deployments, adjust the number of stored rotated secrets (max_number_of_client_rotated_secrets) in the platform configuration file (config/config.yaml).

One-way hashing of client secrets

SecureAuth hashes client secrets using SHA-256 for added security, hiding plaintext values in the interface and database..

Difference between plaintext and hashed secrets

Secrets are only visible::

During client creation (UI or API response)
During secret rotation (UI or API response)

Tip

Copy or download the secret during these steps, as it cannot be viewed again.

Availability: One-way hashing is available for on-premise deployments. Enable it by setting client_secrets_stored_as_one_way_hash to true in your configuration settings.

One-way hashing and authorizers

When you create an authorizer, SecureAuth generates a client application in the System workspace. For multi-tenant authorizers, the client is created in the system tenant.

If one-way hashing is enabled:

Plaintext secrets for authorizers are unavailable
Configuration logic cannot fetch hashed secrets automatically.
Solution: Rotate the client secret, copy or download it, and manually add it to the authorizer’s configuration file.
Example configuration for Istio Authorizer:
```
resources:
- manifest.yaml
secretGenerator:
- name: istio-authorizer-secrets
  namespace: acp-system
  literals:
  - CLIENT_ID=c5fk2d1ngvl012k9noog
  - CLIENT_SECRET=
```

Rotating the secret ensures your authorizer can enforce access control.

In this section: