Guide
OAuth client IDs explained
If you have ever clicked "Sign in with Google" and watched an app redirect through an authorization page, a client ID did quiet work behind the scenes. It is one of the most misunderstood identifiers in web development — routinely confused with user IDs, API keys, and secrets. Here is what it actually is.
What a client ID is
In OAuth 2.0, the client is the application asking for access — your web app, mobile app, or script. The client ID is the public identifier the authorization server assigns when you register that app. It answers one question: which application is asking? It does not identify the user (that is the user ID or subject claim), and it is not a secret — it appears in redirect URLs and front-end code by design. For the format options, see our client ID formats guide.
Client ID vs the things it is not
| Credential | Identifies | Secret? |
|---|---|---|
| Client ID | The application | No — public by design |
| Client secret | The application (authentication) | Yes — never expose |
| User ID / subject | The end user | Not a credential at all |
| API key | Usually a project or app | Yes |
| Access token | The granted authorization | Yes — short-lived |
The classic beginner mistake is treating the client ID like a password — hiding it, or worse, using it as the password. It is a username, not a password. The client secret is the password.
Public vs confidential clients
OAuth splits clients by whether they can keep a secret:
- Confidential clients — server-side apps that can store a client secret safely. They authenticate with client ID plus client secret when exchanging codes for tokens.
- Public clients — SPAs, mobile apps, desktop apps. Anything shipped to users can be decompiled, so these clients get no secret (or one that is not truly secret). They rely on PKCE — a per-request proof — instead of a static secret.
This distinction drives real design decisions: a mobile app registered as "confidential" with an embedded secret is security theater. Register it as public and use PKCE. Our creating unique client IDs guide covers generating the identifiers themselves.
The client secret: handle with care
The client secret authenticates the client to the authorization server — it proves the token request really comes from your app. Rules:
- Server-side only. Never in mobile apps, SPAs, or public repos. If it leaks, rotate it immediately.
- Rotate on a schedule and on any suspected exposure. Support two active secrets briefly during rotation so deploys do not break.
- One secret per environment. Development, staging, and production get separate client registrations — a leaked dev secret should never threaten production.
Where client IDs show up
You will meet client IDs in authorization URLs (client_id=... as a query parameter), in token requests, in the aud (audience) claim of ID tokens, and in provider dashboards where you manage redirect URIs. When debugging a broken login flow, the client ID is the first thing to verify: wrong client ID, wrong redirect URI registered for it, or a mismatch between the two accounts for a large share of "login suddenly broke" incidents.
Testing with mock client IDs
Real client IDs come from provider dashboards and cannot be invented for tests. For everything else — seed data, documentation examples, integration tests that never touch a real provider — generate realistic mock IDs with the client ID generator. Use obviously-fake values in docs (test-client-123) so nobody copies a real-looking ID into production, and keep a documented mapping of which mock ID stands in for which real registration in each environment.
Key takeaway: the client ID names the app (public), the client secret authenticates it (secret), and the user ID names the human. Keep those three jobs separate and OAuth stops being confusing.
FAQ
Is it safe to expose my client ID in front-end code?
Yes — client IDs are public identifiers by design. What must stay secret is the client secret, which is why browser and mobile apps use PKCE instead.
Can I use the same client ID for web and mobile?
You can, but separate registrations are cleaner: they let you set different redirect URIs, different secret handling, and independent revocation per platform.
What happens if my client secret leaks?
Rotate it immediately in the provider dashboard, update your servers, and investigate what the exposed secret could have accessed. Treat it like a password breach, because it is one.
Do I need OAuth for server-to-server calls?
Often yes, via the client credentials flow — the client authenticates with its ID and secret and gets a token with no user involved. It is the standard for service-to-service auth. These service-to-service flows live and die by token lifetimes — see our guide on access token expiration and refresh.
Client ID vs API key — which should I use?
Different jobs. Client IDs belong to OAuth flows with users and delegated permissions; API keys suit simple project-level authentication. See what is a client ID for the full comparison.