Client ID and client secret
The client ID publicly names your OAuth app; the client secret proves the server is that app and must stay off browsers and mobile apps.
What it is
A client ID tells an OAuth provider which application is asking. It is public and appears in browser redirects. A client secret lets a confidential client authenticate itself at the token endpoint. It is a credential, so it belongs only on a server or in a secret manager, never in shipped JavaScript or a mobile binary.
You receive the pair when registering an OAuth application in Google Cloud Console, GitHub, or another provider; Meta's developer console calls the same two values App ID and App Secret. Server-rendered web apps and backend services can usually protect a secret. Browser-only apps and native apps cannot, so they are public clients and use PKCE without pretending an embedded secret is private.
The gotcha is assuming the secret protects everything. It identifies the client, not the human, and it does not replace redirect URI checks, state, or PKCE. Rotate a leaked secret, keep the old one only during a controlled overlap if the provider supports it, and remember that changing it breaks every running deployment still using the old value.
Ask AI for it
Configure Google OAuth 2.0 with `GOOGLE_CLIENT_ID` and `GOOGLE_CLIENT_SECRET` loaded from the deployment's secret manager. Send the client ID in the authorization request, then perform the code exchange against `https://oauth2.googleapis.com/token` on the server with the client ID, client secret, exact redirect URI, code, and PKCE verifier. Never expose the secret through a `NEXT_PUBLIC_` variable, client bundle, log line, or repository. Fail startup when either server variable is missing, document secret rotation, and use Authorization Code with PKCE and no client secret if this is converted into a browser-only or native public client.