Re: [OAUTH-WG] First Draft of OAuth 2.1

Vittorio Bertocci <Vittorio@auth0.com> Thu, 12 March 2020 18:28 UTC

Return-Path: <vittorio.bertocci@auth0.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 307103A0F27 for <oauth@ietfa.amsl.com>; Thu, 12 Mar 2020 11:28:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com
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 yy_yy-mEtM82 for <oauth@ietfa.amsl.com>; Thu, 12 Mar 2020 11:28:20 -0700 (PDT)
Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (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 865D23A0F2B for <oauth@ietf.org>; Thu, 12 Mar 2020 11:28:20 -0700 (PDT)
Received: by mail-il1-x134.google.com with SMTP id g126so6461641ilh.2 for <oauth@ietf.org>; Thu, 12 Mar 2020 11:28:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=P+eJ/cQlSf4uvp1MlWJoyuVPAcl6oOZKdDcWUSXuHpM=; b=l55avBMaQmMDATJLo/9yiI6BQg5PsyO+UgLUFhrY6NMGOBhmllbkGLJhwPuJr/oHzC D4M2RGplLJoAb9aBvyzXOipIFXEvdh32k2bLBI2ffvbRDiyy68Rj56/3S8JkMhbfVNyO Yrb86qHCwdjhNnzBeCX3GIRa3jIjgUHkowqeFuUBw3hNlvu/vD3tLRkiLD4AGuj6jaYI 9IfkTdafF+Sd8DXMyexb/AjWSwQqR3uV5xgQvriJZk2o0NFBNygHorW0atrVF6iO3dfq ALH/yPrV/H+p1U5naOrMkzU5GzsBbZHjIrnE6PsUrrFAg+9BHDqeWiB8ZhhtFXb9hd4b PsVQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=P+eJ/cQlSf4uvp1MlWJoyuVPAcl6oOZKdDcWUSXuHpM=; b=aWhjQ+lgwzBxq5cjyenhr/4HcDiznq5LcaS40Xh9ZgsnA449fAUWwxWxcQnnGX/ypO Vqo/QShyL7UpHDzu1Yq3Dd2ya5PFBZwwokGEVlcv3fwyAjM7NCC9BropKdyR5eofi85w FQ/QOE98YYFJLzt0hEaDe9Fp2+sRYWedIFfjyhzAd+2K1NJphRwia8lSvza2wSHEAGuS W1I9k9YtQFotOkcBIXJihesIqNwsNSrrnj+Kotbdg/CctkfYR1CvOXYg161F9LIc0qzx HB5Kc6igdQDIVtkfYANMsRC9706tXxMNoRbOhIF9qcxFPldgkhED/0aNHrmu1SkSLFxk aOlg==
X-Gm-Message-State: ANhLgQ08UUHq3lESt76jeZ+pRnouxMRn441DAvMBIojemQJFkFlzZHjR LaazbcSTMa0Y8iDRCWKMOpN7jZrob5ir6UYj6UCe/Q==
X-Google-Smtp-Source: =?utf-8?q?ADFU+vsyadkXLsvXjRmyWXMoCvP8nHPx/+jvbhdtJZPf?= =?utf-8?q?d/pmJePU1gwrFSSO9vtx+EvXo+DcnGAwo5dkskuoFAWCePI=3D?=
X-Received: by 2002:a92:1a0b:: with SMTP id a11mr9192964ila.283.1584037699511; Thu, 12 Mar 2020 11:28:19 -0700 (PDT)
MIME-Version: 1.0
References: <CAGBSGjp6xRL21fdY+dosAhwS3Db6z1hxHU5uPGGprC-c_Ec-Cg@mail.gmail.com> <CAO_FVe40ONas2em6gGviEgdh_bf4qG+PnQD+G+KR+QPcY+V8Bw@mail.gmail.com>
In-Reply-To: <CAO_FVe40ONas2em6gGviEgdh_bf4qG+PnQD+G+KR+QPcY+V8Bw@mail.gmail.com>
From: Vittorio Bertocci <Vittorio@auth0.com>
Date: Thu, 12 Mar 2020 11:28:08 -0700
Message-ID: <CAO_FVe63-iCzqRCE0W18Y4sQsdKbaYj4y0fxCU32RoR53c9zEA@mail.gmail.com>
To: Aaron Parecki <aaron@parecki.com>
Cc: OAuth WG <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006422ca05a0ac84fb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/VPS3aEKnwbuHdwAXlOHJKNxAwYA>
Subject: Re: [OAUTH-WG] First Draft of OAuth 2.1
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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, 12 Mar 2020 18:28:23 -0000

damnit, i hit enter too soon.
  Hey guys,
thanks for putting this together.
I am concerned with the real world impact of imposing sender constraint |
rotation as a MUST on refresh tokens in every scenario.
Sender constraint isn't immediately actionable - we just had the discussion
for dPOP, hence I won't go in the details here.
Rotation isn't something that can be added without significant impact on
development and runtime experiences:

   - on distributed scenarios, it introduces the need to serialize access
   to shared caches
   - network failures can lead to impact on experience- stranding clients
   which fail to receive RTn+1 during RTn redemption in a limbo where user
   interaction might become necessary, disrupting experience or functionality
   for scenarios where the user isn't available to respond.
   - remediations currently in the wild for this are either clunky (grace
   periods) or downright cumbersome (waiting for the AT refreshed via RTn to
   be used by the client to invalidate RTn, which locks RS and AS in a
   transaction that is both expensive and itself subject to network failure)

I think it's fine to recommend using those mechanisms with a SHOULD, but
imposing those complexities to everyone in the core is asking too much IMO.
Thanks
V.

On Thu, Mar 12, 2020 at 11:24 AM Vittorio Bertocci <Vittorio@auth0.com>
wrote:

> Hey guys,
> thanks for putting this together.
> I am concerned with the real world impact of imposing sender constraint |
> rotation as a MUST on refresh tokens in every scenario.
> Sender constraint isn't immediately actionable - we just had the
> discussion for dPOP, hence I won't go in the details here.
> Rotation isn't something that can be added without significant impact on
> development and runtime experiences:
>
>    - on distributed scenarios, it introduces the need to serialize access
>    to shared caches
>    - network failures can lead to impact on experience- stranding clients
>    which fail to receive RTn+1 during RTn redemption in a limbo where user
>    interaction might become necessary, disrupting experience or functionality
>    for scenarios where the user isn't available to respond.
>    -
>
>
>
> On Wed, Mar 11, 2020 at 5:28 PM Aaron Parecki <aaron@parecki.com> wrote:
>
>> I'm happy to share that Dick and Torsten and I have published a first
>> draft of OAuth 2.1. We've taken the feedback from the discussions on
>> the list and incorporated that into the draft.
>>
>> https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01
>>
>> A summary of the differences between this draft and OAuth 2.0 can be
>> found in section 12, and I've copied them here below.
>>
>> > This draft consolidates the functionality in OAuth 2.0 (RFC6749),
>> > OAuth 2.0 for Native Apps (RFC8252), Proof Key for Code Exchange
>> > (RFC7636), OAuth 2.0 for Browser-Based Apps
>> > (I-D.ietf-oauth-browser-based-apps), OAuth Security Best Current
>> > Practice (I-D.ietf-oauth-security-topics), and Bearer Token Usage
>> > (RFC6750).
>> >
>> >   Where a later draft updates or obsoletes functionality found in the
>> >   original [RFC6749], that functionality in this draft is updated with
>> >   the normative changes described in a later draft, or removed
>> >   entirely.
>> >
>> >   A non-normative list of changes from OAuth 2.0 is listed below:
>> >
>> >   *  The authorization code grant is extended with the functionality
>> >      from PKCE ([RFC7636]) such that the only method of using the
>> >      authorization code grant according to this specification requires
>> >      the addition of the PKCE mechanism
>> >
>> >   *  Redirect URIs must be compared using exact string matching as per
>> >      Section 4.1.3 of [I-D.ietf-oauth-security-topics]
>> >
>> >   *  The Implicit grant ("response_type=token") is omitted from this
>> >      specification as per Section 2.1.2 of
>> >      [I-D.ietf-oauth-security-topics]
>> >
>> >   *  The Resource Owner Password Credentials grant is omitted from this
>> >      specification as per Section 2.4 of
>> >      [I-D.ietf-oauth-security-topics]
>> >
>> >   *  Bearer token usage omits the use of bearer tokens in the query
>> >      string of URIs as per Section 4.3.2 of
>> >      [I-D.ietf-oauth-security-topics]
>> >
>> >   *  Refresh tokens must either be sender-constrained or one-time use
>> >      as per Section 4.12.2 of [I-D.ietf-oauth-security-topics]
>>
>> https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-12
>>
>> I'm excited for the direction this is taking, and it has been a
>> pleasure working with Dick and Torsten on this so far. My hope is that
>> this first draft can serve as a good starting point for our future
>> discussions!
>>
>> ----
>> Aaron Parecki
>> aaronparecki.com
>> @aaronpk
>>
>> P.S. This notice was also posted at
>> https://aaronparecki.com/2020/03/11/14/oauth-2-1
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>