Client Scope Keycloak
A client scope keycloak setup groups roles and claims into one reusable unit. You link this unit to apps so tokens carry only needed user data. Many teams start by putting every role into one shared default scope. This makes early app setup fast for the whole team. Soon, every token holds admin roles for systems the app does not touch. A stolen token then gives an attacker wide reach across your backend. How a client scope keycloak design works In Keycloak, a client is an app or service that
Keycloak + Client-Initiated Backchannel Authentication (CIBA): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
A client scope keycloak setup groups roles and claims into one reusable unit. You link this unit to apps so tokens carry only needed user data. Many teams start by putting every role into one shared default scope. This makes early app setup fast for the whole team. Soon, every token holds admin roles for systems the app does not touch. A stolen token then gives an attacker wide reach across your backend.
How a client scope keycloak design works
In Keycloak, a client is an app or service that asks for tokens. Without scopes, you must build claim mappers and role rules on each client. If you run fifty apps, you must repeat that same work fifty times. A client scope solves this by acting as a shared template for tokens.
First, you create a scope and add protocol mappers to it. Protocol mappers read user details like groups or email addresses from your directory. They write those details into the token as claims when a user logs in. You can also attach role limits to the scope to restrict token powers.
Next, you bind the scope to your apps as default or optional. Default scopes always run when a user logs into that specific app. Optional scopes only run when the app asks for them during login. This keeps tokens small and stops apps from getting extra roles by mistake.
Where token scopes fall short in daily operations
Scopes do a great job of shaping the token during the login step. They prove who the user is and what high-level group they belong to. Your web apps and APIs can read these claims to hide admin buttons. They also help teams pass basic audit checks for central user login.
Still, a token scope stops working the moment the login step ends. It cannot see or control what a user does inside a live session. For example, an engineer might use an identity token to reach a database. Once inside, the token cannot block a bad command that drops a table.
Keycloak + Client-Initiated Backchannel Authentication (CIBA): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Static scopes also leave standing roles active all day and night. If an engineer needs write rights for ten minutes, the scope stays assigned. No one wants to edit identity scopes by hand before every bug fix. Teams also lack a clear log of which queries ran under that token.
Why runtime controls matter for databases and servers
Relying only on token claims forces you to manage hundreds of tiny scopes. You end up creating one scope per database table or server command group. Soon, your identity server becomes a slow mess of custom rules and roles. Even with all that work, you still cannot inspect live data in flight.
When a support engineer queries a user table, the token just says yes. It cannot rewrite email addresses, phone numbers, or card numbers in the output. True security needs both clean identity scopes at login and statement checks during work. Separating login claims from live session controls keeps your identity setup simple and safe.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev sits inline in the protocol beside each supported service as an open-source proxy, a sidecar for your database or API. For every query or command an AI agent or engineer runs against production, hoop.dev decides to pass, mask, block, or hold it for human approval.
First, hoop.dev guardrails block banned queries before they run or hold risky ones for review, and hoop.dev data masking rewrites matched sensitive values in responses in memory. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
What is the difference between a client and a client scope in Keycloak?
A client represents a single app that asks Keycloak to log users in. A client scope is a shared group of claims and roles for many clients.
When should I use an optional scope instead of a default scope?
Use a default scope for data the app needs on every single login. Use an optional scope for sensitive roles that the app only asks for sometimes.
Do Keycloak scopes restrict what queries an engineer runs in a database?
No, scopes only control what claims and roles go into the login token. They do not read or block live database queries after the session starts.