From: | Ivan Kush <ivan(dot)kush(at)tantorlabs(dot)com> |
---|---|
To: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PoC] Federated Authn/z with OAUTHBEARER |
Date: | 2025-04-22 21:29:10 |
Message-ID: | 7faed780-94a5-494a-b6dc-c41584f2728c@tantorlabs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi Jacob, thank you for detailed explanation and links!
Am I right that classic OAuth flow "create user account based on a
token" is implemented using custom validators?
1) In pg_hba.conf set user to all and "delegate_ident_mapping=1"
"local all all oauth issuer=$issuer scope=$scope delegate_ident_mapping=1"
2) Write a custom validator that will "execute" in C `CREATE USER
token.name WITH token.listofOptions` after verification of a token.
On 25-04-21 19:57, Jacob Champion wrote:
> We have some options for dealing with them, since their documentation
> instructs clients to hardcode their API entry points instead of using
> discovery. (That makes it easy for us to figure out when we're talking
> to Google, and potentially switch to a quirks mode.)
What do you mean by "discovery"? OpenID link that returns endpoint?
Google has this link
https://accounts.google.com/.well-known/openid-configuration
OUTPUT:
{
"issuer": "https://accounts.google.com",
"authorization_endpoint":
"https://accounts.google.com/o/oauth2/v2/auth",
"device_authorization_endpoint":
"https://oauth2.googleapis.com/device/code",
"token_endpoint": "https://oauth2.googleapis.com/token",
"userinfo_endpoint":
"https://openidconnect.googleapis.com/v1/userinfo",
"revocation_endpoint": "https://oauth2.googleapis.com/revoke",
"jwks_uri": "https://www.googleapis.com/oauth2/v3/certs",
............
}
Here it's described
https://developers.google.com/identity/openid-connect/openid-connect
> But! Before we do that: How do you intend to authorize tokens issued
> by Google? Last I checked, they still had no way to register an
> application-specific scope, making it very dangerous IMO to use a
> public flow [2].
I've also thought as Antonin about
https://www.googleapis.com/oauth2/v3/userinfo for verification
As I understand from [2], the current problem is security, Google
doesn't want to add new scopes.
--
Best wishes,
Ivan Kush
Tantor Labs LLC
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Bossart | 2025-04-22 21:29:21 | Re: pgsql: Update guidance for running vacuumdb after pg_upgrade. |
Previous Message | Jelte Fennema-Nio | 2025-04-22 21:28:18 | Re: What's our minimum supported Python version? |