OIDC Group Claims
You set up oidc group claims by adding a group attribute to your identity token. This setting tells your login provider to send a user's team list during sign-in. Engineering teams use these claims to map identity groups to local roles in servers and databases. When teams grant broad roles to whole groups, every member gets full database write permissions. How oidc group claims work during login OpenID Connect builds on top of OAuth to check user identity. When an engineer logs in, the identi
K8s OIDC Authentication: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up oidc group claims by adding a group attribute to your identity token. This setting tells your login provider to send a user's team list during sign-in. Engineering teams use these claims to map identity groups to local roles in servers and databases. When teams grant broad roles to whole groups, every member gets full database write permissions.
How oidc group claims work during login
OpenID Connect builds on top of OAuth to check user identity. When an engineer logs in, the identity provider creates a signed JSON token. This token holds facts about the user, which are called claims. Basic claims store a user's email address and a unique user ID.
Group claims add a list of team names or IDs to that same token. First, an admin creates groups inside the identity provider and assigns users to them. Next, the admin sets the provider to include group data in the login token. Some providers send every group a user belongs to by default. Other providers let you filter the list so only matching team names go out.
The target system reads the signed token and checks the digital signature. It then looks at the group list inside the token payload. Finally, it matches those group names to its own local roles or permission sets. If a developer is in the backend group, the database grants the backend role.
Managing token size and group filtering
Large companies often have hundreds of groups for chat rooms, mailing lists, and projects. If an identity provider puts all those groups into one token, the token grows huge. Big tokens can break browser headers or hit size limits in cloud tools. When a token hits a size limit, the provider drops the group list and sends a pointer instead.
The target app then has to make a second network call to fetch the full list. Many database tools and server login helpers cannot make that extra network call. To fix this, admins apply a group filter inside the identity provider settings. A good filter only sends groups that start with a specific prefix for stack teams. This keeps the login token small, fast, and easy for every tool to read.
K8s OIDC Authentication: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What group mapping solves and what it misses
Group claims save admins from creating separate user accounts in every database and server. When an engineer leaves the company, removing them from the identity provider stops their login everywhere. It also keeps team membership in one central place for security audits.
Still, group claims only decide who can log in and which static role they get. Once the session starts, the identity provider has no visibility into what the user runs. A developer in an admin group can run a drop table command by mistake. A support engineer with read permissions can still pull thousands of customer emails and card numbers.
Identity tokens also stay valid until they expire, even if an admin removes a user's group. Static roles tied to groups cannot check individual SQL queries or shell commands in flight. They cannot pause a risky delete statement or rewrite sensitive fields like phone numbers in results. Teams need controls at the command level to stay safe 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 sits inline in the wire protocol beside those services as an open-source proxy, a sidecar for your Postgres or API. On every query an AI agent or engineer runs against production, hoop.dev decides to pass, mask, block, or hold it for human review.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run, and hoop.dev data masking rewrites matched sensitive values in responses 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
Why are my group claims missing from the ID token?
Most identity providers hide group lists until you ask for the groups scope during login. You must also enable group attribute sharing in the app settings inside your identity provider.
Should I send group names or group IDs in the claim?
Group names are easier for humans to read when writing role rules. Group IDs stay the same even if someone renames the team later, which prevents broken rules.
Can oidc group claims restrict a single SQL query?
No, group claims only assign a broad database role when the user first logs in. They cannot inspect, approve, or mask data inside individual queries during an active session.