Authentication fails when opened in external browser

[tobi-nb]

Home Assistant Android app version(s): 2026.2.1-full

Android version(s): 16

Device model(s): Nothing Phone (2)

Home Assistant version: 2026.1.3

Last working Home Assistant release (if known):

Description of problem, include YAML if issue is related to notifications:
My HA instance is available on the internet but protected via my reverse proxy (Pangolin). This means I have to authenticate before seeing the login screen of HA. In the latest version, when opening the app this would work just fine, but now the behaviour changed.
The unintended behaviour is as follows: When disabling the reverse proxy authentication screen, HA opens the login screen right away in the app and I can log in. When the reverse proxy screen is active, HA does not open the login screen in the app but opens it externally via the phones browser. When I type in the credentials here, HA accepts them but is stuck in the redirection to the app. The only option displayed is then "start from the beginning". It seems as if the redirection to the app is broken. HA sends a notification as "Login attempt or request with invalid authentication from XX.dip0.t-ipconnect.de (193.159.XX.XX). See the log for details."

The log says:
Logger: homeassistant.components.http.ban
Quelle: components/http/ban.py:136
Integration: HTTP (Dokumentation, Probleme)
Erstmals aufgetreten: 11:46:10 (1 Vorkommnis)
Zuletzt protokolliert: 11:46:10
Login attempt or request with invalid authentication from XX.dip0.t-ipconnect.de (193.159.XX.XX). Requested URL: '/auth/login_flow/a4aedce7b7101c7d18a0f53c4db2ca7e'. (Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/144.0.0.0 Mobile Safari/537.36)

I checked if HA somehow banned my IP due to this but it seems as if there are no bans. The video shows the problem.

Companion App Logs:

Screenshot or video of problem:

Authentication.Bug.mp4

Additional information:
This worked before and I had no problems with additional authentication screens. Sadly I cannot recall the version it worked last time.

[hahn23]

Same here. I am using the cloudflared addon with google or github authentication as frontend layer. Worked perfectly fine since the newest update with the new onboarding stuff. After login at the App it shows also only "start from begin" or something.

`Logger: homeassistant.components.http.ban
Source: components/http/ban.py:136
integration: HTTP (documentation, issues)
First occurred: 19:18:42 (5 occurrences)
Last logged: 19:19:43

Login attempt or request with invalid authentication from iXXXXXXXXX.versanet.de (109.XXX.XXX.XXX). Requested URL: '/auth/login_flow/e5abc358b2b4f9d79592bbc51f271edb'. (Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/144.0.0.0 Mobile Safari/537.36)
Login attempt or request with invalid authentication from iXXXXXXXXX.versanet.de (109.XXX.XXX.XXX). Requested URL: '/auth/login_flow/faed73442316812a0af5ba20213ed19c'. (Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/144.0.0.0 Mobile Safari/537.36)
Login attempt or request with invalid authentication from iXXXXXXXXX.versanet.de (109.XXX.XXX.XXX). Requested URL: '/auth/login_flow/4fea4a343ce099493fdbce85bda6e19b'. (Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/144.0.0.0 Mobile Safari/537.36)
Login attempt or request with invalid authentication from iXXXXXXXXX.versanet.de (109.XXX.XXX.XXX). Requested URL: '/auth/login_flow/cef9b3293344e5bdacaa5698c8e3c93a'. (Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/144.0.0.0 Mobile Safari/537.36)
Login attempt or request with invalid authentication from iXXXXXXXXX.versanet.de (109.XXX.XXX.XXX). Requested URL: '/auth/login_flow/e5ebbf5054fcf11d24169a05e1891975'. (Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/144.0.0.0 Mobile Safari/537.36)`

[panzerknacker20111]

Exactly the same here. very annoying. cant use my homeassistant from remote since the new update.
I am using the cloudflared addon too and it worked till the new update perfectly fine.
Since the "new onboarding experience" it fails completely.

Logger: homeassistant.components.http.ban
Quelle: components/http/ban.py:136
Integration: HTTP (Dokumentation, Probleme)
Erstmals aufgetreten: 4. Februar 2026 um 21:57:25 (7 Vorkommnisse)
Zuletzt protokolliert: 4. Februar 2026 um 22:04:45

