Firefly III Remote Authentication Starts at the Proxy

Remote authentication in Firefly III now starts at the proxy. The self-hosted version of Firefly III can use database-backed login, personal access tokens, OAuth clients, or a reverse proxy for remote user authentication. The proxy acts as the primary identity provider and can transform a header into the most crucial authentication asset on the host.

Firefly III's remote user guard is a web server mode that passes an identity header. However, Firefly III does not perform any validity checks on this header or its contents; it simply treats the proxy as the authenticator. For this design to work, every request must pass through the proxy, and the proxy must remove any client-supplied headers with a designated name before adding its own.

The backend listener should not be directly accessible by users or workloads that can set arbitrary headers. The proxy's header name should be unique enough to avoid conflicts with other middleware.

Operators can test remote user authentication by deploying a disposable setup with the same proxy and application containers. Requests should be sent directly to the backend and through the proxy, with various forged, missing, and authenticated headers used. The logs from the proxy and the application should be inspected together to confirm that the header was supplied by the proxy and the backend responded accordingly.

Remote user authentication and API tokens have different delivery paths, and if the application cannot issue tokens in the current guard mode, operators should document the supported path instead of weakening the header boundary. It is essential to review the Firefly III token and OAuth pages as well.