Before Client ID and Client Secret make any sense, you need to know what problem OAuth 2.0 is solving in the first place.

What is OAuth 2.0?

OAuth 2.0 is a set of rules — a protocol — that lets one application access a small, limited piece of your data stored inside another application, without ever seeing your password. When a photo-printing website asks to “see your Google Photos,” it is using OAuth 2.0 behind the scenes. You never type your Google password into the photo-printing website. Instead, Google itself asks you to approve the request, and then hands the photo-printing website a special access pass.

Who are the four players?

OAuth 2.0 always involves four roles working together. The resource owner is you, the person who owns the data. The client is the application asking for access — the photo-printing website in our example. The authorization server is the system that checks identities and hands out access passes — this is where Client ID and Client Secret live. The resource server is where your actual data sits, such as Google’s photo storage.

Client ID and Client Secret belong specifically to the second role — the client. They are how the client introduces itself to the authorization server, long before any user data is ever touched. Every chapter from here on builds on this one idea: these two values are the client’s own identity credentials, separate entirely from the end user’s identity.

Two plain strings of characters carry an enormous amount of responsibility. Let’s define them precisely.

Client ID

A Client ID is a public, unique identifier assigned to an application when it registers with an authorization server. It is typically a long string of random letters and numbers, such as 482910573-abc123xyz.apps.example.com. It is called “public” because it is not a secret at all — it can appear in browser URLs, mobile app code, or even be visible to anyone inspecting network traffic. Its only job is to say “this request is coming from application number 482910573,” the same way a car’s license plate says which vehicle is on the road without revealing anything private about the driver.

Client Secret

A Client Secret is a private, confidential string issued alongside the Client ID, but only to certain types of applications (explained in Chapter 6). Where the Client ID identifies, the Client Secret proves. It works like a password that belongs to the application itself, not to any individual user. If the Client ID is the license plate, the Client Secret is closer to the car’s ignition key — without it, the car cannot actually be started, no matter how visible the license plate is.

What do they look like in practice?

Different providers format these values differently, but the pattern is consistent. Google issues Client IDs ending in .apps.googleusercontent.com. GitHub issues shorter alphanumeric Client IDs alongside a Client Secret that is regenerated each time you request it. Slack, Facebook, and Microsoft all follow the same two-part shape: one identifier meant to be shared, one secret meant to be locked away. No matter the exact formatting, the underlying design goal never changes.

Not the same as a username and password

It is tempting to think of Client ID and Client Secret as “the app’s username and password,” and while the comparison is not wrong at a surface level, it misses something important: these credentials never identify a human being. They identify a piece of software. A single application might be used by millions of different people, and every one of those people’s individual logins are handled completely separately, using the flows described in later chapters. The Client ID and Secret only ever say “this software is who it claims to be” — nothing more.

A useful mental separation

It helps to keep two separate mental boxes while learning OAuth 2.0. The first box holds “who is the user” — this is handled by the user’s own login session with the authorization server, entirely independent of any application. The second box holds “which application is asking” — this is exactly what the Client ID and Secret answer. Beginners often blur these two boxes together, assuming that logging a user in and identifying the requesting application are the same step. They are not, and keeping them mentally separate makes every later chapter in this guide click into place far more easily.

Every piece of security infrastructure exists because someone imagined how things could go wrong without it.

The problem of impersonation

Picture an authorization server that handed out access tokens to absolutely any application that asked, with no way to check who was asking. A malicious developer could write a fake app, call itself “Trusted Banking App,” and request the exact same permissions as the real one. Users would have no way to tell the difference, and the authorization server would have no way to refuse the fake app’s requests. Client registration exists to close this gap.

Three concrete reasons they exist

Why a secret specifically, and not just an ID?

An ID alone can be copied by anyone, because it is never hidden in the first place. If proving identity relied on the ID alone, any application could simply claim someone else’s Client ID and be treated as trusted. The Secret adds a second, hidden factor that only the real, registered application is supposed to know, closing that impersonation gap. This mirrors a wider security principle: public identifiers plus private proof, layered together, are far stronger than either one alone.

Client ID and Client Secret don’t appear out of nowhere — they’re handed out through a formal registration step.

The registration process

Before any application can use OAuth 2.0 with a given provider, a developer must register that application in the provider’s developer console — Google Cloud Console, GitHub Developer Settings, the Slack API dashboard, and so on. During registration, the developer supplies information such as the application’s name, a support contact, a logo, and — critically — one or more redirect URIs, which are the exact web addresses the authorization server is allowed to send users back to after login.

