OIDC Client Secret
An oidc client secret is a shared string that proves an app is real. Your app sends this string to the identity server to trade a login code for tokens. Most teams generate this value inside their identity provider when they register a new backend app. If an attacker steals this string, they can impersonate your app and request user tokens. Overbroad scopes on that app registration then let those tokens reach far too many internal systems. How an oidc client secret works in login flows OpenID
Secret Detection in Code (TruffleHog, GitLeaks) + K8s OIDC Authentication: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
An oidc client secret is a shared string that proves an app is real. Your app sends this string to the identity server to trade a login code for tokens. Most teams generate this value inside their identity provider when they register a new backend app. If an attacker steals this string, they can impersonate your app and request user tokens. Overbroad scopes on that app registration then let those tokens reach far too many internal systems.
How an oidc client secret works in login flows
OpenID Connect relies on a trusted exchange between your backend server and your identity provider. When a user logs in, the identity provider sends a short-lived code to the browser. The browser passes that code to your backend app. Your backend app then calls the token endpoint directly. It sends its client ID, the temporary code, and the oidc client secret. The identity provider checks that the secret matches the registered client ID. When the check passes, the provider returns an ID token and an access token. Public apps like single-page web apps or mobile apps cannot keep a secret safe. Anyone can inspect browser code or a mobile binary and read the string. Because of this risk, only backend apps that run on locked-down servers should hold a secret. Public clients should use Proof Key for Code Exchange instead of a static secret string.
How to store and rotate client secrets safely
Teams should never put a secret string in source code or build files. If a developer pushes that file to a code repo, the secret leaks right away. Instead, store the value in a dedicated secret manager or encrypted server store. The app should read the secret into memory only when it starts up. Rotation is just as vital as safe storage. Identity providers let admins create a second active secret for the same client ID. First, generate the new secret in the identity provider console. Next, update your app store with the new string and restart the app. Once all app nodes use the new secret, delete the old one. This two-step process prevents login downtime during the change. Some teams also switch from shared secrets to private key JWT methods. With a private key setup, the app signs a short message instead of sending a raw secret over the network.
What native identity checks miss after login
A valid client secret proves which app asked for a token and who logged in. It solves the front-door identity problem for your web and backend tools. Yet native identity checks stop once the user gets a valid session or token. The identity provider does not see what happens inside your databases or servers after login. A developer who logs in through an approved app still gets a broad database role. That role lets them run destructive queries or dump sensitive tables in production. The login flow cannot inspect individual SQL statements or shell commands in flight. It also cannot rewrite sensitive fields like emails, phone numbers, card numbers, or national IDs in query results. Teams need controls that work at the command and query level after the login handshake finishes.
Secret Detection in Code (TruffleHog, GitLeaks) + K8s OIDC Authentication: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
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 sits inline in the wire protocol beside those services as an open-source proxy, a sidecar for your Postgres or API. On every query an AI agent or engineer runs against production, hoop.dev decides to pass, mask, block, or hold it for human review.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run, and hoop.dev data masking rewrites matched sensitive values in responses 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
Can a single-page app use an oidc client secret?
No, browser apps cannot hide stored strings from users who open developer tools. Single-page apps should use the authorization code flow with PKCE and no secret.
How often should teams rotate an oidc client secret?
Most security teams rotate these secrets every sixty to ninety days on a schedule. You should also rotate them right away if an engineer leaves or a log leaks.
What is the difference between a client ID and a client secret?
A client ID is a public name that identifies your app to the login server. A client secret is a private password that proves your app owns that public ID.