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 <[email protected]
> 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 endpoints.
>
> We'd previously implemented an earlier draft but were not conformant to the
> final spec when it was published – 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-configuration
>
> If you give it a spin, let me know how you go! The team monitors the Stack
> Overflow google-oauth<http://stackoverflow.com/questions/tagged/google-oauth> 
> <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 declare
> 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 and
> should have sent code_challenge on the authorization request, so something
> is amiss.
>
> William
>
>
>
>
> _______________________________________________
> 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
>
>
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to