雲Message QueueTT 版通過Token鑒權模式向MQTT用戶端提供臨時存取權限。您可通過MQTT Token服務來給本地帳號系統管理的使用者頒發臨時的訪問憑證，並限制存取權限，以實現對單一用戶端、單一資源的細粒度許可權控制。本文介紹使用流程以及相關注意事項。
名詞解釋
術語 | 說明 |
Token（臨時憑證） | 雲Message QueueTT 版頒發的臨時訪問憑證，代表單一用戶端對特定資源的存取權限。 |
應用伺服器 | 您管理本地帳號的伺服器，用來替用戶端申請和管理Token服務的應用。 |
MQTT伺服器 | 雲Message QueueTT 版許可權認證和訊息收發伺服器，用來處理應用伺服器發起的Token相關的請求以及訊息收發業務。 |
使用流程
Token鑒權模式相比簽名模式更加複雜，您需要按照下圖所示的流程，部署您的應用伺服器。而且在初始化時，MQTT用戶端需要具備與您的應用伺服器互動（擷取和更新Token）的能力。
圖 1. 鑒權流程
具體流程如下：
用戶端啟動時，需要先串連應用伺服器驗證身份。
用戶端嚮應用伺服器申請所需的所有Topic的許可權。
應用伺服器驗證用戶端是否有必要操作所需的Topic許可權，如果驗證通過則向雲Message QueueTT 版伺服器申請對應資源的Token。
雲Message QueueTT 版伺服器驗證申請Token的請求，判斷合法之後返回對應的Token。
應用伺服器將返回的Token持久化到本地，對每個用戶端需要的許可權以及Token資訊進行映射。緩衝Token有以下優勢：
用戶端重新啟動後再訪問時，只要許可權範圍沒有變化，應用伺服器可以返回緩衝的Token，避免重複申請。
用戶端重新申請Token時，如果MQTT伺服器異常，應用伺服器可以嘗試返回用戶端之前申請的Token以實現本地容災。
MQTT用戶端按照規範將Token作為參數設定，串連MQTT伺服器，服務端驗證通過後用戶端即可正常收發訊息。
用戶端正常收發訊息。如果服務端判斷Token失效，即會觸發鑒權失敗，中斷連線，用戶端應該重新發起申請Token的請求。
用戶端行為約束
用戶端從應用伺服器拿到的資訊除了Token本身，還需要擷取Token的失效時間，以便本地計算何時提前重新整理Token。
必須按照約定形式將Token作為串連參數設定到Password中，每次串連時上傳。
用戶端應該知曉自己使用的Token的時效性，確保不要使用到期的Token，否則服務端會中斷連線。
用戶端可以監聽服務端下推的Token失效的通知訊息，但服務端不保證通知一定觸發，該通知僅供排查問題使用。
用戶端應該對應用伺服器返回的Token做持久化，避免每次重連都申請一樣的Token，防止大批量用戶端同時串連壓垮應用伺服器。
用戶端更新Token可以選擇關閉舊的用戶端串連，然後重新使用新的Token來串連，也可以選擇使用MQTT提供的系統Topic動態上傳更新Token。如果選擇動態更新Token，需要保證本地的配置也同步更新，以供下次串連初始化使用。
應用伺服器行為約束
應用伺服器必須驗證自己的用戶端是否合法，避免用戶端冒用身份申請Token。
應用伺服器應該對Token和用戶端的關係、已指派的Token、對應許可權內容以及生效時間進行管理，避免同一個用戶端重複調用。
應用伺服器將Token返回給用戶端的同時，也應該告知用戶端當前Token的操作許可權以及到期時間，以便用戶端提前重新整理Token。
應用伺服器需要做本地容災，避免因MQTT伺服器訪問短暫不可用而導致業務阻塞的情況。
相關API
Token鑒權流程通過相關的API來完成。
應用伺服器負責Token的申請和吊銷管理，和雲Message QueueTT 版伺服器之間通過HTTPS的OpenAPI進行互動。
每個介面都要求通過AccessKey和請求籤名來做身分識別驗證。目前開放申請Token、吊銷Token以及校正Token介面。詳細資料，請參見Token應用伺服器介面。
雲Message QueueTT 版用戶端則包括動態更新Token、監聽Token失效資訊，以及監聽Token非法資訊三個介面。詳細資料，請參見Token用戶端介面。