灵活多样认证授权，零开发投入保障 IoT 安全

引言：灵活认证/授权机制带来高效安全保障

EMQX 始终十分关注安全性，通过大量开箱即用的安全功能为广大物联网用户提供持续增强的安全保障，包括 MQTT over TLS/SSL、基于国密算法的传输加密认证集成方案，以及用户名/密码、LDAP、JWT、PSK 和 X.509 证书等多种身份认证功能。

其中，客户端认证与授权是安全保障的核心之一。最新发布的 EMQX 5.0 对配置方式和使用流程进行了优化，内置实现了客户端认证授权功能：用户通过简单配置，无需编写代码即可对接各类数据源与认证服务，实现各个级别与各类场景下的安全配置，以更高的开发效率获得更安全的保障。

本文将通过对 EMQX 客户端认证与授权机制以及 5.0 版本中相关优化的详细解析，为读者展示 EMQX 进行物联网安全保障的原理机制，帮助大家更好地使用这一功能构建更加安全可靠的物联网平台与应用。

EMQX 客户端认证机制

身份认证是大多数应用程序的重要组成部分，在物联网应用中也一样。

MQTT 协议允许客户端携带用户名/密码用于身份认证，在此基础上 EMQX 扩展允许客户端在密码中携带 Token 实现 JWT 认证。同时，EMQX 完整支持 MQTT 5.0 增强认证功能，能够通过质询/响应风格方式实现对客户端和服务器的双向认证，实现更强的安全性保障。

三种认证方式

密码认证

EMQX 支持最简单也是使用最多的认证方式，密码认证要求客户端提供能够表明身份的凭据，例如用户名、客户端 ID 以及对应的密码。在某些场景下，用户可能会选择将 TLS 证书中的一些字段（例如证书公用名称）作为客户端的身份凭据使用。

但不论使用何种身份凭据进行认证，这些身份凭据都会提前存储到特定数据源（数据库）中，其中密码通常都会以加盐后散列的形式存储，这也是我们强烈建议的方式。

密码认证在 EMQX 中的基本运作原理为：在客户端连接时，EMQX 将使用用户指定的查询语句在数据库中查询与该客户端提供的身份凭据对应的密码散列值，然后与客户端当前连接密码的散列值进行匹配，一旦匹配成功，EMQX 将允许该客户端登录。

JWT 认证

JWT 是一种基于 Token 的认证机制，它不需要服务器来保留客户端的认证信息或会话信息。客户端可以在密码或用户名中携带 Token，EMQX 则使用预先配置的密钥或公钥对 JWT 签名进行验证。

如果用户配置了 JWKs 服务器，则 JWT 认证器将使用从 JWKs 服务器查询到的公钥列表对 JWT 签名进行验证。在持有密钥的情况下用户可以为客户端批量签发认证信息，是最简便的认证方式。

MQTT 5.0 增强认证

MQTT 5.0 增强认证是对密码认证的扩展，它更像是一种认证框架，允许使用各种更安全的认证机制，例如 SCRAM 认证、Kerberos 认证等。目前 EMQX 已支持 SCRAM 认证，并且通过内置数据库提供了对 SCRAM 用户管理的支持。

在传输层方面，EMQX 支持 TLS 的双向认证，这在某种程度上能满足客户端和服务端之间的身份验证要求，EMQX 也支持基于 PSK 的 TLS/DTLS 认证，本文不再赘述此部分内容。

认证链、超级用户与权限

EMQX 允许创建多个认证器构成一条认证链，认证器将按照在链中的位置顺序运行，如果在当前认证器中未检索到身份凭证，将会切换至链上的下一个认证器继续认证，所有认证器都没有查找到数据则客户端认证失败。

EMQX 允许在认证阶段为客户端设置超级用户角色以及预设权限列表，用于后续的发布订阅权限检查。

EMQX 授权机制

EMQX 授权是指对客户端的发布和订阅操作进行权限控制。与客户端认证一样，客户端权限列表同样需要提前存储到特定数据源（数据库、文件）中，更新对应的数据即可实现权限的运行时动态更新。

