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 <[email protected]> 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%20 > https://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 > > > > _______________________________________________ > OAuth mailing [email protected]https://www.ietf.org/mailman/listinfo/oauth > > -- > Vladimir Dzhuvinov > >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
