Google OIDC Groups

Google OIDC groups let teams map directory memberships to internal app and database roles. Still, standard Google OpenID tokens do not include user group claims by default. Engineering teams must pull group data from the directory API during the login flow. Many teams skip this extra step and grant broad access to every verified user. When roles are too broad, any user can run dangerous commands on production systems.

How google oidc groups work in identity workflows

Standard OpenID flows send a signed token to your app when a user logs in. This token holds the user email, a unique ID, and basic profile facts. Google leaves group names out of this token to keep the payload small. Because of this design, your app only knows who the person is.

To check google oidc groups, your login service must do extra work after login. First, you create a project and a client credential in your cloud console. Next, you set up a service account with rights to read directory data. When a person logs in, your app trades the login code for an identity token. Then, the backend calls the cloud directory API using that user email address. The API returns the list of groups that belong to that specific person. Your app reads this list and matches each group to an internal role.

Some teams use an identity broker to handle this extra API call. The broker pulls the directory groups and injects them into a new token. Downstream servers and databases then read the new token to grant role access. This flow keeps directory logic out of your individual apps and scripts.

Why directory groups alone leave a runtime gap

Mapping directory groups to system roles solves the initial login problem. When someone joins the team, you add them to a group once. When they leave, you remove them from the directory and cut off login rights. You do not have to manage local user accounts on every database or server.

Still, directory groups only decide who can open a session at login time. Once a database or server accepts the session, the identity provider steps away. Every person in the engineering group gets the exact same runtime rights. A broad group role lets any member drop tables or read sensitive rows. The login token cannot inspect individual SQL queries or shell commands in flight.

Also, group claims in tokens stay valid until the token expires. If you remove a user from a group, their active keeps the session active. The identity provider cannot mask sensitive fields like emails, phone numbers, or card numbers. To control live queries and hide raw data, teams need runtime controls after login.

Best practices for mapping directory groups to roles

Start by creating small, focused groups in your central directory for each job task. Avoid using one wide engineering group for all database and server roles. Map read-only groups to basic roles and keep write roles empty by default. Check your directory API quotas so login bursts do not fail during peak hours. Finally, pair your group login setup with runtime checks for sensitive commands and queries.

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

Why are my Google groups missing from the ID token?

Google OpenID tokens only include basic user profile fields like email and user ID. You must query the cloud directory API or use a SAML flow for groups.

How do I read user groups during an OpenID login?

Give a cloud service account permission to read your workspace directory groups and members. Have your login backend query the directory API right after verifying the ID token.

Do group changes update active database sessions right away?

No, group checks only happen when a user starts a new login session. Active sessions keep their initial role until the token expires or the session closes.

Related guides

• AI Coding Agent Human Oversight
• AI Coding Controls for Regulated Industries
• AI Data Exposure Through Agents