Loading cookie with alternative name

[martenjacobs]

I'm trying to use Caddy to set up SSO between some services that are proxied by Caddy on different subdomains. This works pretty well, by setting the cookie-domain of the login plugin to a common domain all these services share. However, I'd like to be able to change the cookie name, as the default name "jwt_token" seems pretty generic, which I think could easily be overwritten by a careless service. http.login supports the cookie_name directive, but as far as I can tell, there's no equivalent in caddy-jwt.

[BTBurke]

Sorry, Marten, this isn't something I'm likely to spend time on implementing. Unless there's a real bug here, I don't have time to do it.

Happy to accept a pull request from you or someone else if they want to work on it.

[magikstm]

loginsrv does use caddy-jwt and cookie-domain indeed does that.

It should work to create a SSO between services. There are some tweaks needed for it to work properly locally, but otherwise it should work.

What issue are you having? Is it a local setup?

[martenjacobs]

@BTBurke Fair enough. I'll try to make some time to put together a PR. Not too familiar with Go though, so I'll have to see where that goes.

@magikstm The issue isn't with cookie-domain but with cookie-name. My set-up is actually working at the moment, so there's no actual issue per sé, but I'm forced to use the default cookie name jwt_token in http.login. I'm using caddy to provide SSO through a reverse proxy to several services, so I don't have full control over what the other services are doing. As jwt_token is a very generic name, I'm afraid that in the future some of the services may overwrite it. I'd like to use a more specific name like my_sso_jwt_token_iue8u4w5is so I can be reasonably sure it remains untouched.

[magikstm]

The variable -cookie-name in http.login should do what you wish. It is available for Caddy.

I just tested it and it should work in the latest version.

[martenjacobs]

@magikstm I know, that's what I'd like to use, but I don't think that it's supported by http.jwt. It's possible for me to log in and have the the cookie created with the name I want, but it's not possible to have it loaded and verified with that name.

[magikstm]

Oh. I see. It's not supported in http.jwt yet.

With what are you trying to load and verify it?

http.login and http.jwt both use https://github.com/dgrijalva/jwt-go. You should be able to verify it with that library.

See this method in loginsrv: https://github.com/tarent/loginsrv/blob/master/login/handler.go#L283

[igor-petruk]

If I were to work on this feature and now we make the token sources configurable, do you think it is worth extending it to also make some sources optional?

For example, if the set of third-party services are protected with a single SSO that issues jwt_token in a cookie, then to keep things clean we could

1) Rename it to use my_sso_jwt_token cookie. 2) Teach it to only use this source and bypass Authorization header or query path unchanged and non-validated to the service behind the proxy.

The latter is important if we don't control the third party software which can use its own jwt authorization. Current example: it is impossible to use https://thelounge.chat/ behind the current version of this plugin, as it used "Authorization: Bearer" header. The user is forced to either abandon http.jwt and just rely on the proxied service to be unhackable, or to use client certificates.

The change could be the following:

1) Add support for cookie_name option for the cookies. 2) Add support for query_name option for JWT in the query path. 3) Keep the header unconfigurable, as it is now. I am not sure how to configure it meaningfully. Do we want to opt-in to use some other header? 3) Add support for specifying what checks to perform and in what order, e.g. "checks cookie,header". If unspecified - preserves the current behaviour from https://github.com/BTBurke/caddy-jwt/blob/master/jwt.go#L175. Which is equivalent to user explicitly specifying "checks header,cookie,query"