Relational Database

PostgreSQL wire protocol

Query Audit

SAML/OIDC SSO for PostgreSQL Database Access

PostgreSQL is a trademark of the PostgreSQL Community Association of Canada.

Add SAML/OIDC Single Sign-On to PostgreSQL database connections. Replace shared database passwords with identity-based access via your corporate IdP. Every query is tied to an individual identity with full audit trail.

How It Works

Overview

Why PostgreSQL Needs Identity-Based Database Access

PostgreSQL is the world's most advanced open-source relational database, powering mission-critical applications across every industry. Yet PostgreSQL access still relies on shared database credentials stored in configuration files, environment variables, and developer laptops. When multiple engineers share the same database user account, it becomes impossible to attribute queries to individuals — creating compliance gaps and security blind spots. OnePAM's database proxy sits between your applications and PostgreSQL, authenticating every connection via your corporate IdP (Okta, Azure AD, Google Workspace). Users connect through the proxy using their corporate identity instead of shared passwords. OnePAM injects short-lived credentials from its vault, logs every query with identity context, and provides the compliance-ready audit trails that SOC 2, HIPAA, and PCI DSS require. The proxy supports PostgreSQL wire protocol natively, works with any PostgreSQL client (psql, pgAdmin, DBeaver, application connection pools), and adds zero-day protection by preventing direct access to your PostgreSQL instances.

Database Security Risks

PostgreSQL Access Security Risks

Without identity-based database access, these risks threaten your data every day.

Shared database credentials across teams and environments

No audit trail for individual query activity

Static passwords stored in config files and environment variables

Inability to revoke access instantly when team members leave

Default port 5432 exposed without identity verification

The Challenge

Database Security Challenges

These are the risks organizations face with traditional database authentication.

Shared Database Credentials

Multiple engineers sharing the same PostgreSQL user/password makes it impossible to attribute queries to individuals. Password rotation disrupts every application and developer using that credential.

No Native SSO for PostgreSQL

PostgreSQL's pg_hba.conf supports password, LDAP, and certificate auth — but not SAML or OIDC. Adding modern SSO requires complex proxy infrastructure that most teams lack.

Credential Sprawl

PostgreSQL passwords end up in .pgpass files, environment variables, CI/CD pipelines, Docker configs, and Slack messages. Each copy is a potential breach vector.

No Query-Level Audit Trail

PostgreSQL's pg_stat_statements tracks queries but not the human identity behind each connection. Shared credentials mean audit logs show 'app_user' instead of '[email protected]'.

Manual Credential Rotation

Rotating PostgreSQL passwords requires updating every application, script, and developer machine that uses the credential. Most teams avoid rotation because the blast radius is too large.

Compliance Gaps

SOC 2, HIPAA, and PCI DSS require individual accountability for database access. Shared PostgreSQL credentials fail this requirement by design.

Setup Guide

How OnePAM Adds SSO to PostgreSQL

Step-by-step guide to deploying identity-based database access.

Connect via OnePAM Proxy

Point your PostgreSQL client (psql, pgAdmin, DBeaver, or application) to the OnePAM database proxy instead of directly to PostgreSQL. The proxy speaks native PostgreSQL wire protocol.

Connection string changes from postgresql://user:pass@db-host:5432/mydb to postgresql://user@proxy-host:5432/mydb — OnePAM handles authentication.

Authenticate via Corporate IdP

OnePAM redirects you to your corporate Identity Provider (Okta, Azure AD, Google Workspace) for SAML/OIDC authentication with MFA.

For CLI tools like psql, OnePAM opens a browser for IdP auth and returns a short-lived token. GUI tools integrate with the OnePAM auth flow natively.

Credential Injection from Vault

After identity verification, OnePAM retrieves the appropriate PostgreSQL credentials from its encrypted vault and establishes the database session on your behalf.

Users never see or handle database passwords. Credentials are scoped to the authenticated identity and can be rotated without disrupting users.

Query Logging with Identity Context

Every SQL query is logged with the authenticated user's corporate identity, timestamp, source IP, and session metadata. Full audit trail for compliance.

Audit logs show '[email protected] executed SELECT * FROM users' instead of 'app_user executed SELECT * FROM users'.

Key Benefits

Benefits of SSO for PostgreSQL

