From nobody Thu Nov 5 06:02:03 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44E5D3A11A6 for ; Thu, 5 Nov 2020 06:01:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLFBFJlESq3u for ; Thu, 5 Nov 2020 06:01:40 -0800 (PST) Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AE843A119D for ; Thu, 5 Nov 2020 06:01:40 -0800 (PST) Received: by mail-ed1-x535.google.com with SMTP id k9so1648074edo.5 for ; Thu, 05 Nov 2020 06:01:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2nZhatwqvu7na2YgxCmRpVSs4iQ90l6W64JbbuMOAcM=; b=mPwj8FG/SVg1bljUwEn1fuFWgTIo1JL/xAr1UGAIIbXIakpp5h/h8Tj7BLJBDYCQaw OjOf+N0MKVMQhCb3Y0zz44eR+F0ag69E/2yqKd1vOlsW9tAIrhpe8MWKBY3sakJEdr8q C+FzXseu0l3FolhTHemC0nR56PvQebEFM2wKz9FiBTNdL07fi8X3ClKI/ni7Vnf3wjh8 I4GZA8ZcJgdWDKfR7IkPrPjhzYqrwTONsyUWn+onZHJnIyFWm3dn7E1bAO7uOuc1Fm4q kvTmnlyeLdHdNIfCS5RYScLBUgdInnahsWEXgcqhm/sQ16YZZLF3/C+NP967xvnFyzkt yrVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2nZhatwqvu7na2YgxCmRpVSs4iQ90l6W64JbbuMOAcM=; b=cIeGD1q+hFo+/5JNk1V9c+BGK9d3Vpq/F5Ecxo4d/4IqDaOJVP6m4nyw8IlbU7b/u0 XYTWqwRteWja9fqXwSC7rhp5h2xlGt7RbPrEop7jFBayVbDk6sfpxHYs0xXWvip/J9ks brm5e/WrR+185MAb+yrNJBrtBu76vZ4E/RDXvCzCiUCJczbo6zr+wyHqbJUFhvkRVb+L btmOeDqTrrF5eGUKbL8jYuQVHJNoKP7EIrDFrs1N4EnZnY6MsCH949PwIh6RcM9H4AUf /fx1WIYEK/5gEQlCwV/OlNQafU0e/LzQbVU8mK7iDrIYyETRwsQNzyxtSp5JGBwIIH6e EXIQ== X-Gm-Message-State: AOAM5300EREUechxufSnqmtT2kQbwVghxHAzrfENrCEDmQ/bUBtEy+mN r8qj4rGQ0ok3eT7q4xfC3oXt1zsd+Zm003yGiOU= X-Google-Smtp-Source: ABdhPJzMeKeUXhVRSYwQl+aO67csUA5gtnArjZaaKkqauoSmLkxMvcK4thPCG4LqxwiLagUND/tG+Z9fPwGxWbFzLMk= X-Received: by 2002:a05:6402:b68:: with SMTP id cb8mr2693636edb.198.1604584898563; Thu, 05 Nov 2020 06:01:38 -0800 (PST) MIME-Version: 1.0 References: <188bcca0-e2d9-2f8d-89a5-cdf653849ce9@connect2id.com> In-Reply-To: <188bcca0-e2d9-2f8d-89a5-cdf653849ce9@connect2id.com> From: Bunh Tha Chau Date: Thu, 5 Nov 2020 21:01:23 +0700 Message-ID: To: Dzhuvinov Cc: Alex Kalp , oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000e4133d05b35c888f" Archived-At: Subject: Re: [OAUTH-WG] The response from the Google authorization endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 14:01:42 -0000 --000000000000e4133d05b35c888f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable V=C3=A0o 12:00, Th 5, 5 thg 11, 2020 Vladimir Dzhuvinov =C4=91=C3=A3 vi=E1=BA=BFt: > 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*=3Dcaf324471khs872&%20*code* > =3D4/5wFzvDar86R-AJWCIE&%20*scope*=3Dprofile%20openid%20 > https://www.googleapis.com/auth/userinfo.profile&%20*authuser*=3D0&%20 > *prompt*=3Dconsent > > 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 OAut= h > 2.0 RFC - and do we consider those additional parameters as a violation o= f > the RFC6749? > > Thanks! > -Alex > > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > -- > Vladimir Dzhuvinov > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000e4133d05b35c888f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

V= =C3=A0o 12:00, Th 5, 5 thg 11, 2020 Vladimir Dzhuvinov <vladimir@connect2id.com> =C4=91=C3=A3 vi= =E1=BA=BFt:
=20 =20 =20

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:
=20
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=3Dcaf3244= 71khs872&%20code=3D4/5wFzvDar86R-AJWCIE&%20scope=3Dpr= ofile%20openid%20https://www.googleapis.com/= auth/userinfo.profile&%20authuser=3D0&%20prompt= =3Dconsent

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 list
OAut=
h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--=20
Vladimir Dzhuvinov
_______________________________________________
OAuth mailing list
OAut= h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000e4133d05b35c888f--