Before service accounts make sense, you need a quick picture of the system they live inside.

Keycloak is an open-source Identity and Access Management (IAM) server. Its job is to answer two questions for every request that hits your applications: “Who are you?” (authentication) and “What are you allowed to do?” (authorization). Instead of every application writing its own login page, password database, and permission logic, they all delegate that work to Keycloak. Keycloak issues digital tokens — small, cryptographically signed pieces of text — that prove identity and carry permissions, and applications simply trust those tokens.

Keycloak organizes everything inside a realm — an isolated space containing its own users, applications (“clients”), roles, and policies. Within a realm, you register each application as a client. A client can be a web app, a mobile app, an API, or — importantly for this tutorial — a backend service that has no human user directly attached to it.

A service account in Keycloak is a special, automatically generated user that represents an application instead of a human being. When you register a confidential client in Keycloak and enable the “service accounts” option on it, Keycloak silently creates a hidden user behind the scenes, usually named something like service-account-<client-id>. This hidden user has no password, never logs in through a browser, and never sees a login screen. Instead, the client itself authenticates using its own client credentials (a client ID and a client secret, or a certificate), and Keycloak treats that authentication as if this invisible user had logged in.

Why does this matter? Because most authorization systems, including Keycloak, are built around the idea of a “subject” that holds roles and permissions. Humans are subjects. But machines — batch jobs, microservices, cron scripts, CI/CD pipelines, IoT devices — also need to be subjects sometimes. Rather than inventing a completely separate permission system just for machines, Keycloak reuses its existing user-and-role model and simply gives each machine client a dedicated, machine-only “user” to hang roles on.

Practically speaking, this means a service account can do almost everything a normal user can do inside the authorization model: it can be assigned realm roles, client roles, and group memberships (in newer Keycloak versions), and those roles will appear inside the access token the client receives. The one thing it typically cannot do is interactively log in through the standard browser-based login form, because it has no password and no human behind it.

Every design decision in software exists to solve a real problem. Here is the problem service accounts solve.

Modern systems are rarely a single application. A typical setup includes a frontend, several backend microservices, a message queue, a batch-processing job, a reporting tool, and a CI/CD pipeline that deploys new versions automatically. Many of these components need to call each other’s APIs — with no human sitting at a keyboard to type a username and password. If you don’t have a proper mechanism for this, teams tend to fall into two bad habits:

Service accounts exist specifically to close this gap. They let machine-to-machine (M2M) communication use the exact same trusted identity infrastructure that human logins use — the same token format, the same signing keys, the same audit trail, the same role model — without ever needing a human’s credentials or an insecure shortcut.

Let’s look at the moving pieces that make a service account work.

A Keycloak service account is built from a small number of interlocking pieces. Understanding each one individually makes the whole picture click into place.

All of these pieces live inside a single realm. The client and its service-account user are two separate objects in Keycloak’s data model, but they are permanently bound together — you cannot delete one without affecting the other, and you generally manage the service account’s roles from a dedicated “Service Account Roles” tab right on the client’s own configuration page.

graph TD
    A[Confidential Client] -->|has service accounts enabled| B[Service Account User]
    B -->|assigned| C[Realm Roles]
    B -->|assigned| D[Client Roles]
    A -->|authenticates with| E[Client ID and Secret]
    E -->|sent to| F[Keycloak Token Endpoint]
    F -->|issues| G[Access Token]
    G -->|contains| C
    G -->|contains| D
    G -->|presented to| H[Protected API / Resource Server]
        

When an administrator flips the “Service Accounts Enabled” switch on a client and saves it, Keycloak performs a small but important sequence of internal steps. Understanding this sequence removes a lot of the mystery around why the feature behaves the way it does.

This is the actual conversation that happens between an application and Keycloak, step by step.

Service accounts authenticate using an OAuth 2.0 flow called the Client Credentials Grant. It is deliberately the simplest of all OAuth2 flows, because there is no human involved to redirect to a login page, type a password, or click “Allow.” The application simply presents its own identity directly.

sequenceDiagram
    participant App as Backend Service (Client)
    participant KC as Keycloak Token Endpoint
    participant API as Protected Resource API

    App->>KC: POST /token grant_type=client_credentials, client_id, client_secret
    KC->>KC: Validate client_id and secret
    KC->>KC: Load service account user and its roles
    KC-->>App: Access Token (JWT with roles/claims)
    App->>API: Call API with Authorization: Bearer token
    API->>API: Verify token signature and roles
    API-->>App: Response (allowed or denied based on roles)
        

