Before OAuth 2.0 can trust an application, it needs to answer a surprisingly basic question: can this application actually protect a secret, or not?

Early designs for delegated access assumed every application was roughly the same kind of thing — a piece of software running somewhere the developer controlled, capable of holding onto a password-like value and never exposing it. That assumption works fine for a backend web server sitting in a company’s own data center. Nobody outside the company can open that server and read its configuration files. But the moment OAuth needed to support mobile apps and browser-based apps, that assumption fell apart.

This isn’t a hypothetical concern. A mobile app’s installer file can be downloaded by anyone and taken apart piece by piece. A single-page web application’s entire JavaScript source is, by definition, sent to and executed inside the user’s own browser — the user’s browser has to be able to read it in order to run it. In both cases, anything embedded in that code — including a supposedly secret value — should be treated as effectively public information, because a sufficiently motivated person can always extract it.

OAuth 2.0’s answer to this reality is to formally split applications into two categories — confidential clients and public clients — and to require different behavior from each. This tutorial walks through exactly what that split means, how the Authorization Server decides which category an app falls into, and how the rest of the protocol bends around that decision.

This isn’t just an academic label buried in a specification document — it directly shapes engineering decisions that teams make every single day. Whether a mobile team needs to stand up a backend service purely for authentication, whether a browser extension can safely call a third-party API directly, whether a secret needs a rotation schedule at all — every one of these questions traces back to whether the application in question is confidential or public. Getting this classification wrong early in a project tends to surface later as a security review finding, a failed compliance audit, or, worse, an actual incident where a “hidden” credential turns out to have been public all along.

A handful of terms carry the entire chapter — once these are clear, everything else in this tutorial builds on top of them.

A few common misunderstandings are worth clearing up before going further.

Here’s how the confidential/public split maps onto the kinds of applications people actually build.

Confidential clients don’t just have “a secret” — OAuth defines several different ways that secret, or an alternative credential, can be presented.

Public clients use the “none” method not because authentication doesn’t matter, but because there’s genuinely nothing secret left to authenticate with. Instead of proving who the client is through a credential, the system leans on other tools — PKCE to prove continuity within one specific flow, and a pre-registered, tightly checked redirect address to ensure tokens only ever reach the legitimate app instance.

Choosing between these methods in practice usually comes down to how much operational effort a team is willing to invest versus how sensitive the data behind the integration is. client_secret_basic and client_secret_post are simple to implement and widely supported, which makes them the default choice for most confidential clients. private_key_jwt and mTLS require managing cryptographic key pairs or certificates, which adds real operational overhead — generating, distributing, and eventually rotating keys — but removes the risk of a shared secret ever being transmitted or stored in a form that could be copied wholesale. Organizations handling especially sensitive data, such as financial transactions or health records, frequently mandate the stronger methods specifically because they eliminate that shared-secret exposure entirely.

There’s also a practical difference in how each method behaves when something goes wrong. With client_secret_basic or client_secret_post, a leaked secret can be used by an attacker for as long as it remains valid, with no way to distinguish the attacker’s requests from the legitimate application’s own requests — both simply present the same value. With private_key_jwt, the client signs a fresh statement for every single request rather than transmitting a reusable secret, so even observing one signed request doesn’t hand an attacker anything they could replay later. This difference is why security-conscious teams increasingly favor signature-based methods for their most sensitive confidential clients, even though the simpler shared-secret methods remain perfectly adequate for lower-risk integrations.

The four core OAuth roles stay the same regardless of client type — but the path a request takes, and who holds what, shifts noticeably.

