除了前幾篇文章中提到的認(rèn)證方法,，本文將對(duì)其他認(rèn)證方法進(jìn)行深入分析和探討。

具體而言,，我們將深入了解基于 Token 的認(rèn)證和 OAuth 2.0，闡述它們的原理并展示它們?cè)?MQTT 中的應(yīng)用,。

基于 Token 的認(rèn)證

讓我們先來(lái)認(rèn)識(shí)一下基于 Token 的認(rèn)證，了解它相較于傳統(tǒng)的用戶名和密碼認(rèn)證的一些優(yōu)勢(shì),。

什么是基于 Token 的認(rèn)證,？

簡(jiǎn)單來(lái)說(shuō)，基于 Token 的認(rèn)證使用 Token 來(lái)驗(yàn)證客戶端身份,，而不是使用傳統(tǒng)的憑據(jù)（如用戶名和密碼）。這個(gè)過(guò)程類(lèi)似于使用電子門(mén)卡進(jìn)入酒店房間,。當(dāng)您向前臺(tái)出示身份證時(shí)，他們會(huì)提供一張電子門(mén)卡,，讓您能夠打開(kāi)酒店房門(mén),。這張電子門(mén)卡在您入住期間起到了 Token 的作用,，您無(wú)需每次進(jìn)入房間時(shí)都向前臺(tái)證明身份，只需刷卡即可,。

Token 的一個(gè)重要特性是其具備有效期限制，可以在到期后失效,。例如，您的酒店門(mén)卡在退房后將失效,。然而,，您可能會(huì)入住另一家酒店并拿到新房間的門(mén)卡。因此,，相較于用戶名和密碼，Token 更加靈活且易于管理,。酒店房門(mén)上的電子門(mén)卡閱讀器無(wú)需記錄有效的用戶名和密碼，只需驗(yàn)證門(mén)卡上的房間號(hào)碼和有效期即可,。

下面我們將深入研究一些適用于 MQTT 的基于 Token 的認(rèn)證方法,。

基于 Token 的 MQTT 認(rèn)證方法

在 MQTT 中，我們通常使用 JWT 來(lái)實(shí)現(xiàn)令牌認(rèn)證,。

JWT（JSON Web Token）是一種在 MQTT Broker 中驗(yàn)證客戶端身份的簡(jiǎn)潔方式,?？蛻舳讼?Broker 發(fā)送一個(gè)簽名的 JWT Token,，Broker 根據(jù)該 Token 驗(yàn)證客戶端身份。Broker 不需要保存客戶端的用戶名和密碼,。

JWT Token 由以下部分組成：

• 頭部：用 Base64 編碼 - 說(shuō)明生成簽名所采用的算法。

• 有效載荷：用 Base64 編碼 - 攜帶可以驗(yàn)證客戶端身份的聲明,。

• 簽名：將頭部和有效載荷連接后用 Base64 編碼，再用密鑰對(duì)其簽名,。

下圖顯示了 JWT 的結(jié)構(gòu)：

 請(qǐng)注意，頭部和有效載荷并沒(méi)有加密,，它們只是用 base64 二進(jìn)制到文本編碼函數(shù)進(jìn)行了編碼。這是一個(gè)可逆的函數(shù),，所以只要用 base64 解碼函數(shù)就能輕松地看到內(nèi)容。因此,，不要在頭部和有效載荷部分放置敏感信息。另外,，最好使用 TLS 對(duì)客戶端連接進(jìn)行加密,。JWT 使用 密鑰 進(jìn)行簽名。

Broker 需要驗(yàn)證 JWT 是否有效,。這可以通過(guò)兩種方式實(shí)現(xiàn)：一種是在本地持有密鑰，可以是一個(gè)和客戶端共享的密鑰,，也可以是一個(gè)與簽發(fā) JWT 使用的私鑰相對(duì)的公鑰,；另一種是使用 JWKS (JSON Web Key Set)，JWKS 是一組公鑰,，可以用來(lái)檢驗(yàn)密鑰是否有效,。Broker 可以通過(guò) JWKS 端點(diǎn)來(lái)獲取公鑰，而無(wú)需自己持有它,。

JWT Token 在頒發(fā)后,，就無(wú)法撤銷(xiāo),，只能等到它過(guò)期,。因此,，一定要把它保存在安全的地方，如果落入他人之手,，攻擊者就可以利用它來(lái)訪問(wèn) Broker。