Notice what is absent from this diagram: there is no browser redirect, no login form, and no consent screen. The entire exchange happens in a single, direct, server-to-server HTTP call. This is precisely why service accounts are the right tool for machine-to-machine communication and the wrong tool for anything involving a human user — humans should always go through an interactive flow (like Authorization Code) so they can see and control what they’re logging into.

The resulting access token is a signed JSON Web Token (JWT). Inside it, the “subject” claim identifies the service account user, and the roles/claims sections list every realm role and client role that was assigned to that service account. Downstream APIs never need to call back to Keycloak to check permissions for every request — they simply verify the token’s digital signature and read the roles straight out of it. This makes the whole system fast, because trust is established once, at token-issuance time, and then carried along inside the token itself for its short lifetime.

A service account is powerful precisely because it needs no human to operate it — which is exactly why it must be protected carefully.

Because a service account’s “password” is really just a shared secret string (or, in stronger setups, a certificate), that secret becomes the single point of trust for the entire identity. If it leaks — say, it’s accidentally committed to a public code repository — anyone who finds it can impersonate the application, with whatever roles that account holds, for as long as the secret remains valid.

Keycloak provides several tools that meaningfully reduce this risk when used correctly:

It’s also worth understanding what a service account cannot do by default. It cannot perform interactive login, meaning phishing attacks that target humans (fake login pages, for example) simply do not apply to it. Its entire attack surface is the secret itself and the roles attached to it — which is exactly why hardening those two things covers the overwhelming majority of real-world risk.

Over years of production use, a handful of clear patterns have emerged for how teams successfully use Keycloak service accounts — and a matching set of anti-patterns that consistently cause pain later.

On the positive side, the pattern that scales best in real organizations is one client per service, one service account per client, and roles granted individually per integration. This “principle of least privilege at the identity level” mirrors good practice in cloud IAM systems generally, and it makes incident response dramatically simpler — if one service is compromised, you disable exactly one client and nothing else breaks.

A service account you can’t observe is a service account you can’t fully trust.

Because service accounts operate without a human clicking anything, unusual behavior can slip by unnoticed unless it is deliberately monitored. Keycloak surfaces several signals worth watching in production environments.

Keycloak’s admin event log can record every time a client’s roles are added or removed, and its login/token event stream shows every successful and failed client-credentials exchange. Piping these events into a centralized logging or SIEM system lets a team notice, for example, a service account suddenly requesting tokens far more often than its normal baseline — a common early sign of a leaked secret being abused by an attacker.

It also helps to track metrics such as token request rate per client, average token lifetime remaining at time of use, and the count of distinct IP addresses a given client authenticates from. A service account that suddenly authenticates from a new, unexpected network location is a strong signal worth investigating immediately, since — unlike a human — a legitimate service typically runs from a small, predictable set of infrastructure.

Service accounts of this general shape — a non-human identity with a secret and a scoped set of permissions — are not unique to Keycloak. The same underlying idea appears across the industry under different names, which helps put Keycloak’s approach in context.

This convergence across platforms is not a coincidence — it reflects a shared, well-understood principle in identity engineering: humans and machines need different authentication mechanisms, but they can share the same underlying authorization model. Keycloak simply applies that principle using standard OAuth2/OIDC building blocks, which is part of why it integrates cleanly with so many other systems that already speak the same protocol.

No. A service account has no password, so it cannot be used with the interactive, browser-based login form. It can only be used through the Client Credentials Grant, called directly by the application’s backend code.

No. Service accounts must be explicitly enabled on a client, and only confidential clients (never public clients) are allowed to have one, since only confidential clients can safely hold a secret.

In modern Keycloak versions, yes — a service account user can be placed into groups just like a regular user, which is a convenient way to grant it a bundle of roles at once instead of assigning each role individually.

The linked service account user is deleted along with it, since it exists only as an extension of that specific client and has no independent life of its own.

No. By default a service account has no special privileges at all. It only gains administrative power if an administrator explicitly assigns it administrative roles — which, per the security best practices covered earlier, should be avoided unless truly necessary.

No. The relationship is strictly one-to-one — each confidential client with service accounts enabled gets its own dedicated, uniquely named service account user.

A Keycloak service account is, at its heart, a small but elegant solution to a very common problem: how do applications prove who they are to each other without a human typing a password? By quietly creating a dedicated, passwordless user behind every confidential client, Keycloak lets machine-to-machine communication use exactly the same trusted token infrastructure, role model, and audit trail that human logins use — no shortcuts, no shared “robot” passwords, no disabled security between internal services. Used with narrowly scoped roles, rotated secrets, and proper monitoring, service accounts become one of the most reliable building blocks for secure automation in any system built on Keycloak.