Jwt Groups Claim

Published
Length
3 min read

Luis Felipe Dias

All posts

A jwt groups claim is a list of user roles inside a signed token. Your identity tool adds this list when a person logs in to an app. Teams use this claim to map directory groups to app or database roles. This setup lets admins manage permissions from one central login system. Still, broad groups often grant users far more power than they need each day. One wide group can give an entire team full admin rights across production systems. How the jwt groups claim works in your login flow First, a

Groups Claim: the complete guide

Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.

Free white paper. No spam. Unsubscribe anytime.

A jwt groups claim is a list of user roles inside a signed token. Your identity tool adds this list when a person logs in to an app. Teams use this claim to map directory groups to app or database roles. This setup lets admins manage permissions from one central login system. Still, broad groups often grant users far more power than they need each day. One wide group can give an entire team full admin rights across production systems.

How the jwt groups claim works in your login flow

First, an engineer logs in through your central identity provider. The identity tool checks the user account and looks up their assigned team groups. Next, the provider builds a JSON token and writes those groups into the payload. The provider signs the token with a private key and sends it back.

The user client then sends this signed token to your target server or database. The server checks the signature using the public key from your identity provider. It also checks that the token has not expired and matches the right audience. After that check passes, the server reads the jwt groups claim from the payload. It matches each group name in the list to a local role or rule. If a user belongs to several groups, the system combines all of those permissions.

How to keep token sizes small and manageable

Large companies often have hundreds of directory groups for different projects and teams. Putting every group into a single token makes the payload huge. Big tokens can break web headers and slow down network calls. To fix this, admins filter which groups get sent in the token.

You can set up your identity tool to send only groups for that app. Most teams use a simple naming rule to filter out unrelated company groups. Only groups that match the naming rule go into the token payload. You should also keep token lifetimes short so group changes take effect fast. When an admin removes a user from a group, old tokens still work until expiry.

Groups Claim: architecture patterns and best practices

Continue reading? Get the full guide.

Free. No spam. Unsubscribe anytime.

What group claims solve and what they miss

Mapping directory groups to local roles saves hours of manual setup work. Admins do not need to create separate user accounts on every single server. When someone leaves a team, you remove them from the directory group once. Their next login token will no longer carry that group name.

Still, a jwt groups claim only decides who can open a session. Once the server grants the role, the token check is over. The claim cannot see or filter what commands the user runs next. A developer in an admin group can still run a bad delete query. The token also cannot mask sensitive fields like emails or card numbers in results. Group claims handle entry, but they do not control live queries in flight.

Add runtime guardrails and masking beside your databases and APIs

Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits inline in the protocol beside the service as an open-source proxy, a sidecar for your database or API. On every production query an agent or human runs, hoop.dev decides whether to pass, mask, block, or escalate it for review.

Before a query runs, hoop.dev guardrails check the statement against your rules, an AI Analyzer you configure can score intent or hold risky calls for human approval, and hoop.dev data masking rewrites sensitive fields in responses in memory. Explore the MIT-licensed project on GitHub.

Frequently asked questions

What happens when a user belongs to too many directory groups?

The token grows too large and can exceed standard web header size limits. Filter the groups in your identity tool so only relevant app roles get included.

How fast do group changes update for active users?

Changes apply only when the user gets a new token from the identity tool. Keep token lifetimes short so removed group roles stop working right away.

Can a jwt groups claim restrict specific database queries?

No, the claim only assigns a starting role when the user logs in. It cannot inspect individual SQL statements or rewrite sensitive fields like phone numbers.

Save the open-source gateway.

hoop is MIT-licensed infrastructure for controlling how AI agents reach production data. Star hoophq/hoop so you can inspect it, deploy it, or share it when your team starts governing agent access.