Hur autentiserar Home Assistant lokala och fjärranslutna sessioner?
Home Assistant skapar normalt inte ett autentiseringssystem för det lokala nätverket och ett annat för fjärråtkomst. Användaren autentiserar mot Home Assistant-instansen, applikationerna tar emot token och dessa token autentiserar API- eller WebSocket-sessioner oavsett om begäran kommer via en lokal URL, Home Assistant Cloud, ett VPN eller en omvänd proxy.
Det som främst skiljer lokal och fjärranvändning åt är nätverkssökvägen: DNS, TLS, proxyhantering, tunnling och åtkomst från internet. Det är viktigt att hålla rutt och identitet åtskilda, eftersom en trasig fjärr-URL kan se ut som ett inloggningsproblem även när Home Assistant-användarens inloggningsuppgifter och token fortfarande är giltiga.
Applikationer autentiserar en gång och tar emot åtkomst- och uppdateringstoken
Home Assistants autentiseringsflöde för applikationer genererar en auktoriseringskod och därefter en åtkomsttoken samt en uppdateringstoken. Den kortlivade åtkomsttoken används för API-anrop, medan uppdateringstoken gör det möjligt för applikationen att begära en ny åtkomsttoken utan att be användaren logga in inför varje session.
Det aktuella autentiserings-API:t dokumenterar flödet för auktorisering, åtkomsttoken, uppdateringstoken och HTTP Bearer-token. När en åtkomsttoken blir ogiltig returnerar en HTTP API-begäran statuskoden 401, och klienten bör uppdatera token eller autentisera på nytt.
Detta skiljer en användares långsiktiga auktorisering från den korta giltighetstiden hos en specifik API-uppgift.
WebSocket-sessioner autentiseras innan direktuppdatering av tillstånd börjar
Frontendgränssnittet och många applikationer håller en WebSocket-anslutning öppen så att Home Assistant kan skicka tillstånds- och händelseuppdateringar utan att servern behöver tillfrågas vid varje ändring.
Home Assistants WebSocket-API definierar en uttrycklig autentiseringsfas: servern skickar auth_required, klienten returnerar en åtkomsttoken och först ett svar med auth_ok för anslutningen vidare till kommandofasen.
En ogiltig token avslutar sessionen. En nätverkstidsgräns innan autentiseringsutbytet börjar är ett annat fel än ett svar med auth_invalid efter att servern har tagit emot token.
Fjärråtkomst ändrar hur klienten når Home Assistant
Som standard är Home Assistant lokalt tillgängligt. Fjärråtkomst kan tillhandahållas via Home Assistant Cloud, ett VPN, en omvänd proxy eller en medvetet säkrad direktanslutning. Varje alternativ ändrar routningen och exponeringen, men målet är fortfarande samma Home Assistant-instans.
Den aktuella guiden för fjärråtkomst skiljer mellan anslutningar via molntjänst, VPN, omvänd proxy och portvidarebefordran. Omvända proxyservrar skapar dessutom en förtroendegräns, eftersom Home Assistant måste veta vilken proxy som tillåts tillhandahålla vidarebefordrad information om begäran.
Därför kan en ändring av router, DNS, certifikat eller proxy bryta fjärråtkomsten utan att användare behöver skapas på nytt.
Lokala och fjärranslutna sessioner kan ha olika nätverksrisker
En LAN-anslutning kan förbli inom ett betrott hemnätverk, medan en fjärranslutning passerar via det publika internet eller ett överlagrat nätverk. En säker fjärrlösning lägger därför till kryptering, härdning av proxyer, VPN-policy och flerfaktorsautentisering runt samma Home Assistant-kontosystem.
Tolka inte ”samma autentiseringsmodell” som ”samma nätverksexponering”. En direkt publik port, en hanterad molntunnel och ett privat VPN har olika attackytor, även om alla tre i slutändan skickar Home Assistant-åtkomsttoken.
ZimaSpaces säkerhetsguide för fjärråtkomst beskriver den övergripande nätverksgränsen som hjälper dig avgöra vilken väg som bör bära dessa autentiserade sessioner.
Skilj routningsfel från autentiseringsfel
| Symtom | Trolig nivå | Första åtgärd |
|---|---|---|
| Det går inte att slå upp fjärrvärdnamnet | DNS / rutt | Autentiseringen har inte startat |
| TLS- eller proxyfel före inloggning | Fjärranslutningens ingång | Testa direkt lokal åtkomst |
| HTTP 401 från Home Assistant-API:t | Token/autentisering | Uppdatera token eller autentisera klienten på nytt |
| WebSocket returnerar auth_invalid | Token/autentisering | Validera klientens auktorisering |
| Lokalt fungerar det, men fjärranslutningen misslyckas | DNS/VPN/proxy/NAT | Återställ inte användare som första åtgärd |
Den tydliga mentala modellen är identitet först, sessionstoken därefter och nätverksrutt sist. Lokala och fjärranslutna klienter kan komma in via helt olika nätverkssökvägar, men de behöver fortfarande en giltig Home Assistant-auktorisering när de väl når instansen.
Vanliga frågor
Kräver fjärråtkomst till Home Assistant ett annat lösenord eller konto?
Nej. Fjärrklienter autentiserar normalt mot samma användarsystem i Home Assistant. Fjärrmetoden ändrar hur klienten når instansen, inte vilken användardatabas kontot tillhör.
Bör jag radera token när det bara är fjärr-URL:en som slutar fungera?
Inte som första åtgärd. Kontrollera först att DNS, VPN, proxy, TLS eller NAT faktiskt når Home Assistant. Återställ eller autentisera token på nytt när Home Assistant själv avvisar autentiseringen, inte enbart för att nätverkssökvägen är otillgänglig.
Rekommenderade produkter
Teknik- och AI-hubb
Mer att läsa
Tillstånd under körning kontra beständigt tillstånd i Home Assistant: Vad måste överleva en omstart?
Home Assistant sparar inte varje aktuellt värde permanent; konfiguration, register, utvalda återställda tillstånd, historik och distributionsdata har olika roller vid omstart.
Varför kan historikfrågor i Home Assistant bli långsammare när Recorder-data växer?
Ökad loggstorlek kan höja kostnaden för historikfrågor när det begärda intervallet omfattar fler rader, cachemissar ökar eller arbete med lagring och index blir långsammare.
Varför återskapar Home Assistant ett annat tillstånd efter en omstart av containern?
Omstart av containern är inte detsamma som att tillstånd går förlorat: Home Assistant återskapar körtidstillståndet från beständig konfiguration, integrationer, register och externa källor.
