Enviado desde mi iPhone El jul 6, 2025, a la(s) 12:57, Dick Hardt <dick.ha...@gmail.com> escribió:
Did you look at the code? (Its _javascript_) :)
Yes, I did. And as a coder, I would immediately recommend a case-insensitive match; _javascript_ does allow for that. bearer will fail as the startsWith() is looking for 'Bearer'
Indeed. The parser should be more lenient, by following the specification.
If there is a starting space or 2 spaces between Bearer and the token it will fail
As it should, if you ask me.
-johnk
const authHeader =
request.headers.authorization if (authHeader && authHeader.startsWith('Bearer ')) {
const token = authHeader.split(' ')[1] 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
> -- 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
