[FEATURE] Proxy/Forward Authentication Support

[vorpalhex]

Is your feature request related to a problem?

I want my users to be able to log into stump without needing a second user account.

I already have a working login system that lets my users login with plex or discord (and all the right sub-rules, eg "must be in X discord guild", etc). I want Stump to simply "listen" to my existing authentication solution (Authentik) and respect headers that it will include in the request with the users username.

Describe the solution you'd like

I want Stump to support Proxy (aka Forward) auth. This is where my authentication system includes http-headers on the user's request to stump that includes that user's information. Stump then creates that user (if they don't exist in Stump's database) and logs in the user.

This allows the following:

1. Stump is well integrated like all of my other apps
2. Stump no longer has to implement fifty million possible authentication possibilities (discord, google, plex, github, passkeys, yubikey, etc)
3. Rules around 2FA or passkey/magic email login are now possible (eg for ereaders)

For security reasons, this feature should be disabled by default and require enablement. The exact headers stump looks for should be configurable to allow maximum compatability with different proxy and authsystems.

Here's an overview doc: https://store-restack.vercel.app/p/open-source-authentication-tools-knowledge-reverse-proxy-authentication-answer-cat-ai

And a much longer blog writeup: http://morganridel.fr/authentication-for-multiple-apps-behind-a-reverse-proxy

This solution is generally compatible with most authentication and proxy setups (traefik, caddy, nginx, authentik, authelia, and more).

Describe alternatives you've considered

OIDC or LDAP are much more complex and painful versions of a similar concept. They have their place but Proxy/Forward Auth is usually easier to implement and easier to integrate, and is even automatic in many stacks.

[aaronleopold]

I'd have to spend some time to read through the docs you linked (thank you for that, btw) to better gauge how involved it might be, but on the surface I like this. Thanks for the write up! I'll probably revisit when I had originally planned to look into OIDC, but would also happily accept/facilitate contributions if interested