Re: OAuth client code doesn't work with Google OAuth - Mailing list pgsql-hackers

> 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 authorization server MUST ignore
unrecognized request parameters.", and RFC 6749 states that the
client_id is not a secret credential, so I assumed this should work
with all providers - if some doesn't use it, the RFC requires it to
ignore the parameter.

Also in RFC  6749, it states:

> The authorization server MAY establish a client authentication method
> with public clients.  However, the authorization server MUST NOT rely
> on public client authentication for the purpose of identifying the
>  client.

And later it explicitly states that clients may repeat the client id
parameter, and in some cases, they have to:

> A client MAY use the "client_id" request parameter to identify itself
> when sending requests to the token endpoint.  In the
> "authorization_code" "grant_type" request to the token endpoint, an
> unauthenticated client MUST send its "client_id" to prevent itself
> from inadvertently accepting a code intended for a client with a
> different "client_id".



> 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://developers.google.com/identity/protocols/oauth2/limited-input-device#authorization-pending

On Mon, Sep 8, 2025 at 10:11 AM Daniel Gustafsson <daniel@yesql.se> wrote:
>
> > On 7 Sep 2025, at 21:02, Zsolt Parragi <zsolt.parragi@percona.com> 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 expects it in the body
>
> AFAICT adding this would not violate the RFC but it is "NOT RECOMMENDED".
> There is also this comment a few lines up from your change which makes it
> problematic.
>
>     * client_id is not added to the request body in this case. Not only
>     * would it be redundant, but some providers in the wild (e.g. Okta)
>     * refuse to accept it.
>
> We clearly want to be able to support Google as an OAuth provider, but it seems
> we need to operate in different modes here?
>
> > * The wait loop for the authorization only expects HTTP 400 and 401,
> > but the Google endpoint responds with HTTP 428 (Precondition required)
>
> It doesn't seem in line with the specification, which error are they sending
> 428 for? Do they use 401 for invalid_client?
>
> --
> Daniel Gustafsson
>