Gatekeeper - allow anyone to trigger actions without accessing Home Assistant

I made a Home Assistant app (add-on) that allows visitors that don’t use Home Assistant to trigger actions within your Home Assistant instance, while still begin secured with a login screen and long-living access tokens.

Expose this app’s port (e.g. via reverse proxy). Anybody who now visits this port, will see a login screen. Once they have logged in, their device will store a token so that in future they won’t have to login anymore.

I use this to have guests open the gate to my driveway. They visit a website subdomain that points to my reverse proxy that points to this port, and they can access my driveway.

Tokens are stored for 365 days (customizable).

Find the app in my repo.

Open your Home Assistant instance and show the add app repository dialog with a specific repository URL pre-filled.

Don’t use this to unlock doors or other stuff you don’t want people to use/access. I can’t promise the security of this app won’t be compromised. Use at your own risk!

Atleast You are Honest :wink: , but why do you have all your various HA-Apps under same repos-url ?
I Don’t believe this is the right “approach” , but maybe “convenient” for You

Also make an effort in clearly state in Your Apps, whether they are made for HTTP vs HTTPS
Opening HTTP ports into HA is not a recommended way, and i.e New Users should be aware of this

That’s how app repositories are organised. e.g. all the community apps are in one repository.

ok !, first time i noticed this for Custom:Integrations, most authors keep And Links to their Apps/Integrations under it’s respective Name, And OP ( For his Gatekeeper App ) links to author/ha-apps ( Which means all his apps/integrations, not the specifics )

Integrations get individual repositories. Apps (add-ons) don’t.

Ok, never to late to “discover” something “new” :slight_smile:

There are always going to be security implications you have no control over, and broadening your exposure surface is sometimes fraught with danger.

A few questions:
Can you retrospectively retract the token once it has been issued, or update the validity to extend it? Will that be synchronised before the next approval is actioned, during the exchange phase?

Is the token stored on both ends and compared during the authenticate process (HTTP or HTTPS) or later?

Does it go plain text or subject to replay and MITM attacks?

Once it is verified, is it renewed with a fresh token to the other end? Each and every time it is used? Do you get a notification this has been done?

Can I use these for more than one destination that has this app installed? When multiple people such as friends and tradesmen have different allocations, and alternatively, when I visit other HomeAssistant aficionados like on a campus that may just want to trust me enough to let me wander in, edit yaml code, and wander off again, their problem fixed while they are in class or away on vacation?

Can I have a ‘master’ token, usable by many, such as a disabled person that has a host of rotating carers that all have the same token and trigger the same response in HomeAssistant, but you share it amongst the carers?

Great questions, makes me think deeper about the security of this app.

  1. Currently, the only way to get rid of a token is to delete the username/password combo from the app config and reboot the app. You could then re-add the user and restart the app and older logins will have become invalid.
  2. Both sides store a token to be compared, server saved in /data/sessions.db, client will receive it as a cookie. The cookie and token will have an expiry date of your set session_days: (default: 365) and will be refreshed each time the link is visited (as of 2.2.0).
  3. The cookie is just a plain HTTP header. So when enabling the option cookie_secure: (default is true), it will be TLS encrypted. This is secure enough for most applications, but as we know, TLS is not airtight. I wouldn’t use this add on for essential infrastructure like the door to your house just to be sure.
  4. The token/cookie is be refreshed every time it is used (as of 2.2.0). The logs show who logged in and triggered, or failed, and also failed login attempts, all with their client IP adresses. There is no notification exposed to HA, but you could track the logs if you’d like.
  5. This is not an app that allows other people access to your HA instance! It is just a ‘someone visited the link’ detector, it just turns on a binary_sensor for every registered user that is logged in and visits the link. This means the app will generate a binary_sensor per user, allowing you to configure what each user triggers. Use binary_sensor.gatekeeper_tradesman as a trigger in an automation to open your back gate, but use binary_sensor.gatekeeper_father_in_law to unlock the shed.
    Again, I will stress, be mindful that this app is not perfectly secure so don’t have it allow access to places you don’t want broken into.
  6. There’s not something like a master token, but you could just have multiple people sign in using the same username/password.

Consider using a shorter session_days: value if you want the tokens to be more secure. Users will just have to sign in more often.