授权机制在 EMQX 中的基本运作原理为：在客户端发布或订阅时，EMQX 将使用特定的流程或用户指定的查询语句从数据源中查询该客户端相关的访问控制列表（ACL），与当前操作进行匹配并根据匹配结果允许或拒绝当前操作。

缓存、授权链与权限优先级

大量的客户端订阅和发布将会对授权数据后端产生访问压力，因此 EMQX 引入了缓存机制。

EMQX 允许创建多个授权检查器构成一条授权链，授权检查将按照在链中的位置顺序运行，如果在当前授权检查器中未检索到权限数据，将会切换至链上的下一个检查器继续检查，所有检查器都没有查找到数据则客户端根据 no_match 配置默认允许或拒接操作。

如果客户端在认证阶段设置了超级用户角色，则后续的发布订阅操作不会再触发授权检查；如果设置了权限列表，则优先匹配客户端权限数据。三者匹配关系如下：

代码语言：text复制

超级用户 > 权限数据 > 授权检查

认证与授权数据源

EMQX 为密码认证、授权提供了与多种后端数据库的集成支持，包括 MySQL、PostgreSQL、MongoDB 和 Redis。

同时 EMQX 也支持用户将身份凭证和权限列表存储到内置数据库（基于 Mnesia）中，这种方式提供了非常简单的配置流程和用户管理接口。用户可以通过 REST API 或 Dashboard 管理认证数据，或从 CSV 或 JSON 文件批量导入用户。

除此之外，EMQX 还可以通过 HTTP 方式对接用户自己开发的服务，借此实现更复杂的认证与授权逻辑。

移除认证授权插件

EMQX 5.0 中我们将认证授权功能从插件迁移至内置功能，原认证授权插件不再内置。

除了配置文件的方式外，EMQX 允许通过 Dashboard 与 REST API 配置认证授权功能，选择需要的认证方式，选择擅长的数据源，填入参数即可启用连接认证和授权检查功能，为客户端提供最重要的安全防护。REST API 的配置方式能够在实现将配置一次性分发并生效至集群所有节点中，这种热配置的方式大大提升了易用性，能够更快的上手使用。

相比于 4.x 版本，使用内置数据时 EMQX 5.0 还在 Dashboard 提供了数据管理页面，用户在浏览器上即可完成数据的导入/添加与管理，真正实现开箱即用零开发能力。

保留插件使用方式

内置的认证授权本身也是通过挂载钩子的形式实现控制的，用户仍然可以使用 EMQX 4.x 中开发的认证授权插件，或基于 EMQX 5.0 开发新的插件，此时插件与内置功能将以钩子挂载顺序确定执行优先级。

以下是认证与授权功能挂载的钩子信息，更多信息请参考插件与扩展 - 钩子：

多语言扩展开发认证授权功能

除了原生插件开发外，EMQX 还支持通过多语言钩子扩展的形式实现认证授权功能。

移除匿名认证机制

EMQX 4.x 中提供了匿名认证配置 allow_anonymous，没有启用认证插件或认证插件中没有查找到当前客户端的身份凭证时，EMQX 将根据匿名认证启用情况决定是否允许客户端连接*。

我们建议用户务必在生产环境中禁用匿名认证以避免数据库列表之外的客户端连接至 EMQX。

为了进一步提升安全性，同时降低用户使用的复杂度，我们在 EMQX 5.0 中移除了这一机制。目前是否启用认证的逻辑如下：

EMQX 没有配置任何认证器时，此时允许所有客户端连接
EMQX 配置认证器后：
- 所有认证器禁用：允许客户端连接
- 任意认证器启用：查找身份凭证进行认证，如果全部启用的认证器中都没有找到身份凭证，则禁止客户端连接

调整认证器与授权检查器顺序

用户可以创建多个认证器和授权检查器组成链实现链式认证，尽管我们不推荐这么做，但某些场景下这是有益的：比如客户端数量多、发布订阅速率很高的极端场景下，用户可能使用 Redis 作为链中的第一个授权检查器，与 HTTP 授权检查服务搭配使用，借助 Redis 高性能、自带 TTL 优势提供缓存层以实现更高性能的授权检查能力。

此前链上检查器执行的顺序是通过对应插件加载顺序决定的，并没有对应的配置接口，这会带来几个问题：