Re: [OAUTH-WG] Authorization Header Encoding
Justin Richer <jricher@mit.edu> Thu, 18 February 2021 16:42 UTC
Return-Path: <jricher@mit.edu>
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 4D71B3A142D; Thu, 18 Feb 2021 08:42:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 px4XJsC3tY2o; Thu, 18 Feb 2021 08:42:44 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 E02593A142C; Thu, 18 Feb 2021 08:42:43 -0800 (PST)
Received: from [192.168.1.22] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 11IGgd1B026920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 18 Feb 2021 11:42:40 -0500
From: Justin Richer <jricher@mit.edu>
Message-Id: <09D9F690-52F6-4D6F-9F5F-EF9B1D64CF7D@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_2C675989-7971-44B4-83B9-FBC48503219F"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Thu, 18 Feb 2021 11:42:39 -0500
In-Reply-To: <CA+k3eCTxfXDzzMs+w2BB8MSmFy7=e4rxNG2Yz80oH++kOi1Kww@mail.gmail.com>
Cc: Vladimir Dzhuvinov <vladimir@connect2id.com>, oauth <oauth@ietf.org>
To: Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>
References: <A492D4E9-3491-4F09-8F1C-3875C5FD6E51@mit.edu> <97a82c6d-1410-a9a9-a7aa-e8cff61a1807@connect2id.com> <CA+k3eCTxfXDzzMs+w2BB8MSmFy7=e4rxNG2Yz80oH++kOi1Kww@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/oeUkXLMaavJVI56wmp8P5OvqtBs>
Subject: Re: [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, 18 Feb 2021 16:42:47 -0000
The issue was whether to remove the token68 portion and just use auth-param as part of the syntax, as far as I know. Bearer goes a little off from even the draft spec and admits as much in place. If we can improve the definition in 2.1, or at least make it clearer what’s expected, then I think that’s better. I’ll guarantee you that developers aren’t following “token68” syntax in practice when making Bearer headers. — Justin > On Feb 17, 2021, at 6:35 PM, Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org> wrote: > > AFAIK the character set for the "Bearer" scheme in RFC6750 is what it is to align with the token68 part of "credentials = auth-scheme [ 1*SP ( token68 / #auth-param ) ]" from https://tools.ietf.org/html/rfc7235#section-2.1 <https://tools.ietf.org/html/rfc7235#section-2.1> (the draft that would become RFC7235 is referenced by RFC6750 in https://tools.ietf.org/html/rfc6750#section-2.1 <https://tools.ietf.org/html/rfc6750#section-2.1> where it says basically as much). > > Also it looks like https://github.com/httpwg/http-core/issues/733 <https://github.com/httpwg/http-core/issues/733> was closed with no action. > > So I don't see what change would be made in OAuth 2.1 or elsewhere. Nor does it seem like any change is needed or appropriate. > > On Mon, Feb 15, 2021 at 4:34 AM Vladimir Dzhuvinov <vladimir@connect2id.com <mailto:vladimir@connect2id.com>> wrote: > Hi Justin, > > Thanks for alerting us on this development. > > +1 for keeping the updated HTTP semantics unencumbered by the Authorization header formatting in RFC 6750. > > IMO revising the RFC 6750 to reflect that is too late now, as few people will notice. So updating the Bearer header definition in OAuth 2.1 seems like the most sensible move. I expect OAuth 2.0 implementers who maintain their software to pick up the 2.1 spec, sooner or later. > > Vladimir > > > > On 12/02/2021 00:01, Justin Richer wrote: >> 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 >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth> > -- > Vladimir Dzhuvinov > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth> > > CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
- [OAUTH-WG] Authorization Header Encoding Justin Richer
- Re: [OAUTH-WG] Authorization Header Encoding Vladimir Dzhuvinov
- Re: [OAUTH-WG] Authorization Header Encoding Brian Campbell
- Re: [OAUTH-WG] Authorization Header Encoding Justin Richer