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

Torsten Lodderstedt <torsten@lodderstedt.net> Thu, 12 March 2020 18:58 UTC

Return-Path: <torsten@lodderstedt.net>
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 4EA133A1003 for <oauth@ietfa.amsl.com>; Thu, 12 Mar 2020 11:58:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net
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 5KVDbrYNDygv for <oauth@ietfa.amsl.com>; Thu, 12 Mar 2020 11:58:04 -0700 (PDT)
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (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 9721D3A0FBF for <oauth@ietf.org>; Thu, 12 Mar 2020 11:58:03 -0700 (PDT)
Received: by mail-wm1-x333.google.com with SMTP id 25so7298315wmk.3 for <oauth@ietf.org>; Thu, 12 Mar 2020 11:58:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=Q7ga4l8nLA5UwL7kdPh8r0FsqlOmb60dzwhNu4xu7b4=; b=crNwwHLI6e7bAddy8fJj5EIgTtNawvR304abPlYq/YvEnJIB6TE10kgLwhMfUvvsA0 G9hmxbIX6sBekbVnkViqyK7r6OBWq1nkjsrmfjiRuz7ehMQWMOyBtOT2pOSpkIVD3fVG k8nUrhgNclsq69iKaXN66euvnyiwaCat8F8IPMXrFybvn+Lul20FnuRzRWSObMEOy48B y/+g7aWlu67rCf+3iabTZ9Bo1w+NGDMfOsJhGDOQNU7Di+eSa6kL4uu9x7uv/R2m/9aA FjwtoFzgQ821q3DeztdwQMrNT+W5tyyWAvxMYkg/R0MQkXI5GILg+S0AWuN8EPrkRU80 YoPg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=Q7ga4l8nLA5UwL7kdPh8r0FsqlOmb60dzwhNu4xu7b4=; b=Idu12ifCmWHj3RQDUodJfPiAIpHIkHqKFipSOffUZ3PDdeX4htiU4Sq+KgnCE2RyLN ZgO/yxcUK8wSLaAfB+WadyjyS2DaPhnwvVDym7/E7Eda+y4rdLs/3PkYeyNTxWtK8h2u h9V3vNBd72/jvSe87aORhJ9WSiY2n6nYaKFOHt94l4fQtIw2FsKcHJLybhr3Kcpbzvbu PuGn9JrSiUm/QQQowiBcDbPQskCHb56/e7Rg3tYrUbIryIJIXyivje42B0Sl04Wxr5Hx QHT1AiX3j5rOTlPPSbvcCDOwcUUUbRZTSqE9YcjU4fyK52ZHS943npCPRXOT3vNgbJJ8 as6A==
X-Gm-Message-State: ANhLgQ3s9vniqd4WmFbAMmD/vjvyV5CqnuyFmsusu6ZtcHpS0yg+uX1M 1deOBec4fw96Ujp4sv0mjdMk1vxJ9Og=
X-Google-Smtp-Source: =?utf-8?q?ADFU+vsrHq0/Jyl+pB7FQjqajxmgru5uHmZceZI1/Yye?= =?utf-8?q?wePnBA0Sp+k+MmCBNKz5uKS2hm9ee3dGcA=3D=3D?=
X-Received: by 2002:a1c:9a88:: with SMTP id c130mr6500569wme.73.1584039481651; Thu, 12 Mar 2020 11:58:01 -0700 (PDT)
Received: from ?IPv6:2003:eb:8f11:fd2f:348e:272d:b645:611d? (p200300EB8F11FD2F348E272DB645611D.dip0.t-ipconnect.de. [2003:eb:8f11:fd2f:348e:272d:b645:611d]) by smtp.gmail.com with ESMTPSA id o7sm24117998wrx.60.2020.03.12.11.58.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 12 Mar 2020 11:58:00 -0700 (PDT)
Content-Type: multipart/signed; boundary=Apple-Mail-D9A8739C-C44C-40C9-BF6C-DA914733CB93; protocol="application/pkcs7-signature"; micalg=sha-256
Content-Transfer-Encoding: 7bit
From: Torsten Lodderstedt <torsten@lodderstedt.net>
Mime-Version: 1.0 (1.0)
Date: Thu, 12 Mar 2020 19:57:59 +0100
Message-Id: <2E956E04-3919-45E8-B9A0-9DB74E7067AC@lodderstedt.net>
References: <CAO_FVe40ONas2em6gGviEgdh_bf4qG+PnQD+G+KR+QPcY+V8Bw@mail.gmail.com>
Cc: Aaron Parecki <aaron@parecki.com>, OAuth WG <oauth@ietf.org>
In-Reply-To: <CAO_FVe40ONas2em6gGviEgdh_bf4qG+PnQD+G+KR+QPcY+V8Bw@mail.gmail.com>
To: Vittorio Bertocci <Vittorio=40auth0.com@dmarc.ietf.org>
X-Mailer: iPhone Mail (17D50)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/h7RSmcWsIeT7CCB9QiEBdVn8w9Y>
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:58:08 -0000

Hi,

sender constraining refresh tokens for confidential client means client authentication + check the binding of the refresh token with the respective client id. I don’t think this is new as RFC6759 already required ASs to check this binding. Assuming backends are generally confidential clients also means no rotation and no cache synchronization needed.

Rotation should be used for frontends, e.g. native apps and only if there is there no other option. If a refresh fails, the app must go through the authorization process again. That’s inconvenient so the question is how often this happens. What I can say, I have never seen customer complaining in several years of operation of ASs with refresh token rotation (including replay detection) for native apps with millions of users.

best regards,
Torsten.

> Am 12.03.2020 um 19:24 schrieb Vittorio Bertocci <Vittorio=40auth0.com@dmarc.ietf.org>:
> 
> 
> 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
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth