Great news. If you have sent a PKCE challenge and no verifier that should be a authentication failure as if the value were wrong.
I don’t know if it needs a special error. Thanks for bringing it up. John B. > On Jan 19, 2016, at 2:46 AM, William Denniss <[email protected]> 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 > <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> 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 list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
