Confidential Clients
Confidential clients are applications that can keep a secret away from the browser. Server-rendered web apps and backend services are typical examples.
Client authentication
Section titled “Client authentication”DarkAuth supports confidential clients using client_secret_basic. The application sends the client ID and secret to the token endpoint using HTTP Basic authentication. This proves the token exchange is coming from a server that has the registered secret.
Confidential clients must authenticate as confidential clients. They cannot redeem authorization codes or refresh tokens by sending only client_id like a public client.
Do not put a confidential client secret in frontend code. If the browser can see it, the client is not confidential.
Authorization Code flow
Section titled “Authorization Code flow”A server-side web app can still use the Authorization Code flow. The browser redirects to DarkAuth, returns to the app callback, and the server exchanges the code for tokens. Because the exchange happens server-side, the client secret can be used safely.
PKCE can still be used for defense in depth. Public clients require it; confidential clients should use it when practical.
Client credentials
Section titled “Client credentials”Confidential clients can also use client credentials for service-to-service work. This is useful when no end user is involved, such as a backend job calling an API protected by DarkAuth.
Keep this separate from user authorization. A client credentials token represents the client, not a person.
Introspection and revocation
Section titled “Introspection and revocation”Confidential clients can call POST /introspect with client_secret_basic to validate access or refresh tokens issued to that same client. Tokens for other clients return inactive metadata.
Confidential clients can call POST /revoke with client_secret_basic to revoke refresh tokens issued to that client. Access and ID tokens are stateless in v1, so revocation accepts them as a successful no-op.
Secret rotation
Section titled “Secret rotation”DarkAuth shows a generated client secret once when a confidential client is created. Subsequent reads return secret metadata only, not the plaintext secret.
Write admins can rotate a client secret. Rotation returns the new plaintext value once, updates the encrypted secret at rest, and invalidates use of the old secret for future token endpoint authentication. Store the new value in a secret manager, deploy it safely, verify token exchange, then remove the old value from application configuration. Avoid copying secrets into logs, issue trackers, or local scripts.
When not to use a confidential client
Section titled “When not to use a confidential client”Do not choose a confidential client just because it sounds more secure. If token exchange happens in a browser, native app, or other environment where users can inspect the secret, use a public client with PKCE instead.