Recommended use of Tinyauth

[Stephan-P]

@steveiliop56 in a recent discussion thread you mentioned
I generally recommend against adding Tinyauth on top of apps that already have authentication and/or have companion apps that depend on their APIs.

Could you elaborate on that?

• which are the specific features (AND/OR) of apps where you'd recommend to not use Tinyauth?
• I was under the assumption that it'd be best for the security of my Nas app stack to try and place everything behind tinyauth. It would be helpful if you could provide some examples where inserting Tinyauth in the login process is recommended and where it is not.

My apologies if this subject is already documented elsewhere. A link to that will be much specificated.

[steveiliop56]

Hello @Stephan-P,

Tinyauth works through proxy authentication. The way proxy authentication works is that with every request you make to an application behind a proxy, the proxy asks Tinyauth "Is this user allowed to continue?", if Tinyauth says yes, the proxy allows the request, otherwise it redirects to Tinyauth for you to login. However there isn't a single standard for proxy authentication, so most (if not all) self-hosted applications don't support it. So, when you try to use an application with its companion app, the app expects a standard response from some internal API endpoint in which Tinyauth may reply with its non-standard redirect for logging in which the app wouldn't understand.

That's why I advice against using Tinyauth (and proxy authentication in general) for applications that need companion apps. In this case, it's much better to use OpenID Connect with Tinyauth's OpenID Connect Server which doesn't interfere with the app's internal design but still allows you to login through one centralized gateway.

Now for apps that don't have their own authentication (and usually no companion apps) Tinyauth is a perfect fit as it can protect them to the full extend.