Re: [OAUTH-WG] Misplaced Resource Owner in PKCE

John Bradley <ve7jtb@ve7jtb.com> Thu, 29 January 2015 22:14 UTC

Return-Path: <ve7jtb@ve7jtb.com>
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 5EDE71A8883 for <oauth@ietfa.amsl.com>; Thu, 29 Jan 2015 14:14:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 7up8HveIGeM6 for <oauth@ietfa.amsl.com>; Thu, 29 Jan 2015 14:14:25 -0800 (PST)
Received: from mail-qg0-f47.google.com (mail-qg0-f47.google.com [209.85.192.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53C431A039C for <oauth@ietf.org>; Thu, 29 Jan 2015 14:14:25 -0800 (PST)
Received: by mail-qg0-f47.google.com with SMTP id z60so35149671qgd.6 for <oauth@ietf.org>; Thu, 29 Jan 2015 14:14:24 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=a3p/SG4Ds4V9z4lGA2vc43qKtIxuAeVrg0Qgb8+pUuk=; b=Ad6DvRhgnGBsEIn7c83wmMQrg7trETxMKnh0BUJ3a6dR1B7NFyS5xvN98XRuKU/224 vPjxi/8/rbNHotqk1Qr23EYgGFQLrlEcKuhC5IiTSg4bijloGs10h+p25OLsKDwThv2F M8anh3cYEgUSGNV5x3hONEWN5jLcEefqn9EFPNNBz52KTe5SfUsx1hxquo8TLLO975xH WQSF2qryMIEIGxktP/qtvBHeNguydcWtJUDINwR36BPoSRF4MarPpAaxLpXp+NaD0Drc GVIdSLLzA6GKnFceFEwz231uGpeVyt+3A948YmeaQtqEUeb/mzbcUupMSHqTYE1nj+1t 79+w==
X-Gm-Message-State: ALoCoQkgGexPLgjjssSDJD2BBFlozhYbW5RwuKDQQZpUkDuHNBiU9U5erk5ayvD7sV6fq2HuP5Wa
X-Received: by 10.224.72.8 with SMTP id k8mr6204807qaj.26.1422569664529; Thu, 29 Jan 2015 14:14:24 -0800 (PST)
Received: from [192.168.8.101] ([181.202.1.158]) by mx.google.com with ESMTPSA id t12sm8223058qam.48.2015.01.29.14.14.21 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 Jan 2015 14:14:23 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_29317EAB-6085-4816-AAA6-8F0D4495DFCF"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <CA+k3eCS0BP5se-nbhw6bpCWH9HSe_4afQRXrS8fL8vYm3+LGmA@mail.gmail.com>
Date: Thu, 29 Jan 2015 19:14:19 -0300
Message-Id: <DE5F6289-144D-4002-85F0-34DCF3F783E6@ve7jtb.com>
References: <CA+k3eCS0BP5se-nbhw6bpCWH9HSe_4afQRXrS8fL8vYm3+LGmA@mail.gmail.com>
To: Brian Campbell <bcampbell@pingidentity.com>
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/mdKunaPy1Ij29ZgYhbAOuc1hsog>
Cc: oauth <oauth@ietf.org>, Naveen Agarwal <naa@google.com>
Subject: Re: [OAUTH-WG] Misplaced Resource Owner in PKCE
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Jan 2015 22:14:29 -0000

How about

    +--------+                                  +---------------+
    |        |--(A)-- Authorization Request --->|               |
    |        |        + t(code_verifier), t     | Authorization |
    |        |                                  |    Endpoint   |
    |        |<-(B)- Authorization Code Grant --|               |
    |        |                                  +---------------+
    | Client |  
    |        |                                  +---------------+
    |        |--(C)--- Access Token Request --->|               |
    |        |          + code_verifier         |    Token      |
    |        |                                  |   Endpoint    |
    |        |<-(D)------ Access Token ---------|               |
    +--------+                                  +---------------



> On Jan 29, 2015, at 7:01 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:
> 
> In SPOP/PKCE §1.1 [1] the figure and explanation have the authorization request going to the "Resource Owner" and goes on to say that 'the resource owner responds as usual, but records "t(code_verifier)" and the transformation method.' That's not what the resource owner does.
> 
> I know the protocol flow in RFC 6749 tries to have authorization grants be these abstract things that sorta come from the resource owner but, in the context of the the authorization request and authorization code grant type, it really doesn't work like that. The content in §1.1 seems, at best, to be  more abstract and complicated than it needs to be and is bordering on being just kinda wrong.
> 
> The RO and AS boxes should probably be consolidated into just the AS. The RO could be omitted from the diagram, I think. Or stick it over with the client, if you really want it in there, and have it authenticating and approving authorization though an interaction with the AS. Or something like that...
> 
> 
> 
> [1] https://tools.ietf.org/html/draft-ietf-oauth-spop-06#section-1.1 <https://tools.ietf.org/html/draft-ietf-oauth-spop-06#section-1.1>
> 1.1 <https://tools.ietf.org/html/draft-ietf-oauth-spop-06#section-1.1>.  Protocol Flow
> 
> 
> 
>        +--------+                                  +---------------+
>        |        |--(A)-- Authorization Request --->|               |
>        |        |        + t(code_verifier), t     |   Resource    |
>        |        |                                  |     Owner     |
>        |        |<-(B)--- Authorization Grant -----|               |
>        |        |                                  +---------------+
>        | Client |
>        |        |                                  +---------------+
>        |        |--(C)--- Access Token Request --->|               |
>        |        |          + code_verifier         | Authorization |
>        |        |                                  |     Server    |
>        |        |<-(D)------ Access Token ---------|               |
>        +--------+                                  +---------------+
> 
>                      Figure 2: Abstract Protocol Flow
> 
> 
>    This specification adds additional parameters to the OAuth 2.0
>    Authorization and Access Token Requests, shown in abstract form in
>    Figure 1.
> 
>    A. The client creates and records a secret named the "code_verifier",
>       and derives a transformed version "t(code_verifier)" (referred to
>       as the "code_challenge") which is sent in the OAuth 2.0
>       Authorization Request, along with the transformation method "t".
>    B. The resource owner responds as usual, but records
>       "t(code_verifier)" and the transformation method.
>    C. The client then sends the code to the Access Token Request as
>       usual, but includes the "code_verifier" secret generated at (A).
>    D. The authorization server transforms "code_verifier" and compares
>       it to "t(code_verifier)" from (B).  Access is denied if they are
>       not equal.
>