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

Vladimir Dzhuvinov <> Tue, 19 January 2016 16:03 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 60D4B1B310A for <>; Tue, 19 Jan 2016 08:03:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3XckyfhsBiqQ for <>; Tue, 19 Jan 2016 08:02:57 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2201E1B3108 for <>; Tue, 19 Jan 2016 08:02:57 -0800 (PST)
Received: from [] ([]) by with id 7s2v1s00615ZTut01s2v7E; Tue, 19 Jan 2016 09:02:56 -0700
References: <>
From: Vladimir Dzhuvinov <>
X-Enigmail-Draft-Status: N1110
Organization: Connect2id Ltd.
Message-ID: <>
Date: Tue, 19 Jan 2016 18:02:54 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms080206030604030505000400"
Archived-At: <>
Subject: Re: [OAUTH-WG] Google's OAuth endpoints now fully support PKCE (RFC7636)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 19 Jan 2016 16:03:01 -0000

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.



On 19/01/16 07:46, William Denniss 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:
> If you give it a spin, let me know how you go! The team monitors the Stack
> Overflow 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

Vladimir Dzhuvinov