Home Assistantはローカルセッションとリモートセッションをどのように認証しますか?

エヴァ・ウォンテクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

Home Assistantは通常、LAN用とリモートアクセス用に別々の認証システムを作成しません。ユーザーはHome Assistantインスタンスに対して認証を行い、アプリケーションはトークンを受け取ります。これらのトークンは、リクエストがローカルURL、Home Assistant Cloud、VPN、リバースプロキシのいずれを経由して届く場合でも、APIセッションやWebSocketセッションの認証に使用されます。

ローカル利用とリモート利用で主に変わるのは、ネットワーク経路です。DNS、TLS、プロキシ、トンネリング、外部公開の可否などが該当します。経路とIDを分けて考えることが重要なのは、Home Assistantユーザーの認証情報やトークンが有効なままでも、壊れたリモートURLがログイン問題のように見える可能性があるためです。

アプリケーションは一度認証し、アクセストークンとリフレッシュトークンを受け取る

Home Assistantのアプリケーション認証フローでは、認証コードに続いてアクセストークンとリフレッシュトークンが発行されます。短期間だけ有効なアクセストークンはAPI呼び出しに使用され、リフレッシュトークンを使うと、アプリケーションはセッションごとにユーザーへログインを求めることなく、新しいアクセストークンを要求できます。

現在の認証APIのドキュメントでは、認証、アクセストークン、リフレッシュトークン、HTTP Bearerトークンのフローについて説明されています。アクセストークンが無効になると、HTTP APIリクエストは401を返すため、クライアントはトークンを更新するか、再認証する必要があります。

これにより、ユーザーの長期的な認証状態と、特定のAPI認証情報の短い有効期間を分離できます。

WebSocketセッションはライブ状態のストリーミング開始前に認証する

フロントエンドや多くのアプリケーションはWebSocket接続を維持します。これにより、変更があるたびにサーバーへポーリングすることなく、Home Assistantから状態やイベントの更新をストリーミングできます。

Home AssistantのWebSocket APIでは、明示的な認証フェーズが定義されています。サーバーがauth_requiredを送信し、クライアントがアクセストークンを返します。その後、auth_okの応答によって接続がコマンドフェーズへ移行します

無効なトークンはセッションを終了させます。認証情報の交換が始まる前に発生するネットワークタイムアウトは、サーバーがトークンを受信した後に返すauth_invalidとは異なる障害です。

リモートアクセスでは、クライアントがHome Assistantへ接続する方法が変わる

Home Assistantはデフォルトではローカル環境で動作します。リモートアクセスは、Home Assistant Cloud、VPN、リバースプロキシ、または適切に保護した直接接続によって提供できます。各方式によってルーティングや公開範囲は変わりますが、接続先は同じHome Assistantインスタンスです。

現在のリモートアクセスガイドでは、Cloud、VPN、リバースプロキシ、ポート転送による経路が区別されています。リバースプロキシでは、Home Assistantが転送されたリクエスト情報を提供できるプロキシを把握する必要があるため、信頼境界も生じます。

そのため、ルーター、DNS、証明書、プロキシを変更すると、ユーザーを作り直さなくてもリモートアクセスが機能しなくなることがあります。

ローカルセッションとリモートセッションではネットワーク上のリスクが異なる

LAN接続は信頼された家庭内ネットワークにとどまる一方、リモート接続はインターネットやオーバーレイネットワークを経由する場合があります。そのため、安全なリモート構成では、同じHome Assistantアカウントシステムを基盤としながら、暗号化、プロキシの強化、VPNポリシー、多要素認証を追加します。

「同じ認証モデル」であることを、「同じネットワーク公開範囲」であると解釈しないでください。直接公開されたポート、管理されたクラウドトンネル、プライベートVPNでは、最終的にHome Assistantのアクセストークンを送信する場合でも、攻撃対象領域は異なります。

ZimaSpaceのリモートアクセスセキュリティガイドでは、認証済みセッションをどの経路で通すべきかを判断するための、より広いネットワーク境界について説明しています。

経路の障害と認証の障害を分けて考える

症状 可能性の高い層 最初に確認する点
リモートホスト名を解決できない DNS / 経路 認証が開始されていない
ログイン前にTLSまたはプロキシエラーが発生する リモート接続経路 ローカルからの直接アクセスをテストする
Home Assistant APIからHTTP 401が返る トークン / 認証 クライアントのトークンを更新するか、再認証する
WebSocketがauth_invalidを返す トークン / 認証 クライアントの認証状態を確認する
ローカルでは動作するが、リモート経路で失敗する DNS / VPN / プロキシ / NAT まずユーザーをリセットしない

シンプルな考え方は、第一にID、第二にセッショントークン、第三にネットワーク経路です。ローカルクライアントとリモートクライアントはまったく異なるネットワーク経路から接続できますが、インスタンスに到達した後は、どちらも有効なHome Assistant認証が必要です。

よくある質問

Home Assistantへのリモートアクセスには、別のパスワードやアカウントが必要ですか?

いいえ。リモートクライアントは通常、同じHome Assistantユーザーシステムで認証されます。リモート方式によって変わるのはクライアントがインスタンスへ到達する方法であり、アカウントを管理するユーザーデータベースではありません。

リモートURLだけが機能しなくなった場合、トークンを削除すべきですか?

最初に行うべきではありません。まず、DNS、VPN、プロキシ、TLS、NATを経由してHome Assistantに到達できることを確認してください。トークンのリセットや再認証は、ネットワーク経路が利用できないというだけでなく、Home Assistant自体が認証を拒否した場合に行います。

テック&AIハブ

もっと読む

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.