Re: [OAUTH-WG] Clarifying Bearer token usage OAuth 2.1 draft-ietf-oauth-v2-1-00

Aaron Parecki <aaron@parecki.com> Thu, 30 July 2020 16:46 UTC

Return-Path: <aaron@parecki.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 6079C3A0C90 for <oauth@ietfa.amsl.com>; Thu, 30 Jul 2020 09:46:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, 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, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki.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 nrWH0CwpA_HJ for <oauth@ietfa.amsl.com>; Thu, 30 Jul 2020 09:46:49 -0700 (PDT)
Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 397413A0B81 for <oauth@ietf.org>; Thu, 30 Jul 2020 09:46:49 -0700 (PDT)
Received: by mail-il1-x133.google.com with SMTP id t4so23018868iln.1 for <oauth@ietf.org>; Thu, 30 Jul 2020 09:46:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DEmEsBCRlQSmUxXjBTS6wsEoM8QcbO5yHWseucvYQdw=; b=bh0KsWNClqe281xFSgZbnWmi/LUDwNmKAVH9rfj6rw6jCGBjH1rXOmVqeIDy59zTaS CS6jHsPtf0ShYFrVYOElQSECR2RN2BqTlKSmFhDnjl9ZDe8yCuwLxoOXyaepcJWU2m1B N1lVgn7vf9aZLbZ2XoRNYhDax1R0EGemh/KZD+X1b7w/N/OonvmjBeccfhsvRJoo8Ndr Yg5+R/Y4lVNEIjZfmauqKHjtaSnLHIviZNRpV0wpu6NV3e09V1IOK+dlOYmZUhpxnu6T 2ws5IYoNKkPHcoisUAi8xf01o/xHd6k1lAOvMubBqTHDvOilUS7V1h0soy1mYlS3wc69 H4Rg==
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=DEmEsBCRlQSmUxXjBTS6wsEoM8QcbO5yHWseucvYQdw=; b=dWK1MxLZHfCjp9lUdZN//0OcYyJDwIDYfRk9oS8c6hGjemnGtj0g3JLMiiV/GimZ/S ZUCSWgDyGKyw33mLKrvMkv2zAA/MmnIdbH26nPlhB5am35NbO9vJ2KsCBDDlCccWUmJu iIjb48iSW9hYfAA1TScBsBbLu9GmaPLpNT4uHTI6E0gHlNTmR3i0rtKyA22GPjC1jZ6v BgpPRg4yg1JYoj8m90AJN2xwU5YjtLbu3HdtV4NuGs9UdOjBVy5Jbl5Zj5+6lBIzEv1l krgNtscFgUAo5G8iHZgM91WxPT86vGeGLTKi3MCiF7VsRPErjmMHCbBWwNjmP+Wlw1xo DXjw==
X-Gm-Message-State: AOAM532++5yfhRYBa5s4qhjS2NCyUAcv1fTYci+on+m7MleRJcCBmc6v KtlVV+HGyx8ROitL4iyicLI1oazLk8w=
X-Google-Smtp-Source: ABdhPJzFYMqgILfQvCo2lOJVFfgCHRGYWXNmX4Ct8f4AuogP253YxF8dOJoQnzoxraGohlgU0n+Qug==
X-Received: by 2002:a92:bb58:: with SMTP id w85mr16889049ili.94.1596127607920; Thu, 30 Jul 2020 09:46:47 -0700 (PDT)
Received: from mail-il1-f182.google.com (mail-il1-f182.google.com. [209.85.166.182]) by smtp.gmail.com with ESMTPSA id f20sm3129529ilj.62.2020.07.30.09.46.46 for <oauth@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 30 Jul 2020 09:46:46 -0700 (PDT)
Received: by mail-il1-f182.google.com with SMTP id y18so14593742ilp.10 for <oauth@ietf.org>; Thu, 30 Jul 2020 09:46:46 -0700 (PDT)
X-Received: by 2002:a92:c8d1:: with SMTP id c17mr24251474ilq.166.1596127606498; Thu, 30 Jul 2020 09:46:46 -0700 (PDT)
MIME-Version: 1.0
References: <CAJot-L2yAaBAJ_q3KzPH3_U4ND0_TOXMiSjnLj_wz4YbPv5MuA@mail.gmail.com> <0d9c249a-0a96-7d0a-bdee-f6d76811ae00@manicode.com>
In-Reply-To: <0d9c249a-0a96-7d0a-bdee-f6d76811ae00@manicode.com>
From: Aaron Parecki <aaron@parecki.com>
Date: Thu, 30 Jul 2020 09:46:35 -0700
X-Gmail-Original-Message-ID: <CAGBSGjriuuD6VAKJi8G9FwnVV+2h2e=BBfY+QiX29Tx5CJoLgA@mail.gmail.com>
Message-ID: <CAGBSGjriuuD6VAKJi8G9FwnVV+2h2e=BBfY+QiX29Tx5CJoLgA@mail.gmail.com>
To: Jim Manico <jim@manicode.com>
Cc: Warren Parad <wparad@rhosys.ch>, oauth <oauth@ietf.org>
Content-Type: multipart/related; boundary="0000000000000145d705abab6b70"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/kXvb-hvJ6RcKoDSsMNMEs0pfIqs>
Subject: Re: [OAUTH-WG] Clarifying Bearer token usage OAuth 2.1 draft-ietf-oauth-v2-1-00
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, 30 Jul 2020 16:46:52 -0000

I haven't seen any OAuth drafts that talk about sending OAuth access tokens
in HTTP cookies. OAuth 2.1 isn't supposed to add new features that don't
already exist, but this sounds like a good candidate to develop as an OAuth
extension.

---
Aaron Parecki
https://aaronparecki.com
https://oauth2simplified.com

On Thu, Jul 30, 2020 at 9:35 AM Jim Manico <jim@manicode.com> wrote:

> In a browser, HTTPOnly cookies are the *only* location where an access
> (or other) token can be stored in a way where it *cannot be stolen from
> XSS*.
>
> It's a very strong place to store tokens from a security point of view.
>
> Cookie storage of tokens does leave one open to CSRF attacks so it's
> certainly a trade-off. But CSRF is much easier to defense against that XSS
> and cookies are a better choice if the specific risk of having tokens
> stolen via XSS matters to your threat model.
>
> - Jim
> On 7/30/20 11:43 AM, Warren Parad wrote:
>
> https://www.ietf.org/id/draft-ietf-oauth-v2-1-00.html#name-bearer-tokens
>
> It seems recently more and more common to pass the access_token to some RS
> via a cookie, yet 7.2.1 says it defines two methods. I think we need some
> RFC2119 <https://www.ietf.org/id/draft-parecki-oauth-v2-1-03.html#RFC2119> keywords
> here, to suggest that either SHOULD use one of these two, or MUST. And then
> optionally state whether or not we recommend or reject the use of cookies
> as a place for access tokens. It's also possible that the language threw me
> off, because would an access token in a cookie be a bearer token, but no
> matter, if I'm having this thought, then surely others have it as well,
> right?
>
> [image: image.png]
>
> Warren Parad
>
> Founder, CTO
> Secure your user data and complete your authorization architecture.
> Implement Authress <https://bit.ly/37SSO1p>.
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
> --
> Jim Manico
> Manicode Securityhttps://www.manicode.com
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>