Thanks - we'll fail if the client defaults to plain, as we didn't implement. Will take a look in the future though.
I am curious if an implementing client can move back and forth between Salesforce and Google implementations. If someone tries, please let us know! On Fri, Jan 22, 2016 at 4:21 PM, John Bradley <[email protected]> wrote: > In the final spec plain is not MTI. S256 is MTI for the server in Sec > 4.2. so you are OK. > > The client will default to plain if it doesn’t set a code_challenge_method. > > That was to be backwards compatible with the people who deployed when > plain was the only option. > > John B. > > On Jan 22, 2016, at 8:45 PM, Chuck Mortimore <[email protected]> > wrote: > > We quietly rolled out PKCE support at Salesforce a year ago, as well. > We're on a slightly earlier draft, but look to be compliant with final RFC > with one exception - we default to S256, and do not have support for "plain" > > Would be interesting to interop test our deployments. > > -cmort > > On Mon, Jan 18, 2016 at 9:46 PM, 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 >> >> 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 >> >> > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
