ApsaraMQ for MQTT:認証の概要

UserName の例

トークンモード

クライアントの ClientId が GID_Test@@@0001、インスタンス ID が mqtt-xxxxx、AccessKey ID が YYYYY の場合：

Token|YYYYY|mqtt-xxxxx

DeviceCredential モード

クライアントの ClientId が GID_Test@@@0001、インスタンス ID が mqtt-xxxxx、DeviceAccessKeyId が YYYYY の場合：

DeviceCredential|YYYYY|mqtt-xxxxx

トークンベースの認証が適したケース

このモードは、次のような場合に使用します：

• アプリケーションに独自のアカウントシステムがあり、ローカルアカウント (部門、デバイス、または個人ユーザー) を個別の MQTT 権限にマッピングする必要がある場合。

• Alibaba Cloud RAM システムでは、クライアントごとの権限粒度を実現できない場合。署名認証は Alibaba Cloud アカウントレベルで動作しますが、トークンベースの認証は個々のリソースレベルまでアクセスを制御します。

• クライアントがモバイルデバイスや、クラッキングやハイジャックに対して脆弱な他の環境で実行されており、固定された認証情報がセキュリティリスクとなる場合。

• 権限を一定期間後に自動的に失効させる必要がある場合。

トークンの使用方法

バックエンドはアカウントやデバイスを管理し、権限と有効期限を管理して、クライアントにトークンを配信します：

1. 安全で信頼できる管理ノードからトークンを発行します。

2. 各トークンを対応する MQTT クライアントに配信します。

3. クライアントはトークンを使用して ApsaraMQ for MQTT ブローカーに対して認証を行います。

トークンのアップロードと管理方法を含む、トークン認証フローの全体像については、「トークンベースの認証」をご参照ください。

デバイスごとの一意の証明書認証が適したケース

このモードは、次のような場合に使用します：

• クライアントが安全で信頼でき、トークンのローテーションよりも永続的な認証が望ましい場合。

• リアルタイムのトークン更新が非現実的な IoT デプロイメントに似た環境である場合。

• 各クライアント ID に認証情報を直接バインドして、トークンのなりすましを防ぐ必要がある場合。

• 各デバイスが独自の認証情報で独立して認証する必要がある場合。

デバイスアクセス認証情報の使用方法

アプリケーションサーバーは、ApsaraMQ for MQTT ブローカーに対し、MQTT クライアントごとに一意のデバイスアクセス認証情報を要求します。この認証情報には DeviceAccessKeyId が含まれており、クライアントはこれを使用して接続時に UserName と Password を計算します。

認証情報ワークフローと計算ルールの全体像については、「デバイスごとの一意の証明書認証」をご参照ください。

初回接続のための認証情報取得

ApsaraMQ for MQTT インスタンスの購入後、コンソールにはデバイスアクセス資格情報を管理するための UI が提供されていません。RegisterDeviceCredential OpenAPI オペレーションを呼び出して、デバイスアクセス資格情報を登録する必要があります。最初のクライアント接続の接続資格情報を取得するには：

1. コンソールでグループ ID (形式： GID_xxx) を作成します。

2. RegisterDeviceCredential OpenAPI を呼び出し、インスタンス ID (InstanceId) とクライアント ID (ClientId、形式： GroupId@@@DeviceId) を渡します。

3. API から返された DeviceAccessKeyId と DeviceAccessKey secret を取得します。

4. デバイスごとの一意の証明書認証のルールに従って、UserName と Password を計算します。