Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1111B2E0F for ; Fri, 22 Jan 2016 16:43:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UoLc9g05oqdN for ; Fri, 22 Jan 2016 16:43:24 -0800 (PST) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A28D1B2DFD for ; Fri, 22 Jan 2016 16:43:24 -0800 (PST) Received: by mail-ig0-x229.google.com with SMTP id z14so2654224igp.1 for ; Fri, 22 Jan 2016 16:43:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salesforce.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AAyc1Ts0QS+FZTyFIJ2lNr20lKK/jFwwEnFZ4W2WIBY=; b=OEwbeq6/lqpovyNSqMYnmvAX5dvKYEZqhAQYaRfOSwUIi76E/OLU2kY8rh5ZV4rv9e NpvDqdBZeJ9HpSnNBmbA1H8V7tFkdxX6adOxu7DymXZhjOeDz7RgDeXRmJnagoIt1e87 sEFqGm00R3bMpRcMo32rVKPDA75mEuSCv9nI8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=AAyc1Ts0QS+FZTyFIJ2lNr20lKK/jFwwEnFZ4W2WIBY=; b=UCNbHqddw27Alyay2HtWf8ZmhbQ4WOnaa62Peyvr3wdLmZ+xkPyrxgBeZyUKtTYISj WzNsQniF6hLFdSiI07qvrFBvVVixbRrGOSvTS3NdqKIKU2NkgWY9SO296lk+5KyQe45e G7+Gk1LQRg2sBb3LbaHaRmt+pCoZHBq1MqsT+qVQq1Rs6Nt0wIa4P4aZiyKQt7D1kWV/ fxORYHqPyIMi8/Ict2iDE1ZE27nMtH7fJPXQcXXVYx8KjU4tvJZs+4X3ybyLxKBKatVt ScfPNBWAGl87VSVAW/nDuu625ROmshTB2qTmdKntM+hSlKdLr3oSYHp9X3AiyYO6tDEb i78A== X-Gm-Message-State: AG10YORI5B4DSZ1bsY/ZD9y3iBrFp1CPsPGRiD2NgQzcV0Ga0cy5guhjBtzn7uqLNyLHNhO9ad97JvdW89Rzk4P3 MIME-Version: 1.0 X-Received: by 10.50.36.74 with SMTP id o10mr5912246igj.73.1453509803888; Fri, 22 Jan 2016 16:43:23 -0800 (PST) Received: by 10.64.162.131 with HTTP; Fri, 22 Jan 2016 16:43:23 -0800 (PST) In-Reply-To: <0E094321-8A8A-4D94-8BE9-27D49BC6572F@ve7jtb.com> References: <0E094321-8A8A-4D94-8BE9-27D49BC6572F@ve7jtb.com> Date: Fri, 22 Jan 2016 16:43:23 -0800 Message-ID: From: Chuck Mortimore To: John Bradley Content-Type: multipart/alternative; boundary=089e013a00208a12130529f59f16 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Google's OAuth endpoints now fully support PKCE (RFC7636) X-BeenThere: oauth@ietf.org 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: Sat, 23 Jan 2016 00:43:26 -0000 --089e013a00208a12130529f59f16 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 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=E2=80=99t set a code_challen= ge_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 > 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 RF= C > with one exception - we default to S256, and do not have support for "pla= in" > > Would be interesting to interop test our deployments. > > -cmort > > On Mon, Jan 18, 2016 at 9:46 PM, 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 =E2=80=93 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 >> 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 somethi= ng >> is amiss. >> >> William >> >> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --089e013a00208a12130529f59f16 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks - we'll fail if the client defaults to plain, a= s we didn't implement. =C2=A0 =C2=A0Will take a look in the future thou= gh. =C2=A0 =C2=A0=C2=A0

I am curious if an implementing = client can move back and forth between Salesforce and Google implementation= s. =C2=A0 =C2=A0If someone tries, please let us know!

On Fri, Jan 22, 2016 at 4:2= 1 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
In the final spec p= lain is not MTI.=C2=A0 S256 is MTI for the server in Sec 4.2. so you are OK= .

The client will default to plain if it doesn=E2=80=99t= set a code_challenge_method.

That was to be backw= ards compatible with the people who deployed when plain was the only option= .

John B.

On Jan 22, 2016, at 8:45 PM, Chuck Mortimore <cmortimore@sales= force.com> wrote:

We quietly rolled o= ut PKCE support at Salesforce a year ago, as well. =C2=A0 We're on a sl= ightly earlier draft, but look to be compliant with final RFC with one exce= ption - 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 <wdenniss@google.com> wrote:
https://accounts.google.com/.well-known/openid-con= figuration

If you give it a spin, let me know = how you go! The team monitors the Stack Overflow=C2=A0google-oaut= h=C2=A0tag=C2=A0too, 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.

On= e implementation detail not covered in the spec: we error if you send=C2=A0= code_verifier=C2=A0to the token endpoint when exchanging a code that was is= sued without a code_challenge being present. The assumption being that if y= ou 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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth

--089e013a00208a12130529f59f16--