Adding my 2 cents... the code like this is already a bit problematic
authHeader.split(' ')[1]
and, in fact, considered to be a security issue by some (due to excessive
memory allocation during parsing)
https://github.com/golang-jwt/jwt/security/advisories/GHSA-mh63-6h87-95cp
in a popular GoLang JWT package
https://pkg.go.dev/vuln/GO-2025-3488 in the GoLang OAuth2
<https://pkg.go.dev/golang.org/x/oauth2> package.
All the best,
Andrii
On Sun, Jul 13, 2025 at 2:54 PM Joe DeCock <joe=
40duendesoftware....@dmarc.ietf.org> wrote:
> I agree that we should align with http for the reasons mentioned elsewhere
> in the thread, and also because OAuth 2.1 should only consolidate
> existing specifications without introducing new behavior.
>
> I also agree that the existing examples seem sufficient. It would be
> problematic to pick which capitalization of bearer to suggest as the best
> way to deal with non-conforming RS implementations. Surely there are
> implementations that incorrectly require "Bearer" and others "bearer"?
>
> Joe
>
> On Sun, Jul 13, 2025 at 2:51 PM Justin Richer <jric...@mit.edu> wrote:
>
>> We should absolutely align with http. I believe this is already addressed
>> in the language and examples of OAuth 2.1, yes?
>>
>> This would hardly be the first example of an AI powered tool creating
>> extremely fragile code, anyway. Coddling it won't help it get better.
>>
>> - Justin
>> ------------------------------
>> *From:* Dick Hardt <dick.ha...@gmail.com>
>> *Sent:* Sunday, July 6, 2025 8:22 AM
>> *To:* oauth@ietf.org <oauth@ietf.org>
>> *Subject:* [OAUTH-WG] coding agents don't follow the spec for parsing
>> Authorization header
>>
>> Hey
>>
>> I was working with Claude on an MCP server which requires authorization,
>> and it generated this code,
>> const authHeader = request.headers.authorization
>> if (authHeader && authHeader.startsWith('Bearer ')) {
>> const token = authHeader.split(' ')[1]
>>
>> which is likely based on patterns in the wild. In the OAuth 2.1 draft we
>> are making it clear that "Bearer" is case insensitive and that the
>> separator can be multiple spaces. A client sending
>>
>> Authorization: bearer ey-access-token
>>
>>
>> would of course fail in this validation. Do we as a WG want to be aligned
>> with the HTTP spec, or align with what is widely deployed?
>>
>> /Dick
>>
>>
>> _______________________________________________
>> OAuth mailing list -- oauth@ietf.org
>> To unsubscribe send an email to oauth-le...@ietf.org
>>
> _______________________________________________
> OAuth mailing list -- oauth@ietf.org
> To unsubscribe send an email to oauth-le...@ietf.org
>
_______________________________________________
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org
