除了前幾篇文章中提到的認證方法，本文將對其他認證方法進行深入分析和探討。

具體而言，我們將深入瞭解基於 Token 的認證和 OAuth 2.0，闡述它們的原理並展示它們在 MQTT 中的應用。

基於 Token 的認證

讓我們先來認識一下基於 Token 的認證，瞭解它相較於傳統的用户名和密碼認證的一些優勢。

什麼是基於 Token 的認證？

簡單來説，基於 Token 的認證使用 Token 來驗證客户端身份，而不是使用傳統的憑據（如用户名和密碼）。這個過程類似於使用電子門卡進入酒店房間。當您向前台出示身份證時，他們會提供一張電子門卡，讓您能夠打開酒店房門。這張電子門卡在您入住期間起到了 Token 的作用，您無需每次進入房間時都向前台證明身份，只需刷卡即可。

Token 的一個重要特性是其具備有效期限制，可以在到期後失效。例如，您的酒店門卡在退房後將失效。然而，您可能會入住另一家酒店並拿到新房間的門卡。因此，相較於用户名和密碼，Token 更加靈活且易於管理。酒店房門上的電子門卡閲讀器無需記錄有效的用户名和密碼，只需驗證門卡上的房間號碼和有效期即可。

下面我們將深入研究一些適用於 MQTT 的基於 Token 的認證方法。

基於 Token 的 MQTT 認證方法

在 MQTT 中，我們通常使用 JWT 來實現令牌認證。

JWT（JSON Web Token）是一種在 MQTT Broker 中驗證客户端身份的簡潔方式。客户端向 Broker 發送一個簽名的 JWT Token，Broker 根據該 Token 驗證客户端身份。Broker 不需要保存客户端的用户名和密碼。

JWT Token 由以下部分組成：

• 頭部：用 Base64 編碼 - 説明生成簽名所採用的算法。
• 有效載荷：用 Base64 編碼 - 攜帶可以驗證客户端身份的聲明。
• 簽名：將頭部和有效載荷連接後用 Base64 編碼，再用密鑰對其簽名。

下圖顯示了 JWT 的結構：

請注意，頭部和有效載荷並沒有加密，它們只是用 base64 二進制到文本編碼函數進行了編碼。這是一個可逆的函數，所以只要用 base64 解碼函數就能輕鬆地看到內容。因此，不要在頭部和有效載荷部分放置敏感信息。另外，最好使用 TLS 對客户端連接進行加密。JWT 使用 密鑰 進行簽名。

Broker 需要驗證 JWT 是否有效。這可以通過兩種方式實現：一種是在本地持有密鑰，可以是一個和客户端共享的密鑰，也可以是一個與簽發 JWT 使用的私鑰相對的公鑰；另一種是使用 JWKS (JSON Web Key Set)，JWKS 是一組公鑰，可以用來檢驗密鑰是否有效。Broker 可以通過 JWKS 端點來獲取公鑰，而無需自己持有它。

JWT Token 在頒發後，就無法撤銷，只能等到它過期。因此，一定要把它保存在安全的地方，如果落入他人之手，攻擊者就可以利用它來訪問 Broker。

可以通過使用認證服務器來獲取 JWT Token。在這種情況下，客户端先連接到認證服務器，認證服務器核實其身份後，向客户端發放 JWT Token。客户端憑藉這個令牌來連接 Broker。

下圖展示了這個過程：

下面是一個 JWT 有效載荷的例子。

{
 "clientid": "client1",
 "username": "user1",
 "iat": 1516239022,
 "nbf": 1678114325,
 "exp": 1709649185
}

除了 clientid 和 username 字段外，JWT 令牌還可以包含一些時間字段，用於表示令牌的有效期。這些時間字段以 Unix 時間的形式表示，即從 1970 年 1 月 1 日開始計算的秒數。

• “iat”：頒發時間 - Token 頒發的日期和時間。用 Unix 時間表示。
• “nbf”：生效時間 - Token 開始生效的日期和時間。用 Unix 時間表示。
• “exp”：過期時間 - Token 失效的日期和時間。用 Unix 時間表示。

請注意，通過使用 nbf 字段，您可以頒發一個在未來某個日期才生效的 JWT。

OAuth 2.0

在上一節中，我們介紹了 JWT Token 的格式，但是並沒有説明如何獲取 Token。接下來，讓我們看看如何將 OAuth 2.0 和 JWT 結合使用，以使客户能夠訪問 Broker。

什麼是 OAuth 2.0？

OAuth 2.0 是一個框架，它讓用户可以用他們在一個獨立的認證和授權服務器（如 Google、Facebook、GitHub 等）註冊的憑證來訪問其他網站或應用的資源。這樣，用户就不需要為每個網站或應用設置不同的密碼，實現了單點登錄（SSO）的效果。用户可以在不同的應用程序中使用相同的 Google 憑證。

最初，OAuth 2.0 被設計為一種授權框架，用於授予第三方應用程序對特定資源的有限訪問權限。一個常見的例子是對 Gmail 聯繫人的只讀權限。我們可以允許應用程序讀取我們的聯繫人，但不希望它能夠刪除它們。OAuth 2.0 解決的一個問題是，它允許我們讓第三方應用程序訪問我們的聯繫人，而無需將我們的 Gmail 密碼提供給該應用程序，從而提升了安全性。

為了方便使用 OAuth 2.0 協議進行認證，一個名為 OpenID Connect 的 OAuth 2.0 擴展應運而生。該擴展定義了使用 OAuth 2.0 進行認證的標準方法。考慮到認證是本文的主題，我們將 OAuth 2.0 和 OpenID Connect 結合起來使用，共同實現 MQTT 客户端訪問 Broker 的授權機制。

OAuth 2.0 如何與 MQTT 配合？

客户端可以利用 OAuth 2.0 和 OpenID Connect 來獲取合適的 JWT，然後再將 JWT 發送給 Broker。參考上面的圖片，第一步是 MQTT 客户端向認證服務器申請 JWT Token。我們這裏假設認證服務器支持帶有 OpenID Connect 擴展的 OAuth 2.0。OpenID Connect 規定了認證服務器返回的令牌必須是 JWT 格式。客户端拿到 JWT 後，就可以把它發送給 Broker。通常，JWT 放在 CONNECT 報文的密碼字段裏發送給 Broker。

結語

作為全球領先的 MQTT Broker，EMQX 提供了多種認證方式，其中包括 JWT 認證。您可以選擇 HMAC 作為簽名方案，也可以選擇更安全的 RSA，或者直接為 EMQX 配置一個 JWKS 端點來啓用 JWT 認證。

通過使用這些額外的認證方式，您可以增強整個系統對未授權訪問和潛在安全威脅的防護。隨着技術的不斷進步，與最新的認證技術保持同步將變得更加重要。

版權聲明： 本文為 EMQ 原創，轉載請註明出處。
原文鏈接：https://www.emqx.com/zh/blog/a-deep-dive-into-token-based-authentication-and-oauth-2-0-in-mqtt