Leveraging cookies for authentication

[blakeblackshear]

Context

I am currently attempting to develop a "reverse_proxy" component that makes it possible to leverage homeassistant's authentication while exposing an API on my internal network. It is similar to the Ingress feature in Hass.io, but doesn't require Hass.io. This would allow me to use things like a picture card with an image from /api/reverse_proxy/my_application/image.

Proposal

I would like to propose the use of industry standard cookies for authentication in addition to the current authorization headers. Looking at the source for Ingress, camera_proxy, etc., it seems like a lot of complexity is introduced by passing around tokens and creating system users to pass the authorization headers. In addition, this breaks standard browser caching of images due to the authSig parameter.

Consequences

I understand that security is hard to get right, but using HTTP only cookies for authentication is a widely used pattern. This would increase the surface area a little, but the benefits outweigh the costs in my opinion.

[shbatm]

Similar issue here if you want to see some discussions on the auth process https://github.com/home-assistant/architecture/issues/286

[blakeblackshear]

My reddit post on how I implemented oauth2_proxy previously is linked on that issue. Using an upstream authentication proxy would be a solution for my use case as well (and an alternative to ingress). I'm not actually a fan of implementing a reverse proxy as a HA component, but that seemed simpler than trying to implement compatible authentication in another reverse proxy. It is also a solution that others can use more readily.

[balloob]

This is not something that we should currently consider. Session cookies expire, and then you need to make sure they stay up to date. As it stands now, Home Assistant hardly makes any requests to the server (all websocket) to keep such cookies up to date. Also it gets complex if a browser window is activated after being inactive for a while. We're already running into random auth issues of requests being fired on tab focus. On top of that it's yet another part of the code that could have bugs that allow people to gain unauthorized access to Home Assistant.

[blakeblackshear]

Could you set the cookie with the appropriate expiration on the response when posting to /auth/token? Seems like that would keep the cookie current. I didn't see another way that new tokens could be retrieved.

[blakeblackshear]

I'm trying to work through how ingress works to see if it is something that works for my use case. Here is what I understand so far:

1. The hass.io component registers a view with authentication disabled
2. A system user is created for hass.io which generates tokens
3. Addons supporting ingress use a special base container than can inject a token into the base url in the nginx config dynamically
4. The panel for the addon then makes requests as /api/hassio_ingress/{token}/{path:.*}
5. This request is forwarded to supervisor and routed to the addon container

Not sure if I got all of this right, but that is a lot of surface area to worry about introducing bugs which allow people to gain unauthorized access to Home Assistant. If a standard cookie could be used:

1. No need for a specialized base container. Most applications are designed to work behind a reverse proxy already.
2. No need for a hass.io system user to generate token based paths for ingress
3. No need to embed an auth token in the path of requests

Maybe I am missing something, but this change seems like it would actually be a net decrease in surface area.

[frenck]

This architecture issue is old, stale, and possibly obsolete. Things changed a lot over the years. Additionally, we have been moving to discussions for these architectural discussions.

For that reason, I'm going to close this issue.

../Frenck