[OAUTH-WG] Authorization Header Encoding

Justin Richer <jricher@mit.edu> Thu, 11 February 2021 22:01 UTC

Return-Path: <jricher@mit.edu>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 2CD553A0CB5 for <oauth@ietfa.amsl.com>; Thu, 11 Feb 2021 14:01:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id AJqtjPaCzw-7 for <oauth@ietfa.amsl.com>; Thu, 11 Feb 2021 14:01:15 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED1A63A0CA2 for <oauth@ietf.org>; Thu, 11 Feb 2021 14:01:14 -0800 (PST)
Received: from [] (static-71-174-62-56.bstnma.fios.verizon.net []) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 11BM1CN1004187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <oauth@ietf.org>; Thu, 11 Feb 2021 17:01:13 -0500
From: Justin Richer <jricher@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_DA47148D-23F5-492C-9C1F-1B1D55DEE341"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Message-Id: <A492D4E9-3491-4F09-8F1C-3875C5FD6E51@mit.edu>
Date: Thu, 11 Feb 2021 17:01:12 -0500
To: oauth <oauth@ietf.org>
X-Mailer: Apple Mail (2.3608.
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/aG_Q221c0VbYWyKYIQ_W7W7amZw>
Subject: [OAUTH-WG] Authorization Header Encoding
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, 11 Feb 2021 22:01:17 -0000

The HTTP Working Group opened an issue for discussion in relation to the updated HTTP semantics specification. The core of the issue is the format of the “Authorization” header, which of course gets used by the “Bearer” scheme defined in RFC6750.

https://github.com/httpwg/http-core/issues/733 <https://github.com/httpwg/http-core/issues/733>

As it turns out, Bearer defines a more limited character set than is allowed by core HTTP, and doesn’t follow the HTTP guidelines and definitions for the Authorization header. There were a few observations on the call:

 - The Bearer spec was limited because OAuth tokens were also allowed in HTTP URLs and form parameters (and therefore had to have a more limited character set)
 - In practice people don’t actually restrict the values they put into this field; pretty much any implementation is just going to concatenate whatever access token value they get to the magic word “Bearer” and send it
 - It’s not likely (or in my opinion proper) for the HTTP spec to change to address the oddities of RFC6750 and decisions that were made many years ago

So the question is, what do we do about it? We could do a revision of 6750 that reflects reality better, pretty much just changing the ABNF.

Or, we could update the definition of the Bearer header in the upcoming OAuth 2.1 specification.

Are there other options?

 — Justin