Keycloak Full Scope Allowed
The keycloak full scope allowed setting lets a client token carry every role a user owns. You turn it off in your client settings to limit which roles go into a token. Many teams leave this toggle on when they first set up a new app. That choice makes early testing fast and simple for developers. Still, broad token scopes give every connected app way too much power. If one small app gets compromised, attackers gain roles meant for other internal systems. How keycloak full scope allowed works i
Keycloak: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
The keycloak full scope allowed setting lets a client token carry every role a user owns. You turn it off in your client settings to limit which roles go into a token. Many teams leave this toggle on when they first set up a new app. That choice makes early testing fast and simple for developers. Still, broad token scopes give every connected app way too much power. If one small app gets compromised, attackers gain roles meant for other internal systems.
How keycloak full scope allowed works in token creation
Keycloak uses roles to track what a person can do across different apps. A user might hold admin rights in a billing tool and read rights in a dashboard. When that user logs in, the server builds an access token for the current app. If the full scope setting is active, the server puts all user roles into that token. The app receives roles for the billing tool, the dashboard, and every other system.
Turning this setting off changes how the server builds the token. With the toggle off, you must pick the exact roles that this specific client needs. The server then checks this approved list before it sends the token out. Even if a user is a super admin, the token only gets the mapped client roles. This keeps the token small and limits what the client can do on the user's behalf.
Teams also use client scopes to group common roles and claims together. You can attach a shared scope to several related apps at once. Each app still gets only the roles defined in its assigned scopes. This method saves time while keeping strict limits on every token.
Why narrow token scopes help with least privilege
Limiting token scopes stops lateral movement when an app token leaks. Suppose a low-risk reporting tool has a bug that exposes user tokens in error logs. If those tokens carry full scope, an attacker can use them against your core APIs. When you restrict the scope, that leaked token only works for the reporting tool. Other services check the token, see their required roles are missing, and block the request.
Smaller tokens also improve network speed and prevent header size errors. Users in big companies often collect dozens of groups and roles over time. Packing all of those roles into every token makes the token huge. Web servers and load balancers often reject requests when headers pass size limits. Trimming the scope keeps tokens compact so web requests do not fail.
Keycloak: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What token scope limits solve and what they miss
Configuring client scopes solves the problem of which roles reach an app during login. It ensures a frontend app cannot impersonate a user on an unrelated backend service. This setup acts as a strong first check at the door.
Still, token scopes only decide who logs in and which high-level role they hold. Once a user or service passes that check, the token grants standing permissions for the whole session. Keycloak does not see the actual database queries or shell commands that run next. An engineer with a valid admin role can still run a destructive delete statement by mistake. A valid role also does not filter sensitive data like emails or card numbers from query results. Teams still need a way to inspect individual commands and protect raw data during live sessions.
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 happens when I turn off full scope allowed on an existing client?
New tokens for that client will stop including roles unless you map them explicitly. You must assign the needed roles in the client scope settings so users do not lose access.
Does turning off full scope allowed remove roles from the user account?
No, the user keeps all of their assigned roles inside the identity server. The setting only filters which of those roles appear inside the token for that one client.
Why is my access token missing a role I assigned to the user?
Check if the full scope setting is off for that specific client app. If it is off, you need to add the missing role to the client scope list.