MIME-Version: 1.0
In-Reply-To: <569E5E2E.40204@connect2id.com>
References: <CAAP42hD3vpwnBYzu6YZVXtTimVuFHzgQ9Pksn1RQNEwogPZRJw@mail.gmail.com>
 <569E5E2E.40204@connect2id.com>
From: William Denniss <wdenniss@google.com>
Date: Tue, 19 Jan 2016 09:14:40 -0800
Message-ID: <CAAP42hDksSuEFeWaxOV=k0vY5-k-+YP2d-4Tjkew1T8-pz=KtQ@mail.gmail.com>
To: Vladimir Dzhuvinov <vladimir@connect2id.com>
Content-Type: multipart/alternative; boundary=001a11408cf87412630529b302ae
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/tzo-5FX4eJLbH6WQ9YxWgp-a5tY>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Google's OAuth endpoints now fully support PKCE
 (RFC7636)
Precedence: list

--001a11408cf87412630529b302ae
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Awesome! Great to hear you've implemented it too :)

I added client-side support this weekend into an iOS client that I'm
writing, didn't take long at all.

On Tue, Jan 19, 2016 at 8:02 AM, Vladimir Dzhuvinov <vladimir@connect2id.co=
m
> wrote:

> This is good news William! I hope more developers will become aware of
> PKCE through its adoption by Google. Right now there's virtually zero
> awareness about this option among devs.
>
> Coincidentally we also put support for PKCE in the Nimbus OAuth/OIDC SDK
> this week. Regarding errors we practice what Nat suggested - i.e. we don'=
t
> detail the exact cause of the error, but in the "error_description" field
> we list all possible causes that a client dev should check - invalid code=
,
> redirect_uri mismatch, bad pkce challenge, etc.
>
> Cheers,
>
> Vladimir
>
> On 19/01/16 07:46, William Denniss wrote:
>
> This month we rolled out full PKCE (RFC7636) support on our OAuth endpoin=
ts.
>
> We'd previously implemented an earlier draft but were not conformant to t=
he
> final spec when it was published =E2=80=93 now we are. Both "plain" and "=
S256"
> transforms are supported. As always, get the latest endpoints from our
> discovery document:https://accounts.google.com/.well-known/openid-configu=
ration
>
> If you give it a spin, let me know how you go! The team monitors the Stac=
k
> Overflow google-oauth<http://stackoverflow.com/questions/tagged/google-oa=
uth> <http://stackoverflow.com/questions/tagged/google-oauth> tag too, for =
any
> implementation questions.
>
> I'm keen to know what we should be putting in our discovery doc to declar=
e
> PKCE support (see the thread "Advertise PKCE support in OAuth 2.0
> Discovery"), hope we can agree on that soon.
>
> One implementation detail not covered in the spec: we error if you
> send code_verifier to the token endpoint when exchanging a code that was
> issued without a code_challenge being present. The assumption being that =
if
> you are sending code_verifier on the token exchange, you are using PKCE a=
nd
> should have sent code_challenge on the authorization request, so somethin=
g
> is amiss.
>
> William
>
>
>
>
> _______________________________________________
> 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
>
>

--001a11408cf87412630529b302ae
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Awesome! Great to hear you&#39;ve implemented it too :)<di=
v><br></div><div>I added client-side support this weekend into an iOS clien=
t that I&#39;m writing, didn&#39;t take long at all.</div><div class=3D"gma=
il_extra"><br><div class=3D"gmail_quote">On Tue, Jan 19, 2016 at 8:02 AM, V=
ladimir Dzhuvinov <span dir=3D"ltr">&lt;<a href=3D"mailto:vladimir@connect2=
id.com" target=3D"_blank">vladimir@connect2id.com</a>&gt;</span> wrote:<br>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    This is good news William! I hope more developers will become aware
    of PKCE through its adoption by Google. Right now there&#39;s virtually
    zero awareness about this option among devs.<br>
    <br>
    Coincidentally we also put support for PKCE in the Nimbus OAuth/OIDC
    SDK this week. Regarding errors we practice what Nat suggested -
    i.e. we don&#39;t detail the exact cause of the error, but in the
    &quot;error_description&quot; field we list all possible causes that a =
client
    dev should check - invalid code, redirect_uri mismatch, bad pkce
    challenge, etc.<br>
    <br>
    Cheers,<br>
    <br>
    Vladimir<span class=3D""><br>
    <br>
    <div>On 19/01/16 07:46, William Denniss
      wrote:<br>
    </div>
    </span><blockquote type=3D"cite">
      <pre><span class=3D"">This month we rolled out full PKCE (RFC7636) su=
pport on our OAuth endpoints.

We&#39;d previously implemented an earlier draft but were not conformant to=
 the
final spec when it was published =E2=80=93 now we are. Both &quot;plain&quo=
t; and &quot;S256&quot;
transforms are supported. As always, get the latest endpoints from our
discovery document:
<a href=3D"https://accounts.google.com/.well-known/openid-configuration" ta=
rget=3D"_blank">https://accounts.google.com/.well-known/openid-configuratio=
n</a>

If you give it a spin, let me know how you go! The team monitors the Stack
Overflow google-oauth
</span><a href=3D"http://stackoverflow.com/questions/tagged/google-oauth" t=
arget=3D"_blank">&lt;http://stackoverflow.com/questions/tagged/google-oauth=
&gt;</a> tag too, for any
implementation questions.

I&#39;m keen to know what we should be putting in our discovery doc to decl=
are
PKCE support (see the thread &quot;Advertise PKCE support in OAuth 2.0
Discovery&quot;), hope we can agree on that soon.

One implementation detail not covered in the spec: we error if you
send code_verifier to the token endpoint when exchanging a code that was
issued without a code_challenge being present. The assumption being that if
you are sending code_verifier on the token exchange, you are using PKCE and
should have sent code_challenge on the authorization request, so something
is amiss.

William

</pre>
      <br>
      <fieldset></fieldset>
      <br><span class=3D"">
      <pre>_______________________________________________
OAuth mailing list
<a href=3D"mailto:OAuth@ietf.org" target=3D"_blank">OAuth@ietf.org</a>
<a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">h=
ttps://www.ietf.org/mailman/listinfo/oauth</a>
</pre>
    </span></blockquote><span class=3D"HOEnZb"><font color=3D"#888888">
    <br>
    <pre cols=3D"72">--=20
Vladimir Dzhuvinov </pre>
  </font></span></div>

<br>_______________________________________________<br>
OAuth mailing list<br>
<a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/oauth" rel=3D"noreferrer" =
target=3D"_blank">https://www.ietf.org/mailman/listinfo/oauth</a><br>
<br></blockquote></div><br></div></div>

--001a11408cf87412630529b302ae--