What changes when you deploy identity-based database access.

Individual Accountability

Every PostgreSQL query is tied to a specific corporate identity. No more shared credentials masking who did what.

100% identity attribution

Zero Password Exposure

Developers and DBAs never see PostgreSQL passwords. Credentials are injected from the vault at session time.

Zero credential exposure

Automatic Credential Rotation

OnePAM rotates PostgreSQL credentials automatically without disrupting users or applications.

Automated rotation

MFA on Every Connection

Enforce your IdP's MFA policies on every PostgreSQL connection. No database-specific MFA configuration needed.

MFA enforced

Instant Deprovisioning

Disable a user in your IdP and PostgreSQL access stops immediately. No credential rotation needed.

Instant revocation

Compliance-Ready Audit Trail

Identity-verified query logs satisfy SOC 2, HIPAA, PCI DSS, and SOX audit requirements out of the box.

Audit-ready

SSO Features

Database SSO Features

Every feature needed for enterprise-grade database authentication.

SAML 2.0 and OIDC authentication

Native PostgreSQL wire protocol support

Works with psql, pgAdmin, DBeaver, and any client

Connection pooling with identity context

Role-based access control via IdP groups

Short-lived database credentials

Read-only vs read-write access policies

Schema-level access control

Time-limited database sessions

Just-in-time privilege elevation

Security

Security Features

Enterprise-grade security controls for database access.

Credential vaulting with AES-256 encryption

Automatic password rotation

Query-level audit logging

Sensitive data masking in logs

IP allowlist enforcement

TLS encryption for all connections

No direct database port exposure

Session timeout enforcement

Anomalous query detection

SIEM integration for alerts

Real-World Scenarios

PostgreSQL SSO Use Cases

Common scenarios where organizations deploy OnePAM Database SSO.

Engineering teams accessing production PostgreSQL databases with individual identity instead of shared credentials

SOC 2 audit requiring identity-verified access logs for every database query

HIPAA-regulated healthcare applications needing individual accountability for patient data access

Onboarding and offboarding employees with instant PostgreSQL access provisioning and revocation

Contractor access to staging databases with time-limited, MFA-protected sessions

PCI DSS compliance requiring audit trails for cardholder data environment access

Database migration projects where multiple teams need temporary access to PostgreSQL instances

DevOps teams managing PostgreSQL on AWS RDS, Azure Database, and GCP Cloud SQL

Frequently Asked Questions

SSO for PostgreSQL FAQ

Common questions about Database SSO and query-level auditing.

Does OnePAM work with PostgreSQL on AWS RDS, Azure, and GCP?

Yes. OnePAM's database proxy works with any PostgreSQL instance — self-hosted, AWS RDS, Azure Database for PostgreSQL, GCP Cloud SQL, and managed services like Supabase, Neon, and CrunchyData. The proxy connects to your PostgreSQL endpoint just like any other client.

Do I need to change my PostgreSQL configuration?

No. OnePAM's proxy sits in front of PostgreSQL and handles authentication externally. Your pg_hba.conf, PostgreSQL users, and application connection strings only need to point to the proxy instead of directly to PostgreSQL.

How does authentication work with psql and CLI tools?

When connecting via psql through the OnePAM proxy, a browser window opens for IdP authentication. After successful SAML/OIDC auth with MFA, OnePAM issues a short-lived token that the CLI uses for the session. Subsequent connections within the token lifetime connect instantly.

Can I use OnePAM with connection poolers like PgBouncer?

Yes. OnePAM can sit in front of PgBouncer or behind it, depending on your architecture. The proxy maintains identity context through connection pooling, ensuring every query is attributed to the correct user.

Does OnePAM support PostgreSQL SSL/TLS connections?

Yes. OnePAM enforces TLS encryption on all connections — both between clients and the proxy, and between the proxy and PostgreSQL. You can configure mutual TLS (mTLS) for additional security.

What happens to performance with the proxy?

OnePAM's proxy adds sub-millisecond latency per query. The proxy is designed for high-throughput environments and supports connection pooling to minimize overhead. Most teams see no measurable performance impact.

Add SSO to PostgreSQL Access

Deploy OnePAM database proxy in minutes. No PostgreSQL configuration changes required.

Get Started All Database SSO Guides