可以通過(guò)使用認(rèn)證服務(wù)器來(lái)獲取 JWT Token。在這種情況下,，客戶端先連接到認(rèn)證服務(wù)器，認(rèn)證服務(wù)器核實(shí)其身份后,，向客戶端發(fā)放 JWT Token?？蛻舳藨{借這個(gè)令牌來(lái)連接 Broker,。

下圖展示了這個(gè)過(guò)程：

下面是一個(gè) JWT 有效載荷的例子,。

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

除了 clientid 和 username 字段外,，JWT 令牌還可以包含一些時(shí)間字段，用于表示令牌的有效期,。這些時(shí)間字段以 Unix 時(shí)間的形式表示，即從 1970 年 1 月 1 日開(kāi)始計(jì)算的秒數(shù),。

• “iat”：頒發(fā)時(shí)間 - Token 頒發(fā)的日期和時(shí)間。用 Unix 時(shí)間表示,。

• “nbf”：生效時(shí)間 - Token 開(kāi)始生效的日期和時(shí)間。用 Unix 時(shí)間表示,。

• “exp”：過(guò)期時(shí)間 - Token 失效的日期和時(shí)間。用 Unix 時(shí)間表示,。

請(qǐng)注意，通過(guò)使用 nbf 字段,，您可以頒發(fā)一個(gè)在未來(lái)某個(gè)日期才生效的 JWT。

OAuth 2.0

在上一節(jié)中，我們介紹了 JWT Token 的格式,，但是并沒(méi)有說(shuō)明如何獲取 Token。接下來(lái),，讓我們看看如何將 OAuth 2.0 和 JWT 結(jié)合使用，以使客戶能夠訪問(wèn) Broker,。

什么是 OAuth 2.0,？

OAuth 2.0 是一個(gè)框架,，它讓用戶可以用他們?cè)谝粋€(gè)獨(dú)立的認(rèn)證和授權(quán)服務(wù)器（如 Google,、Facebook、GitHub 等）注冊(cè)的憑證來(lái)訪問(wèn)其他網(wǎng)站或應(yīng)用的資源,。這樣,，用戶就不需要為每個(gè)網(wǎng)站或應(yīng)用設(shè)置不同的密碼，實(shí)現(xiàn)了單點(diǎn)登錄（SSO）的效果,。用戶可以在不同的應(yīng)用程序中使用相同的 Google 憑證,。

最初，OAuth 2.0 被設(shè)計(jì)為一種授權(quán)框架,，用于授予第三方應(yīng)用程序?qū)μ囟ㄙY源的有限訪問(wèn)權(quán)限,。一個(gè)常見(jiàn)的例子是對(duì) Gmail 聯(lián)系人的只讀權(quán)限。我們可以允許應(yīng)用程序讀取我們的聯(lián)系人,，但不希望它能夠刪除它們,。OAuth 2.0 解決的一個(gè)問(wèn)題是，它允許我們讓第三方應(yīng)用程序訪問(wèn)我們的聯(lián)系人,，而無(wú)需將我們的 Gmail 密碼提供給該應(yīng)用程序,，從而提升了安全性。

為了方便使用 OAuth 2.0 協(xié)議進(jìn)行認(rèn)證,，一個(gè)名為 OpenID Connect 的 OAuth 2.0 擴(kuò)展應(yīng)運(yùn)而生。該擴(kuò)展定義了使用 OAuth 2.0 進(jìn)行認(rèn)證的標(biāo)準(zhǔn)方法,。考慮到認(rèn)證是本文的主題,，我們將 OAuth 2.0 和 OpenID Connect 結(jié)合起來(lái)使用，共同實(shí)現(xiàn) MQTT 客戶端訪問(wèn) Broker 的授權(quán)機(jī)制。

OAuth 2.0 如何與 MQTT 配合？

客戶端可以利用 OAuth 2.0 和 OpenID Connect 來(lái)獲取合適的 JWT,，然后再將 JWT 發(fā)送給 Broker。參考上面的圖片,，第一步是 MQTT 客戶端向認(rèn)證服務(wù)器申請(qǐng) JWT Token。我們這里假設(shè)認(rèn)證服務(wù)器支持帶有 OpenID Connect 擴(kuò)展的 OAuth 2.0,。OpenID Connect 規(guī)定了認(rèn)證服務(wù)器返回的令牌必須是 JWT 格式?？蛻舳四玫?JWT 后，就可以把它發(fā)送給 Broker,。通常,，JWT 放在 CONNECT 報(bào)文的密碼字段里發(fā)送給 Broker,。

結(jié)語(yǔ)

作為全球領(lǐng)先的 MQTT Broker，EMQX 提供了多種認(rèn)證方式,，其中包括 JWT 認(rèn)證。您可以選擇 HMAC 作為簽名方案,，也可以選擇更安全的 RSA，或者直接為 EMQX 配置一個(gè) JWKS 端點(diǎn)來(lái)啟用 JWT 認(rèn)證,。

通過(guò)使用這些額外的認(rèn)證方式，您可以增強(qiáng)整個(gè)系統(tǒng)對(duì)未授權(quán)訪問(wèn)和潛在安全威脅的防護(hù),。隨著技術(shù)的不斷進(jìn)步，與最新的認(rèn)證技術(shù)保持同步將變得更加重要,。