Securing Client Secrets

What the secret protects

A client secret is what proves to the authorisation server that a token request genuinely comes from your application and not an impostor. Combined with the public client identifier, it authenticates the client itself, in the same way a password authenticates a user. If that secret ever leaks, an attacker can request tokens as though they were your application, inheriting whatever privileges it holds.

For that reason the secret deserves exactly the same level of protection as any other high-value credential in your system when you integrate with the Merion API. It is not configuration to be sprinkled casually through your codebase; it is a key to the front door. Treating it with that seriousness from the first day of an integration is far easier than retrofitting good hygiene after a secret has already spread into places it should never have been.

Where to store secrets

The guiding rule is to keep secrets out of source control, out of build artefacts, and entirely out of any client-side code that ships to users. The preferred home is a dedicated secrets manager that controls and audits access; at a minimum, use environment variables injected at deploy time rather than values baked into the repository. Either way, restrict access to the small number of systems and people that truly need it.

By far the most common serious mistake is committing a secret to a repository, even a private one, where it then lives forever in the history. If that happens, deleting the offending commit is not a fix, because the value may already have been cloned, cached, or logged elsewhere. The only safe response is to treat the secret as compromised and rotate it immediately, then investigate where it may have spread.

Public clients have no secret

A public client, such as a mobile app or a single-page application, runs in an environment the user fully controls and can inspect. That means any secret embedded in it can ultimately be extracted by decompiling the app or reading the browser's network traffic and source. Such clients must therefore not rely on a client secret at all; instead they secure the authorization code flow using PKCE, which needs no stored secret to be effective.

Attempting to hide a secret inside shipped client code provides only the illusion of security, and a dangerous one, because it invites teams to trust a protection that does not actually exist. The honest and correct approach is to design public clients around having no secret in the first place. See PKCE Explained for how that is achieved in practice without weakening the flow.

Rotating secrets

Rotation means replacing a secret periodically as a matter of routine, and immediately whenever exposure is even suspected rather than confirmed. Where the platform supports having two active secrets at once, you can introduce the new secret, update all deployments to use it, and only then retire the old one — performing the whole rotation with no downtime and no failed requests in between.

The key cultural shift is to build rotation into your normal operational routine, so it is a scheduled, unremarkable task rather than a stressful emergency you scramble to perform only after something has gone wrong. A secret that is rotated regularly is one whose eventual leak does far less damage, because its useful life to an attacker is already bounded. For related guidance on the long-lived machine credentials this most often applies to, see The Client Credentials Flow.