Re: [OAUTH-WG] The response from the Google authorization endpoint

[Vladimir Dzhuvinov <[e-mail]>]

I suspect those params are to signal the client if the user was
(re)authenticated, prompted for consent and the consented scope. But
being non-std and non-documented params it would be best to ignore them.

Vladimir

On 05/11/2020 15:47, Alex Kalp wrote:
> Hi Vladimir,
>
> Thanks for the reply. Would be great if you can share your insights on
> how those parameters are being used.
>
> I could not find any public docs explaining their usage, so thought
> they probably are being used by the Google applications by themselves.
>
> Thanks!
>
>
> On Wed, Nov 4, 2020 at 9:00 PM Vladimir Dzhuvinov
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>     Hi Alex,
>
>     OAuth 2.0 doesn't forbid other params to be present in the
>     response. If you find such - ignore them.
>
>     https://tools.ietf.org/html/rfc6749#section-4.1.2
>
>>     The client MUST ignore unrecognized response parameters.
>     I have a theory why those 3 extra params (scope, authuser, prompt)
>     are there, but I don't think it would matter in your case.
>
>     Vladimir
>
>     On 05/11/2020 02:23, Alex Kalp wrote:
>>     Hi All,
>>
>>     While trying out the OAuth 2.0 authorization code grant type with
>>     Google, I got the following response to my registered redirect_uri.
>>
>>     https://localhost:9000/app_uri?*state*=caf324471khs872&%20*code*=4/5wFzvDar86R-AJWCIE&%20*scope*=profile%20openid%20https://www.googleapis.com/auth/userinfo.profile&%20*authuser*=0&%20*prompt*=consent
>>
>>     As per the RFC6749 section 4.1.2, the authorization response from
>>     the authorization endpoint only includes code and state.
>>
>>     Appreciate if you can share any insights on why Google adds
>>     scope, authuser and prompt parameters to the response, which are
>>     not in the OAuth 2.0 RFC - and do we consider those additional
>>     parameters as a violation of the RFC6749?
>>
>>     Thanks!
>>     -Alex
>>