0.77: Authentication system 👮‍♂️ + Hangouts bot 🤖

It’s time for a great new release and it includes a big change: the new authentication system has been activated! We’ve worked very hard on this for the last couple of months to make the transition as smooth as possible. Updating to this release is a non-breaking change (unless you had no API password configured). As can be seen in the video above, when you start Home Assistant after the update, you will be presented with our new onboarding flow. This will ask you to create a new account after which you will be able to log in to Home Assistant.

Once logged in, you will have access to the following new features:

  • Change your password
  • Configure multifactor authentication (TOTP)
  • Manage other users (limited to account created during onboarding)

Although it’s possible to configure authentication, we stronlgy recommend to stick with the default authentication configuration. If you had auth providers configured in a previous Home Assistant release, we recommend to remove the configuration and start using the default.

It will take some time before all of the Home Assistant ecosystem has been migrated over to the new auth system. Home Assistant will print a warning whenever an application connects to Home Assistant with the legacy authentication. This will help users notify the application developers to transition to use the new OAuth2 authentication. For non-interactive scripts or other applications that are unable to update, we are planning to introduce a migration path for components to adopt url specific auth tokens and also introduce long lived access tokens to replace API passwords. A list of impacted components can be found here.

Our iOS app will soon be updated to work with the new auth. It’s already in testing. The old app will continue to work with the legacy API password support. It will however require a second login when using the webview.

If you are using a proxy server (NGINX etc) in front of Home Assistant to provide authentication, check this blogpost by @DubhAd how to make it work.

I want to say a biiiig thank you to all the people that have been involved in the development and testing of the new authentication system. It’s been a big project and it’s been great to see how we, as a community, have rallied together to tackle it. Especially a big shout out to @awarecan who has done an amazing job on this.


And that’s not it ! @hobbypunk90 has contributed a new integration for Google Hangouts. You can send messages but can also configure intents to handle incoming messages from specific people. Very cool!


You didn’t think we would forget about Lovelace, did you? This release include a new notification drawer thanks to @jeradM. It will collect all persistent notifications and configurator entities and shows it in a new sidebar toggleable from the toolbar.

New Platforms

If you need help…

…don’t hesitate to use our very active forums or join us for a little chat. The release notes have comments enabled but it’s preferred if you use the former communication channels. Thanks.

Reporting Issues

Experiencing issues introduced by this release? Please report them in our issue tracker. Make sure to fill in all fields of the issue template.

Breaking Changes

Beta Fixes

All changes

This is a companion discussion topic for the original entry at https://www.home-assistant.io/blog/2018/08/29/release-77/

If anyone’s wondering why they don’t see the MFA prompt in user settings after upgrading, log out and log back in, then you’ll get the option to enable MFA.

Although it’s possible to configure authentication, we strongly recommend to stick with the default authentication configuration. If you had auth providers configured in a previous Home Assistant release, we recommend to remove the configuration and start using the default.

What exactly does this mean if I am coming from 0.76 with the config below? Do I have to remove auth_providers:?

  name: Home
  latitude: !secret homeassistant_latitude
  longitude: !secret homeassistant_longitude
  elevation: !secret homeassistant_elevation
  unit_system: metric
  time_zone: !secret homeassistant_timezone
  customize: !include customize.yaml
   - type: homeassistant
   - type: legacy_api_password

Thank you in advance for the clarification.

EDIT: I forgot to say THANKS for your hard work. I love the user system and am eager to see whats about to come!

Yes, remove it. You won’t need it anymore. If you have an API password configured, the legacy_api_password provider will be automatically part of the default config.


Can I combine disabling legacy API password with Trusted Networks?

Anyone have an example of just sending a hangouts message? I’m not sure the help page assists much with that part, it only shows how to read messages.

I get that we first send HA a message and then we get a message ID, but do we need to setup a notify component with this? Or is this not part of notify and in this case do we just use “hangouts.send_message”?

The github notes seem to suggest using notify in this case but I’m not sure if this is relevant to what was released…

Thanks for the update!

Maybe I’m missing something, but how does this work and where can I find any documentation about it? I still don’t see any persistent notifications in my lovelace interface

edit Forget about my question, cache clear, relogin and now it works, no configuration change necessary. I see a notification-icon in the topright of the title-bar now.

So after this update I will not be able to use the https urls I setup in Tasker to automatically/quickly kick off scripts or toggle switches and tv anymore?

Is there another easy way I can achieve this?

1 Like

Legacy API password is still an option if you have a legacy API password configured.

Hold on,… if I read the docs correctly, … there’s no way to connect to the websocket without a bearer token, even if you have the legacy bit flipped on?
So I need to go trough the oauth pingpong routine just to talk to my locally hosted hass serving locally hosted apps to get the token?

No, you can still use api_password to connect websocket

1 Like

you need to follow this example:

Get the hangouts ID as described and place it in a list, this is a quick example of the YAML for hangouts.send_message service call

  - text: "text in here"

Here’s the thing, I have no need for that. It was fine the way it was, now I’m forced on a migration path with no added value for my use cases. Not cool.


The Devs haven’t gone out of their ways to make life difficult here. There was a genuine security issue which had to be addressed.


We have features need to know which user belongs to this websocket connection.

1 Like

I currently do not use a password (my HA is not connected to the internet). How do I replicate that with v0.77?

@gpbenton use this

Set a password and add your LAN IP range via the trusted_networks option. You should then be able to connect without a password from any device on your LAN. I’ve not tested this with v0.77 yet, but it should work fine.

Thanks for this (and @Sitrate), but when I attempt to connect I still get prompted to create a user.

ok create a user then continue to login using trusted networks?