Login attempt or request with invalid authentication from iXXXX0XXX.versanet.de (1XX.XXX.XX.XX). Requested URL: '/auth/login_flow/257d2df232f4dfa9b425877baaef3b17'. (Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/144.0.0.0 Mobile Safari/537.36)
Login attempt or request with invalid authentication from iXXXX0XXX.versanet.de (1XX.XXX.XX.XX). Requested URL: '/auth/login_flow/33b58e53e6960d52766ab8ef070d0aa0'. (Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/144.0.0.0 Mobile Safari/537.36)
Login attempt or request with invalid authentication from iXXXX0XXX.versanet.de (1XX.XXX.XX.XX). Requested URL: '/auth/login_flow/348dba8c64f9fba4b78db8497ec00722'. (Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/144.0.0.0 Mobile Safari/537.36)
Login attempt or request with invalid authentication from iXXXX0XXX.versanet.de (1XX.XXX.XX.XX). Requested URL: '/auth/login_flow/83e7ced33288c95def76a9970c305449'. (Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/144.0.0.0 Mobile Safari/537.36)
Login attempt or request with invalid authentication from iXXXX0XXX.versanet.de (1XX.XXX.XX.XX). Requested URL: '/auth/login_flow/18e490d2b30cf19d7fcfee73fda9a5e0'. (Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/144.0.0.0 Mobile Safari/537.36)

Access over normal webbrowser works just fine. But the app fails to work remotely. Only when in the lan and using local adress.

[hahn23]

Because there was no help or recommendations at all I downgraded my app using the 2025 november apk and guess what? All worked again perfectly fine. I did not touch any of the server parts and my homeassistant os is on the most resent beta release. So it is clearly an Android App issue that is causing this. Something with the redirection etc seems completely broken on the new app releases.

[dispatchrabbi]

I'm in exactly the same boat as OP, though I am on a Pixel 6 and Android 15. I'll come back and add logs when I can, but I expect they are similar.

[TimoPtr]

The new onboarding flow is actually fixing a flow in the previous design that was allowing the app to open an external links where it shouldn't have. When a user click on a link we from the discovery page the app is not allowing any redirection there. In the previous flow when your auth expired while in the app the only way to get back access was to re-onboard since the main WebView was not allowing opening an external URL. Now both are aligned.

If you want an extra layer of security today the only supported way is using mTLS. We don't want the app any other website than Home Assistant and risking any access that are not controlled to the data store in the app.

[GeorgeCastanza]

Same issue here. Very frustrating. Needs to be reverted, regardless of what @TimoPtr says is the reason.

[Choromanski]

I went through all the pre-releases and this seems to have been introduced in the 2025.1.3 build

[soonic6]

same here, after my cookie isnt valid anymore, i cant login into my homeassistant app.

[soonic6]

I used that one https://github.com/home-assistant/android/releases/tag/2025.11.3 for login, than upgrading from playstore for use.

[alexanderbittner]

@TimoPtr could a potential middle ground be to add allowed origins for a redirect? For example, users could allowlist their own authentication page / middleware as trusted sites, while untrusted content would still not be allowed.

[tobi-nb]

@TimoPtr So let me clarify this. The usability was purposely reduced for an increase in security? And exclude users who actually want to increase their exposure by using i.e. Cloudflare? As you can see, the change has already affected multiple people and leading to them actually downgrading their app, leading to less security overall. I won't be able to roll out mTLS for every device I may use HomeAssistant in the future, especially explaining it to friends or family or managing jt.
I can understand the attacker model if someone redirects to a phishing site, but is there no better way to restrict this than reducing the usability drastically?

[TimoPtr]

@tobi-nb even if you downgrade if for any reason the session expires the user won't be able to reconnect in the main WebView. This happen because of the code that handle the auth and the actual main view was not shared. So the checks were implemented properly in the main view but not in the onboarding, now we are sharing the same logic for maintenability.

The authentication by itself is a huge topic in HA, and I don't want to change it until we settle at the Home Assistant level where we want to go with it.
See #4466
See Open letter for improving HA auth system

In terms of security the bare minimum to have is at least HTTPS with a proper certificate. Having Pangolin and HA is a bit redundant if they use the same factor of authentication (only password = something you know). You could instead enable 2FA in HA and remove the auth layer from Pangolin in your case. If you have Cloudflare in front you can also enable geoblocking or even use Zero trust approach with wrap (that is the solution I use personally, indeed your user needs 2 apps or mTLS for users that doesn't want 2 apps).

If it is a real blocker for you at the moment you could do like @soonic6 did by doing the onboarding in an old version and update from the PlayStore, until we come up with a better way to handle third party auth.

[hahn23]

@TimoPtr you said:
The new onboarding flow is actually fixing a flow in the previous design that was allowing the app to open an external links where it shouldn't have.

But that is not really the case. I use the cloudflare addon and using zero trust with github and google auth in front. Restricted to only germany and only with emailaccounts i approved.

Even with the new onboarding it triggers the webauth with opening the browser. It fails after the login. Odd is also that i have no port opened to the public internet but the failed login messages get to the server anyway. Which with my understanding means that cloudflare succesfully authenticates the zero trust auth and forwards it to the tunnel. But HA than blocks it. Shouldnt those requests come from the internal docker network?!

To summarize:

In my opinion you did more harm to HA with this new stuff than good. And as you see i am not alone with this opinion.