While proposing Firefly III to support OAuth login, my proposal got rejected because they already support REMOTE_USER from RFC3875. This is very interesting, because I never thought we can utilize authentication via proxy. I’m aware of Authentik’s Proxy Provider, but never thought that there’s standard for this. Especially when you provide the upstream with just user id and force the upstream to “trust” them. No validate-able tokens, string, or auth strings.

What is it

REMOTE_USER is a HTTP header that we can use to tell upstream that current remote user id is this user (either by user id, email, etc). The upstream then don’t have to build their own authentication stack and can just rely on this proxy who’s currently it is connected to.

Projects

Project that support this protocol are:

• oauth2-proxy
  A reverse proxy that you can use to force user to login first before accessing the upstream.
• mod_auth_openidc
  This one provides a way to authenticate with OAuth2 directly via Apache2.

Notable project:

• Authentik’s Proxy Provider
  While this provider isn’t exactly supports OAuth2 protocol, the Authentik it self is! Also, another reason is this is the first time I noticed the “wall” part of “walled garden” project exists.

Security Considerations

Everyone can just add REMOTE_USER header directly when requesting to our server, right? So we need to make sure that the REMOTE_USER is completely filled by trusted proxy server.

One way to do that is by allowlisting the proxy’s IP, either by directly giving the list of IPs, or just give them CIDR range of proxy. If you’re using docker or kubernetes, it probably makes more sense by just giving the CIDR of the cluster.

As far as I know, reverse proxy tools usually won’t just forward these headers to the upstream, so if external party tries to do fill these headers, it will just be discarded (See RFC7230, Section 6).