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 > <vladi...@connect2id.com <mailto:vladi...@connect2id.com>> 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 >>
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
