Re: OAuth client code doesn't work with Google OAuth

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 client secret.

But I also agree that making this configurable is a better approach.
Seems like while putting both the client_id and client_secret into the
postdata is not recommended, it is also supported by all
implementations I tested so far, including both google and okta.

What do you think about adding an `oauth_authentication_method`
parameter to the frontend, which defaults to `basic`, but can be
changed to `post` (or `http_basic` and `request_body`, as the rfc
refers to them)?

On Mon, Sep 8, 2025 at 11:58 AM Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
>
> > On 8 Sep 2025, at 11:46, Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com> 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!
>
> > , but I think this isn't clear in the RFCs:
> > ...
>
> Unfortunately thats true for most of the OAuth related RFCs, they are in places
> wishy washy at best.
>
> >> It doesn't seem in line with the specification, which error are they sending
> >> 428 for? Do they use 401 for invalid_client?
> >
> > During the wait for the user to enter the device code. It's documented here:
> >
> > https://url.avanan.click/v2/r01/___https://developers.google.com/identity/protocols/oauth2/limited-input-device%23authorization-pending___.YXAzOnBlcmNvbmE6YTpnOjE1MDdmOTlmYjY1ZTJlYzM3NWE2NjE4MDNlOTMyNDQ3Ojc6MTRhYTo5ZGNlNmI2YzMyYTI3ZTY3NDQzNDMxZDJlMWViY2I0Y2JmMTQyYzMwM2JjZWFmMTRhYzEzMjllMGFhYTg1MDgxOnA6VDpO
>
> Thanks for the reference, I'm not sure we should handle it equally to 400/401
> (need to think about that, and am looking foward to Jacob's wisdom on it) but
> it should regardless be quite doable to support.
>
> --
> Daniel Gustafsson
>