OIDC Lookup
An oidc lookup fetches the public metadata document from your identity provider URL. You run this check to find login endpoints, signing keys, and supported user claims. Engineering teams use this process when they connect databases and internal apps to single sign-on. If teams map the returned claims to broad roles, users get too much backend power. How an oidc lookup works in your login flow OpenID Connect relies on a standard discovery document hosted by your identity provider. When an app
K8s OIDC Authentication: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
An oidc lookup fetches the public metadata document from your identity provider URL. You run this check to find login endpoints, signing keys, and supported user claims. Engineering teams use this process when they connect databases and internal apps to single sign-on. If teams map the returned claims to broad roles, users get too much backend power.
How an oidc lookup works in your login flow
OpenID Connect relies on a standard discovery document hosted by your identity provider. When an app starts an oidc lookup, it sends a request to that public path. The provider returns a JSON file that lists all key URLs for the login flow. This file shows where to redirect users to log in and where to request tokens. It also points to the public keys used to check digital signatures on tokens.
Client tools read this metadata so admins do not have to type every URL by hand. When the identity provider rotates its signing keys, the discovery link helps apps find the new keys. Next, the app checks the token signature and reads the user claims inside the payload. These claims hold the user email, group list, and role names from the directory. Finally, the target system uses those group names to pick a local role for the session.
Mapping directory claims to backend roles
After the metadata check finishes and the user logs in, the backend must grant permissions. Most teams map an identity provider group directly to a database role or server account. For example, everyone in the backend engineering group might map to a shared read-write role. This setup removes the need to manage local passwords for each engineer on the team.
Still, directory groups rarely match the exact permissions needed for a single support task. Teams end up creating coarse roles so engineers can get their daily work done. A developer who needs to check one row often gets full read permissions across all tables. If an admin needs to fix one setting, the group claim often grants full superuser rights. The identity provider confirms who the user is, but the target system trusts the whole session.
K8s OIDC Authentication: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Where identity provider metadata stops
Running an oidc lookup and checking tokens solves the first step of login security. It proves that a valid user signed in through your central directory with multi-factor checks. It also lets you cut off login rights fast when someone leaves the company.
Yet the discovery flow and token check only happen at the start of a session. Once the database or server accepts the token, it steps back and trusts the mapped role. The identity provider cannot see which SQL queries or shell commands the user runs next. It cannot pause a risky delete command or rewrite sensitive fields like emails and card numbers. To control what happens inside the session, teams must inspect commands and queries in flight.
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
What does an OIDC discovery endpoint return?
It returns a JSON file with login URLs, token endpoints, public key links, and supported claims. Client apps read this file to set up single sign-on without manual URL entry.
Why would an oidc lookup fail during setup?
Lookups usually fail due to a wrong issuer URL, network blocks, or DNS errors. Check that your server can reach the provider domain and that the issuer path matches.
Does OpenID Connect control what queries a user can run?
No, OpenID Connect only checks user identity and passes claims like group names at login. The target database or server decides what actions the user can run after login.