Hi Dick, El 07/06/25 a las 08:22, Dick Hardt escribió:
HeyI 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 -- oauth@ietf.org To unsubscribe send an email to oauth- le...@ietf.org
-- Independent Security Architect t: +1.413.645.4169 e: stable.pseudo...@gmail.com https://www.linkedin.com/in/johnk-am9obmsk/ https://github.com/frumioj _______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
