Subject: [OAUTH-WG] Google's OAuth endpoints now fully support PKCE (RFC7636)

From: William Denniss <[email-masked]>
Date: Mon, 18 Jan 2016 21:46:24 -0800

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

---

From: "Nat Sakimura" <[email-masked]>
Date: Tue, 19 Jan 2016 18:45:28 +0900

Wow, Congratulations, and thanks very much!

Best, 

--

PLEASE READ :This e-mail is confidential and intended for the

named recipient only. If you are not an intended recipient,

please notify the sender  and delete this e-mail.

From: OAuth [mailto:[email-masked]] On Behalf Of William Denniss
Sent: Tuesday, January 19, 2016 2:46 PM
To: [email-masked]
Subject: [OAUTH-WG] Google's OAuth endpoints now fully support PKCE (RFC7636)

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

---

From: John Bradley <[email-masked]>
Date: Tue, 19 Jan 2016 09:32:41 -0300

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-masked]> wrote:
> 
> 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>
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Nat Sakimura <[email-masked]>
Date: Tue, 19 Jan 2016 14:31:51 +0000

Agreed. It should give out an error.
It might have been easier for the developers to get a special error so that
they can debug, but giving less information in general is better
security-wise, so...

Nat

2016年1月19日(火) 21:33 John Bradley <[email-masked]>:

> Great news.
>
> If you have sent a PKCE challenge and no verifier that should be a
> authentication failure as if the value were wrong.
>
> 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"

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Tue, 19 Jan 2016 18:02:54 +0200

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

-- 
Vladimir Dzhuvinov

---

From: William Denniss <[email-masked]>
Date: Tue, 19 Jan 2016 09:08:26 -0800

> authentication failure as if the value were wrong.

I agree that case would always error.

This is the opposite case, where there was no challenge on the
authorization request, but there was the verifier on the token request.

---

From: William Denniss <[email-masked]>
Date: Tue, 19 Jan 2016 09:14:40 -0800

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-masked]
> wrote:

> 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
>
> discovery document:https://accounts.google.com/.well-known/openid-configuration
>
> Overflow google-oauth<http://stackoverflow.com/questions/tagged/google-oauth> <http://stackoverflow.com/questions/tagged/google-oauth> tag too, for any
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
> --
> Vladimir Dzhuvinov
>
>

---

From: Chuck Mortimore <[email-masked]>
Date: Fri, 22 Jan 2016 15:45:47 -0800

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

---

From: John Bradley <[email-masked]>
Date: Fri, 22 Jan 2016 21:21:34 -0300

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-masked]> 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"
> 
> On Mon, Jan 18, 2016 at 9:46 PM, William Denniss <[email-masked] <mailto:[email-masked]>> wrote:
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
>

---

From: Chuck Mortimore <[email-masked]>
Date: Fri, 22 Jan 2016 16:43:23 -0800

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-masked]> wrote:

>> 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

---

From: Nat Sakimura <[email-masked]>
Date: Sat, 23 Jan 2016 03:19:31 +0000

That's a great news.
Thanks so much for sharing.

Nat