In addition to the authentication methods mentioned in the previous articles , this article will conduct an in-depth analysis and discussion of other authentication methods.
Specifically, we'll take an in-depth look at Token-based authentication and OAuth 2.0, explain their principles, and show their application in MQTT.
Token-based authentication
Let's first get acquainted with token-based authentication and understand some of its advantages over traditional username and password authentication.
What is token-based authentication?
Simply put, Token-based authentication uses Tokens to verify client identities instead of traditional credentials (such as usernames and passwords). The process is similar to using an electronic key card to enter a hotel room. When you show your ID to the front desk, they will provide you with an electronic key card that will allow you to open the hotel door. This electronic door card acts as a Token during your stay. You don't need to prove your identity to the front desk every time you enter the room, just swipe the card.
An important feature of Token is that it has a limited validity period and can expire after expiration. For example, your hotel key card will not work after you check out. However, you might check into another hotel and get a key card to your new room. Therefore, compared to usernames and passwords, tokens are more flexible and easier to manage. The electronic key card reader on the hotel room door does not need to record a valid user name and password, but only needs to verify the room number and expiration date on the key card.
Below we will delve into some Token-based authentication methods suitable for MQTT.
Token-based MQTT authentication method
In MQTT, we usually use JWT for token authentication.
JWT (JSON Web Token) is a concise way to verify client identity in MQTT Broker. The client sends a signed JWT Token to the Broker, and the Broker verifies the identity of the client based on the Token. Broker does not need to save the client's username and password.
JWT Token consists of the following parts:
- Header : Encoded in Base64 - Describes the algorithm used to generate the signature.
- Payload : Encoded in Base64 - Carries claims that can authenticate the client.
- Signature : After concatenating the header and the payload, encode it with Base64, and then sign it with a key.
The following diagram shows the structure of a JWT:
Note that the header and payload are not encrypted, they are just encoded with the base64 binary-to-text encoding function. This is a reversible function, so just base64 decode the function to see the content easily. So, don't put sensitive information in header and payload section. Also, it is best to encrypt client connections using TLS. The JWT is signed with a secret key .
Broker needs to verify that the JWT is valid. This can be achieved in two ways: one is to hold the key locally, which can be a key shared with the client, or a public key that is opposite to the private key used to issue the JWT; the other is to use JWKS (JSON Web Key Set), JWKS is a set of public keys that can be used to verify whether the key is valid. Broker can obtain the public key through the JWKS endpoint without holding it itself.
After the JWT Token is issued, it cannot be revoked, only until it expires. Therefore, be sure to keep it in a safe place, if it falls into the wrong hands, an attacker can use it to gain access to the Broker.
JWT Token can be obtained by using an authentication server. In this case, the client first connects to the authentication server, and the authentication server issues JWT Token to the client after verifying its identity. The client uses this token to connect to the Broker.
The following figure shows this process:
Below is an example of a JWT payload.
{
"clientid": "client1",
"username": "user1",
"iat": 1516239022,
"nbf": 1678114325,
"exp": 1709649185
}
In addition to the clientid and username fields, the JWT token can also contain some time fields, which are used to indicate the validity period of the token. These time fields represent Unix time in seconds since January 1, 1970.
- "iat" : Issue Time - The date and time the token was issued. Expressed in Unix time.
- "nbf" : effective time - the date and time when the token becomes effective. Expressed in Unix time.
- "exp" : expiration time - the date and time when the token expires. Expressed in Unix time.
Note that by using the nbf field, you can issue a JWT that is valid at a future date.
OAuth 2.0
In the previous section, we introduced the format of the JWT Token, but did not explain how to obtain the Token. Next, let's see how to use OAuth 2.0 with JWT to enable clients to access the Broker.
What is OAuth 2.0?
OAuth 2.0 is a framework that allows users to access resources on other websites or applications using their credentials registered with an independent authentication and authorization server (such as Google, Facebook, GitHub, etc.). In this way, users do not need to set different passwords for each website or application, and realize the effect of single sign-on (SSO). Users can use the same Google credentials in different applications.
Originally, OAuth 2.0 was designed as an authorization framework for granting third-party applications limited access to specific resources. A common example is read-only access to Gmail contacts. We can allow the app to read our contacts, but don't want it to be able to delete them. One problem that OAuth 2.0 solves is that it increases security by allowing us to give third-party applications access to our contacts without giving the application our Gmail password.
In order to facilitate authentication using the OAuth 2.0 protocol, an OAuth 2.0 extension named OpenID Connect came into being. This extension defines a standard method for authentication using OAuth 2.0. Considering that authentication is the subject of this article, we combine OAuth 2.0 and OpenID Connect to implement the authorization mechanism for MQTT clients to access Broker.
How does OAuth 2.0 work with MQTT?
The client can use OAuth 2.0 and OpenID Connect to obtain the appropriate JWT, and then send the JWT to the Broker. Referring to the picture above, the first step is that the MQTT client applies for a JWT Token from the authentication server. We assume here that the authentication server supports OAuth 2.0 with the OpenID Connect extension. OpenID Connect stipulates that the token returned by the authentication server must be in JWT format. After the client gets the JWT, it can send it to the Broker. Usually, JWT is sent to the Broker in the password field of the CONNECT message.
epilogue
As the world's leading MQTT Broker, EMQX provides a variety of authentication methods, including JWT authentication. You can choose HMAC as the signature scheme, or choose the more secure RSA, or directly configure a JWKS endpoint for EMQX to enable JWT authentication.
By using these additional authentication methods, you can increase the protection of the entire system against unauthorized access and potential security threats. As technology continues to advance, it will become even more important to stay abreast of the latest authentication techniques.
Copyright statement: This article is original by EMQ, please indicate the source for reprinting.
Original link: https://www.emqx.com/zh/blog/a-deep-dive-into-token-based-authentication-and-oauth-2-0-in-mqtt