歡迎閱讀 MQTT 5.0 報文系列 的最後一篇文章。在上一篇中，我們已經介紹了 MQTT 5.0 的 DISCONNECT 報文。現在，我們將介紹 MQTT 中的最後一個控制報文：AUTH。
MQTT 5.0 引入了增強認證特性，它使 MQTT 除了簡單密碼認證和 Token 認證以外，還能夠支持質詢/響應風格的認證。爲了實現這一點，它在原先 CONNECT 和 CONNACK 報文的基礎上，又引入了 AUTH 報文來實現任意多次的認證數據交換，以支持各種不同類型的認證機制，例如 SCRAM、Kerberos 認證等等。
一次典型的增強認證的報文交互流程如下：
關於增強認證的詳細介紹，可以參考 《MQTT 5.0 中的安全認證機制：增強認證介紹》。本文我們將主要介紹在增強認證中至關重要的 AUTH 報文。
AUTH 報文示例
由於目前沒有支持增強認證特性的 MQTT 客戶端，所以我們直接以圖示的方式來展示一個典型的 AUTH 報文，裏面包含了 AUTH 報文中最重要的兩個屬性，即認證方法（Authentication Method）和認證數據（Authentication Data）：
接下來，我們將依次介紹這些字段的含義。
AUTH 報文結構
固定報頭
固定報頭中首字節高 4 位的報文類型字段的值爲 15（0b1111），低 4 位全部爲 0，表示這是一個 AUTH 報文。
可變報頭
AUTH 報文的可變報頭按順序包含以下字段：
- 原因碼（Reason Code）：一個單字節的無符號整數，AUTH 報文只有 3 個可用的原因碼，它們都用於控制認證流程，分別是：
| Value | Reason Code Name | Sent By | Description |
|---|---|---|---|
| 0x00 | Success | 服務端 | 認證成功，只會在重新認證成功時由服務端返回，如果是連接時的首次認證成功，服務端將返回 CONNACK 報文。 |
| 0x18 | Continue authentication | 客戶端、服務端 | 指示對端繼續下一步認證。 |
| 0x19 | Re-authenticate | 客戶端 | 客戶端可以在一個連接內隨時發起重新認證，重新認證期間消息可以正常收發。 |
- 屬性（Properties）：下表列出了 AUTH 報文的所有可用屬性。
| Identifier | Property Name | Type | Description |
|---|---|---|---|
| 0x15 | Authentication Method | UTF-8 編碼的字符串 | 認證方法是一個 UTF-8 編碼的字符串，用於指示本次認證所使用的認證機制，它可以是 SCRAM-SHA-1 這類已註冊的 SASL 機制，也可以是客戶端和服務端協商好的任意名稱。一旦在 CONNECT 報文中確定了認證方法，那麼後續的 AUTH、CONNACK 報文都不可以對其進行變更。 |
| 0x16 | Authentication Data | 二進制數據（由最前面的雙字節整數來指示後續的字節數量） | 用於承載認證需要的數據，數據的格式與內容由認證方法決定。 |
| 0x1F | Reason String | UTF-8 編碼的字符串 | 表示返回此響應的原因，它可以是任意的內容，由發送端決定，但最好是人類易讀的。 |
| 0x26 | User Property | UTF-8 字符串對 | 用於在報文中附加用戶自定義的信息。一個報文中可以包含多個用戶屬性，即使它們的名字相同。 |
有效載荷
AUTH 報文不包含有效載荷。
總結
AUTH 報文是實現任意次數認證數據交換的核心，也使得 MQTT 的增強認證能夠支持各種不同的認證機制。像 SCRAM 認證、Kerberos 認證，都能提供比簡單密碼認證更高的安全保障，目前 EMQX 已經支持了其中的 SCRAM 認證。
現在，我們已經介紹了 MQTT 中的所有控制報文類型，MQTT 作爲一個二進制協議，允許我們傳輸任意格式的應用消息。但相應地，我們也需要嚴格地按照協議規範來編碼和解析 MQTT 報文，否則就可能造成協議錯誤。
當我們遇到問題時，可以優先查看對端返回的響應報文中的 Reason Code，它可以指明大部分的錯誤原因。而當一些嵌入式設備上的端側 SDK 實現不佳無法直接給出 Reason Code 時，我們可以嘗試網絡抓包來查看報文中的 Reason Code，此時我們可以藉助 Wireshark，避免自己人工解析。
EMQX 作爲被廣泛使用的可擴展、高可用的 MQTT Broker，也提供了一個方便用戶排查問題的 日誌追蹤 功能，它可以記錄下指定 Client ID、主題、IP 的所有相關日誌，包括報文收發日誌。所以我們可以用它來分析客戶端的行爲是否異常，例如是否正確地響應了 PUBACK，是否重複發送了連接報文等等。