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

Reply via email to