ApsaraMQ for MQTT：鑒權概述

鑒權原理

使用雲Message QueueTT 版的用戶端收發訊息時，服務端會根據MQTT用戶端設定的UserName和Password參數來進行鑒權。針對不同的許可權驗證情境，UserName和Password參數具備不同的含義。MQTT用戶端開發應該根據實際情境選擇合適的鑒權模式，按照對應的規範計算正確的UserName和Password。

各鑒權模式下UserName和Password的計算方法和應用情境如下表所示。

鑒權模式分類和比較

按照上文分類，雲Message QueueTT 版目前支援了Token校正及一機一密校正的驗證方式，具體細分和適用情境分析如下所述：

• Token模式（臨時許可權）

  如果業務上需要對每個MQTT用戶端的許可權進行細緻劃分，或者僅需要對用戶端授予臨時的有時間期限的許可權，則可以通過Token模式這種臨時憑證訪問方式實現。通過Token服務，您可以設定單一用戶端訪問的資源內容、權限等級和許可權到期時間。

  關於Token鑒權的流程和注意事項，請參見Token鑒權模式。

  • 適用情境

    業務方擁有自己獨立的本地帳號系統，需要對阿里雲帳號的身份做二次拆分，甚至需要對每個MQTT用戶端分配獨立的個體帳號和許可權範圍。在這種情況下MQTT用戶端的細分使用阿里雲的RAM使用者系統無法滿足。

    因為啟動並執行MQTT用戶端的業務雖然隸屬於同一個阿里雲帳號，但是還需要有本地帳號（業務部門或者單一用戶端）的角色區分。此時簽名模式下劃定的阿里雲帳號維度就無法滿足。特別是在移動端情境，用戶端如果需要考慮破解劫持的風險，固定的許可權模式管理相對比較受限，如果許可權控制需要細化到單一用戶端，且許可權粒度需要細化到單一資源，所有的許可權都是臨時的非固定的，則更加靈活。

  • Token使用

    使用Token模式相對比較複雜，按照上文描述，需要業務方自己擁有帳號（裝置）管理能力，業務方需要自己管理每個裝置的許可權範圍和時效性，由業務方在安全可控的管理節點來申請Token並發放給MQTT用戶端使用。具體的使用方法，請參見Token鑒權模式。

• 一機一密模式

  一機一密給予MQTT用戶端能夠以獨立的使用者名稱、密碼來進行身份識別的能力，協助您解決用戶端在不安全情境下，存在Token冒認的問題。且在一機一密模式下，使用者名稱、密碼與ClientId綁定，您可獨立管理。

  • 適用情境

    業務方對安全性要求較高，且類似於IoT這種不便即時更新Token的情境，一機一密能夠提供持久化驗證能力，不需要頻繁的被動更新訪問憑證。

  • 裝置訪問憑證使用

    一機一密模式下，用戶端應用伺服器為每個用戶端申請獨一無二的裝置訪問憑證，用戶端向雲Message QueueTT 版發起認證請求時，按照約定的規範對訪問憑證中的資訊進行計算並作為串連參數，具體的計算方法，請參見一機一密鑒權模式。