pgAdmin OIDC
You set up pgadmin oidc by linking the web app to your identity provider. This step lets your team log in with single sign-on instead of local passwords. Most teams use this setup to manage web user accounts in one place. Still, web login does not change how users log in to Postgres databases. Teams often end up sharing broad database keys inside the tool. When one person leaves, rotating those shared keys disrupts the whole team. How the native pgadmin oidc workflow operates A server mode de
K8s OIDC Authentication: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up pgadmin oidc by linking the web app to your identity provider. This step lets your team log in with single sign-on instead of local passwords. Most teams use this setup to manage web user accounts in one place. Still, web login does not change how users log in to Postgres databases. Teams often end up sharing broad database keys inside the tool. When one person leaves, rotating those shared keys disrupts the whole team.
How the native pgadmin oidc workflow operates
A server mode deployment separates web app login from database login. When you turn on OIDC, the web app trusts an outside identity provider. Users click the single sign-on button on the login screen. The browser sends them to the identity provider to check their identity. After a pass, the provider sends a signed token back to the web app. The web app reads the email and claims inside that token. If no local profile exists, the app can create one on the spot.
To build this flow, admins first register a new client app in the provider. The provider gives back a client ID, a secret, and a discovery link. Admins place these values into the server settings file for the web app. They also map token claims to user profiles so the right person gets in. Once the service restarts, the login screen shows the new sign-on option. You can keep local login active as a backup or turn it off.
Why web login leaves database connections exposed
Setting up pgadmin oidc solves account sprawl for the web tool itself. Admins no longer need to create or delete local web tool passwords by hand. When someone leaves the company, disabling their main identity blocks them from the web screen. This step keeps your entry point clean and cuts down on support tickets.
Still, a big gap remains between the web app and your Postgres servers. The OIDC token only proves who can open the web app in a browser. It does not log the user in to the actual Postgres database instances. Once inside the workspace, an engineer must still add a server and enter a database password. Many teams save these database passwords in the tool so they do not type them again. Others share one master database role across the whole team to save time.
K8s OIDC Authentication: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Because of this gap, your database logs only show the shared role name. You cannot tell which human ran a bad delete query from the web query tool. Also, the web login flow cannot check or block risky SQL statements in flight. If a user has the database key, they can read raw emails, phone numbers, or card numbers. Native single sign-on decides who opens the app, not what their queries do to your data.
Managing database roles after web login
Teams that rely on native settings must lock down database roles by hand. You should give each engineer a separate Postgres user with narrow read rules. Never let the team save shared admin passwords inside their web profiles. You should also turn on Postgres audit logs to track queries by database user. Even with these steps, matching web sessions to database rows takes manual work during audits.
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 beside the service as an open-source proxy, a sidecar for your database or API.
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 review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
Does pgadmin oidc log users directly into Postgres databases?
No, it only handles login for the web app interface itself. Users still need valid database credentials or tokens to open a Postgres session.
Can I turn off local passwords after setting up single sign-on?
Yes, admins can remove the internal login source in the server settings. Doing this forces every user to log in through the identity provider.
What happens if the identity provider goes down?
If you disable internal login, users cannot open the web app during an outage. Many teams keep one local admin account active for emergency recovery.