what are the client authentication methods for apsaramq for mqtt - ApsaraMQ for MQTT

このトピックでは、ApsaraMQ for MQTT のクライアント認証の原則と種類について説明し、適切な認証機能を選択する際に役立つ情報を提供します。

認証の原則

ApsaraMQ for MQTT クライアントがメッセージを送受信する際、サーバーは `UserName` および `Password` パラメーターに基づいてクライアントを認証します。これらのパラメーターの意味は、認証シナリオによって異なります。MQTT クライアントを開発する際には、シナリオに合った認証パターンを選択し、そのパターンの仕様に従って `UserName` と `Password` の値を計算する必要があります。

次の表では、各認証パターンの `UserName` と `Password` の計算方法、および各パターンの一般的なシナリオについて説明します。

認証パターン

パターン名

UserName

Password

シナリオ

一時トークン認証

Token

認証メソッド名、`AccessKey ID`、インスタンス ID を縦棒 (|) で区切って構成されます。

たとえば、クライアントの `ClientId` が `GID_Test@@@0001`、インスタンス ID が `mqtt-xxxxx`、`AccessKey ID` が `YYYYY` の場合、署名ベースの認証の `UserName` を「Signature|YYYYY|mqtt-xxxxx」に設定します。

アップロードされたトークン。詳細については、「トークン認証パターン」をご参照ください。

一時的な権限付与。このパターンは、クライアントが安全でないシナリオに適しています。

デバイス固有の認証情報による認証

DeviceCredential

認証パターン名、`DeviceAccessKeyId`、インスタンス ID を縦棒 (|) で区切って構成されます。

例：クライアントの `ClientId` が `GID_Test@@@0001`、インスタンス ID が `mqtt-xxxxx`、`DeviceAccessKeyId` が `YYYYY` の場合、デバイス固有の認証情報パターンの `UserName` を「DeviceCredential|YYYYY|mqtt-xxxxx」に設定します。

`DeviceAccessKeyId` は、ApsaraMQ for MQTT サーバーがデバイスに発行するアクセス認証情報内のパラメーターです。詳細については、「デバイス固有の認証情報パターン」をご参照ください。

`ClientId` の Base64 エンコードされた署名です。署名は、`DeviceAccessKey Secret` をキーとして使用して計算されます。詳細については、「デバイス固有の認証情報パターン」をご参照ください。

永続的な権限付与。このパターンは、クライアントが安全で信頼でき、かつサーバーが発行済みのデバイスアクセス認証情報をいつでも更新または無効化できるシナリオに適しています。

重要

`AccessKey ID` と `AccessKey Secret` は機密情報です。これらは、クライアントの `UserName` と `Password` を計算するために使用されます。情報漏洩を防ぐため、`AccessKey ID` と `AccessKey Secret` をクライアントコードにハードコーディングしないでください。代わりに、この情報をバックエンドアプリケーションに保存してください。バックエンドアプリケーションで `UserName` と `Password` を計算し、クライアントに送信することができます。

認証パターンの分類と比較

ApsaraMQ for MQTT は、トークン検証、およびデバイス固有の認証情報検証という 3 つの認証パターンをサポートしています。以降のセクションでは、各パターンの詳細と一般的なシナリオについて説明します。

トークンパターン (一時権限)
トークンパターンを使用すると、各 MQTT クライアントに詳細な権限を定義したり、一時的で時間制限のある権限を付与したりできます。このパターンでは、アクセスに一時的な認証情報を使用します。トークンサービスを使用すると、単一のクライアントに対して、アクセス可能なリソース、権限レベル、および生存時間 (TTL) を設定できます。
トークン認証フローと重要な注意事項の詳細については、「トークン認証パターン」をご参照ください。
- シナリオ
  このパターンは、ビジネスが独自のローカルアカウントシステムを持ち、Alibaba Cloud アカウント内で ID をさらにセグメント化する必要がある場合に使用します。各 MQTT クライアントに独立したアカウントと権限範囲を割り当てる必要がある場合もあります。この場合、Alibaba Cloud `Resource Access Management (RAM)` ユーザーシステムだけでは MQTT クライアントを管理するのに十分ではありません。
  MQTT クライアントは同じ Alibaba Cloud アカウントで実行されますが、事業部門や個々のクライアントなどのローカルロールによって区別される必要があります。この場合、署名パターンのアカウントレベルの権限では不十分です。クラッキングやハイジャックのリスクを考慮する必要があるモバイルアプリケーションの場合、固定の権限モデルでは制約が大きすぎます。アクセスの制御を単一のクライアントとリソースにまで詳細化し、すべての権限を一時的なものにする必要がある場合は、より柔軟なアプローチが必要です。
- トークンの使用
  トークンパターンの使用は比較的複雑です。このパターンでは、独自のアカウントまたはデバイス管理システムが必要です。各デバイスの権限と有効期間を管理する責任があります。安全なコントロールプレーンノードからトークンをリクエストし、MQTT クライアントに配布する必要があります。トークンの使用方法の詳細については、「トークン認証パターン」をご参照ください。
デバイス固有の認証情報パターン
デバイス固有の認証情報パターンを使用すると、各 MQTT クライアントが本人確認のためにユニークなユーザー名とパスワードを使用できます。これにより、安全でないクライアントシナリオでのトークンの偽装を防ぐことができます。このパターンでは、ユーザー名とパスワードは `ClientId` にバインドされ、独立して管理できます。
- シナリオ
  このパターンは、ビジネスのセキュリティ要件が高い場合に使用します。また、モノのインターネット (IoT) のように、リアルタイムでトークンを更新するのが不便なシナリオにも適しています。デバイス固有の認証情報パターンは、永続的な認証を提供し、アクセス認証情報を頻繁に更新する必要がありません。
- デバイスアクセス認証情報の使用
  デバイス固有の認証情報パターンでは、クライアントのアプリケーションサーバーが各クライアントにユニークなデバイスアクセス認証情報をリクエストします。クライアントが ApsaraMQ for MQTT に認証リクエストを送信する際、特定の規則に従って、アクセス認証情報内の情報に基づいて接続パラメーターを計算します。計算方法の詳細については、「デバイス固有の認証情報パターン」をご参照ください。