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

Jim Manico <jim@manicode.com> Thu, 30 July 2020 19:15 UTC

Return-Path: <jim@manicode.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 752893A0AE1 for <oauth@ietfa.amsl.com>; Thu, 30 Jul 2020 12:15:26 -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, 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, 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=manicode.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 pwNWSvVWF1ew for <oauth@ietfa.amsl.com>; Thu, 30 Jul 2020 12:15:23 -0700 (PDT)
Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 C05083A0AB7 for <oauth@ietf.org>; Thu, 30 Jul 2020 12:15:23 -0700 (PDT)
Received: by mail-qk1-x72d.google.com with SMTP id h7so26642272qkk.7 for <oauth@ietf.org>; Thu, 30 Jul 2020 12:15:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode.com; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=g7lZL9V0ji/CIn211ew6SmQ2XvufePV25gq9NNwm1tY=; b=TfnFD/fewV1/cSbGsdrfpxASUZwNjwVTX209NB4ocntXXk+qO/wBBYUpc55QI6SAE1 KlOGChaLhlZ0m/TtY83I/5tSGlvZIWVAswZKZrsnx1pPzXrTPjWH/Ci9hvJvNyPAy23P SyGSo3wPqaL9cizeEwG+yd41Ev68mwByYLvslund5s9tm25x9qAtMjaaW9KhcGE9CJk9 WHAADWo3MwZLR4auR87JFk9kQnCWVGVoXqEZ8zjjYqGT67ZTBQp9s7MiX8OT5O8gfPnm pv5F1X7lmy4SxzKJq01Ww9mKTX/RKZuGGK4ZDwDTrLaMbE2YZ4N41V9smY2+AQYyoILO TTfA==
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=g7lZL9V0ji/CIn211ew6SmQ2XvufePV25gq9NNwm1tY=; b=UdDgol0t1EqAr/PKR4ILSfz12bY8RAtMnvXcfZzo1cXD3BV+CcyEkWDHIof1wgO8ir uncvZnvE4+WfP1u2ypuIA9phqYastCegg0+t9OLnoJLxA+nLg2lDxM90qGUVFhWYS31w TIqrY+QUBU+iDd4OsZ9EmZexAFrP4Wdab26XnO+ODSt71v0oekVmGeG7LeYgb+NQrndc AEapZA1weYrQa7KjuY/IU9SKXSFar+gSswA418MWPbJccOAjScp2HY9u/yWe7EzCMYRQ xq3ygMHg88UUEjxzoLGEYz+zGZsPOcVRFWC2+oQCrqg4RWmHBTN4941o5QDy0wCErNAG gShQ==
X-Gm-Message-State: AOAM532WWA4f1vmvkrPf8TsH/RZnJUMrKWS9vASnUi9RAkzFH9Q8yvti GDw24G3IJ/yfqK+X5+merCTjsw==
X-Google-Smtp-Source: ABdhPJwMMBcuNrbGjd9VOe8mq9uoRSvg8zQ8AH7Fy3S1fvURt4RiYGsTs2rxdCpNbXkXXXuqTUWsTQ==
X-Received: by 2002:a37:5dc6:: with SMTP id r189mr706211qkb.364.1596136522751; Thu, 30 Jul 2020 12:15:22 -0700 (PDT)
Received: from [192.168.0.197] (pool-71-126-184-140.washdc.east.verizon.net. [71.126.184.140]) by smtp.gmail.com with ESMTPSA id z68sm5058266qke.113.2020.07.30.12.15.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 30 Jul 2020 12:15:21 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-1F64C9D3-3D5C-4A52-AD40-402E5FE64295
Content-Transfer-Encoding: 7bit
From: Jim Manico <jim@manicode.com>
Mime-Version: 1.0 (1.0)
Date: Thu, 30 Jul 2020 15:15:20 -0400
Message-Id: <4E2EAEF4-A0E4-4560-86C3-083A19A0F440@manicode.com>
References: <CAJot-L0gx6-NSGmWsY_qx4sTiKNJ9NtExX-zZWM=+CjVn=5MPg@mail.gmail.com>
Cc: Aaron Parecki <aaron@parecki.com>, oauth <oauth@ietf.org>
In-Reply-To: <CAJot-L0gx6-NSGmWsY_qx4sTiKNJ9NtExX-zZWM=+CjVn=5MPg@mail.gmail.com>
To: Warren Parad <wparad@rhosys.ch>
X-Mailer: iPhone Mail (17G68)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/SP5wGr8xKNXe1c97xOxfp-M9Pj0>
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 19:15:27 -0000

Yea to cookie configuration suggestions!

I suggest SameSite=LAX at least, which is actually the default behavior in chrome if you do not set the samesite value. LAX will not break links that originate from emails, STRICT will.

Point being is that CSRF defense is easy. XSS defense is brutally hard in apps with complex UI’s!

--
Jim Manico
@Manicode


> On Jul 30, 2020, at 1:13 PM, Warren Parad <wparad@rhosys.ch> wrote:
> 
> 
>> 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.
> 
> I would assume if we included cookie language, it would explicitly specify Secure; HttpOnly; SameSite=Strict as the recommendation, and then neither XSS nor CSRF should be a problem (right?)
> 
> 
>> 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.
> 
> Is this really a new feature though?
> 
> Okay, I'll submit that RFC 6749 does state the cookie wouldn't be created by the AS.
>> 5.1.  Successful Response
>>    The authorization server issues an access token and optional refresh
>>    token, and constructs the response by adding the following parameters
>>    to the entity-body of the HTTP response with a 200 (OK) status code:
>  
> However that wouldn't prevent a client using the password grant (I know I said a bad word) or authorization code flow from creating the cookie to contain that. Specifically
>> 7.  Accessing Protected Resources
>>    The client accesses protected resources by presenting the access
>>    token to the resource server.  The resource server MUST validate the
>>    access token and ensure that it has not expired and that its scope
>>    covers the requested resource.  The methods used by the resource
>>    server to validate the access token (as well as any error responses)
>>    are beyond the scope of this specification but generally involve an
>>    interaction or coordination between the resource server and the
>>    authorization server.
>>    The method in which the client utilizes the access token to
>>    authenticate with the resource server depends on the type of access
>>    token issued by the authorization server.  Typically, it involves
>>    using the HTTP "Authorization" request header field [RFC2617] with an
>>    authentication scheme defined by the specification of the access
>>    token type used, such as [RFC6750].
> 
> So that's definitely some gray area. Although perhaps I'm missing a relevant section. If we are going to go so far to detail a list of possible RS bearer token possible locations (i.e. Header and Body), to what I assume is to implicitly say Don't use a query parameter. It also suggests Don't use a cookie at all, even with SameSite=Strict. Although maybe that is the point.
> 
> For my reference, what makes a new feature and what makes an OAuth extension?
> 
> 
> Warren Parad
> Founder, CTO
> Secure your user data and complete your authorization architecture. Implement Authress.
> 
> 
>> On Thu, Jul 30, 2020 at 6:46 PM Aaron Parecki <aaron@parecki.com> wrote:
>> 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 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.png>
>>>> 
>>>> 
>>>> 
>>>> Warren Parad
>>>> Founder, CTO
>>>> Secure your user data and complete your authorization architecture. Implement Authress.
>>>> 
>>>> 
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> -- 
>>> Jim Manico
>>> Manicode Security
>>> https://www.manicode.com
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth