Client Secret Basic Client Authentication
Client secret–based authentication (client_secret_basic) is still supported in
many OAuth 2.0 deployments but is increasingly discouraged for new high-security
integrations because it relies on secrets that are difficult to
protect and rotate at scale.
Modern guidance favors methods like mTLS client auth or private_key_jwt for confidential clients wherever possible.
How client_secret_basic Client Authentication Works
In client_secret_basic, a confidential client authenticates to the token
endpoint using HTTP Basic Authentication with its client_id and
client_secret. The credentials are concatenated as client_id:client_secret,
Base64-encoded, and sent in the Authorization: Basic <base64> header over
HTTPS when requesting tokens.
The request body then contains only grant-specific parameters (for example,
grant_type, code, redirect_uri), while the authorization server extracts
and validates the client credentials from the header. If the secret matches what
the authorization server has stored and the client is allowed to use the
requested grant, the server issues tokens; otherwise, it returns standard OAuth
errors such as invalid_client.
Why client_secret_basic Client Authentication Is Discouraged
Despite being simple to implement, client_secret_basic inherits the weaknesses
of symmetric secrets and Basic authentication. The same secret must be shared
between client and authorization server, often copied across environments and
services, increasing the risk of leakage through misconfiguration, logging, or
dependency compromise.
Even with TLS, any compromise of logs, configuration repositories, CI pipelines, or monitoring systems that handle the secret can give an attacker long-lived access to the client's identity. Additionally, rotating secrets across multiple environments is operationally painful, which often leads to long-lived or never-rotated secrets that do not meet modern security expectations.
More Secure Alternatives to client_secret_basic Client Authentication
For new confidential clients and higher-assurance use cases, asymmetric and assertion-based methods are strongly preferred. These approaches avoid sharing a single static secret across systems and typically provide better isolation, auditability, and rotation characteristics.
Common alternatives include:
-
Private key JWT (
private_key_jwt) The client authenticates with a signed JWT using an asymmetric key pair, and the authorization server validates signatures using the registered public key. This removes shared secrets, allows independent key rotation, and aligns well with financial-grade API profiles and modern zero-trust designs. -
Asymmetric, connection-bound methods Approaches such as mTLS client authentication (
tls_client_auth), which combine TLS client authentication or proof-of-possession tokens with JWT-based client authentication, further reduce replay risks and centralize credential management.
When client_secret_basic Might Still Appear
There are ecosystems and legacy clients where client_secret_basic remains
enabled for compatibility. In such contexts, it is often seen as a transitional
mechanism rather than a strategic choice, with migration paths towards stronger
methods defined in security profiles and roadmaps.
If client_secret_basic must be supported, it should be constrained by strict
policies: short-lived secrets, enforced rotation, hardened storage, and clear
deprecation timelines. New client integrations, especially those handling
sensitive data or operating in regulated environments, should be directed
towards private key JWT or equivalent stronger mechanisms instead of relying on
shared client secrets.
client_secret_basic Client Authentication to Raidiam APIs
Client applications registered in Raidiam Connect can authenticate to the authorization server using the client_secret_basic method to obtain access tokens and call Connect APIs.
Although supported for compatibility, client_secret_basic is not recommended. It relies on symmetric secrets and does not meet FAPI requirements. For new or security-sensitive integrations, you should use FAPI-aligned methods such as private_key_jwt.
When configuring an application to use client_secret_basic, Connect will display a warning indicating that the application will no longer be FAPI-compliant. After confirming, a client secret is generated. You must copy this secret at creation time and store it securely, as it will not be shown again.
