OIDC Auth
You set up oidc auth by linking your apps to an identity provider. The provider checks user logins and sends back a signed identity token. Engineering teams use this flow to stop sharing static passwords across tools. Still, many teams map these tokens to broad roles inside their databases and servers. When a role is too wide, any logged-in user can run risky commands. How oidc auth works in your stack OpenID Connect sits on top of the standard OAuth protocol. It lets an app check who a user
K8s OIDC Authentication + Network Location-Based Auth: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up oidc auth by linking your apps to an identity provider. The provider checks user logins and sends back a signed identity token. Engineering teams use this flow to stop sharing static passwords across tools. Still, many teams map these tokens to broad roles inside their databases and servers. When a role is too wide, any logged-in user can run risky commands.
How oidc auth works in your stack
OpenID Connect sits on top of the standard OAuth protocol. It lets an app check who a user is without seeing their password. First, a developer tries to log in to a tool or database. The tool sends the developer to your central identity provider. The developer logs in there and completes a multi-factor check.
Next, the identity provider creates an ID token in JSON format. This token holds claims about the user, like their email and group names. The provider signs the token with a private key. Then, it sends the token back to the developer's client tool. The target system checks the signature using the provider's public keys. Once the check passes, the system reads the group claims and assigns a role.
Teams use this flow for web apps, cloud consoles, and Kubernetes clusters. You manage all user accounts in one directory. When someone leaves the team, you disable their account in that one place. They lose login rights across every linked tool right away.
Mapping identity claims to system roles
After the login check finishes, the target system must grant permissions. Most teams map identity provider groups to native roles inside the target tool. For example, a group claim might map to a read-only database role. Another group claim might map to an admin role in a cluster.
This group mapping works well at the start. Over time, teams add more databases, servers, and cloud accounts. Creating fine-grained roles for every single task takes too much work. Admins start placing whole teams into shared admin or writer groups instead. Everyone in that group gets the same wide permissions all day long.
Tokens also stay valid until their timer runs out. If an admin changes a group in the identity provider, active sessions keep running. The target tool will not check the provider again until the token expires. Short token timers fix this lag, but they force users to log in often.
K8s OIDC Authentication + Network Location-Based Auth: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What login checks solve and what they miss
A strong login flow stops attackers from guessing weak passwords. It also gives your security team a clear log of who signed in. You know which person started a session and when they did it. This solves the problem of shared admin accounts with unknown users.
Still, login checks only guard the front door of your systems. Once a session starts, the identity provider steps out of the way. It cannot see what queries or commands the developer runs next. If a developer has a write role, they can drop a table by mistake. They can also pull sensitive data like emails, phone numbers, or card numbers.
Standard login tokens also do not mask sensitive fields in query results. If a table holds national IDs, a valid user pulls the raw values. To control what happens during a session, you need checks on individual commands.
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 is OpenID Connect different from OAuth?
OAuth grants an app permission to act on your behalf. OpenID Connect adds an identity layer to prove who the user is. It provides a signed ID token with user profile details.
What goes inside an ID token?
An ID token holds JSON claims about the user and the login event. Common claims include the user email, group names, issuer URL, and expiration time. The target app reads these claims to set up the session.
Does single sign-on stop bad database queries?
No, single sign-on only checks who the user is at login time. Once the database grants a role, the user can run any allowed query. Stopping bad queries requires checking statements in flight after login.