Repository navigation
Add OAuth support #1162
Description
PostgreSQL provides support for OAuth authentication.
There are a few libpq function helping to interact with OAuth parties (drafted in #1116), but on top of this low-level layer we will probably want to build something higher level, which must be designed.
Reacted by Edgar Ramírez Mondragón, Yevhenii Hyzyla, Andreas Karlsson, Eigil Skjæveland, Trygve Bærland, Magnus Longva, 93578237 and Manuel J. Diaz
Activity
dutow commentedon Jan 7, 2026
Hello @dvarrazzo !
Are you interested in help/contributions with this feature? If yes, do you have some ideas about the specific direction? The currently open pull request (#1190) seems quite minimal. I'm not a python expert, but I am familiar with PG + OIDC ( https://github.com/Percona-Lab/pg_oidc_validator/ ), and it would be great to get support for OIDC into psycopg.
dvarrazzo commentedon Jan 7, 2026
Hello @dutow
This is a feature I want to work in the coming weeks, probably I will need to get in touch with other PostgreSQL devs to figure out better the features we want to implement.
Nothing concrete right now but I can keep you informed.
khushboovashi commentedon Feb 5, 2026
Hi @dvarrazzo,
If you had a chance to work on this, could you please share some insights into exactly what you plan to do?
As per my understanding, if any client app (ex, pgAdmin) handles the Device Auth flow and passes the oauth_issuer and oauth_client_id connection parameters, the OAuth authentication should work. Please correct me if I am wrong, as I am currently working on supporting OAuth2 with PostgreSQL authentication in pgAdmin.
Also, pgAdmin supports OAuth2 for user login, so I'm wondering whether that auth_token can be used directly and whether the device flow can be bypassed.
dutow commentedon Feb 5, 2026
That's great news, I asked my previous question with this end goal in mind
This is why psychopg needs explicit support for OAuth, the hooks in libpq support this workflow, but they are currently not exposed to python. The issuer has to be the same as configured in pg_hba, and of course the server side oauth validator has to accept the token. This at minimum means that the token should contain the required oauth_scopes specified in pg_hba, and it should be a non expired oauth token, but validators can specify other more specific conditions.
dutow commentedon Feb 20, 2026
@dvarrazzo @khushboovashi I started working on this, I have an experimental branch that works with both the python and C version, but for now I only created the PR about related test infrastructure changes / questions (#1264), and 2 more about small quality of life things I found/did while working on it.
kfox1111 commentedon Apr 17, 2026
any movement on this? It would be great to have a release with this in it. especially since things like the trivy exploit have shown just how bad having static credentials can be.
dvarrazzo commentedon Apr 17, 2026
I have started working on this. There should be some news in the coming weeks.
ivishalgandhi commentedon Apr 27, 2026
+1
kfox1111 commentedon Jun 22, 2026
Any updates on this?
kfox1111 commentedon Sep 2, 2026
any updates? Would really really like to use this
kfox1111 commentedon Sep 8, 2026
a static auth token would be problematic for me in some cases. It would be nice if it could be a lambda function so it can be dynamically fetched/generated.
dvarrazzo commentedon Sep 9, 2026
@UsmanGhias I have deleted your comments. Don't pust spam anymore or I will report you.
dvarrazzo commentedon Sep 9, 2026
@kfox1111 we are working on this feature. You should hear something about it soon.