Allow public access without forcing auth, but still pass HTTP headers for SSO capability

[The-Shortman]

Hello,

I have been scratching my head at this (probably niche) use case for a few days now, and I can't find any explicitly helpful information online.

I have a few self-hosted apps that support SSO via HTTP headers from a trusted reverse-proxy, but don't support any other form of external authentication, such as OIDC. I'm running Tinyauth in a docker compose stack as a Traefik middleware, with LLDAP as the account handler.

My problem is that I don't necessarily wish to block any access to these applications with Tinyauth by using it as a forwardauth middleware, as these applications can be used for certain things that I still wish to be publicly viewable without an account. I only want to be able to pass user info via HTTP headers so that the application knows if the user is logged in via SSO.

As of now, these applications, when placed behind forwardauth middleware, cannot be accessed. I can get around this in some niche scenarios by adding middleware override rules in Traefik's dynamic config, where certain paths in the application are exempt from authorisation, but this causes the app to think the user is logged out when accessing those paths, as it is no longer receiving the headers from Tinyauth.

As an example, one of these applications is a wiki that supports auth using trusted HTTP headers, the pages of which I would prefer to be publicly viewable without an account, but I would also like it to be able to recieve HTTP headers forwarded from either Tinyauth or LLDAP, so that I can log in and edit the pages using my selfhosted SSO ecosystem. Here, to my knowledge, it isn't possible to add exempt paths in Traefik's dynamic config, as the same paths need to be accessed by both a logged-in user, and a logged-out user.

Apologies if I'm missing something glaringly obvious :P

[dosubot[bot]]

Hi @The-Shortman! I'm Dosu and I'm helping the Tinyauth team.

Unfortunately, Tinyauth does not currently have an "optional authentication" or "permissive pass-through" mode that would let unauthenticated users access an app while still forwarding SSO headers for authenticated users. This exact use case has been raised before [1], and the maintainer noted it doesn't align well with Tinyauth's current architecture — Tinyauth either requires authentication (returning 401/redirect for unauthenticated users) or fully bypasses it (passing no headers at all).

The closest available options are:

• path.allow — regex-based path patterns that completely bypass auth for matching paths [2]. However, this is a full bypass: no identity headers are sent even if the user has a valid session.
• IP-based bypass — skips auth entirely for whitelisted IPs/CIDRs [3], but again, no headers are forwarded.
• ACL policy set to "allow" — controls default permissions for authenticated users, but still requires authentication in the first place [4].

None of these achieve the "pass headers if logged in, but don't block if not" behavior you're looking for. This would likely require a new mode in Tinyauth's forward auth endpoint that returns 200 (with empty identity headers) for unauthenticated requests instead of 401, while still populating headers when a valid session cookie exists.

You're not missing something obvious — this is a genuine gap in the current feature set. You may want to add a 👍 to the existing discussion or open a feature request to signal interest to the maintainers.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[The-Shortman]

This exact use case has not been raised before. I read that discussion and it does not answer my question about my specific situation.

I'd appreciate if an actual human can provide an answer to my question.

[steveiliop56]

Hey @The-Shortman,

Yeah the bot kind of missed that one but it's mostly correct. I don't understand how this feature could work. If you allow everyone to access X app then what's the point of it receiving SSO headers? And even if there is a point then what should Tinyauth forward? If the app absolutely needs SSO headers then can't you use the Traefik middleware that sets headers on every request to authenticate?

[The-Shortman]

One of the more useful cases as I mentioned was a wiki, where you would need an account to edit pages, but unauthenticated users can still view the pages.

The wiki I am selfhosting is LeafWiki, which, as far as I know, only supports SSO authentication through HTTP headers (i.e. Remote-User) received from a trusted reverse-proxy, but doesn't support other forms of external authentication such as OIDC. In other apps that I selfhost, OIDC can be used to request credentials from Tinyauth, and still allow unauthenticated users to access the app.

I have seen this same scenario in other softwares such as copyparty, where the only SSO method they support is HTTP headers. Copyparty is not as affected by this scenario, as it's most likely used as a private file server, so you wouldn't necessarily need it to be accessed by unautheniticated users anyway, and can just use Tinyauth as a forwardauth middleware as standard, then forward the headers.

I have been looking at the Traefik docs on the topic of HTTP headers, namely this article, but they only cover custom-defined headers in Traefik's config, or true/false standardised security headers. If I'm missing something there please do correct me.

Also, this isn't exactly a requirement for the apps to function, as the ones I'm using have their own authentication anyway, but rather it's a nice-to-have.

[steveiliop56]

I am still trying to understand how such thing would work. Can you please provide an example of how such feature would work?

[The-Shortman]

Based on the documentation of LeafWiki and copyparty, what it seems they are expecting is something along the lines of the following (using a wiki as an example):

1. User accesses wiki.example.com, which is behind a reverse-proxy.
2. The reverse-proxy handles the connection with an authorisation middleware.
3. The authorisation middleware (i.e. Tinyauth), at auth.example.com does one of two things:

• If the user is signed in already, Tinyauth then applies Remote-User, Remote-Groups, etc. to the headers (which it already does). The wiki on the other end reads these headers and automatically logs the user in. The user can now view and edit pages.
• If the user is not signed in, however, instead of showing them a login screen, Tinyauth simply lets them through without passing any authorisation headers. The wiki thus doesn't see the headers, and allows the viewing of pages only, without the need for an account.

4. Applications, such as LeafWiki, that behave like this have a configuration to remap their "Login" button to redirect users to an authorisation provider, with a redirect back to the application after logging in. Tinyauth already supports this functionality so nothing changes there. The "Log out" button can also be mapped to the log out URL of Tinyauth.

If there's anything else you need me to clarify let me know.