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

Jim Manico <> Thu, 30 July 2020 16:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 246703A040F for <>; Thu, 30 Jul 2020 09:34:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Status: No, score=-2.088 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, NICE_REPLY_A=-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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id g48U6eWb9JBS for <>; Thu, 30 Jul 2020 09:34:47 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::f2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D0D273A0400 for <>; Thu, 30 Jul 2020 09:34:18 -0700 (PDT)
Received: by with SMTP id o2so12769758qvk.6 for <>; Thu, 30 Jul 2020 09:34:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=RpSml/O9o64dC2cr1pPvP4YmyoDHspvjqWlXOYJaJYs=; b=NXn1qttts0FZMVl7s4M2xaAXAaPRlpI4w2OFiVSM6dZvuq9PRDHb4yk503MTlNcSQy xzZHKpqXPdasqZP/ZL5PjCH7if6rLkYQBAByHCHYwbWGgkKQopFz/W0HKWXRCwENAp66 I1KGPEFZjYMSEtPM1rVCayU8sWWYDSOTYNBoP6ONa2zqhYtEAE5U/VipiZiZINXWhb45 /8Nk73fe6cLny6gHjo4gpGcIaAnRA438dHRYkSL2SR2CX7iADy+p1e+cnQnkwvAO3Rom 9LhCy5ZxEddqnuDH4bKcrDGdCR7PjXR0cKX6goOZrYPG2qO8d2bVOL221rmsCAObwwiM yX9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=RpSml/O9o64dC2cr1pPvP4YmyoDHspvjqWlXOYJaJYs=; b=ZIbNZEBXVz/H2/SUEPPgAiU8qMe7pet2sGBquK/sDkP8BDX4h79HBUVGICdB5PNP/E 8vCl8+NEIUdeobcPlvxMoTIAiwJF/PH0uy2y7cxK1E8k6/9BhTkpke1QnXA4ONHhI2DB OAEad2c6W1VeFYiuN3S9iiouG45SIZH13pSPoSQDxvCid+n3d/SYt7cNELtGGn6h8ZsH GZFvo0ErAFeGiS3Odp2GQbgKmZz+4STcDaivup9kDDByCrIOYxH/MTP6AtInjYhxNruw VLsgbPbzghQvC0gT8qmKC+g8ybgZmUjglR6bw7matuUTsTZ377BP+4itT09vFgbnJ3Gr WqjQ==
X-Gm-Message-State: AOAM5304I4OuyqYSun0nELUu0XWEzT2lHXYyoINLPgcsgub7SrZGljR/ qYMkn+uMstesPhT1qo/zdu+YmqfXZi0=
X-Google-Smtp-Source: ABdhPJx+31u7oKfr1ktep1j0rWviH56s2z4EVqoRQpFT1HjJHGmiz2/bseHCdpLoF4HAY54argTlMw==
X-Received: by 2002:a05:6214:452:: with SMTP id cc18mr3205545qvb.100.1596126857032; Thu, 30 Jul 2020 09:34:17 -0700 (PDT)
Received: from heembo.fios-router.home ( []) by with ESMTPSA id s30sm4925247qtc.87.2020. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 30 Jul 2020 09:34:15 -0700 (PDT)
To: Warren Parad <>, oauth <>
References: <>
From: Jim Manico <>
Message-ID: <>
Date: Thu, 30 Jul 2020 12:34:14 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------6DFD61349FA4B207838BB1F7"
Content-Language: en-US
Archived-At: <>
Subject: Re: [OAUTH-WG] Clarifying Bearer token usage OAuth 2.1 draft-ietf-oauth-v2-1-00
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 30 Jul 2020 16:34:51 -0000

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 

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:
> 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

Jim Manico
Manicode Security