Before comparing the two, let’s understand what a “client” is and why Keycloak needs to classify them differently at all.

A Quick Refresher: What Is a Client?

In Keycloak, a client is any application that has been registered to use Keycloak for login — a website, a mobile app, a backend service, or a single-page application. Every client is given a unique identifier so Keycloak knows exactly which application is asking for a login at any given moment.

The Core Question Keycloak Asks

When registering a client, Keycloak asks one crucial question: can this application safely keep a secret hidden from end users and potential attackers? The honest answer to that question depends entirely on where the application’s code actually runs, and it determines which of the two client types it should be.

This isn’t just a technical label — getting it wrong has real security consequences.

A client secret is meant to prove that a request genuinely came from your registered application, and not from an impostor pretending to be it. If that secret is embedded in code that runs on a user’s own device — like a mobile app or a browser-based single-page application — a sufficiently motivated user could extract it by inspecting the app’s files or its network traffic. Once extracted, that secret is no longer secret at all, and the entire point of having one collapses.

With the concepts established, let’s compare the two directly across the dimensions that matter most.

The distinction isn’t just paperwork — it changes what Keycloak actually requires during every single login.

flowchart TB
    subgraph Public["Public Client Flow"]
        PU[Browser / Mobile App] -->|Auth Code, No Secret| PKC[Keycloak checks PKCE proof]
    end
    subgraph Confidential["Confidential Client Flow"]
        CS[Backend Server] -->|Auth Code + Client Secret| CKC[Keycloak checks Client Secret]
    end
    PKC --> TOK1[Tokens Issued]
    CKC --> TOK2[Tokens Issued]
        

How Public Clients Prove Legitimacy Without a Secret

Since a public client can’t hold a secret, Keycloak relies instead on a mechanism called PKCE (Proof Key for Code Exchange), pronounced “pixy.” Rather than a fixed secret, the application generates a random, one-time value at the start of the login, keeps a mathematically related “proof” locally, and presents that proof back to Keycloak at the very end of the flow. Even if someone intercepts the authorization code in transit, they can’t complete the exchange without also having generated that one-time proof themselves.

How Confidential Clients Prove Legitimacy With a Secret

A confidential client, running safely on a backend server, simply includes its pre-registered client secret directly when exchanging the authorization code for tokens. Since only the legitimate backend server ever holds that secret, Keycloak can trust that the request genuinely came from the real application.

Let’s walk through both flows side by side to see exactly where they diverge.

Public Client Login Flow

Confidential Client Login Flow

Many modern applications combine both client types to get the strongest possible security for browser-based apps.

A pure single-page application talking directly to Keycloak must be a public client, since its code runs entirely in the user’s browser. But some teams prefer to avoid even handling tokens in the browser at all. In this pattern, called Backend for Frontend (BFF), a small backend server sits between the browser and Keycloak. That backend is registered as a confidential client, safely holding the client secret and any refresh tokens, while the browser itself only ever talks to this trusted backend, never directly to Keycloak’s token endpoint.

Choosing between the two isn’t a permanent architectural decision made in code alone — it’s a setting configured directly in Keycloak.

Administrators make this decision while registering a new client, based entirely on an honest assessment of where and how that application actually runs — not based on how “important” the application feels, and not something that should be changed casually once real users depend on it.

Each client type comes with its own genuine strengths and limitations, rather than one simply being “better” than the other.

Neither type is inherently more secure in the abstract — each is the correct, secure choice for its own kind of environment, and the real risk comes from mismatching a client’s type to where it actually runs.

Regardless of which type an application uses, a few security practices deserve extra attention.

Watching how each client type behaves in production helps catch misconfiguration and misuse early.

Keycloak’s event logs capture client authentication attempts and failures, giving administrators the visibility needed to spot a misconfigured client type or a potential attack before it causes real damage.

Real-world Keycloak deployments have converged on clear guidance around choosing and managing client types correctly.

Concrete, actionable guidance for getting client type classification right the first time.

This distinction shows up constantly across everyday software architecture, even when developers don’t explicitly think in these exact terms.

This pattern repeats across virtually every modern software architecture: whatever runs directly on a user’s device is public, and whatever runs safely on a company-controlled server is confidential.

Yes, this can be changed in the Admin Console, though it typically requires updating the application’s code to handle the new authentication requirements correctly.

PKCE is mandatory for public clients, but many organizations also enable it for confidential clients as an additional layer of protection, since it adds security without real downsides.

The embedded client secret can likely be extracted from the app’s code, giving a false sense of security rather than genuine protection — it should be reconfigured as a public client using PKCE instead.

Not inherently — when properly configured with PKCE and restricted redirect URIs, public clients offer strong security appropriate to their environment; they simply rely on different mechanisms than confidential clients do.

Yes, this is common in the Backend for Frontend pattern, where a browser-based frontend and its dedicated backend are registered as two separate clients with two different types.

Keycloak generates it automatically when a client is configured as confidential, and it can be viewed or regenerated by an administrator directly from that client’s Credentials tab in the Admin Console.

The difference between a Public Client and a Confidential Client in Keycloak comes down to one honest question: can this application actually keep a secret safe from anyone who might run or inspect it? Applications running on a user’s own device — browsers, mobile apps — cannot, and should be registered as public clients relying on PKCE for security. Applications running on a company-controlled backend server can, and should be registered as confidential clients using a genuinely private client secret. Getting this classification right, rather than optimistically hoping nobody inspects the code, is foundational to building a Keycloak integration that’s actually secure rather than just appearing secure.