On Wed, Sep 10, 2025 at 2:12 AM Zsolt Parragi wrote:
> > I think this is focusing on authentication again. I mean that you need
> > to authorize the _client_ -- libpq itself. What does the consent
> > screen say for a user logging in, in your proposed architecture?
>
> I tried to implement my idea
> and the only chance
> you'll have to reject the theft is to notice that the client name
> looks different from usual. (If I catch you on the first login, you
> might not even know what "usual" is.)
Isn't this also true with custom scopes? Similarly the only thing
protecting users if they notice
On Thu, Sep 11, 2025 at 12:42 AM Zsolt Parragi
wrote:
> It just says that:
>
> > Once you enter the code displayed on your app or device, it will have
> > access to your account.
> > Do not enter codes from sources you don't trust.
>
> And that's all. And not loudly, this isn't written with a big
> My overall position is this, let me know what you think about it: I'm
> fine with supporting the Google-flavor handshake. That's life, and we
> already have some code that deals with variant spellings. But if the
> end result is a system that still can't safely authorize clients, I'm
> much less
> I think this is focusing on authentication again. I mean that you need
> to authorize the _client_ -- libpq itself. What does the consent
> screen say for a user logging in, in your proposed architecture?
I tried to implement my idea, and apparently it doesn't work the way I
described it. Limite
> On 7 Sep 2025, at 21:02, Zsolt Parragi wrote:
> * The device code request only includes the OAuth Client ID in the
> request body if the user doesn't specify a client secret (if the
> secret is specified, the client ID is only sent as part of the basic
> auth header), but Google OAuth always ex
On Fri, Sep 12, 2025 at 12:02 AM Zsolt Parragi
wrote:
> I realized something incorrect in my last email: I wrote that google
> doesn't ask permission for the email/profile scope. That's not true,
> it didn't show the scope screen because I already gave permission for
> the application and it remem
> I hear what you're saying, but I don't see how it relates to the
> paragraph you replied to.
I realized something incorrect in my last email: I wrote that google
doesn't ask permission for the email/profile scope. That's not true,
it didn't show the scope screen because I already gave permission
The comment is unfortunately correct, Okta refuses to authenticate if
the client_id is specified at two places with secret authentication.
On the other hand okta also doesn't require secrets for native apps,
where the secret is public anyway. Even with these changes okta is
usable, just without a
> So, MS Entra does something that's kind of the reverse of the
> situation I described above: it just yells at you loudly that a device
> is going to "have access to your account", even if the device isn't
> actually requesting access scopes, and demands that you double-check
> the trustworthiness
On Wed, Sep 10, 2025 at 11:50 AM Zsolt Parragi
wrote:
> > and the only chance
> > you'll have to reject the theft is to notice that the client name
> > looks different from usual. (If I catch you on the first login, you
> > might not even know what "usual" is.)
>
> Isn't this also true with custom
On Sun, Sep 7, 2025 at 12:03 PM Zsolt Parragi wrote:
>
> Hello Hackers,
Thank you for the report!
> While working on an OAuth validator for PG18 I noticed that currently
> the client code doesn't work when using Google as the OAuth provider.
Yep, this came up a couple of times previously [1, 2
> On 8 Sep 2025, at 11:46, Zsolt Parragi wrote:
>
>> AFAICT adding this would not violate the RFC but it is "NOT RECOMMENDED".
>
> I didn't test Okta yet, but it worked with all other providers I tried
> so far. I try to verify this with Okta and modify it if it doesn't
> work
Great, thanks!
>
> AFAICT adding this would not violate the RFC but it is "NOT RECOMMENDED".
I didn't test Okta yet, but it worked with all other providers I tried
so far. I try to verify this with Okta and modify it if it doesn't
work, but I think this isn't clear in the RFCs:
RFC 8628 states that "The authoriza
In the previous email I attached a git diff not a proper patch file, I
added the correct attachment to this email.
On Sun, Sep 7, 2025 at 8:02 PM Zsolt Parragi wrote:
>
> Hello Hackers,
>
> While working on an OAuth validator for PG18 I noticed that currently
> the client code doesn't work when
Hello Hackers,
While working on an OAuth validator for PG18 I noticed that currently
the client code doesn't work when using Google as the OAuth provider.
It requires two small changes:
* The device code request only includes the OAuth Client ID in the
request body if the user doesn't specify a
16 matches
Mail list logo
