深入解析MQTT中的基于令牌的认证与OAuth 2.0# 示例输入和输出 **输入** 人工智能（AI）是计算机科学的一个分支，旨在开发表现出人类智能的软件或机器。这包括从经验中学习、理解自然语言、解决问题以及识别模式。 **输出** 人工智能（AI）是计算机科学的一个分支，旨在开发表现出人类智能的软件或机器。这包括从经验中学习、理解自然语言、解决问题以及识别模式。

插图：© IoT For All --> 本文深入探讨了额外的认证方法。具体来说，我们将探索基于令牌的认证和 OAuth 2.0，解释它们的概念，并演示它们在 MQTT 中的实现方式。基于令牌的认证 首先，我们来看看基于令牌的认证，并了解用户名和密码认证的一些优势。顾名思义，基于令牌的认证使用令牌来认证客户端，而不是使用其凭证，比如用户名和密码。这类似于酒店的电子钥匙。你向前台出示身份证件，他们会给你一把电子钥匙，允许你进入房间。在你入住期间，这把电子钥匙就起到令牌的作用。你不需要每次进入房间时都向前台重新确认身份，只需要使用钥匙即可。令牌的一个重要特性是它们可以设置过期时间，以限制其有效时长。例如，你入住结束后，酒店钥匙将不再有效。但是，你可以入住新的酒店，并获得用于新房间的另一个令牌。因此，与用户名和密码相比，令牌更加灵活且更易于管理。酒店房间门口的电子钥匙读取器不需要记录有效的用户名和密码，它只需要验证电子钥匙上的房间号和过期日期是否有效。MQTT 中的基于令牌认证方法 在 MQTT 中，我们通常使用 JWT 来实现令牌认证。JWT（JSON Web Token）是一种紧凑的方式，用于在 MQTT 代理中认证客户端。客户端将签名的 JWT 令牌发送给代理，代理使用该令牌认证客户端。代理不需要维护客户端用户名和密码的列表。JWT 令牌由以下部分组成：- **头部（Header）**：Base64 编码，标识用于生成签名的算法。- **载荷（Payload）**：Base64 编码，包含可用于认证客户端的声明。- **签名（Signature）**：将头部和载荷拼接后，使用密钥签名并进行 Base64 编码。下图展示了 JWT 的结构：EMQ Technologies Inc.请注意，头部和载荷并未加密，只是使用了 Base64 编码，这是二进制到文本的编码方式，而非单向函数。因此，通过 Base64 解码函数可以轻松读取内容。因此，请确保头部和载荷部分不包含敏感信息。另外，使用 TLS 加密客户端连接是个好主意。JWT 使用一个**密钥**进行签名。代理需要验证 JWT 是否有效。为此，代理要么需要知道该密钥（即客户端和代理之间共享密钥），要么可以使用 JWKS（JSON Web Key Set）。JWKS 是一组用于验证密钥是否有效的公钥。代理可以引用一个 JWKS 终端，而无需自行存储密钥。一旦 JWT 令牌被签发，在其过期之前无法被撤销。因此，非常重要的一点是将令牌安全地保存在合适的位置。如果令牌被窃取，攻击者可以使用它来访问代理。可以使用认证服务器来获取 JWT 令牌。在这种情况下，客户端连接到认证服务器，服务器验证其身份并向客户端发放 JWT 令牌。客户端使用该令牌连接到代理。下图展示了该过程：EMQ Technologies Inc.下面是一个 JWT 载荷的示例：{ "clientid": "client1", "username": "user1", "iat": 1516239022, "nbf": 1678114325, "exp": 1709649185}除了 `clientid` 和 `username` 字段外，JWT 令牌还可以包含一些时间字段，这些字段表示令牌的有效时间。这些时间均以 Unix 时间表示，即自 1970 年 1 月 1 日以来的秒数。- **"iat"**：签发时间（Issued at）—— 令牌的签发日期和时间，以 Unix 时间表示。- **"nbf"**：开始生效时间（Not before）—— 令牌开始生效的日期和时间，以 Unix 时间表示。- **"exp"**：过期时间（Expired）—— 令牌的过期日期和时间，以 Unix 时间表示。请注意，通过使用 `nbf` 字段，你可以签发一个在未来某个日期才生效的 JWT 令牌。OAuth 2.0 在上一节中，我们讨论了 JWT，它描述了令牌的格式，但并未规定如何获取令牌。接下来，我们来看看 OAuth 2.0 和 JWT 如何协同工作，以允许客户端访问代理。OAuth 2.0 是一个框架，允许用户通过来自其他认证和授权服务器（如 Google、Facebook、GitHub 等）的凭证来访问资源。这可以作为单点登录（SSO, Single Sign On）机制，因为用户不需要记住多个密码。他们可以使用相同的 Google 凭证登录不同的应用程序。最初，OAuth 2.0 被设计为一种授权框架，用于向第三方应用授予特定范围的资源访问权限。一个常见的例子是读取 Gmail 的联系人。我们可以允许某个应用读取我们的联系人，但不希望它能删除联系人。OAuth 2.0 所解决的一个问题是：我们可以授权第三方应用访问联系人，而无需将 Gmail 密码交给该应用，这显然更安全。由于使用该协议进行认证也很方便，因此 OAuth 2.0 被扩展为一个名为 OpenID Connect 的协议。这个扩展创建了一种使用 OAuth 2.0 进行认证的标准方式。由于本文讨论的是认证，我们将 OAuth 2.0 与 OpenID Connect 一起作为授权 MQTT 客户端访问代理的机制。OAuth 2.0 如何与 MQTT 配合工作？OAuth 2.0 与 OpenID Connect 可以作为客户端获取相应 JWT 的机制，然后将该 JWT 发送给代理。参考上面的图示，第一步是 MQTT 客户端向认证服务器请求 JWT 令牌。我们假设该认证服务器支持 OpenID Connect 扩展的 OAuth 2.0 协议。OpenID Connect 规定，认证服务器返回的令牌必须为 JWT 格式。一旦客户端收到 JWT，就可以将其发送给代理。通常，JWT 会通过 CONNECT 数据包的密码字段发送给代理。认证方法 通过采用这些额外的认证方法，您可以加强整个系统对未经授权访问和潜在安全漏洞的防护。随着技术的不断发展，保持对最新认证技术的了解变得越来越重要。TweetShareShareEmail IT 和安全MQTT安全 --> IT 和安全MQTT安全