Openid Client Secret
An openid client secret is a shared private key between your app and identity provider. You send this secret from your backend server to exchange a login code for tokens. Most teams generate this value when they register a new app with their provider. If teams store this key in plain text or share it across apps, attackers can steal it. Once stolen, that key lets an attacker request tokens and impersonate your app. How an openid client secret works during login The sign-in flow starts when a
OpenID Connect (OIDC) + Secret Detection in Code (TruffleHog, GitLeaks): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
An openid client secret is a shared private key between your app and identity provider. You send this secret from your backend server to exchange a login code for tokens. Most teams generate this value when they register a new app with their provider. If teams store this key in plain text or share it across apps, attackers can steal it. Once stolen, that key lets an attacker request tokens and impersonate your app.
How an openid client secret works during login
The sign-in flow starts when a user clicks the login button in your app. Your app redirects the user to your identity provider to enter their password. After the user signs in, the provider sends a temporary code back to your app. This code alone does not grant user data or system roles.
Next, your backend server makes a direct call to the identity provider token endpoint. Your server sends the temporary code, the client ID, and the openid client secret. The provider checks if the secret matches the client ID on file. If they match, the provider returns an ID token and an access token.
This secret proves that the token request comes from your real backend server. Public apps like mobile or single-page web apps cannot keep this value hidden. Those public apps must use proof keys for code exchange instead of a static secret. Only confidential backend servers that hide their code from users should hold a secret.
How to store and rotate your client credentials
You should never put your secret in source code, git repos, or frontend bundles. Store the value in a dedicated secret manager or encrypted server variable instead. Limit read permissions so only the specific app service account can read the secret. Do not share one client ID and secret across multiple apps or test stages.
Regular key rotation reduces the risk of leaked credentials over time. Good identity providers let you create a second active secret for the same app. You generate the new secret first and update your backend server to use it. Once your server runs with the new value, you delete the old secret. This dual-key process lets you rotate credentials with zero downtime for users.
OpenID Connect (OIDC) + Secret Detection in Code (TruffleHog, GitLeaks): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What client secrets solve and the gap they leave open
A valid client secret proves your app identity to the identity provider during sign-in. It ensures that only your registered backend server can trade login codes for tokens. It also helps you map user groups and roles to your internal tools.
Still, the login flow only checks identity at the start of a session. Once a user or service logs in, the identity provider steps out of the way. The secret does not control what SQL queries, shell commands, or API requests run next. If a logged-in engineer runs a destructive database query, the identity provider cannot stop it. Also, standard login logs do not show if query results contain raw emails or card numbers. Teams still need a way to inspect commands and rewrite sensitive fields like phone numbers in flight.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
What is the difference between a client ID and an openid client secret?
A client ID is a public name that identifies your app to the identity provider. You can include the client ID in login URLs and browser code safely. The secret is a private password that proves your backend server owns that client ID.
Can I use a client secret in a single-page web app?
No, you should never put a client secret in browser code or mobile apps. Anyone can inspect browser network traffic or app files and steal the key. Single-page apps should use the authorization code flow with proof key for code exchange instead.
What should I do if a client secret leaks in a code repo?
You must revoke the exposed secret in your identity provider console right away. First, create a new secret and deploy it to your production servers. Then delete the leaked secret and check your provider logs for strange token requests.