[Feature Request] more customization options.

[My1]

honestly I think That this is a very intresting plugin since it essentially does htaccess-like access structure, but with allowing custom logins and similar fun (something I searached long enough with no proper results, funnily, I fairly recently changed the format of the cookie to a JWT, and just now I found this plugin.

There just a few things that would make it nicer. 1) specify the way of passing, including customization, for example so I could force it to a cookie and have it a name I like. 2) specify necessary/forbidden header fields, someone might for example only use one was of signing the JWT (HS512 in my case) and reject the rest, also there may be a different type for example "auth" to discern it from other JWTs used in a web application (I think this shouldnt be TOO hard since it's essentially same as the normal allow/deny commands, but on the header instead of the payload)

[BTBurke]

What security benefit is there to naming the cookie yourself?

If you want to enforce necessary/forbidden fields, it's better to do that in your application. For advanced use cases like that, you're still free to act on the claims that are passed to your application and reject the request from there. There are too many possible use cases to put them all in Caddy middleware because often the decision depends on access to some data in your DB.

You have to specify the signing algorithm in the header or the token will fail validation. The only potential vulnerability relates to people using the RS family of algorithms. If they make their key public it's possible to forge a token if the alg is set to HS and the public key is used to sign it. This middleware prevents that attack by only validating HS family algorithms when JWT_SECRET is set and only RS family algorithms when JWT_PUBLIC_KEY is set.

[My1]

regarding your second point. I dont mean not specifying the signing algorithm, but on the server setting what algos are allowed and what not. so that for example a token which has HS256 get automatically dropped because I would have established that only HS512 should be used, because even if HS256 is technically safe, I dont think that we need to keep doors open that dont get used. Same for the Idea of having allow/deny for header clains. especially with larger JWTs, it might be easier to do the pre-sorting based in information listed in the header, like for example using multiple types to keep different JWTs apart.

for about what security benefit there is in setting the source of the JWT, I actually didnt think this from a security standpoint, but rather from an "If we dont distribute JWTs over an Auth header, why even care about looking for that" and as said having the ability to change this also allows for better integration into whatever thing spits out the JSON

[BTBurke]

The main reason is because processing the header like that isn't in accordance with the spec. There's no attack that I know of that would benefit from changing the algorithm (e.g., specifying HS256 when the token is signed HS512). The middleware already handles the case of trying to specify HS in place of RS because that is a known attack vector.

As far as acting on info in the header, you should put that kind of info in the claims. The allowed header fields are listed in the JWT spec. If you want to distinguish between roles, you put that in the claims and then that gets passed to your application. The middleware will take all the claims and add them as headers to the downstream request so the proxied application can act on them without doing anything with the JWT. Nothing in the header portion gets passed.