Keycloak Signed Jwt
You create a keycloak signed jwt by setting up a realm key pair and client app. After a user logs in, Keycloak signs the token with its private key. Teams use this setup to pass user roles to backend apps and databases. Still, broad roles inside these tokens often grant users too much power over live data. How a keycloak signed jwt works in practice Keycloak acts as the central login server for your team and your apps. First, an admin sets up a realm to hold users, groups, and signing keys. W
Keycloak: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You create a keycloak signed jwt by setting up a realm key pair and client app. After a user logs in, Keycloak signs the token with its private key. Teams use this setup to pass user roles to backend apps and databases. Still, broad roles inside these tokens often grant users too much power over live data.
How a keycloak signed jwt works in practice
Keycloak acts as the central login server for your team and your apps. First, an admin sets up a realm to hold users, groups, and signing keys. When a user logs in, Keycloak checks their password and MFA step. Next, the server builds a JSON payload with user details and role claims.
Keycloak then signs this payload using the active private key of the realm. This step creates the final token that the client app receives. The client sends this token along with every request to backend servers. Backend apps fetch the public key from the Keycloak realm endpoint to check the signature.
If the signature matches, the backend trusts the claims inside the token. No one can change the user ID or roles without breaking the signature. Teams also map group memberships into the token so backend systems know the user role. Key rotation happens in the realm settings so admins can retire old keys on a schedule.
Why token roles leave a gap during live sessions
A signed token proves who the user is and which group they belong to. It solves the login problem across web apps, APIs, and internal tools. Once the backend checks the token, the user gets an active session. That is where standard identity tokens stop helping your security team.
A token cannot see or control what a user does inside a database session. If a developer gets a write role, they can run any update or delete query. The token check happens at login, not when each SQL statement or shell command runs. A single bad query can still drop a table or pull sensitive rows.
Tokens also do not mask sensitive fields in query results. When a user queries a customer table, the database returns raw emails, phone numbers, and card numbers. The login server has no way to rewrite those matched fields in results. Also, token logs only show when someone logged in, not which commands they ran later.
Keycloak: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Best practices for managing realm keys and token claims
Keep your token lifespan short so stolen tokens expire within a few minutes. Short lifespans force client apps to refresh tokens often and check if the user is still active. Limit the number of claims you put inside each token. Large tokens slow down network calls and expose internal role names to client devices.
Set up audience claims so a token for one app cannot work on another service. Each backend service should check both the signature and the audience field on every call. Rotate your realm signing keys on a regular schedule to reduce the risk of key leaks. Publish new public keys before you activate the new signing key so apps do not reject valid users.
Even with strict token rules, you still need controls over live database queries and commands. Pairing identity tokens with query-level approvals and data masking closes the gap after login.
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
How do backend apps check a Keycloak signed JWT?
Backend apps download the public key from the realm key endpoint. They use this public key to check the token signature and expiration time before trusting any user claims.
What happens when you rotate signing keys in Keycloak?
Keycloak signs new tokens with the new private key right away. It keeps the old public key listed so existing tokens stay valid until they expire.
Can a Keycloak token restrict which SQL queries a user runs?
No, a token only passes identity and role claims at login time. It cannot inspect, block, or mask individual SQL queries or shell commands during a live session.