Vaultwarden app setup issue with TinyAuth (+ suggestion for new feature)

[RealAntithesis]

I'm trying to set up Vaultwarden with NPMPlus using TinyAuth for authentication. This is working fine, except when it comes to the mobile and Windows app, which can't work with the TinyAuth forward_auth. I'm understanding that the usual way to get around this is to add a path.allow label to the Vaultwarden compose file, such as: tinyauth.apps.MyVaultWardenAppSubDomain.path.allow: ^/(api|identity|wl)/

The problem with this (apart from the obvious reduction in security which relies on the app being properly secure and unexploitable), is that this seems to bypass authentication for all of Vaultwarden, including browser and mobile/Window apps. I at least wanted to keep the TinyAuth authentication for the browser. I'm guessing the "api" path is used by both the browser and app versions of Vaultwarden since the above behaviour happens if I only have ^/api as the path.allow.

Is there a way to bypass authentication for just the mobile and Windows Vaultwarden apps with TinyAuth? Even better would be a feature to allow the user to login via a browser to authenticate their IP, which would then allow that device IP to access protected apps as if they had authenticated via TinyAuth, and then blocked when the user logs out of TinyAuth in the browser (and/or after a certain user-definable time has elapsed). I'm not sure if this adds further security concerns, but it sounds like a decent solution for non-browser-based client apps rather than permanently bypassing this authentication layer. I think there is also a proposal here along similar lines.

In the meantime, I'm not sure what I'm doing wrong with the path.allow method above.

[steveiliop56]

I generally recommend against adding Tinyauth on top of apps that already have authentication and/or have companion apps that depend on their APIs.

I don't know what's the case with the Vaultwarden API paths but you should be able to allow them with /^\/(api|identity|wl).*/ (should allow /api/*, /identity/* and /wl/*). Also make sure that Tinyauth has access to the Docker socket and I would recommend you also explicitly set the Vaultwarden domain with tinyauth.apps.vaultwarden.config.domain: vaultwarden.example.com.

In any case please be careful with the path.allow label as with a simple misconfiguration it can leave important parts of your network unprotected and with regex it's oftentimes not hard to shoot yourself in the foot ; ).

Is there a way to bypass authentication for just the mobile and Windows Vaultwarden apps with TinyAuth? Even better would be a feature to allow the user to login via a browser to authenticate their IP, which would then allow that device IP to access protected apps as if they had authenticated via TinyAuth, and then blocked when the user logs out of TinyAuth in the browser (and/or after a certain user-definable time has elapsed)

I am not really sure how such feature would work with Tinyauth. Tinyauth has no way to know in what you are logging in, it just sits in the middle and says "If you have the cookie you are in".

[RealAntithesis]

Just thinking about this some more, I think I was thinking more of a temporary TINYAUTH_AUTH_IP_ALLOW (which can already be done) , so when a user logs in, they would then have an option (eg in the TinyAuth logout screen when navigating to that url) to authorise the IP of the device until logged out or until a certain duration has passed.

The intent I have is to impose a reliable authentication barrier between the app (regardless of whether the app is a browser based app, phone or desktop app, and regardless of whether it has its own authentication mechanism or not) and whoever reaches the app url via the reverse proxy.

This way, I can worry less about the robustness of the app in keeping out unwanted individuals.