Keycloak Public vs Confidential Clients: Which Should You Use?

In this article we will compare public and confidential OIDC clients in Keycloak 26.7.3 so you can pick the right type for each application. The difference is not that one client type is inherently more secure than the other. It depends on whether the application can safely keep a credential such as a client secret.

Public clients (browser SPAs, installed mobile apps) cannot keep a client secret. Confidential clients (server-side web apps, backend services that obtain tokens, batch jobs) can. In the current Admin Console that maps directly to Client authentication OFF or ON.

If you need client vocabulary first, read Keycloak clients explained before this page.

Public vs confidential clients at a glance

A public client still authenticates users. User login is separate from client authentication. Confidential means the client application itself can authenticate to Keycloak during token requests.

Public vs confidential clients in the Keycloak Admin Console

Client authentication OFF means a public client. Client authentication ON means a confidential client.

Keycloak 26.x replaces the old Access Type dropdown with Client authentication on Clients → client → Settings → Capability config.

Older tutorials may tell you to choose Access Type public or confidential. In the current Admin Console, use Client authentication OFF or ON instead.

Keycloak 26.7 documents that the old Bearer-only switch is deprecated and will be removed. Prefer an OIDC client that does not enable login grants when the application only represents a service or resource server.

Which client type should you use?

JavaScript bundles, mobile APKs, and desktop binaries ship to the user's device. Any static string you embed, including a so-called hidden client secret, can be extracted. Obfuscation does not make a browser app confidential.

Native mobile apps are public for the same reason: credentials embedded in the installed application cannot be treated as secret. If you use a backend-for-frontend pattern, the BFF can be a confidential client because its credential remains on the server. The browser normally talks to the BFF using the application's session rather than storing an OAuth client secret itself.

A resource API that only validates incoming access tokens is a separate case. Being a backend API alone does not automatically mean it needs client credentials.

How to configure a public client

For a browser SPA such as storefront-spa:

1. Set Client authentication to OFF.
2. Enable Standard flow.
3. Under Capability config, set PKCE Method to S256 and enable Require PKCE when you want Keycloak to enforce it.
4. Register exact SPA callback URLs under Valid redirect URIs. Avoid production wildcards.

Public clients cannot rely on a client secret, so redirect URIs should be as tight as possible. Redirect URI validation stops Keycloak from sending authorization responses to unregistered locations. PKCE separately stops someone who steals an authorization code from redeeming it.

Never call token endpoints with a client secret from frontend code.

How to configure a confidential client

For a server-side application such as storefront-web:

1. Set Client authentication to ON.
2. Enable Standard flow when users log in through this client.
3. Open Credentials and configure a client authenticator.
4. Enable Service account roles only when the application needs the client_credentials grant.

The OAuth credential lives in environment variables, a secrets manager, or the container platform, not in HTML sent to the browser. When Client authentication is ON, Keycloak needs proof that the caller is the registered application:

Rotate the secret if it leaks and update every server instance that reads it. The value never belongs in frontend repositories or mobile app config checked into git.

User authentication (username, password, MFA) is unrelated. That is the human logging in, not the OAuth client proving its identity.

Why public clients use PKCE

Public clients have no shared secret to present at the token endpoint, so they should use the authorization code flow with PKCE (Proof Key for Code Exchange), not the legacy implicit flow.

PKCE binds the authorize request to the later code exchange:

1. The client creates a random code_verifier and keeps it locally.
2. It sends a code_challenge (usually the S256 hash of the verifier) on the authorize request.
3. When exchanging the authorization code for tokens, it sends the original code_verifier. Keycloak checks that it matches the earlier challenge.

An attacker who intercepts only the authorization code cannot redeem it without the verifier.

On Keycloak 26.7.3, set this under Settings → Capability config → Require PKCE and PKCE Method → S256:

They are complementary. PKCE does not create a client identity, encrypt tokens, or make a public client confidential. A confidential server app may also use PKCE. A public SPA with PKCE remains public: there is still no client secret, and client_credentials stays unavailable.

Can a public Keycloak client use client_credentials?

No. In Keycloak, client_credentials requires a client that can authenticate itself and has Service account roles enabled. That is how a backend service obtains a token without a user logging in.

To use client_credentials:

• Client authentication ON
• Service account roles ON
• A configured client authenticator such as the generated secret

Then assign the service-account roles or scopes the application needs. Role assignment is not required merely to obtain a token; it controls what permissions and role claims the token carries. Public clients cannot use service accounts. For role mapping and token claims, see Keycloak service accounts.

A confidential client with service accounts enabled can call the token endpoint like this:

curl -s -X POST 'http://127.0.0.1:8080/realms/golinuxcloud/protocol/openid-connect/token' \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -d 'grant_type=client_credentials' -d 'client_id=storefront-web' -d 'client_secret=YOUR_CLIENT_SECRET'

Replace YOUR_CLIENT_SECRET with the value from Clients → storefront-web → Credentials. Sample trimmed response:

{"access_token":"eyJ...","expires_in":300,"token_type":"Bearer","scope":"profile email"}

The access token azp claim is storefront-web. The client authenticated as itself, not as an end user.

The same grant against public storefront-spa fails:

curl -s -X POST 'http://127.0.0.1:8080/realms/golinuxcloud/protocol/openid-connect/token' \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -d 'grant_type=client_credentials' -d 'client_id=storefront-spa'

Sample output:

{"error":"unauthorized_client","error_description":"Public client not allowed to retrieve service account"}

A public client cannot use the service-account client_credentials flow. For backend jobs or machine-to-machine calls, create a confidential client and enable service accounts.

Common mistakes

Summary

Choose public when the app cannot keep a credential (SPA, mobile). Choose confidential when a server you control can authenticate to Keycloak (server-rendered app, token-obtaining backend, batch job).

On Keycloak 26.x, Client authentication OFF is public and ON is confidential. That replaces the legacy Access Type dropdown. Public clients should use authorization code with PKCE (S256) and tight redirect URIs. Confidential clients use a secret or another authenticator, and enable service accounts only when they need client_credentials.

References

• Keycloak Server Administration Guide — OIDC clients
• OAuth 2.0 RFC 6749 — Client Types
• RFC 7636 — Proof Key for Code Exchange (PKCE)
• OpenID Connect Core 1.0