Proxy Outpost Basic Auth 2025.10.x Breaks after Outpost Restart

[christensenjairus]

Describe the bug As described in this other (now resolved) bug, basic auth through the proxy provider wasn't working on 2025.10.0. The solution (included in 2025.10.1) does work on the embedded outpost, but I can't seem to get non-embedded outposts running 2025.10.1 to send basic auth credentials after they restart and the sessions are reset.

I made an issue here about session storage with the outpost proxy that's worth noting. There I learned that currently, because the session storage is in memory & can't be stored elsewhere, when my single outpost pod restarts, I lose all my sessions stored by the outpost.

When this happens, every application that relied on basic auth credential sending from the provider, now prompts me for basic auth.

I can get the basic auth to work again as intended when I fully clear my browser's cache and log back into Authentik. Simply logging out & back into Authentik does not fix it - I need to clear the cookies.

To Reproduce Steps to reproduce the behavior:

1. Add a proxy outpost (I made mine manually on k8s)
2. Add a proxy provider w/ basic auth credentials
3. Assign the application to your external proxy outpost
4. Log into the application using the outpost
5. Kill the outpost container, clearing out its stored sessions. Wait for new outpost pod to start.
6. Refresh the page of the application

Expected behavior The application shouldn't prompt me for basic auth after an outpost restart

Logs Startup logs are normal after restart

When refreshing the application page after an outpost restart, logs like this one occur.

{"error":"failed to get session: open /dev/shm/session_TH4LDU4USSDPDED2TEYUG6OV5BHLG3TFBRPB45M2WNFTIQAVI3XQ: no such file or directory","event":"failed to create state","level":"warning","logger":"authentik.outpost.proxyv2.application","name":"Provider for Radarr","timestamp":"2025-11-13T20:10:24Z"}

I'd expect that for the first request, but it doesn't seem to be recovering after, it just logs the same thing for every request I send.

Version and Deployment (please complete the following information):

• authentik version: 2025.10.1
• Deployment: helm

[christensenjairus]

I use a simple echo server (fdeantoni/echo-server:latest) behind authentik to see which headers & cookies are getting through. After restarting the outpost, the only Authentik-related header that gets through is cookie, whereas before I had all the x-authentik- headers.

This may be a larger issue than just basic auth, as missing those other headers I'm sure would break apps that rely on headers for groups, username, etc. Though, you're already logged into the app & have a cookie at this point so maybe not?

[christensenjairus]

Just checked, and these issues don't exist if I use the 2025.8.4 proxy image.

Maybe I misunderstood, was the fix for basic auth & headers in the 2025.10.1 release?

[dubyatp]

I had a similar issue happening -- upgraded to 2025.10.1 earlier this week, and recently noticed I could no longer access the three applications I have under the embedded proxy outpost (the *arr stack)... it would just go to the Authentik portal after signing in, while keeping the proper URL for the application (no redirect to my authentik domain)

I ended up creating a separate proxy outpost and i'm able to access those applications again.

FWIW all my *arr's use basicauth as Proxy providers and haven't seen any of the issues with the basic auth prompt, but it seems like the original issue was related to forwardauth, so that makes sense.

[RomRider]

Same here with forward auth:

{"error":"failed to get session: open /dev/shm/session_GS7BD5RNWBUITCP2OCS4Q5U3XB2GVVH73Z5VTTZOHKZI6XAHSAVA: no such file or directory","event":"failed to create state","level":"warning","logger":"authentik.outpost.proxyv2.application","name":"XXXX - FwdAuth Provider","timestamp":"2025-11-17T13:55:11Z"}

And basic auth is still mostly broken

I can also confirm this behavior:

I use a simple echo server (fdeantoni/echo-server:latest) behind authentik to see which headers & cookies are getting through. After restarting the outpost, the only Authentik-related header that gets through is cookie, whereas before I had all the x-authentik- headers.

Also I need to refresh at least 3 times before being able to access any app behind either fwd auth or basic auth else I get a 400 error (using external outposts in k8s) and most of the time the app doesn't get the fwd auth headers (X-Authentik-XXX) or the authentication header.

Everything was rock solid for 1y... until redis was removed.

[christensenjairus]

2025.10.2 does not fix this either

[rickyelopez]

This may be a larger issue than just basic auth, as missing those other headers I'm sure would break apps that rely on headers for groups, username, etc. Though, you're already logged into the app & have a cookie at this point so maybe not?

Yeah, I'm having this issue. In my case, the only applications that are affected are those that depend on these headers. I'm surprised this isn't a bigger issue? Took me a while to even find this thread.

[BeryJu]

ref https://github.com/goauthentik/internal-customer-ref/issues/5

[rickyelopez]

Any ETA on a fix here? This completely breaks my apps that use header auth (namely lightweight media server and frigate)