Proxy authentication by http header value

[max-tet]

Verified feature request does not already exist?

• I have searched and found no existing issue

💻

• Would you like to implement this feature?

Pitch: what problem are you trying to solve?

When self-hosting multiple applications, you really want to have a single point for user management and authentication. It is annoying to login to each and every app seperately.

Describe your ideal solution to this problem

A pretty simple way to centralize authentication is achieved by deploying apps behind a reverse proxy, and use proxy auth. The proxy handles authentication in some way and sets http headers containing the username that was successfully logged-in. The apps read the headers and associate incoming requests to that user.

The perfect proxy auth feature for me would work like this:

1. Start the app with additional environment variables:

• containing the name of the initial admin user (e.g. admin=admin_user)
• enabling proxy auth (e.g. proxy_auth=true)
• setting the key of the http header that contains the username (e.g. auth_header=X-Authenticated-User)

2. Configure the reverse proxy to authenticate incoming requests in any way you like.
3. Let the reverse proxy set X-Authenticated-User to the authenticated username on every request.
4. The app treats the requests as if they belong to the appropriate user session.
5. Bonus: if the app does not know the username, it creates a new user with that name.

Other SSO methods like OIDC still require the user to login with each app, even it no credentials are required. It is still an additional step that is unneeded and hurting the user experience.

Here are some examples of apps that feature proxy authentication: FreshRSS, LinkDing, Navidrome.

Additional context:
I am using the app for this product. Since this is a single-user platform, users really should see no login screen at all, not even for SSO.

Teaching and learning

The documentation should contain a section about proxy auth where the configuration is described.

[j-f1]

How would you feel about generating an auth token and then having the proxy inject a Authorization: Bearer ${token} header in all requests? I don’t think most existing setups would work well since they are intended to work for multiple users, although we certainly could move to one of them if/when we add multi-user support.

[max-tet]

Right, I did not consider that Actual has no user management/is a single-user app.

In that case, tbh, the most straightforward approach would be to offer an option to just disable the password prompt completely. But I have seen a discusson about this which was deemed too insecure if I am not mistaken. I personally don't agree, after all the option would have to be actively enabled.

The alternative with the token is an interesting option. If it works for me would depend on how the token is generated and how the proxy would get to it. If Actual generates it itself, I don't think it would work. It would have to be known before the app is started.

It could be set by an environment variable, e.g. AUTH_TOKEN=supersecrettoken. Perhaps also specify the header key like AUTH_TOKEN_HEADER=auth-token. Then, the proxy would set the header auth-token=supersecrettoken. (I would skip the Bearer prefix.)

But again, an option to simply disable the password auth is the most simple approach and totally legitimate imo. You can add a large warning label in the docs that people should setup their proxy properly when using the option.

[github-actions]

✨ Thanks for sharing your idea! ✨

This repository is now using lodash style issue management for enhancements. This means enhancement issues will now be closed instead of leaving them open. This doesn’t mean we don’t accept feature requests, though! We will consider implementing ones that receive many upvotes, and we welcome contributions for any feature requests marked as needing votes (just post a comment first so we can help you make a successful contribution).

The enhancement backlog can be found here: https://github.com/actualbudget/actual/issues?q=label%3A%22needs+votes%22+sort%3Areactions-%2B1-desc+

Don’t forget to upvote the top comment with 👍!

[MFYDev]

Hi, just think this and found the issue, is there any progress here?

[deathblade666]

Hello, I was pointed to this issue as i was asking about this very thing. trying to setup SSO but dont want to have to double auth. as detailed above if disabling the password prompt or using proxy auth headers could be a thing that would make this possible!!

[joewashear007]

Hell, I am use Authentik for Proxy SSO. I see that the app uses the X-ACTUAL-TOKEN header which it got from the api. Is it possible to have the nginx proxy pass this header along? I tried setting it with proxy_set_header X-ACTUAL-TOKEN <value from application> but it sadly didn't work.

I would love to see this implemented, so that I can do the authentication via Authentik, and them my wife i could simple access the application with our own individual accounts (on the proxy side - i understand there is only one actual account)

[d3x7r0]

Just adding my 2 cents to this feature request. I'm looking into setting up Actual for myself as well and I already use Authelia for authentication which supports header based Auth. It would be great to have Actual support these headers as well.

Here's Authelia's documentation on the feature. They forward 4 headers: Username, User Groups, User Display Name and User Email. Then, tools that support this will usually have some sort of configuration for these headers and a whitelist for proxies they accept headers from (see Organizr's example)

[youngcw]

Im going to close this off as completed. The ability to pass a password via header to bypass the server password was added in v24.6.0.

For discussion on more involved login/users please use #524