flowchart TD
    subgraph Confidential["Confidential Client Architecture"]
        U1["Resource Owner"] --> B1["Backend Server
(holds client secret)"]
        B1 -- authenticated token request --> AS1["Authorization Server"]
        B1 -- access token --> RS1["Resource Server"]
    end
    subgraph Public["Public Client Architecture"]
        U2["Resource Owner"] --> B2["Mobile App / SPA
(no secret, uses PKCE)"]
        B2 -- unauthenticated + PKCE proof --> AS2["Authorization Server"]
        B2 -- access token --> RS2["Resource Server"]
    end
        

In the confidential architecture, a backend server sits between the end user and the Authorization Server for the sensitive parts of the exchange, and that backend is the only place the client secret ever lives. In the public architecture, there is no such intermediary — the mobile app or browser talks directly to the Authorization Server, presenting a PKCE proof instead of a secret. Both architectures still produce an access token that gets sent to the Resource Server in the end; the difference is entirely in how the client proves itself along the way.

Here’s the token exchange step specifically from a confidential client’s point of view — the part of the flow where its secret actually gets used.

sequenceDiagram
    participant User as Resource Owner
    participant Backend as Confidential Client (Backend)
    participant AS as Authorization Server
    participant RS as Resource Server

    Backend->>AS: Redirect user with scopes
    AS->>User: Show login and consent screen
    User->>AS: Approve requested scopes
    AS->>Backend: Redirect back with authorization code
    Backend->>AS: Exchange code + client secret for tokens
    AS->>Backend: Return access token and refresh token
    Backend->>RS: API request with access token
    RS->>Backend: Return requested data
        

Notice that the client secret is used exactly once per token exchange — at step four — and only ever travels between the backend server and the Authorization Server, never through the user’s browser. This is precisely what makes it viable: the secret’s confidentiality depends on it staying inside infrastructure the developer controls from beginning to end.

Public clients follow a similar shape, but replace “prove you know the secret” with “prove you’re the same app that started this flow.”

sequenceDiagram
    participant User as Resource Owner
    participant App as Public Client (Mobile/SPA)
    participant AS as Authorization Server
    participant RS as Resource Server

    App->>App: Generate code verifier + code challenge
    App->>AS: Redirect user with scopes + code challenge
    AS->>User: Show login and consent screen
    User->>AS: Approve requested scopes
    AS->>App: Redirect back with authorization code
    App->>AS: Exchange code + code verifier for tokens
    AS->>App: Return access token (and refresh token, if allowed)
    App->>RS: API request with access token
    RS->>App: Return requested data
        

Before any of the flows above can run, an application has to be registered with the Authorization Server — and that registration is where its client type is locked in.

flowchart TD
    A["Developer registers a new application"] --> B{"Can the app keep a secret confidential?"}
    B -- Yes --> C["Registered as Confidential Client"]
    B -- No --> D["Registered as Public Client"]
    C --> E["Issued Client ID + Client Secret"]
    D --> F["Issued Client ID only"]
    E --> G["Secret stored securely, rotated periodically"]
    F --> H["App relies on PKCE + redirect URI checks per flow"]
        

Registration typically happens once, when a developer creates a new application entry in the Authorization Server’s dashboard or through an automated process called dynamic client registration. At that point, the developer (or an automated policy) declares the client’s type, its allowed redirect addresses, and which scopes it may request. From then on, every login attempt from that application is checked against these registered settings.

For confidential clients, the lifecycle doesn’t end at registration — client secrets are typically rotated periodically, meaning a new secret is issued and the old one retired on a schedule, or immediately if a leak is suspected. This is straightforward because the secret lives in infrastructure the developer controls and can update centrally. Public clients have no equivalent secret to rotate; instead, their ongoing security depends on keeping the app itself updated, since a security fix to the PKCE implementation, for instance, only reaches users once they update the app.

Dynamic client registration adds another layer worth understanding. Rather than a developer manually filling out a form in an Authorization Server’s dashboard, some systems allow applications to register themselves programmatically at runtime — useful for platforms where many independent client instances need their own registration, such as an enterprise software product installed separately by hundreds of customer organizations. Even in this automated case, the confidential-versus-public decision still has to be made explicitly as part of the registration request; automation changes how the decision is recorded, not whether it needs to be made.

Confidential and public clients aren’t just handled differently by convention — each faces a genuinely different threat model.

It’s worth stepping back to notice what these defenses have in common: none of them depend on the client type staying secret from an attacker. An attacker can know perfectly well that a given app is a public client, know its Client ID, and even see its entire source code — and still be unable to complete a login on someone else’s behalf, because PKCE ties each flow to the specific device that started it, and the redirect URI check ensures results only ever land back with the legitimate app. This is a deliberate design principle: OAuth’s security for public clients was built to hold up even under the assumption that the attacker already knows everything about the client’s own code.

Neither client type is simply “better” — each fits a different kind of application, with its own costs.

Because the two client types face different risks, the signals worth watching differ slightly between them too.

Some ways of handling client type reflect solid engineering; others reintroduce exactly the risk this whole classification exists to avoid.

A condensed checklist for treating client type as a first-class design decision rather than an afterthought.

It also helps to revisit this classification whenever an application’s architecture changes, not just when it’s first built. A tool that started as a simple command-line script talking directly to an API might later grow a companion web dashboard with its own backend — at that point, the original command-line client may still be public, but the new dashboard component deserves its own, separate confidential-client registration rather than inheriting settings meant for a different kind of application. Treating client classification as a one-time decision made at project kickoff, rather than something revisited as the system evolves, is one of the quieter ways teams end up with a mismatch between an app’s real environment and how it’s been configured to authenticate.

This split shows up constantly once you know to look for it — often as the quiet reason two similar-looking apps are built so differently underneath.

Not as a single registration, but an application’s different components often are registered separately — for example, a mobile app (public) and its backend service (confidential) are typically two distinct client registrations working together.

PKCE was originally designed for public clients, but modern guidance recommends using it for confidential clients too, as an extra layer of protection against authorization code interception — it doesn’t replace client authentication, it complements it.

Nothing dangerous on its own — the Client ID was never meant to be secret in the first place. It only identifies which app is making a request; actual protection for public clients comes from PKCE and redirect URI validation, not from hiding the Client ID.

Many Authorization Servers do issue refresh tokens to public clients, but often with extra safeguards like rotation on every use and shorter overall lifetimes, precisely because there’s no client authentication backing them up the way there is for confidential clients.

No. HTTPS protects data while it travels over the network, but it does nothing to protect a value once it has already arrived and been installed on the user’s own device, where the app’s code itself can be inspected directly.

Requiring a backend for every application would be impractical — many useful apps, like offline-capable mobile tools or simple browser extensions, are genuinely meant to run entirely on the user’s device. OAuth’s public-client model exists precisely to support these cases safely, rather than forcing unnecessary infrastructure on every developer.

OAuth 2.0’s confidential-versus-public split comes down to one honest question: can this application’s environment actually protect a secret, or not? Backend servers, running entirely inside infrastructure a developer controls, can — and are trusted with client secrets, stronger authentication methods, and server-side token storage. Mobile apps, browsers, and other user-controlled environments generally cannot — and instead lean on PKCE, strict redirect URI matching, and careful token handling to stay safe without ever needing a secret that couldn’t really stay secret. Neither category is inherently more trustworthy or more secure; each is simply matched to a different set of real-world constraints, and understanding which one an application belongs to is one of the first and most consequential decisions in designing any OAuth integration.