Keycloak Openid Scope
You set up a keycloak openid scope by adding it to your client request. This step tells the login server to return an ID token with user claims. Most teams start by sharing one broad client role across many backend systems. When roles are too broad, one token lets users run any command they want. How a keycloak openid scope works in practice Standard OAuth flows only handle basic permissions for an app. Adding the OpenID scope switches the login flow to an identity check. The client app sends
Keycloak + OpenID Connect (OIDC): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up a keycloak openid scope by adding it to your client request. This step tells the login server to return an ID token with user claims. Most teams start by sharing one broad client role across many backend systems. When roles are too broad, one token lets users run any command they want.
How a keycloak openid scope works in practice
Standard OAuth flows only handle basic permissions for an app. Adding the OpenID scope switches the login flow to an identity check. The client app sends the user to the login server with this scope.
After the user logs in, the server builds a signed ID token. This token holds basic facts about the user, such as a unique subject ID. Teams also attach extra scopes to include email addresses or group roles.
Keycloak uses mappers to pull user attributes from your directory into the token. A mapper reads a user group and writes it as a claim. The client app then reads this signed token to confirm who logged in.
How teams map scopes to backend roles
Platform teams often map directory groups to claims inside the OpenID token. For example, a developer joins an engineering group in the main company directory. The login server puts that group name inside the user token during login.
Downstream tools and databases read that group claim to grant a local role. To save time, admins often map one group to a shared admin role. Every engineer in that group gets the same broad rights on the backend.
Managing dozens of tiny scopes for every single database table takes too much effort. Teams avoid scope sprawl by keeping token claims wide and simple. That choice makes login setup fast, but it creates a big security risk.
Keycloak + OpenID Connect (OIDC): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What token scopes solve and where they fall short
An OpenID scope does a great job proving who a person is. It stops unknown users at the front door before they reach your network. It also gives teams one central place to turn off a user account.
Still, a login scope only works at the moment the session starts. Once the user gets a valid token, the login server steps out of the way. The token scope cannot see what the user does inside the session.
A valid token does not check individual SQL queries or shell commands in flight. An engineer with a valid role can still run a bad delete statement. They can also read raw tables full of customer emails and card numbers.
Identity tokens also cannot mask sensitive fields like phone numbers or national IDs. If a query pulls customer rows, the database sends all the raw text back. To control actual commands and rewrite sensitive data, you need controls at the session level.
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 runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
What does the openid scope return in a token?
It tells the server to return an ID token alongside the access token. This ID token contains the user identity and basic login facts.
How is an OpenID scope different from a role?
A scope defines what facts about a user go into the token. A role defines what actions that user can take inside an app.
Can token scopes block dangerous database queries?
No, token scopes only work during login to issue claims. They do not inspect or block live SQL statements after the session starts.