Why the redirect URI matters here

The redirect URI is registered at the same time as the Client ID and Secret because all three work together as a unit. Even with a valid Client ID and Secret, an authorization server will refuse a login request if the redirect URI supplied does not exactly match what was registered. This prevents attackers who somehow learn a Client ID from redirecting users’ approvals to a server they control.

The secret is shown only once

Most providers display the Client Secret a single time, immediately after generation, and never show it in plaintext again. If a developer loses it, the only remedy is to generate a brand-new secret, which immediately invalidates the old one. This “shown once” design nudges developers toward storing secrets in password managers or secret-management systems rather than screenshots or sticky notes.

Zooming out to see how these credentials sit inside the broader OAuth 2.0 architecture.

The Client ID and Secret are not used in isolation — they are one part of a small ecosystem of moving pieces that must all cooperate correctly for OAuth 2.0 to function safely. Understanding the architecture helps explain exactly where, and when, these credentials get used.

flowchart LR
    U["User
(Resource Owner)"] -->|1. Wants to log in| C["Client App"]
    C -->|2. Redirects with Client ID| A["Authorization Server"]
    U -->|3. Approves access| A
    A -->|4. Sends Authorization Code| C
    C -->|5. Sends Code + Client ID + Client Secret| A
    A -->|6. Returns Access Token| C
    C -->|7. Uses Access Token| R["Resource Server"]
        

Notice that the Client ID appears early, in step 2, simply tagging along with the login request so the authorization server knows which app is asking. The Client Secret does not appear until step 5, a completely separate, direct, server-to-server exchange that the end user’s browser never even sees. This separation is intentional and matters enormously for security, which the next chapter explores in depth.

Core architectural components

The token endpoint deserves special attention, because it is the one and only place a Client Secret is ever transmitted. It always happens over an encrypted connection, directly between the client’s backend server and the authorization server’s backend — with no browser redirect involved — precisely so the secret is never exposed to anything sitting in between, such as browser extensions, proxies, or curious users viewing page source.

Not every application is even allowed to hold a Client Secret — this chapter explains why.

The core distinction

OAuth 2.0 divides applications into two categories based on one simple question: can this application keep a secret? A confidential client runs on a server the developer fully controls, where nobody outside the company can read the source code or memory — think of a backend web application. A public client runs on a device the developer does not fully control, such as a mobile phone, a single-page browser app, or a smart TV, where a sufficiently determined user or attacker could eventually extract anything embedded in the code.

Comparing the two client types

What public clients use instead

Because public clients cannot reliably protect a secret, modern OAuth 2.0 practice adds an extra mechanism called PKCE (pronounced “pixy”), short for Proof Key for Code Exchange. Instead of a fixed, long-lived secret, PKCE generates a random, one-time value for each individual login attempt, used once and then discarded. This achieves a similar goal — proving the request is genuine — without ever needing a secret that could be stolen and reused later.

Understanding this split answers a question many beginners ask: “why does my mobile app’s Client Secret feel unsafe, even though the documentation gave me one?” The honest answer is that on a public client, no embedded secret can ever be made fully safe — the architecture of OAuth 2.0 openly acknowledges this limitation and provides PKCE as the real solution for that category of app.

A closer look at the exact moment the Client Secret does its job.

The token request

After a user approves access, the authorization server does not immediately hand over an access token. Instead, for the most common flow (Authorization Code), it first hands the client a short-lived, single-use authorization code. The client’s backend then makes a separate, private request directly to the token endpoint, attaching three things together: the authorization code it just received, its Client ID, and its Client Secret. The authorization server checks all three before issuing the real access token.

sequenceDiagram
    participant Browser
    participant ClientServer as Client Backend
    participant AuthServer as Authorization Server
    Browser->>AuthServer: Login + consent (Client ID visible)
    AuthServer-->>Browser: Redirect with Authorization Code
    Browser->>ClientServer: Forwards Authorization Code
    ClientServer->>AuthServer: Code + Client ID + Client Secret
    AuthServer->>AuthServer: Verify Secret matches registered Client ID
    AuthServer-->>ClientServer: Access Token (+ Refresh Token)
        

What “verification” actually means

On the authorization server’s side, verification is a straightforward lookup-and-compare operation. The server holds a client registry mapping every Client ID to a securely stored version of its matching Client Secret. When a token request arrives, the server looks up the Client ID, retrieves the stored secret (or a cryptographic hash of it), and compares it against the value the client just sent. If they match, the request is trusted as genuinely coming from the registered application; if not, the request is rejected outright, regardless of how valid the authorization code itself might be.

Why hashing matters on the server side

Responsible authorization servers never store Client Secrets in plain, readable text in their own databases. Instead, they store a one-way cryptographic hash of the secret — a scrambled fingerprint that can confirm a match without ever being reversible back into the original value. This way, even if the server’s database were somehow leaked, attackers would not directly obtain usable Client Secrets, only their fingerprints, which is a well-established best practice borrowed from how passwords themselves should always be stored.

Client ID and Secret behave slightly differently depending on which OAuth 2.0 “grant type,” or flow, is in use.

What is a grant type?

A grant type is simply a named pattern describing how an access token gets issued for a particular situation. Different situations call for different patterns — a human sitting at a browser needs a different flow than one server talking to another server with no human involved at all. The Client ID and Secret appear in nearly every grant type, but exactly how and when varies.

The lifecycle of a Client Secret

Beyond a single login, it helps to think about the Client Secret’s entire lifespan, from birth to eventual retirement.

Notice that the Client ID rarely changes throughout this entire lifecycle — it is meant to be a stable, long-term identifier. The Secret, on the other hand, is expected to be rotated periodically as routine hygiene, similar to changing a password on a schedule, precisely because it carries the actual trust burden.

One grant type puts Client ID and Secret so squarely at the center that it deserves its own close look.

When there is no human in the loop

Not every OAuth 2.0 interaction involves a person clicking “approve” on a consent screen. Sometimes one backend service simply needs to talk to another backend service directly — for example, an internal billing system fetching data from an internal inventory system, with no user anywhere in sight. This scenario uses the Client Credentials grant, and in this flow, the Client ID and Client Secret are not one ingredient among several — they are the entire identity being proven.

sequenceDiagram
    participant ServiceA as Billing Service (Client)
    participant AuthServer as Authorization Server
    participant ServiceB as Inventory Service (Resource Server)
    ServiceA->>AuthServer: Client ID + Client Secret
    AuthServer->>AuthServer: Validate credentials, no user involved
    AuthServer-->>ServiceA: Access Token
    ServiceA->>ServiceB: Request with Access Token
    ServiceB-->>ServiceA: Protected data
        

Why this flow trusts the secret so heavily

Because there is no authorization code, no redirect, and no consent screen in this flow, there is also no second layer of protection to fall back on. This is precisely why the Client Credentials grant is restricted to confidential clients only — server-to-server systems that can be trusted to store a secret properly. A public client, like a mobile app, is never a sensible fit for this grant type, because it could never protect the secret involved.

Typical real-world uses

Because the Client Secret carries so much trust, protecting it properly is one of the most important responsibilities a developer takes on.

Where secrets should live

A Client Secret should never appear in source code that gets committed to a shared repository, never be written directly into a mobile app binary, and never travel over an unencrypted connection. Instead, it belongs in a dedicated secrets manager, an encrypted environment variable, or a vault service designed specifically to store sensitive values and control exactly which parts of a system can read them.

Transport-level protection

Every request that carries a Client Secret must travel over HTTPS, the encrypted version of the web’s standard protocol. Without encryption, anyone positioned between the client and the authorization server — on a shared coffee-shop network, for instance — could potentially observe the secret in transit. HTTPS wraps the entire exchange in a layer that makes eavesdropping computationally impractical.

Rotation as routine hygiene

Even a perfectly stored secret benefits from periodic rotation. Just as changing a house lock occasionally reduces the risk from an old, forgotten spare key, generating a fresh Client Secret on a schedule — say, every 90 to 180 days — limits how much damage a quiet, undetected leak could ever cause, since the leaked value naturally expires.

What to do if a secret leaks

If a Client Secret is ever suspected of being exposed — accidentally pushed to a public repository, shown in a screen-sharing session, or found in a log file — the correct response is immediate: revoke and regenerate the secret through the provider’s developer console right away, then update the stored value everywhere the legitimate application uses it. Treating a suspected leak calmly but urgently, rather than waiting to “see if anything bad happens,” is the responsible standard.

Least-privilege access to the secret itself

Protecting a Client Secret is not only about where it is stored, but also about who within an organization is even allowed to view it. A well-run engineering team limits access to production secrets to a small, clearly defined group, uses audit logging to record every time a secret is read or updated, and avoids pasting secrets into shared chat channels even temporarily. The fewer people and systems that ever touch the raw value, the fewer opportunities exist for it to leak by accident rather than through any deliberate attack.

Monitoring for misuse

Good security does not stop at prevention — it also includes watching for signs that something has already gone wrong. Authorization servers typically expose logs showing every token request made using a given Client ID, including timestamps, request volume, and sometimes rough geographic origin. A sudden, unexplained spike in token requests, or requests suddenly arriving from an unfamiliar region, can be an early warning sign that a Client Secret has fallen into the wrong hands, even before any other damage becomes obvious. Teams that review these logs periodically catch problems far sooner than teams that only look after something has already broken.

Beyond avoiding mistakes, there are proven patterns experienced teams follow to use these credentials well.

One application, one set of credentials, one purpose

A clean design principle is to register a distinct Client ID and Secret for every distinct application or environment, rather than reusing a single set across multiple unrelated systems. A company’s mobile app, its web dashboard, and its internal admin tool should each have their own registration, even if built by the same team, because it keeps blast radius small if any one of them is ever compromised.

Defense in depth

Experienced architects treat the Client Secret as one layer of a larger defensive stack, never the only line of defense. Combining it with HTTPS everywhere, strict redirect URI matching, short-lived access tokens, PKCE for public clients, and careful scope requests together builds a system where no single failure point can undo everything else.

Documenting ownership

A frequently overlooked but valuable practice is maintaining a clear internal record of which team or person owns each registered Client ID, when it was created, and when it was last rotated. When dozens of integrations accumulate over the years, this simple bookkeeping habit prevents “orphaned” credentials from lingering, unmonitored, long after the project that created them has been forgotten.

Learning what not to do is often just as instructive as learning the right approach.

Seeing how major platforms handle this exact pattern makes the abstract concept concrete.

Google Cloud Console

When a developer creates an “OAuth 2.0 Client ID” inside Google Cloud Console, they choose an application type — Web application, Android, iOS, or Desktop app — and Google tailors what it issues accordingly. Web applications receive both a Client ID and a Client Secret, while Android and iOS entries receive only a Client ID, reflecting the confidential-versus-public client distinction covered earlier.

GitHub OAuth Apps

GitHub’s developer settings let any user register an “OAuth App,” immediately generating a Client ID visible in the dashboard and a Client Secret that can be regenerated on demand. GitHub explicitly labels the secret with a warning that it should be treated like a password and never shared publicly, directly reflecting the trust it carries.

Slack App Management

Slack’s app configuration panel separates “Basic Information,” where the Client ID and Secret live, from “OAuth & Permissions,” where scopes and redirect URLs are configured — a structural choice that mirrors the architecture described in Chapter 5, keeping identity credentials distinct from permission configuration.

Stripe’s Connect Platform

Stripe Connect, used by platforms that let businesses accept payments through Stripe, issues a Client ID for OAuth-based account connections while separately managing API secret keys for direct server-to-server calls — illustrating how larger platforms sometimes maintain multiple related-but-distinct credential systems for different integration patterns.

Despite differences in branding and dashboard layout, every one of these platforms is solving the exact same problem described in Chapter 3, using the exact same two-piece pattern: a public identifier and a private proof, issued together, used at different moments, and protected with different levels of care.

Quick, direct answers to the questions beginners ask most often.

No. The Client ID is designed to be public and often appears in URLs or visible app configuration. Only the Client Secret needs to be protected.

No. Each registered application receives a unique Client ID from the authorization server, which is what allows per-application tracking, revocation, and consent-screen accuracy.

The authorization server rejects the token request entirely, even if the authorization code and Client ID were both completely valid, because all three pieces must match together.

Mobile apps are public clients — their code can be inspected or decompiled by anyone who installs them, so any embedded secret cannot remain genuinely secret. PKCE is used instead.

The Client Secret identifies the application itself and rarely changes. An access token represents a specific, time-limited permission grant, is much shorter-lived, and is issued fresh for each session or renewal.

No. It should only ever travel directly between a trusted backend server and the authorization server’s token endpoint, never through the end user’s browser.

At minimum, a git-ignored environment variable file for local development, and a proper secrets manager or encrypted configuration store for any deployed environment.

Not immediately. Existing, already-issued access tokens and refresh tokens typically remain valid until they naturally expire, but any brand-new token requests must use the new secret going forward.

The Client ID and Client Secret form the quiet foundation underneath nearly every “Sign in with Google,” “Connect your GitHub,” or “Authorize this app” experience on the modern web. The Client ID openly announces which application is making a request, while the Client Secret privately proves that the announcement is genuine — together turning a system that would otherwise trust anyone into one that only trusts applications it has verified in advance. From registration through daily use, through rotation and eventual retirement, these two small strings of text carry an outsized share of the responsibility for keeping OAuth 2.0 trustworthy.