鑒權(quán)概述
本文主要介紹云消息隊列 MQTT 版客戶端鑒權(quán)的原理和分類，以便您使用相應(yīng)的鑒權(quán)功能。
鑒權(quán)原理
使用云消息隊列 MQTT 版的客戶端收發(fā)消息時，服務(wù)端會根據(jù)MQTT客戶端設(shè)置的UserName和Password參數(shù)來進行鑒權(quán)。針對不同的權(quán)限驗證場景，UserName和Password參數(shù)具備不同的含義。MQTT客戶端開發(fā)應(yīng)該根據(jù)實際場景選擇合適的鑒權(quán)模式，按照對應(yīng)的規(guī)范計算正確的UserName和Password。
各鑒權(quán)模式下UserName和Password的計算方法和應(yīng)用場景如下表所示。
權(quán)限驗證模式 | 模式名稱 | UserName | Password | 適用場景 |
簽名驗證 | Signature | 由鑒權(quán)模式名稱、AccessKey ID、Instance ID三部分組成，以豎線（|）分隔。 舉例：一個客戶端的ClientId是GID_Test@@@0001，使用了實例ID是mqtt-xxxxx，使用了AccessKey ID是YYYYY，則簽名模式的UserName應(yīng)該設(shè)置成“Signature|YYYYY|mqtt-xxxxx”。 | 以AccessKey Secret為密鑰，對Client ID簽名的Base64編碼結(jié)果，具體設(shè)置方法，請參見簽名鑒權(quán)模式。 | 永久授權(quán)，適用于客戶端安全受信任的場景。 |
臨時Token權(quán)限驗證 | Token | 上傳的Token內(nèi)容，具體設(shè)置方法，請參見Token鑒權(quán)概述。 | 臨時授權(quán)，適用于客戶端不安全的場景。 | |
一機一密驗證 | DeviceCredential | 由鑒權(quán)模式名稱、DeviceAccessKeyId、Instance ID三部分組成，以豎線（|）分隔。 舉例：一個客戶端的ClientId是GID_Test@@@0001，使用了實例ID是mqtt-xxxxx，DeviceAccessKeyId是YYYYY，則一機一密模式的UserName應(yīng)該設(shè)置成“DeviceCredential|YYYYY|mqtt-xxxxx”。 DeviceAccessKeyId為MQTT服務(wù)端為設(shè)備頒發(fā)的訪問憑證中的參數(shù)，詳細信息，請參見一機一密概述。 | 以DeviceAccessKey Secret為密鑰，對Client ID簽名的Base64編碼結(jié)果，具體設(shè)置方法，請參見一機一密概述。 | 永久授權(quán)，適用于客戶端安全受信的場景，并且服務(wù)端可以隨時更新或禁用已發(fā)放的設(shè)備訪問憑證。 |
AccessKey ID和AccessKey Secret為敏感信息，且和客戶端的UserName和Password計算結(jié)果強相關(guān)。為了避免客戶端信息泄露，請勿將AccessKey ID和AccessKey Secret信息直接寫入客戶端代碼中，建議將該信息寫入到后端應(yīng)用中，由后端應(yīng)用計算UserName和Password后下發(fā)給客戶端。
鑒權(quán)模式分類和比較
按照上文分類，云消息隊列 MQTT 版目前支持了簽名校驗、Token校驗及一機一密校驗三種驗證方式，這三種方式覆蓋了固定權(quán)限以及非固定的臨時權(quán)限的場景，具體細分和適用場景分析如下所述：
簽名模式（固定權(quán)限）
簽名模式是云消息隊列 MQTT 版推薦使用的默認鑒權(quán)模式，該模式下約定同一類型的MQTT客戶端擁有同樣的權(quán)限范圍，這些客戶端使用相同的賬號來做簽名計算，服務(wù)端通過簽名比對即可識別出客戶端對應(yīng)的賬號以及擁有的權(quán)限范圍。該模式理解成本低，使用簡單。
適用場景
使用的MQTT客戶端邏輯上可以劃分為同一類，邏輯意義上都屬于一個賬號，具備同樣的權(quán)限范圍，且每個MQTT客戶端運行的環(huán)境相對可控，不需要考慮設(shè)備被破解盜用等惡意攻擊的場景。
因為在業(yè)務(wù)層面上，對一類的MQTT客戶端都劃分到一個賬號（可以是主賬號或者子賬號），所以客戶端只需要根據(jù)對應(yīng)的賬號AccessKey Secret計算簽名即可，權(quán)限范圍由賬號的管理員在產(chǎn)品的控制臺進行統(tǒng)一管理。
簽名計算
為防止簽名被盜用，需要取每個客戶端獨立的信息進行簽名計算，云消息隊列 MQTT 版約定每個客戶端使用自己獨一無二的ClientId來作為待簽名內(nèi)容。關(guān)于該類型簽名的具體計算方法，請參見簽名鑒權(quán)模式。
Token模式（臨時權(quán)限）
如果業(yè)務(wù)上需要對每個MQTT客戶端的權(quán)限進行細致劃分，或者僅需要對客戶端授予臨時的有時間期限的權(quán)限，則可以通過Token模式這種臨時憑證訪問方式實現(xiàn)。通過Token服務(wù)，您可以設(shè)置單一客戶端訪問的資源內(nèi)容、權(quán)限級別和權(quán)限過期時間。
關(guān)于Token鑒權(quán)的流程和注意事項，請參見Token鑒權(quán)概述。
適用場景
業(yè)務(wù)方擁有自己獨立的本地賬號系統(tǒng)，需要對阿里云賬號的身份做二次拆分，甚至需要對每個MQTT客戶端分配獨立的個體賬號和權(quán)限范圍。在這種情況下MQTT客戶端的細分使用阿里云的RAM賬號系統(tǒng)無法滿足。
因為運行的MQTT客戶端的業(yè)務(wù)雖然隸屬于同一個阿里云賬號，但是還需要有本地賬號（業(yè)務(wù)部門或者單一客戶端）的角色區(qū)分。此時簽名模式下劃定的阿里云賬號維度就無法滿足。特別是在移動端場景，客戶端如果需要考慮破解劫持的風(fēng)險，固定的權(quán)限模式管理相對比較受限，如果權(quán)限控制需要細化到單一客戶端，且權(quán)限粒度需要細化到單一資源，所有的權(quán)限都是臨時的非固定的，則更加靈活。
Token使用
使用Token模式相對比較復(fù)雜，按照上文描述，需要業(yè)務(wù)方自己擁有賬號（設(shè)備）管理能力，業(yè)務(wù)方需要自己管理每個設(shè)備的權(quán)限范圍和時效性，由業(yè)務(wù)方在安全可控的管理節(jié)點來申請Token并發(fā)放給MQTT客戶端使用。具體的使用方法，請參見Token鑒權(quán)概述。
一機一密模式
一機一密給予MQTT客戶端能夠以獨立的用戶名、密碼來進行身份識別的能力，幫助您解決客戶端在不安全場景下，存在Token冒認的問題。且在一機一密模式下，用戶名、密碼與ClientId綁定，您可獨立管理。
適用場景
業(yè)務(wù)方對安全性要求較高，且類似于IoT這種不便實時更新Token的場景，一機一密能夠提供持久化驗證能力，不需要頻繁的被動更新訪問憑證。
設(shè)備訪問憑證使用
一機一密模式下，客戶端應(yīng)用服務(wù)器為每個客戶端申請獨一無二的設(shè)備訪問憑證，客戶端向云消息隊列 MQTT 版發(fā)起認證請求時，按照約定的規(guī)范對訪問憑證中的信息進行計算并作為連接參數(shù)，具體的計算方法，請參見一機一密概述。