add passthrough option

[zikes]

Some applications need to let the user access paths regardless of JWT presence, but still decode and forward JWT claims upstream if a JWT is found. This is helpful for public-facing applications with user logins, e.g. GitHub, Reddit, etc.

If passthrough is specified in a JWT block then instead of returning a 401, 403, or 303 for no JWT, the request will proceed as normal.

[BTBurke]

Can you explain a little more about this use case?How is this different than the except directive that selectively bypasses JWT verification for specified paths?

This seems to defeat the purpose of configuring this middleware at all, since you could get a passthrough by just omitting the JWT block in the Caddyfile.

When you talk about forwarding JWT claims, are you saying you want unverified claims to be passed as headers to the backend after being extracted from the token?

It would be great if you could also include a pull request for the readme that explains when/why you would use this with some examples using social logins so that it's more clear what the benefits/risks are.

[zikes]

To clarify, this is to allow Caddy to validate/forward JWT claims if present, but allow traffic to proceed normally even if no JWT is present.

This is useful for scenarios such as e.g. GitHub. If you imagine GitHub using Caddy+caddy-jwt, currently it would 401 anyone that visited any page except login. With passthrough, pages would still be reachable regardless of whether the user is logged in, but the application would also receive the decoded claims if they are found.

Certain paths could still be fully protected with a separate jwt block without the passthrough option enabled, such as in the GitHub example private repositories or pages only relevant to logged in users, such as profile settings.

Talking through it as above, I realize there is a risk that someone could include their own Token-Claim- headers to spoof a validated JWT, however that can be easily mitigated by stripping those from all requests before forwarding. Notably, this vulnerability is also in the existing codebase, though it would only work alongside a valid JWT and for claims not included in that JWT.

If this sounds good to you, I will add the passthrough documentation to the README and add a new commit to strip incoming token claim headers.

[BTBurke]

Ok that makes sense. Although it's kind of a bad idea to use JWT for that specific scenario because you need to maintain a blacklist to be able to log out. But I can see how this might be useful for other scenarios.

I also need some tests added that verify it does indeed pass through, adds headers for a validated token, and strips malicious headers. This is mainly for regression testing as more bells and whistles are added.

[zikes]

@BTBurke anything else you'd like me to add or change?

[BTBurke]

My bad, should have looked at this a while ago. Can you just add a little to the readme that explains why/how to use the passthrough option? Then it should be good to go.

[BTBurke]

Looks good. Thanks for the contribution.

[zikes]

Looking forward to using this, do you know when you'll be able to make a new release so it's available in Caddy?

[BTBurke]

My bad. I forgot to deploy it to the caddy build server. Will do that tonight.

[BTBurke]

@zikes Ok finally got around to it. Sorry for the wait. Should be good to go now in v2.5.0.

[zikes]

Thank you sir!