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 20:47 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 E37A33A0CA1 for <oauth@ietfa.amsl.com>; Thu, 30 Jul 2020 13:47:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.086
X-Spam-Level:
X-Spam-Status: No, score=-2.086 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_FONT_LOW_CONTRAST=0.001, 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 e1oGBLlIvHFs for <oauth@ietfa.amsl.com>; Thu, 30 Jul 2020 13:47:55 -0700 (PDT)
Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 11F153A0CA0 for <oauth@ietf.org>; Thu, 30 Jul 2020 13:47:54 -0700 (PDT)
Received: by mail-qt1-x831.google.com with SMTP id t23so18299450qto.3 for <oauth@ietf.org>; Thu, 30 Jul 2020 13:47:54 -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=gl0+JIHTh3V4IjGMCEfDYpS9FJc37O9Cl24dkINmcZk=; b=VBprmgwStYNn2b6KDz6zoZtVFUnhO6BNxTQ4OwD7aDG/+GIZ4C6aAg+3d2SfWmwZAF DLife5cMB+KgbfJ6SBZo4kWSBjIe6wMG69W8Ltih+ZSXZG90LwLgCfi6DBiv/rR602Qj lYGMz/hvUS8GS/tBGmloGLEdXUUEVq4McFPJtuJjiRVLXavyZMq9XOAbSVtHi5lUgYGZ Su3EJi7N2maeSq4nlCoq4vQTr2fNDUt6zqr0wMjAAnXJ0+jr7PNC5Hrz8X3bVZKfKZJU Pp/fahR9+TzQzxD4RewDCKbLBROahjGnxlOcIIW1CWNVGp+UPNXXuu9K8tf9Mc8AoKs3 P9bA==
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=gl0+JIHTh3V4IjGMCEfDYpS9FJc37O9Cl24dkINmcZk=; b=oUYH3DsvNE6E4JGDyQJvJd3H+2JDB5ixBBlLbEFoWEJJBBjxyUfUG2XR5eJA44ytR5 7igBukg+hnoganZtntHVwB1qZTT6vlYE5mc7lCkstSRIke+Y8cw6SKJebo50tA0fGlZc attVS5/OO8+yu9LRL2aIrGbTDi/cRGidv2ImcUw+zf0NhUK3F9Uu6h2Bb5UhruNbt6vk /4NM6OoIGT6CQGF49vsOamsk8zATEZDWLaiKf17kX6Pe8PgpSqMeXtAzx0NO5/Kjr93y wag1p+wGEJsxU9YSAa0uCH+wtTtxawt0lxQD6TwNxqetm7qlMqMpRsGR54uRYcXjo7Ka t4ZA==
X-Gm-Message-State: AOAM533fsKOiO4REmC2pFlE6Ffxni18n+qnJLuaqqxBZUrjNKEN1QRpb We6xVM/mlqwd5Co0NyEH6k+2OA==
X-Google-Smtp-Source: ABdhPJxAD2+Ly7ilgk4BrheU80FMD6TGfNn2kN82cVfJ9OU8TrAk9jGA5f5nPB3fxf+mWDhotzrrHw==
X-Received: by 2002:ac8:7181:: with SMTP id w1mr560407qto.172.1596142073868; Thu, 30 Jul 2020 13:47:53 -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 h55sm5889210qte.16.2020.07.30.13.47.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 30 Jul 2020 13:47:53 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-C6328E00-E7D2-4F7D-8157-3F84C18BD49F
Content-Transfer-Encoding: 7bit
From: Jim Manico <jim@manicode.com>
Mime-Version: 1.0 (1.0)
Date: Thu, 30 Jul 2020 16:47:52 -0400
Message-Id: <1842CB01-E0DE-4121-AFAF-B3BE749E55F0@manicode.com>
References: <CAD9ie-uUeX2fKxz=Cn0ea2vcec-rEsGvjTRsYJgCcVrqQf8H3A@mail.gmail.com>
Cc: Warren Parad <wparad@rhosys.ch>, oauth <oauth@ietf.org>
In-Reply-To: <CAD9ie-uUeX2fKxz=Cn0ea2vcec-rEsGvjTRsYJgCcVrqQf8H3A@mail.gmail.com>
To: Dick Hardt <dick.hardt@gmail.com>
X-Mailer: iPhone Mail (17G68)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/ccEOr9CnKRiYZWQrm1zKY3pmX2U>
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 20:47:58 -0000

I politely encourage the rules to be bent and to integrate this basic but fundamental security control into the core standard.

This is just basic security; we want as much basic security in the core of any standard. Dev’s now need to read 20 standards to get OAuth2 basics... and that’s a barrier to entry.

--
Jim Manico
@Manicode

> On Jul 30, 2020, at 3:21 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
> 
> 
> One of the constraints of the OAuth 2.1 document that aligned the WG was it would have no new features.
> 
> I'd recommend a separate document for the cookie bearer token feature. 
> 
> ᐧ
> 
>> On Thu, Jul 30, 2020 at 12:15 PM Jim Manico <jim@manicode.com> wrote:
>> 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
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth