hono icon indicating copy to clipboard operation
hono copied to clipboard

feat(bearer-auth): add `headerName` option

Open eliasbrange opened this issue 10 months ago • 6 comments

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

eliasbrange avatar Apr 16 '24 06:04 eliasbrange

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?

yusukebe avatar Apr 16 '24 06:04 yusukebe

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 avatar Apr 16 '24 12:04 eliasbrange

@eliasbrange

Thank you for the explanation. I can understand your context now. I'll make sure to comment again later.

yusukebe avatar Apr 16 '24 12:04 yusukebe

@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.

callumthomson avatar Apr 19 '24 03:04 callumthomson

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. :)

eliasbrange avatar Apr 19 '24 10:04 eliasbrange

@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.

yusukebe avatar Apr 20 '24 00:04 yusukebe

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.

yusukebe avatar Apr 30 '24 11:04 yusukebe