Keycloak Service to Service Authentication
You set up keycloak service to service authentication using the client credentials grant flow. One backend app sends its client ID and secret to get an access token. Teams often create shared machine accounts with broad roles so apps can talk fast. When you grant broad roles, one compromised app can read or change everything. How keycloak service to service authentication works In a backend system, apps must talk to each other without a human user. You register the calling app as a confidenti
Keycloak + Service-to-Service Authentication: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up keycloak service to service authentication using the client credentials grant flow. One backend app sends its client ID and secret to get an access token. Teams often create shared machine accounts with broad roles so apps can talk fast. When you grant broad roles, one compromised app can read or change everything.
How keycloak service to service authentication works
In a backend system, apps must talk to each other without a human user. You register the calling app as a confidential client inside your identity server. Then you turn on the service account feature for that specific client. This step creates a dedicated machine identity that belongs only to that app.
When the first app needs data, it calls the token endpoint directly. It sends its client ID and a secret key or signed certificate. The identity server checks these credentials against its internal database of registered clients. If the check passes, the server returns a signed JSON Web Token.
The calling app attaches this token to its request to the second app. The receiving app checks the token signature using the public keys of the server. It also reads the token claims to check the expiration time and audience. This flow proves who sent the request without passing raw passwords between apps.
Assigning roles and scopes to machine accounts
Once an app can get a token, you must restrict what it can do. You create specific roles inside the target app definition on the identity server. Then you map those roles to the service account of the calling app. The identity server embeds these role names inside the access token payload.
You can also use client scopes to limit which roles appear in the token. Scopes keep the token small and ensure it only holds needed permissions. If an app talks to three services, it should ask for narrow scopes. Each target service then checks the token for its own required role name.
Teams must also rotate client secrets and signing keys on a set schedule. If a secret leaks in a log file, an attacker can mint valid tokens. Using signed certificates instead of static secrets reduces the risk of leaked strings. Still, managing certificates across dozens of backend services takes constant work from your team.
Keycloak + Service-to-Service Authentication: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Where identity tokens fall short at runtime
Identity tokens do a great job of proving which app sent a request. They also help the target app decide whether to allow the initial call. Still, the token setup only controls who logs in at the front door. It does not inspect what individual requests, queries, or commands do in flight.
Once a service passes the token check, its role stays fixed for that call. A valid token with read permissions might still fetch thousands of sensitive user rows. The identity server cannot see the actual data flowing back to the caller. It cannot mask emails, phone numbers, card numbers, or national IDs in results.
Also, token logs only show when an app asked for a new token. They do not record every action the app took while using that token. Security teams need visibility into the exact commands and queries running across services. Combining identity checks with runtime controls closes this gap for backend apps.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
What OAuth flow should I use for backend services?
Use the OAuth 2.0 client credentials grant flow for machine to machine calls. It lets an app log in using its own identity instead of a user account.
How do I stop one app from calling every other service?
Use audience claims and narrow client roles inside your token setup. Each receiving app must check that its own name appears in the token audience.
Should I use client secrets or certificates for service accounts?
Certificates are safer because the private key is masked in responses before reaching over the network. If you use shared secrets, store them in a vault and rotate them often.