Keycloak Clients: Configure OIDC and OAuth2 Apps (2026)

Keycloak clients aren’t just about registering an application; they’re the fundamental building blocks that define how your application interacts with Keycloak’s security services.

Imagine you’ve got a web application that needs to log users in using Keycloak. You create a "client" in Keycloak for this web app. This client configuration is where you tell Keycloak:

• What kind of application is this? Is it a web app, a public mobile app, a service that needs to call other services on behalf of a user, or a confidential service that manages its own credentials?
• How should Keycloak redirect users after they log in or log out? This is crucial for security, preventing open redirect vulnerabilities.
• What information (scopes) can this application request about the user?
• What are the credentials (if any) this application uses to authenticate itself to Keycloak?

Let’s walk through configuring a standard OIDC/OAuth2 web application client.

Setting Up a Confidential Client for a Web App

This is the most common scenario: a server-side web application that can securely store a client secret.

1. Navigate to Clients: In your Keycloak realm, go to "Clients" in the left-hand menu.
2. Create Client: Click "Create client."
3. Client ID: This is a unique identifier for your application. Let’s call it my-web-app.
4. Client Protocol: Select openid-connect.
5. Client Type: Choose confidential. This is key. It means your application will authenticate to Keycloak using its client ID and a secret, which should be stored securely on your server.
6. Create: Click "Create."

Now, you’re on the "Settings" tab for your new client.

• Valid Redirect URIs: This is critical. Enter the exact URLs where Keycloak is allowed to redirect users after successful authentication or logout. For a local development setup, this might be http://localhost:8080/callback. In production, it would be your application’s domain, e.g., https://myapp.example.com/oidc/callback. You can use wildcards like http://localhost:8080/* for development convenience, but be restrictive in production.
• Web Origins: This relates to CORS (Cross-Origin Resource Sharing). If your application serves content from a different origin than where your API or Keycloak is hosted, you’ll need to specify those origins here. For a typical single-origin web app, you might leave this blank or add +.
• Base URL: The base URL of your application. Useful for Keycloak to generate links.
• Root URL: Similar to Base URL, often the same.

Accessing Client Secrets and Credentials

Scroll down to the "Credentials" tab for your client.

• Client Secret: This is what your web application uses to authenticate itself to Keycloak. It’s like a password for your application. Treat this like a password. Do not embed it directly in frontend JavaScript. Your backend application will use this secret along with its Client ID to exchange an authorization code for an access token. You can regenerate it if it’s compromised.

Understanding Scopes

Navigate to the "Scope" tab.

• Default Scopes: These are scopes automatically granted to the client. openid is always there for OIDC. email and profile are common defaults for basic user information.
• Optional Scopes: These are scopes your application can explicitly request during the authorization flow. For example, if your application needs access to a specific role or group information, you might define a custom scope for that.

The Authorization Code Flow (How it Works)

When a user tries to access a protected resource in your my-web-app:

1. Your app redirects the user’s browser to Keycloak’s authorization endpoint, including your client_id, the requested scope, redirect_uri, and response_type=code.
2. Keycloak authenticates the user (e.g., login form).
3. If successful, Keycloak redirects the user’s browser back to your redirect_uri with an authorization_code.
4. Your backend application receives this code.
5. Your backend then makes a server-to-server request to Keycloak’s token endpoint. It sends the client_id, client_secret, grant_type=authorization_code, the code it received, and the redirect_uri.
6. Keycloak validates all of this and, if correct, returns an access_token, an id_token (for OIDC), and a refresh_token.
7. Your application uses the access_token to make authenticated requests to your resource servers (APIs).

Public Clients for Single-Page Applications (SPAs)

If your application is a pure Single-Page Application (SPA) running entirely in the browser (e.g., React, Vue, Angular), you cannot securely store a client_secret.

1. Create Client: Follow the same steps as above, but for Client Type, choose public.
2. Valid Redirect URIs: Still essential.
3. Web Origins: Also essential.
4. Credentials Tab: You won’t find a "Client Secret" here.

SPAs use flows like the Authorization Code Flow with PKCE (Proof Key for Code Exchange). PKCE adds a security layer by requiring the client to generate a secret per request that Keycloak can verify, effectively compensating for the lack of a static client_secret.

Keycloak Clients and Service Accounts

You can also configure clients to represent services that need to authenticate themselves to Keycloak, not on behalf of a user, but as the service itself.

• Client Type: confidential
• Service Accounts Enabled: Set to On.
• Credentials Tab: This client will have a client_secret.
• Fine-grained Access: You can then grant this service account client specific roles or permissions within Keycloak, allowing it to manage users, realms, or other resources. This is common for CI/CD pipelines or backend services that need to interact with the Keycloak Admin API.

The most surprising thing about Keycloak clients is that they are not just configuration endpoints but also act as the gatekeepers for what information and actions an application can perform, enforced at the Keycloak level before any request even hits your application’s backend. This separation of concerns is powerful.

When you enable "Direct Access Grants Enabled" or "Implicit Flow Enabled" on a client, you’re essentially allowing less secure or older OAuth2 flows that are generally discouraged for modern web applications due to security risks like token leakage in browser history. The Authorization Code Flow with PKCE for public clients and the standard Authorization Code Flow for confidential clients are the recommended patterns.