共计 2681 个字符，预计需要花费 7 分钟才能阅读完成。
除了前几篇文章中提到的认证办法，本文将对其余认证办法进行深入分析和探讨。
具体而言，咱们将深刻理解基于 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
