Flexible Authentication Methods for Secure IoT Device Connections

Introduction: Flexible Authentication/Authorization Mechanisms Provide Efficient Security Assurance

EMQX has always placed great emphasis on security, providing continuous enhancement of security guarantees for IoT users through a wide range of out-of-the-box security features, including MQTT over TLS/SSL, transmission encryption and authentication integration based on national cryptography algorithms, as well as various identity authentication functions such as username/password, LDAP, JWT, PSK, and X.509 certificates.

Identity authentication is a crucial component of most applications, and the same applies to IoT applications.

The MQTT protocol allows clients to carry username/password for authentication; based on this, EMQX extends the capability for clients to carry tokens in the password for JWT authentication. Meanwhile, EMQX fully supports the enhanced authentication features of MQTT 5.0, capable of achieving mutual authentication between clients and servers through a challenge/response style, providing stronger security guarantees.

Three Authentication Methods

Password Authentication

EMQX supports the simplest and most widely used authentication method, password authentication, which requires clients to provide credentials that indicate their identity, such as username, client ID, and corresponding password. In some scenarios, users may choose to use certain fields in the TLS certificate (e.g., the common name of the certificate) as client identity credentials.

Regardless of the identity credentials used for authentication, these credentials are stored in a specific data source (database) in advance, where passwords are typically stored in a salted and hashed format, which is the method we strongly recommend.

The basic operation principle of password authentication in EMQX is as follows: when a client connects, EMQX will use the user-specified query statement to query the hashed password corresponding to the identity credentials provided by the client in the database, and then match it with the hashed value of the password currently used by the client. Once matched successfully, EMQX will allow the client to log in.

JWT Authentication

JWT (https://jwt.io/) is a token-based authentication mechanism that does not require the server to retain client authentication information or session information. Clients can carry tokens in their passwords or usernames, and EMQX verifies the JWT signature using a pre-configured key or public key.

If users configure a JWKs server, the JWT authenticator will verify the JWT signature using the public key list retrieved from the JWKs server. With the key in hand, users can issue authentication information for clients in bulk, making it the simplest authentication method.

MQTT 5.0 Enhanced Authentication

MQTT 5.0 enhanced authentication (https://www.emqx.com/zh/blog/mqtt5-enhanced-authentication) is an extension of password authentication, resembling an authentication framework that allows the use of various more secure authentication mechanisms, such as SCRAM authentication, Kerberos authentication, etc. Currently, EMQX supports SCRAM authentication and provides support for SCRAM user management through its built-in database.

In terms of transport layer, EMQX supports mutual authentication via TLS, which can satisfy the identity verification requirements between clients and servers to some extent. EMQX also supports PSK-based TLS/DTLS authentication, which will not be elaborated upon in this section.

Authentication Chain, Super Users, and Permissions

EMQX allows the creation of multiple authenticators to form an authentication chain, where authenticators will run in the order of their position in the chain. If no credentials are retrieved in the current authenticator, it will switch to the next authenticator in the chain to continue authentication. If no authenticators find data, client authentication will fail.

EMQX allows setting super user roles and predefined permission lists for clients during the authentication phase for subsequent publish/subscribe permission checks.

EMQX authorization refers to permission control over clients’ publishing and subscribing operations. Similar to client authentication, the client’s permission list also needs to be stored in a specific data source (database, file) in advance, and updating the corresponding data can achieve dynamic updates of permissions at runtime.

The basic operation principle of the authorization mechanism in EMQX is as follows: when a client publishes or subscribes, EMQX will use a specific process or user-specified query statement to query the access control list (ACL) related to that client from the data source, match it with the current operation, and allow or deny the operation based on the match result.

Cache, Authorization Chain, and Permission Priority

A large number of clients subscribing and publishing will put access pressure on the authorization data backend. Therefore, EMQX introduces a caching mechanism.

EMQX allows the creation of multiple authorization checkers to form an authorization chain, where authorization checks will run in the order of their position in the chain. If no permission data is retrieved in the current authorization checker, it will switch to the next checker in the chain to continue checking. If all checkers fail to find data, the client will be allowed or denied the operation based on the no_match configuration (https://www.emqx.io/docs/zh/v5.0/security/authz/authz.html#no-match).

If a client has set a super user role during the authentication phase, subsequent publish/subscribe operations will not trigger authorization checks; if a permission list is set, it will prioritize matching client permission data. The matching relationship is as follows:

Super User > Permission Data > Authorization Check

EMQX provides integration support with various backend databases for password authentication and authorization, including MySQL, PostgreSQL, MongoDB, and Redis.

Additionally, EMQX also supports users storing identity credentials and permission lists in a built-in database (based on Mnesia), which provides a very simple configuration process and user management interface. Users can manage authentication data through REST API or Dashboard, or import users in bulk from CSV or JSON files.

Moreover, EMQX can also interface with user-developed services via HTTP to achieve more complex authentication and authorization logic.

In EMQX 5.0, we have migrated the authentication and authorization features from plugins to built-in functionality, and the original authentication and authorization plugins are no longer built-in.

In addition to configuration files, EMQX allows configuring authentication and authorization features through the Dashboard and REST API, selecting the desired authentication methods, preferred data sources, and filling in parameters to enable connection authentication and authorization checks, providing the most critical security protection for clients. The REST API configuration method allows the configuration to be distributed once and take effect across all nodes in the cluster, greatly enhancing usability and enabling faster onboarding.

Compared to version 4.x, when using built-in data, EMQX 5.0 also provides a data management page in the Dashboard, allowing users to complete data import/addition and management directly in the browser, truly achieving out-of-the-box zero development capability.

Retaining Plugin Usage Method

The built-in authentication and authorization are also controlled through a hook mounting method, and users can still use authentication and authorization plugins developed in EMQX 4.x or develop new plugins based on EMQX 5.0. In this case, the priority of execution will be determined by the hook mounting order of the plugins and built-in features.

The following is the hook information for mounting authentication and authorization features; for more information, please refer to: https://www.emqx.io/docs/zh/v5.0/advanced/hooks.html