Did you look at the code? (Its JavaScript) :)
bearer will fail as the startsWith() is looking for 'Bearer'
If there is a starting space or 2 spaces between Bearer and the token it
will fail
const authHeader =
request.headers.authorization if (authHeader &&
authHeader.startsWith('Bearer
')) {
const token = authHeader.split(' ')[1]
On Sun, Jul 6, 2025 at 2:27 PM John Kemp <[email protected]> wrote:
> 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
> > -- [email protected] To unsubscribe send an email to oauth-
> > [email protected]
>
> --
> Independent Security Architect
> t: +1.413.645.4169
> e: [email protected]
>
> https://www.linkedin.com/in/johnk-am9obmsk/
> https://github.com/frumioj
>
>
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
