hono
hono copied to clipboard
feat(bearer-auth): add `headerName` option
Adds the possibility to use custom headers, such as X-Auth
or X-Access-Token
instead of Authorization
with the bearer-auth
middleware.
Author should do the followings, if applicable
- [x] Add tests
- [x] Run tests
- [x]
yarn denoify
to generate files for Deno
Hi @eliasbrange
Thanks for the PR. But I think we should consider whether we make it possible to change the header name.
@callumthomson What do you think about this matter?
This could be useful when deploying Hono in a Lambda and exposing it through CloudFront + Lambda Function URL.
With the newly released OAC , you can simplify deploying a Lambdalith API running Hono without an API Gateway.
However, when using OAC, CloudFront takes over the Authorization header. So, you must use another header to use both OAC and custom auth using JWTs.
Writing custom middleware is possible. However, it would be easier if the header could be customized through the existing middleware.
@eliasbrange
Thank you for the explanation. I can understand your context now. I'll make sure to comment again later.
@yusukebe I suppose it is somewhat reasonably common to want to use a different header name for providing a bearer token for authentication. I guess it depends on where you draw the line between 'batteries included' and 'extend it yourself'.
From a web standards perspective, according to RFC 6750, the header name can be changed, but it is clear which one is considered standard.
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.
I might agree on pulling back this one. For my use case, I would most likely write my own middleware anyway to get more control over caching JWKS and such. :)
@callumthomson Thank you for the comment!
I guess it depends on where you draw the line between 'batteries included' and 'extend it yourself'.
Indeed, you are right. For this case, I prefer "batteries included." This means we can accept this feature to enable the change of the header name.
@eliasbrange So, shall we go with it? I think there are some points to be reviewed, I'll comment.
Hi @eliasbrange
Now, I'll merge this into the "next" branch for the next minor release v4.3.0
which will be shipped soon. Thanks for your contribution.