MQTT におけるTokenベースの認証と OAuth 2.0 の詳細

この記事では、前の記事で説明したもの以外の追加の認証方法について詳しく説明します。

具体的には、Tokenベースの認証と OAuth 2.0 について調査し、その概念を説明し、MQTTでの実装を示します。

Tokenベースの認証

まずTokenベースの認証を見て、ユーザー名とパスワードの認証に比べていくつかの利点を見てみましょう。

Tokenベースの認証とは何ですか?

名前が示すように、Tokenベースの認証では、ユーザー名やパスワードなどの資格情報の代わりにTokenを使用してクライアントを認証します。これはホテルの部屋の電子キーに似ています。受付係に身分証明書を提示すると、部屋にアクセスできる電子キーが渡されます。この電子キーは、滞在期間中Tokenの機能を果たします。部屋に入るたびに受付係に身分証明書を提示する必要はなく、キーを使用するだけで済みます。

Tokenの重要な特徴は、Tokenの有効期間を制限する有効期限を設定できることです。たとえば、ホテルのキーは滞在が終了すると無効になります。ただし、新しいホテルにチェックインし、新しいホテルの部屋の別のTokenを取得する場合があります。したがって、Tokenはユーザー名やパスワードよりもはるかに柔軟で管理が簡単です。ホテルの部屋のドアにある電子キー リーダーは、有効なユーザー名とパスワードを追跡する必要はなく、電子キーの部屋番号と有効期限が有効であることを確認するだけで済みます。

次に、MQTT のTokenベースの認証方法をいくつか見ていきます。

MQTT のTokenベースの認証方式

MQTT では通常、JWT を使用してToken認証を実装します。

JWT (JSON Web Token) は、 MQTT ブローカーでクライアントを認証するためのコンパクトな方法です。クライアントは署名された JWT Tokenをブローカーに送信し、ブローカーはそのTokenを使用してクライアントを認証します。ブローカーはクライアントのユーザー名とパスワードのリストを維持する必要はありません。

JWT Tokenは次の部分で構成されます。

• ヘッダー: Base64 エンコード - 署名の生成に使用されるアルゴリズムを識別します。
• ペイロード: Base64 エンコード - これには、クライアントの認証に使用できるクレームが含まれます。
• Signature : ヘッダーとペイロードを連結した Base64 エンコード。すべてシークレットで署名されます。

次の図は、JWT 構造を示しています。

ヘッダーとペイロードは暗号化されず、base64 バイナリからテキストへのエンコード関数を使用してエンコードされるだけであることに注意してください。一方向関数ではないため、base64デコード関数を使用することで簡単に内容を読み取ることができます。したがって、ヘッダーとペイロードのセクションに機密情報が含まれていないことを確認してください。TLS を使用してクライアント接続を暗号化することもお勧めします。JWT はシークレットを使用して署名されます。

ブローカーは、JWT が有効であることを確認する必要があります。ブローカーはシークレットを知っている必要があるため、クライアントとブローカーの間で共有シークレットを持っているか、ブローカーは JWKS (JSON Web Key Set) を使用できます。JWKS は、秘密鍵が有効であることを検証するために使用される公開鍵のセットです。ブローカーは、キー自体を保持するのではなく、JWKS エンドポイントを参照できます。

JWT Tokenが発行されると、有効期限が切れるまで取り消すことはできません。したがって、安全な場所に保管しておくことが重要です。それが盗まれた場合、攻撃者はそれを使用してブローカーにアクセスする可能性があります。

認証サーバーを使用して JWT Tokenを取得できます。この場合、クライアントは認証サーバーに接続し、認証サーバーがその ID を検証し、JWT Tokenをクライアントに発行します。クライアントはこのTokenを使用してブローカーに接続します。

次の図は、このプロセスを示しています。

以下に、JWT ペイロードの例を示します。

{
  "clientid": "client1",
  "username": "user1",
  "iat": 1516239022,
  "nbf": 1678114325,
  "exp": 1709649185
}

clientidおよびusernameフィールドに加えて、JWT Tokenには、Tokenがいつ有効であるかを示すいくつかの時間フィールドを含めることができます。表示されている時間はすべて Unix 時間であり、1970 年 1 月 1 日からの秒数です。

• 「iat」 : 発行日 - Tokenが発行された日時。Unix 時間で表現されます。
• 「nbf」 : 以前ではありません - Tokenが有効になる日時。Unix 時間で表現されます。
• 「exp」 : Expired - Tokenの有効期限が切れる日時。Unix 時間で表現されます。

nbfフィールドを使用すると、将来の日付まで有効でない JWT を発行できることに注意してください。

OAuth 2.0

前のセクションでは、Tokenの形式を記述する JWT について説明しました。ただし、Tokenの取得方法は決まりません。次に、OAuth 2.0 と JWT を組み合わせて、クライアントがブローカーにアクセスできるようにする方法を見てみましょう。

OAuth 2.0とは何ですか?

OAuth 2.0 は、ユーザーが Google、Facebook、GitHub などの別の認証および認可サーバーからの資格情報を使用してリソースにアクセスできるようにするフレームワークです。これは、ユーザーが複数のパスワードを覚える必要がないため、SSO (シングル サインオン) メカニズムを確立する方法として使用できます。異なるアプリケーションに同じ Google 認証情報を使用できます。

もともと OAuth 2.0 は、サードパーティのアプリケーションにリソースへの特定の範囲のアクセスを許可する承認フレームワークとして設計されました。一般的な例は、Gmail 連絡先への読み取りアクセスです。アプリケーションが連絡先を読み取ることは許可しますが、削除できるようにしたくありません。OAuth 2.0 が解決する問題の 1 つは、Gmail パスワードをアプリケーションに渡すことなく、サードパーティ アプリケーションに連絡先へのアクセスを許可できることです。もちろん、これはあまり安全ではありません。

このプロトコルを認証にも使用すると便利なため、OpenID Connect と呼ばれる OAuth 2.0 の拡張機能が作成されました。これにより、認証に OAuth 2.0 を使用する標準的な方法が作成されました。この記事は認証に関するものであるため、 MQTT クライアントにブローカーへのアクセスを許可するメカニズムとして、OpenID Connect とともに OAuth 2.0 について言及しています。

OAuth 2.0 は MQTT とどのように連携しますか?

OAuth 2.0 と OpenID Connect は、クライアントが適切な JWT を取得し、ブローカーに送信できるメカニズムとして使用できます。上の図に戻って参照すると、最初のステップは、MQTT クライアントが認証サーバーに JWT Tokenを要求することです。ここでは、認証サーバーが OpenID Connect 拡張機能を備えた OAuth 2.0 をサポートしていることを前提としています。OpenID Connect は、認証サーバーから返されるTokenが JWT 形式であることを指定します。クライアントが JWT を受信すると、それをブローカーに送信できます。通常、JWT は CONNECT パケットのパスワード フィールドでブローカーに送信されます。

まとめ

世界をリードする MQTT ブローカーとして、EMQX はJWT 認証を含む複数の認証方法をサポートしています。署名スキームとして HMAC を選択することも、より安全な RSA を選択することも、EMQX の JWKS エンドポイントを直接構成して JWT 認証を有効にすることもできます。

これらの追加の認証アプローチを採用することで、不正アクセスや潜在的なセキュリティ侵害に対するシステム全体の防御を強化できます。テクノロジーが進化し続けるにつれて、最新の認証技術を常に最新の状態に保つことがますます重要になっています。