That's a great news. Thanks so much for sharing. Nat 2016年1月23日(土) 9:43 Chuck Mortimore <[email protected]>:
> 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 >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
