[OAUTH-WG] Re: coding agents don't follow the spec for parsing Authorization header

[John Kemp <[e-mail]>]

Hi Dick,

El 07/06/25 a las 08:22, Dick Hardt escribió:
> 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.

In 2.1.13, I see the following:

> credentials = "bearer" 1*SP token68
> 
> Clients SHOULD make authenticated requests with a bearer token using
> the Authorization request header field with the Bearer HTTP
> authorization scheme. Resource servers MUST support this method.As
> described in Section 11.1 of [RFC9110], the string bearer is case-
> insensitive. This means all of the following are valid uses of the
> Authorization header:
> 
> Authorization: Bearer mF_9.B5f-4.1JqM
> 
> Authorization: bearer mF_9.B5f-4.1JqM
> 
> Authorization: BEARER mF_9.B5f-4.1JqM
> 
> Authorization: bEaReR mF_9.B5f-4.1JqM

So...

> A client sending
> Authorization:   bearer    ey-access-token
> 
> 
> would of course fail in this validation.

It doesn't look like the 'bearer' should fail. The extra spaces, 
however, would be problematic.

I would argue that there should be a limit on whitespace (after all - 
how much is too much?), and _if_ there is a limit, why not have that 
limit be 1? We could leave that limit up to implementers, but then there 
might be implementers that accept 100s of K of whitespace, but then crash.

> Do we as a WG want to be 
> aligned with the HTTP spec, or align with what is widely deployed?

I think we should be as permissive as makes sense, and no more so. I 
believe we are already adequately permissive in the parsing of 'bearer', 
and I would suggest that limiting to one whitespace character only, 
provides for better default security in the specification.

Regards, John

> 
> /Dick
> 
> 
> 
> _______________________________________________ OAuth mailing list
> -- [e-mail] To unsubscribe send an email to oauth-
> [e-mail]

-- 
Independent Security Architect
t: +1.413.645.4169
e: [e-mail]

https://www.linkedin.com/in/johnk-am9obmsk/
https://github.com/frumioj