Why MFA Sidecar?

YunoHost makes it easy to run great self-hosted apps, but many downstream apps still do not offer a clean MFA story.

That leaves operators with a bad choice:

accept weaker authentication than they want
or try to bolt on app-by-app solutions that are inconsistent, fragile, or impossible

MFA Sidecar exists to close that gap.

The core idea

Instead of requiring every downstream app to natively support MFA, MFA Sidecar adds a dedicated authentication perimeter in front of selected apps and paths.

That means an operator can protect real services without waiting for every upstream app to reinvent authentication correctly.

What MFA Sidecar does

MFA Sidecar provides:

a dedicated authentication portal
an operator admin UI
a sidecar-owned user store
host + path level protection rules
explicit Protect vs Bypass control
a break-glass recovery path that is meant to be understandable under stress

Why not just trust the app?

Because many apps:

do not support MFA at all
support it inconsistently
make recovery harder than it should be
were never designed to fit a consistent perimeter-auth model

MFA Sidecar is built for that real-world mess, not an imaginary perfect ecosystem.

Why operator control matters

Security that locks out the operator is not maturity. It is just a different kind of failure.

MFA Sidecar is designed to keep recovery explicit:

Bypass is an intentional state
disable / re-enable behavior is part of the model
recovery is meant to be obvious, not clever

What kind of project this is

MFA Sidecar is not trying to be a flashy consumer auth product.

It is an open-source infrastructure integration layer for people running real YunoHost services who want a practical, operable MFA perimeter.