Hoe verifieert Home Assistant lokale en externe sessies?

Eva Wong

IceWhale author

Eva Wong is de Technisch Schrijver en en vaste knutselaar bij ZimaSpace. Een levenslange geek met een passie voor homelabs en open-source software, zij is gespecialiseerd in het vertalen van complexe technische concepten naar toegankelijke, praktische handleidingen. Eva gelooft dat zelf-hosting leuk moet zijn, niet intimiderend. Met haar tutorials stelt ze de community in staat om hardware-setup te ontrafelen, van het bouwen van hun eerste NAS tot het beheersen van Docker-containers.

How Does Home Assistant Authenticate Local and Remote Sessions?

Home Assistant maakt normaal gesproken niet één authenticatiesysteem voor het LAN en een ander voor externe toegang. De gebruiker autoriseert zich bij de Home Assistant-instantie, applicaties ontvangen tokens en die tokens authenticeren API- of WebSocket-sessies, ongeacht of het verzoek binnenkomt via een lokale URL, Home Assistant Cloud, een VPN of een reverse proxy.

Wat er verandert tussen lokaal en extern gebruik, is voornamelijk het netwerkpad: DNS, TLS, proxying, tunneling en publieke bereikbaarheid. Het is belangrijk om route en identiteit gescheiden te houden, omdat een defecte externe URL eruit kanzien als een inlogprobleem, zelfs wanneer de inloggegevens en tokens van de Home Assistant-gebruiker nog steeds geldig zijn.

Applicaties autoriseren één keer en ontvangen toegangs- en vernieuwingstokens

De authenticatiestroom voor applicaties van Home Assistant genereert een autorisatiecode en vervolgens een toegangstoken plus een vernieuwingstoken. Het kortstondige toegangstoken wordt gebruikt voor API-aanroepen; met het vernieuwingstoken kan de applicatie een nieuw toegangstoken aanvragen zonder de gebruiker voor elke sessie opnieuw te laten inloggen.

De actuele Authentication API documenteert de autorisatie-, toegangs-token-, vernieuwingstoken- en HTTP Bearer-tokenstroom. Wanneer een toegangstoken ongeldig wordt, retourneert een HTTP API-verzoek 401 en moet de client het token vernieuwen of opnieuw autoriseren.

Hiermee wordt de langdurige autorisatie van een gebruiker gescheiden van de korte levensduur van een specifieke API-referentie.

WebSocket-sessies worden geauthenticeerd voordat live statusstreaming begint

De frontend en veel applicaties houden een WebSocket open, zodat Home Assistant status- en gebeurtenisupdates kan streamen zonder de server voor elke wijziging te pollen.

De WebSocket-API van Home Assistant definieert een expliciete authenticatiefase: de server verstuurt auth_required, de client retourneert een toegangstoken en alleen een auth_ok-antwoord brengt de verbinding naar de opdrachtfase.

Een ongeldig token beëindigt die sessie. Een netwerktime-out voordat de authenticatie-uitwisseling begint, is een andere fout dan een auth_invalid-antwoord nadat de server het token heeft ontvangen.

Externe toegang verandert de manier waarop de client Home Assistant bereikt

Standaard is Home Assistant lokaal. Externe toegang kan worden geboden via Home Assistant Cloud, een VPN, een reverse proxy of een bewust beveiligd direct pad. Elke optie verandert de routering en blootstelling, maar de bestemming blijft dezelfde Home Assistant-instantie.

De actuele handleiding voor externe toegang onderscheidt Cloud-, VPN-, reverse-proxy- en port-forwardingroutes. Reverse proxies introduceren ook een vertrouwensgrens, omdat Home Assistant moet weten welke proxy doorgestuurde verzoekinformatie mag aanleveren.

Daarom kan een wijziging aan router, DNS, certificaat of proxy externe toegang verbreken zonder dat gebruikers opnieuw hoeven te worden aangemaakt.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

Lokale en externe sessies kunnen verschillende netwerk risico's hebben

Een LAN-verbinding kan binnen een vertrouwd thuisnetwerk blijven, terwijl een externe verbinding het openbare internet of een overlaynetwerk doorkruist. Een veilig ontwerp voor externe toegang voegt daarom versleuteling, proxybeveiliging, VPN-beleid en meervoudige authenticatie toe rond hetzelfde Home Assistant-accountsysteem.

Interpreteer “hetzelfde authenticatiemodel” niet als “dezelfde netwerkblootstelling”. Een directe openbare poort, een beheerde cloudtunnel en een privé-VPN hebben verschillende aanvalsoppervlakken, ook al dienen ze uiteindelijk alle drie Home Assistant-toegangstokens in.

De handleiding voor veilige externe toegang tot een thuisserver van ZimaSpace biedt de bredere netwerkgrens voor het bepalen welk pad deze geauthenticeerde sessies moet dragen.

Maak onderscheid tussen route- en authenticatiefouten

Symptoom	Waarschijnlijke laag	Eerste onderscheid
Externe hostnaam wordt niet opgelost	DNS / route	Authenticatie is nog niet gestart
TLS- of proxyfout vóór het inloggen	Extern toegangspad	Test directe lokale toegang
HTTP 401 van de Home Assistant-API	Token/authenticatie	Vernieuw het token of autoriseer de client opnieuw
WebSocket retourneert auth_invalid	Token/authenticatie	Controleer de autorisatie van de client
Lokaal werkt, externe route mislukt	DNS/VPN/proxy/NAT	Reset niet meteen de gebruikers

Het juiste mentale model is: eerst identiteit, daarna sessietoken en vervolgens netwerkroute. Lokale en externe clients kunnen via heel verschillende netwerkpaden binnenkomen, maar ze hebben nog steeds een geldige Home Assistant-autorisatie nodig zodra ze de instantie bereiken.

Veelgestelde vragen

Heb ik voor externe Home Assistant-toegang een ander wachtwoord of account nodig?

Nee. Externe clients authenticeren zich normaal gesproken bij hetzelfde gebruikerssysteem van Home Assistant. De externe methode verandert de manier waarop de client de instantie bereikt, niet welke gebruikersdatabase het account beheert.

Moet ik tokens verwijderen wanneer alleen de externe URL niet meer werkt?

Niet als eerste stap. Controleer eerst of DNS, VPN, proxy, TLS of NAT Home Assistant kan bereiken. Reset tokens of autoriseer opnieuw wanneer Home Assistant de authenticatie zelf afwijst, niet alleen omdat het netwerkpad niet beschikbaar is.