Internet of Things equipment access method, device and system and storage medium

Abstract

The invention relates to an Internet of Things equipment access method, device and system and a storage medium, and the method comprises the steps: receiving a connection request sent by at least one piece of Internet of Things equipment, the Internet of Things equipment being in one-to-one correspondence with the connection request; whether an authentication service is available or not is determined through the authentication plug-in, the authentication service is a service independent of the Broker node, and the authentication plug-in can access the authentication service by calling a preset interface; and when it is determined that the authentication service is available, the authentication service is used to authenticate the Internet of Things device, and whether the Internet of Things device is allowed to access is determined based on an authentication result. Therefore, the authentication plug-in in each Broker node in the Broker cluster can be utilized to access the authentication service so as to authenticate the Internet of Things equipment, so that the performance bottleneck caused by a centralized proxy server is avoided, and the access requirement of the large-scale Internet of Things equipment is well met.

Description

Technical Field

[0001] This application relates to the field of Internet of Things (IoT) technology, and in particular to an IoT device access method, apparatus, system, and storage medium. Background Technology

[0002] Message Queuing Telemetry Transport (MQTT) is a lightweight machine-to-machine message transport protocol based on a publish / subscribe model. It is designed to provide efficient and reliable network connectivity for resource-constrained devices in low-bandwidth, high-latency, or unstable network environments. Therefore, MQTT is widely used in IoT device communication scenarios to provide efficient and reliable communication connections for IoT devices.

[0003] However, current technologies typically require a centralized proxy server to handle the access of various IoT devices. Therefore, when the number of IoT devices is large, the proxy server can easily become overloaded and crash. Thus, how to meet the needs of large-scale IoT device access has become an urgent technical problem to be solved. Summary of the Invention

[0004] This application provides an IoT device access method, apparatus, system, and storage medium to solve the problem that the existing technology usually requires a centralized proxy server to complete the access of various IoT devices, which is difficult to meet the needs of large-scale IoT device access.

[0005] In a first aspect, embodiments of this application provide an IoT device access method, applied to any Broker node in a Broker cluster, the method comprising: Receive connection requests from at least one Internet of Things (IoT) device, wherein each IoT device corresponds to a connection request; The availability of the authentication service is determined by the authentication plugin, wherein the authentication service is a service independent of the Broker node, and the authentication plugin can access the authentication service by calling a preset interface. If the authentication service is found to be available, the authentication service is used to authenticate the IoT device, and the authentication result is used to determine whether the IoT device is allowed to access the network.

[0006] Optionally, authenticating the IoT device using the authentication service includes: Determine whether the number of connection requests has reached a preset number; If the number of connection requests does not reach the preset number, the authentication service is used to authenticate the IoT devices sequentially. When the number of connection requests reaches the preset number, the authentication service is used to perform batch authentication of the IoT devices.

[0007] Optionally, the step of sequentially authenticating the IoT device using the authentication service includes: The authentication service is used to parse the connection requests sequentially to obtain the account and password carried in the connection requests; The system sequentially determines whether the parsed password matches the password corresponding to the account in the preset database, and whether the current password is within the validity period of the account in the preset database. The preset database stores accounts, passwords, and validity periods corresponding to multiple IoT devices. If the parsed password matches the password corresponding to the account in the preset database, and the current period is within the validity period of the account in the preset database, the authentication of the IoT device is determined to be successful. If the parsed password does not match the password corresponding to the account in the preset database, and / or the current password is not within the validity period of the account in the preset database, the authentication of the IoT device is determined to have failed.

[0008] Optionally, the step of using the authentication service to perform batch authentication of the IoT devices includes: The connection request is encapsulated into a request message, and the authentication service is invoked through streaming communication to parse the request message and obtain the account and password carried in the connection request in batches. The system batch-determines whether the parsed passwords match the passwords corresponding to the accounts in the preset database, and whether the current passwords are within the validity period of the accounts in the preset database. The preset database stores accounts, passwords, and validity periods corresponding to multiple IoT devices. If the parsed password matches the password corresponding to the account in the preset database, and the current period is within the validity period of the account in the preset database, the authentication of the IoT device is determined to be successful. If the parsed password does not match the password corresponding to the account in the preset database, and / or the current password is not within the validity period of the account in the preset database, the authentication of the IoT device is determined to have failed.

[0009] Optionally, determining whether to allow the IoT device to access the network based on the authentication result includes: If the authentication result is successful, the IoT device is allowed to access the network. If the authentication result is an authentication failure, the IoT device is denied access.

[0010] Optionally, the method further includes: If the authentication service is determined to be unavailable, a fault degradation mode is entered. The fault degradation mode includes a whitelist mode and a blacklist mode. The whitelist mode allows only cached IoT devices to access the network, while the blacklist mode does not allow IoT devices to access the network.

[0011] Secondly, embodiments of this application also provide an IoT device access method, applied to a scheduling server, the method comprising: Receive a scheduling request sent by at least one Internet of Things (IoT) device, wherein the IoT device corresponds one-to-one with the scheduling request, and the scheduling request carries the device identifier and device type corresponding to the IoT device; Based on the device identifier and the device type, determine whether the IoT device is legitimate, and if the IoT device is legitimate, generate the Broker node address and authentication information corresponding to the IoT device. The Broker node address and the authentication information are returned to the IoT device so that the IoT device can send a connection request to the Broker node corresponding to the Broker node address. This allows each Broker node to determine whether the authentication service is available through the authentication plugin. If the authentication service is available, the authentication service is used to authenticate the IoT device, and the authentication result determines whether the IoT device is allowed to access the network. The authentication service is a service independent of the Broker node, and the authentication plugin can access the authentication service by calling a preset interface.

[0012] Optionally, after generating the Broker node address and authentication information corresponding to the IoT device, the method further includes: The authentication information is stored in a preset database for use by the authentication service. The authentication information includes the account, password, and validity period corresponding to the IoT device.

[0013] Thirdly, this application also provides an IoT device access device, applied to any Broker node in a Broker cluster, the device comprising: The first receiving module is configured to receive connection requests sent by at least one Internet of Things (IoT) device, wherein each IoT device corresponds to a connection request. The verification module is used to determine whether the authentication service is available through the authentication plugin. The authentication service is a service independent of the Broker node, and the authentication plugin can access the authentication service by calling a preset interface. The authentication module is used to authenticate the IoT device using the authentication service when it is determined that the authentication service is available, and to determine whether to allow the IoT device to access the network based on the authentication result.

[0014] Fourthly, embodiments of this application also provide an IoT device access device, applied to a scheduling server, the device comprising: The second receiving module is used to receive a scheduling request sent by at least one Internet of Things (IoT) device, wherein the IoT device corresponds one-to-one with the scheduling request, and the scheduling request carries the device identifier and device type corresponding to the IoT device. The determination module is used to determine whether the IoT device is legitimate based on the device identifier and the device type, and if the IoT device is determined to be legitimate, generate the Broker node address and authentication information corresponding to the IoT device; The return module is used to return the Broker node address and the authentication information to the IoT device, so that the IoT device can send a connection request to the Broker node corresponding to the Broker node address. This allows each Broker node to determine whether the authentication service is available through the authentication plugin. If the authentication service is available, the authentication service is used to authenticate the IoT device, and the authentication result determines whether the IoT device is allowed to access the network. The authentication service is a service independent of the Broker node, and the authentication plugin can access the authentication service by calling a preset interface.

[0015] Fifthly, embodiments of this application also provide an Internet of Things (IoT) device access system, the system including a Broker cluster, a scheduling server, and at least one IoT device; The Broker cluster includes multiple distributed Broker nodes, each of which is used to execute the IoT device access method described in the first aspect. The IoT device is connected to the scheduling server, which is used to execute the IoT device access method described in the second aspect.

[0016] Sixthly, embodiments of this application also provide a computer-readable storage medium storing a computer program thereon, wherein the computer program, when executed by a processor, implements the IoT device access method described in the first aspect, or implements the IoT device access method described in the second aspect when executed.

[0017] Compared with the prior art, the technical solution provided in this application has the following advantages: The method provided in this application receives a connection request sent by at least one IoT device, wherein the IoT device corresponds one-to-one with the connection request; determines whether the authentication service is available through an authentication plugin, wherein the authentication service is a service independent of the Broker node, and the authentication plugin can access the authentication service by calling a preset interface; if the authentication service is determined to be available, the authentication service is used to authenticate the IoT device, and the authentication result determines whether the IoT device is allowed to access. Through the above method, when a large number of IoT devices need to access, the authentication plugins in each Broker node of the Broker cluster can be used to access the authentication service to authenticate the IoT devices that need to access, without relying on a centralized proxy server to authenticate each IoT device, thereby avoiding the performance bottleneck caused by a centralized proxy server and better meeting the needs of large-scale IoT device access. Attached Figure Description

[0018] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0019] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0021] Figure 1 A flowchart illustrating an IoT device access method provided in an embodiment of this application; Figure 2 A flowchart illustrating another IoT device access method provided in this application embodiment; Figure 3 This application provides an embodiment of an interaction diagram between an IoT device, a retrieval server, and a Broker node. Figure 4 This is a schematic diagram of the structure of an Internet of Things (IoT) device access device provided in an embodiment of this application; Figure 5A schematic diagram of the structure of another IoT device access device provided in the embodiments of this application; Figure 6 This is a schematic diagram of the structure of an Internet of Things (IoT) device access system provided in an embodiment of this application. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0023] The following disclosure provides numerous different embodiments or examples for implementing various structures of this application. To simplify the disclosure, specific examples of components and arrangements are described below. These are merely examples and are not intended to limit the scope of this application. Furthermore, reference numerals and / or letters may be repeated in different examples. Such repetition is for simplification and clarity and does not in itself indicate a relationship between the various embodiments and / or arrangements discussed.

[0024] To address the problem that existing technologies typically require centralized proxy servers to access various IoT devices, which makes it difficult to meet the needs of large-scale IoT device access, this application provides an IoT device access method, apparatus, system, and storage medium that can meet the needs of large-scale IoT device access.

[0025] It should be noted that the IoT device access method provided in this application embodiment can be applied to an agentless MQTT architecture. The main difference between this agentless MQTT architecture and the traditional MQTT architecture is that the traditional MQTT architecture uses a centralized proxy server to complete the authentication of each IoT device. The authentication logic is fixed in the centralized proxy service. When the number of IoT devices to be connected is large, it is easy to cause the proxy server to be overloaded and paralyzed. In contrast, the agentless MQTT architecture eliminates the centralized proxy server and decouples the authentication logic from the centralized proxy service. Flexible authentication is achieved through an external application programming interface (API), reducing system pressure. This agentless MQTT architecture may include a distributed Broker cluster built based on the BifroMQ open source framework, a scheduling server, and multiple IoT devices. The Broker cluster may include multiple distributed Broker nodes. Each Broker node can load an authentication plugin, which can access the authentication service to authenticate the IoT devices to be connected by calling a preset interface. A scheduling service can be deployed on the scheduling server. Upon receiving a scheduling request from a device seeking to connect to the Internet of Things (IoT), this service verifies the device and returns the Broker node address and authentication information upon successful verification. The IoT device can be any device that needs to connect to the IoT, such as smart home devices, various sensors, and control and management platforms.

[0026] See Figure 1 , Figure 1 This is a flowchart illustrating an IoT device access method provided in an embodiment of this application. Figure 1 As shown, this IoT device access method is applied to any Broker node in a Broker cluster, and the IoT device access method may include the following steps: Step S101: Receive a connection request sent by at least one IoT device, wherein the IoT device corresponds one-to-one with the connection request.

[0027] Specifically, the number of IoT devices and the number of connection requests mentioned above are equal, and there can be one or more of them. That is, the Broker node can receive one connection request from one IoT device at a certain moment or within a short period of time, or it can receive multiple connection requests from multiple IoT devices. This application embodiment does not make specific limitations. The connection request is used to request the Broker node to access the IoT device, and the connection request may include information such as the IoT device identifier, account, and password.

[0028] Step S102: Determine whether the authentication service is available through the authentication plugin. The authentication service is a service independent of the Broker node. The authentication plugin can access the authentication service by calling a preset interface.

[0029] Specifically, the authentication plugin is built into each Broker node. When a connection request is received from an IoT device, the authentication plugin on the Broker node is triggered. It does not perform internal authentication; instead, it forwards the device's credentials (such as username and password) to a separate external authentication service via a standard API call (such as REST / gRPC). This authentication service can be a separate microservice specifically responsible for executing authentication logic and permission queries. It queries credentials from a shared database or cache for verification and returns the result (authentication successful / authentication failed) to the authentication plugin.

[0030] When determining whether the authentication service is available through the authentication plugin, a liveness detection method can be used. For example, assuming the timeout is set to 3 seconds (this value can be flexibly configured), the authentication plugin detects the interface liveness every preset time interval (such as 10 seconds). If no response is detected within 3 seconds, the authentication service is considered unavailable; if a response is detected within 3 seconds, the authentication service is considered available.

[0031] Step S103: If the authentication service is available, use the authentication service to authenticate the IoT device, and determine whether to allow the IoT device to access the network based on the authentication result.

[0032] Specifically, when the authentication service is available, it can be used to authenticate IoT devices and return the authentication results to the authentication plugin. In this way, the Broker node can determine whether to allow IoT devices to access the network based on the authentication results.

[0033] In this way, when a large number of IoT devices need to access the network, the authentication plugins in each Broker node of the Broker cluster can be used to access the authentication service to authenticate the IoT devices that need to access the network, without relying on a centralized proxy server to authenticate each IoT device. This avoids the performance bottleneck caused by a centralized proxy server and better meets the needs of large-scale IoT device access.

[0034] In an optional embodiment, step S103, authenticating the IoT device using the authentication service, includes: Determine if the number of connection requests has reached the preset limit; If the number of connection requests does not reach the preset number, the authentication service is used to authenticate the IoT devices sequentially. When the number of connection requests reaches a preset number, the authentication service is used to perform batch authentication of IoT devices.

[0035] Specifically, when authenticating IoT devices using the authentication service, the Broker node can first determine whether the number of received connection requests has reached a preset number. If the number of connection requests received by the Broker node has not reached the preset number, the authentication service can be used to authenticate each IoT device sequentially. If the number of connection requests received by the Broker node has reached the preset number, the authentication service can be used to perform batch authentication of each IoT device. The preset number can be set according to actual needs, such as 10, 20, etc., and is not specifically limited here.

[0036] In this way, the Broker node can process the received connection requests using either a single authentication method (i.e., authentication one after another) or a batch authentication method, which improves the flexibility of the authentication method.

[0037] In an optional embodiment, the above steps, including authenticating the IoT device using the authentication service, include: The authentication service is used to parse the connection requests one by one to obtain the account and password carried in the connection request; The system sequentially checks whether the parsed password matches the password corresponding to the account in the preset database, and whether the current password is within the validity period of the account in the preset database. The preset database stores accounts, passwords, and validity periods for multiple IoT devices. If the parsed password matches the password corresponding to the account in the preset database, and the current period is within the validity period of the account in the preset database, the authentication of the IoT device is confirmed to be successful. If the parsed password does not match the password corresponding to the account in the preset database, and / or the current password is not within the validity period of the account in the preset database, the authentication of the IoT device is determined to have failed.

[0038] Specifically, when using the authentication service to authenticate each IoT device in the IoT device ecosystem, the authentication service can first parse each connection request sequentially to obtain the account and password carried in each connection request. Then, it can be determined whether the parsed password matches the password corresponding to the account in the preset database, and whether the current password is within the validity period of the account in the preset database. If the parsed password matches the password corresponding to the account in the preset database and the current password is within the validity period of the account in the preset database, then the IoT device corresponding to that password can be determined to have been successfully authenticated. If the parsed password does not match the password corresponding to the account in the preset database, and / or the current password is not within the validity period of the account in the preset database, then the IoT device corresponding to that password can be determined to have failed to be authenticated.

[0039] It should be noted that the preset database here stores the account, password, and validity period for each IoT device to be connected. Specifically, these account, password, and validity period information are generated and stored in the preset database by the scheduling server after the IoT device sends a scheduling request to the scheduling server and passes verification. When authenticating the IoT device to be connected, the authentication service can retrieve the corresponding password and validity period from this preset database using the account as the key.

[0040] In this way, when the number of connection requests received is small, the Broker node can use a single authentication method to authenticate each IoT device.

[0041] In an optional embodiment, the above steps of performing batch authentication of IoT devices using authentication services include: The connection request is encapsulated into a request message, and the authentication service is invoked through streaming communication to parse the request message and obtain the account and password carried in the connection request in batches. The system batch checks whether the parsed passwords match the passwords corresponding to accounts in the preset database, and whether the current passwords are within the validity period of the accounts in the preset database. The preset database stores accounts, passwords, and validity periods for multiple IoT devices. If the parsed password matches the password corresponding to the account in the preset database, and the current period is within the validity period of the account in the preset database, the authentication of the IoT device is confirmed to be successful. If the parsed password does not match the password corresponding to the account in the preset database, and / or the current password is not within the validity period of the account in the preset database, the authentication of the IoT device is determined to have failed.

[0042] Specifically, when using the authentication service to perform batch authentication of IoT devices, Protobuf encoding can be used to encapsulate connection requests into request messages (such as BulkAuthRequest messages). Then, the authentication service is invoked via streaming communication (such as gRPC streaming) to parse each connection request in the request message, batch obtaining the username and password carried in each request. The parsed passwords are then batch-checked to see if they match the passwords corresponding to the accounts in the preset database, and whether the passwords are currently within the validity period of the corresponding accounts in the preset database. If the parsed passwords match the passwords corresponding to the accounts in the preset database, and the passwords are currently within the validity period of the corresponding accounts in the preset database, then the authentication of the IoT device corresponding to that password is successful. If the parsed passwords do not match the passwords corresponding to the accounts in the preset database, and / or the passwords are not currently within the validity period of the corresponding accounts in the preset database, then the authentication of the IoT device corresponding to that password is failed. Finally, the authentication results corresponding to each connection request can be packaged into a response message (such as a BulkAuthResponse message) and returned to the authentication plugin. The Broker node then uses this to return the authentication results corresponding to each connection request to the corresponding IoT device and store them locally.

[0043] In this way, when the number of connection requests received is large, the Broker node can use batch authentication to authenticate each IoT device, thereby improving authentication speed. Furthermore, using Protobuf encoding to encapsulate each connection request into a request message reduces bandwidth consumption.

[0044] In an optional embodiment, step S103, determining whether to allow IoT devices to access the network based on the authentication result, includes: If the authentication result is successful, IoT devices are allowed to access the network. If the authentication fails, the IoT device will be denied access.

[0045] Specifically, when determining whether to allow IoT devices to access the network based on authentication results, if the authentication is successful, the IoT device is allowed to access; if the authentication fails, the IoT device is denied access. This allows for accurate determination of whether to allow each IoT device to access the network based on the authentication results, thereby ensuring network security.

[0046] In an optional embodiment, the method further includes: If the authentication service is determined to be unavailable, the system enters a fault degradation mode, which includes a whitelist mode and a blacklist mode. The whitelist mode allows only cached IoT devices to access the system, while the blacklist mode does not allow IoT devices to access the system.

[0047] Specifically, when the authentication plugin in the Broker node determines that the authentication service is unavailable, it can enter a fault degradation mode. This fault degradation mode can include a whitelist mode and a blacklist mode. The whitelist mode allows only cached IoT devices to access the network; in this mode, only IoT devices that have previously successfully authenticated are allowed to connect, and already connected devices can maintain their sessions. The blacklist mode disallows all IoT devices from accessing the network; in this mode, device access is denied, but already connected devices can maintain their sessions. This allows for the activation of local emergency policies to ensure the normal operation of already connected devices.

[0048] See Figure 2 , Figure 2 This is a flowchart illustrating another IoT device access method provided in an embodiment of this application. Figure 2 As shown, this IoT device access method is applied to a scheduling server, and the IoT device access method may include the following steps: Step S201: Receive a scheduling request sent by at least one IoT device, wherein the IoT device corresponds one-to-one with the scheduling request, and the scheduling request carries the device identifier and device type corresponding to the IoT device.

[0049] Specifically, the number of IoT devices and the number of scheduling requests are equal, and there can be one or more of them. That is, the scheduling server can receive one scheduling request from one IoT device at a certain moment or within a short period of time, or it can receive multiple scheduling requests from multiple IoT devices; this embodiment does not impose specific limitations. The scheduling request is used to obtain the credential data of the IoT device. The scheduling request may include device identifiers such as Media Access Control Address (MAC) or International Mobile Equipment Identity (IMEI), and device type such as Mobile Internet Device (MID).

[0050] Step S202: Based on the device identifier and device type, determine whether the IoT device is legitimate, and if the IoT device is legitimate, generate the Broker node address and authentication information corresponding to the IoT device.

[0051] Specifically, the scheduling server has pre-set valid device identifiers and device types. Therefore, after receiving a scheduling request from an IoT device, the scheduling server can compare the device identifier and device type carried in the scheduling request with the pre-set device identifier and device type to determine whether the IoT device is valid. If the IoT device is valid, the server generates the corresponding Broker node address and authentication information (such as account, password, and validity period) for the IoT device.

[0052] Step S203: Return the Broker node address and authentication information to the IoT device so that the IoT device can send a connection request to the Broker node corresponding to the Broker node address. This allows each Broker node to determine whether the authentication service is available through the authentication plugin. If the authentication service is available, the authentication service is used to authenticate the IoT device, and the authentication result determines whether the IoT device is allowed to access the network. The authentication service is a service independent of the Broker node, and the authentication plugin can access the authentication service by calling a preset interface.

[0053] Specifically, the scheduling server can return the Broker node address and authentication information to the corresponding IoT devices. These IoT devices can then send connection requests to the Broker node corresponding to the Broker node address. Each Broker node can then determine the availability of the authentication service through its authentication plugin. If the authentication service is available, it uses the authentication service to authenticate the IoT devices and determines whether to allow the IoT devices to access the network based on the authentication result. It should be noted that the Broker node here has the same function as the Broker node in the previous embodiment, and will not be described again here.

[0054] In this way, before an IoT device initiates a connection request to a Broker node, it can obtain the Broker node address and authentication information from the scheduling server, so that it can subsequently find the corresponding Broker node for authentication.

[0055] In an optional embodiment, after step S202 above, generating the Broker node address and authentication information corresponding to the IoT device, the method further includes: The authentication information is stored in a preset database for use by the authentication service. The authentication information includes the account, password and validity period corresponding to the IoT device.

[0056] Specifically, after generating the Broker node address and authentication information corresponding to the IoT device, the scheduling server can also store the authentication information in a preset database. In this way, when the authentication service authenticates the IoT device, it can query the credential data of the IoT device from the preset database for authentication and verification. In an optional embodiment, the IoT device access method provided in this application can be applied to a brokerless MQTT architecture. The interaction flow between the IoT device, the invocation server, and the Broker node in this brokerless MQTT architecture is as follows: Figure 3 As shown: Step S301: The IoT device sends a retrieval request to the retrieval server.

[0057] Step S302: Retrieve MQTT connection information returned by the server to the IoT device.

[0058] The MQTT connection information includes the Broker node address and authentication information.

[0059] Step S303: Retrieve the service to cache the authentication information in the preset database.

[0060] Step S304: The IoT device initiates a connection request to the Broker node corresponding to the Broker node address.

[0061] Step S305: The Broker node determines whether to initiate a single authentication / batch authentication process.

[0062] Step S306: Use the authentication plugin to determine whether the authentication service is available.

[0063] If the authentication plugin determines that the authentication service is available, then proceed to step S307; if the authentication plugin determines that the authentication service is unavailable, then enter the fault degradation mode.

[0064] Step S307: Use the authentication plugin to initiate a single authentication / batch authentication process to the authentication service.

[0065] Step S308: The authentication service reads authentication information from the preset database.

[0066] Step S309: The authentication service authenticates the IoT devices.

[0067] Step S310: The authentication service returns the authentication result to the authentication plugin.

[0068] By executing steps S301 to S310, when a large number of IoT devices need to access the network, the authentication plugins in each Broker node of the Broker cluster can be used to access the authentication service to authenticate the IoT devices that need to access the network, without relying on a centralized proxy server to authenticate each IoT device. This avoids the performance bottleneck caused by a centralized proxy server and better meets the needs of large-scale IoT device access.

[0069] See Figure 4 , Figure 4This is a schematic diagram of the structure of an IoT device access device provided in an embodiment of this application. The IoT device access device 400 is applied to any Broker node in a Broker cluster, and the IoT device access device 400 includes: The first receiving module 401 is used to receive connection requests sent by at least one Internet of Things (IoT) device, wherein there is a one-to-one correspondence between the IoT device and the connection request; The verification module 402 is used to determine whether the authentication service is available through the authentication plugin. The authentication service is a service independent of the Broker node. The authentication plugin can access the authentication service by calling a preset interface. The authentication module 403 is used to authenticate IoT devices using the authentication service when it is determined that the authentication service is available, and to determine whether to allow IoT devices to access the network based on the authentication result.

[0070] Furthermore, the authentication module 403 includes: The judgment submodule is used to determine whether the number of connection requests has reached the preset number; The first authentication submodule is used to authenticate IoT devices sequentially using the authentication service when the number of connection requests has not reached the preset number. The second authentication submodule is used to perform batch authentication of IoT devices using the authentication service when the number of connection requests reaches a preset number.

[0071] Furthermore, the first authentication submodule includes: The first parsing unit is used to parse the connection request sequentially using the authentication service to obtain the account and password carried in the connection request; The first judgment unit is used to sequentially judge whether the parsed password is consistent with the password corresponding to the account in the preset database, and whether the current period is within the validity period of the account in the preset database. The preset database stores accounts, passwords and validity periods corresponding to multiple IoT devices. The first determining unit is used to determine that the IoT device authentication is successful if the parsed password matches the password corresponding to the account in the preset database and the current period is within the validity period of the account in the preset database. The second determining unit is used to determine that the authentication of the IoT device has failed if the parsed password is inconsistent with the password corresponding to the account in the preset database, and / or the current period is not within the validity period of the account corresponding to the preset database.

[0072] Furthermore, the second authentication submodule includes: The second parsing unit is used to encapsulate the connection request into a request message, and to parse the request message by calling the authentication service through streaming communication, so as to obtain the account and password carried in the connection request in batches. The second judgment unit is used to batch judge whether the parsed password is consistent with the password corresponding to the account in the preset database, and whether the current period is within the validity period of the account in the preset database. The preset database stores accounts, passwords and validity periods corresponding to multiple IoT devices. The third determining unit is used to determine that the IoT device authentication is successful if the parsed password matches the password corresponding to the account in the preset database and the current period is within the validity period of the account in the preset database. The fourth determining unit is used to determine that the authentication of the IoT device has failed if the parsed password is inconsistent with the password corresponding to the account in the preset database, and / or the current period is not within the validity period of the account corresponding to the preset database.

[0073] Furthermore, the authentication module 403 also includes: The allow submodule is used to allow IoT devices to access the network when the authentication result is successful. The Reject submodule is used to deny IoT devices access when authentication fails.

[0074] Furthermore, the IoT device access device 400 also includes: The entry module is used to enter a fault degradation mode when the authentication service is determined to be unavailable. The fault degradation mode includes a whitelist mode and a blacklist mode. The whitelist mode only allows cached IoT devices to access the network, while the blacklist mode does not allow IoT devices to access the network.

[0075] It should be noted that the IoT device access device 400 can achieve the aforementioned Figure 1 The method embodiments shown provide IoT device access methods that can achieve the same technical effects, and will not be described in detail here.

[0076] See Figure 5 , Figure 5 A schematic diagram of another IoT device access device provided in this application embodiment. The IoT device access device 500 is applied to a scheduling server and includes: The second receiving module 501 is used to receive a scheduling request sent by at least one Internet of Things (IoT) device, wherein the IoT device corresponds one-to-one with the scheduling request, and the scheduling request carries the device identifier and device type corresponding to the IoT device. The determination module 502 is used to determine whether the IoT device is legitimate based on the device identifier and device type, and if the IoT device is legitimate, generate the Broker node address and authentication information corresponding to the IoT device. The return module 503 is used to return the Broker node address and authentication information to the IoT device, so that the IoT device can send a connection request to the Broker node corresponding to the Broker node address. This allows each Broker node to determine whether the authentication service is available through the authentication plugin. If the authentication service is available, the authentication service is used to authenticate the IoT device, and the authentication result determines whether the IoT device is allowed to access the network. The authentication service is a service independent of the Broker node, and the authentication plugin can access the authentication service by calling a preset interface.

[0077] Furthermore, the IoT device access device 500 also includes: The storage module is used to store authentication information in a preset database for use by the authentication service. The authentication information includes the account, password, and validity period corresponding to the IoT device.

[0078] It should be noted that the IoT device access device 500 can achieve the aforementioned Figure 2 The method embodiments shown provide IoT device access methods that can achieve the same technical effects, and will not be described in detail here.

[0079] See Figure 6 , Figure 6 This is a schematic diagram of an IoT device access system provided in an embodiment of this application. The IoT device access system includes a Broker cluster 601, a scheduling server 602, and at least one IoT device 603; The Broker cluster 601 comprises multiple distributed Broker nodes, each of which is used to execute the aforementioned implementation. Figure 1 The method embodiments shown provide IoT device access methods that can achieve the same technical effects, and will not be described in detail here.

[0080] IoT device 603 is connected to scheduling server 602, which is used to execute the aforementioned implementation. Figure 2 The method embodiments shown provide IoT device access methods that can achieve the same technical effects, and will not be described in detail here.

[0081] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the IoT device access method provided in any of the foregoing method embodiments.

[0082] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0083] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented using software plus a general-purpose hardware platform, or of course, using hardware. Based on this understanding, the above technical solutions, in essence or the parts that contribute to the related technology, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0084] It should be understood that the terminology used herein is for the purpose of describing particular exemplary embodiments only and is not intended to be limiting. Unless the context clearly indicates otherwise, the singular forms “a,” “an,” and “described” as used herein may also include the plural forms. The terms “comprising,” “including,” “containing,” and “having” are inclusive and therefore indicate the presence of the stated features, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, elements, components, and / or combinations thereof. The method steps, processes, and operations described herein are not construed as requiring them to be performed in a particular order described or illustrated unless the order of performance is explicitly indicated. It should also be understood that additional or alternative steps may be used.

[0085] The above description is merely a specific embodiment of this application, enabling those skilled in the art to understand or implement this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A method for accessing Internet of Things (IoT) devices, characterized in that, The method, applied to any Broker node in a Broker cluster, includes: Receive connection requests from at least one Internet of Things (IoT) device, wherein each IoT device corresponds to a connection request; The availability of the authentication service is determined by the authentication plugin, wherein the authentication service is a service independent of the Broker node, and the authentication plugin can access the authentication service by calling a preset interface. If the authentication service is found to be available, the authentication service is used to authenticate the IoT device, and the authentication result is used to determine whether the IoT device is allowed to access the network.

2. The method according to claim 1, characterized in that, The authentication of the IoT device using the authentication service includes: Determine whether the number of connection requests has reached a preset number; If the number of connection requests does not reach the preset number, the authentication service is used to authenticate the IoT devices sequentially. When the number of connection requests reaches the preset number, the authentication service is used to perform batch authentication of the IoT devices.

3. The method according to claim 2, characterized in that, The step of authenticating the IoT devices sequentially using the authentication service includes: The authentication service is used to parse the connection requests sequentially to obtain the account and password carried in the connection requests; The system sequentially determines whether the parsed password matches the password corresponding to the account in the preset database, and whether the current password is within the validity period of the account in the preset database. The preset database stores accounts, passwords, and validity periods corresponding to multiple IoT devices. If the parsed password matches the password corresponding to the account in the preset database, and the current period is within the validity period of the account in the preset database, the authentication of the IoT device is determined to be successful. If the parsed password does not match the password corresponding to the account in the preset database, and / or the current period is not within the validity period of the account corresponding to the preset database, the authentication of the IoT device is determined to have failed.

4. The method according to claim 2, characterized in that, The step of using the authentication service to perform batch authentication of the IoT devices includes: The connection request is encapsulated into a request message, and the authentication service is invoked through streaming communication to parse the request message and obtain the account and password carried in the connection request in batches. The system batch-determines whether the parsed passwords match the passwords corresponding to the accounts in the preset database, and whether the current passwords are within the validity period of the accounts in the preset database. The preset database stores accounts, passwords, and validity periods corresponding to multiple IoT devices. If the parsed password matches the password corresponding to the account in the preset database, and the current period is within the validity period of the account in the preset database, the authentication of the IoT device is determined to be successful. If the parsed password does not match the password corresponding to the account in the preset database, and / or the current period is not within the validity period of the account corresponding to the preset database, the authentication of the IoT device is determined to have failed.

5. The method according to claim 1, characterized in that, The step of determining whether to allow the IoT device to access the network based on the authentication result includes: If the authentication result is successful, the IoT device is allowed to access the network. If the authentication result is an authentication failure, the IoT device is denied access.

6. The method according to claim 1, characterized in that, The method further includes: If the authentication service is determined to be unavailable, a fault degradation mode is entered. The fault degradation mode includes a whitelist mode and a blacklist mode. The whitelist mode allows only cached IoT devices to access the network, while the blacklist mode does not allow IoT devices to access the network.

7. A method for connecting IoT devices, characterized in that, Applied to a scheduling server, the method includes: Receive a scheduling request sent by at least one Internet of Things (IoT) device, wherein the IoT device corresponds one-to-one with the scheduling request, and the scheduling request carries the device identifier and device type corresponding to the IoT device; Based on the device identifier and the device type, determine whether the IoT device is legitimate, and if the IoT device is legitimate, generate the Broker node address and authentication information corresponding to the IoT device. The Broker node address and the authentication information are returned to the IoT device so that the IoT device can send a connection request to the Broker node corresponding to the Broker node address. This allows each Broker node to determine whether the authentication service is available through the authentication plugin. If the authentication service is available, the authentication service is used to authenticate the IoT device, and the authentication result determines whether the IoT device is allowed to access the network. The authentication service is a service independent of the Broker node, and the authentication plugin can access the authentication service by calling a preset interface.

8. The method according to claim 7, characterized in that, After generating the Broker node address and authentication information corresponding to the IoT device, the method further includes: The authentication information is stored in a preset database for use by the authentication service. The authentication information includes the account, password, and validity period corresponding to the IoT device.

9. An Internet of Things (IoT) device access device, characterized in that, The device, applicable to any Broker node in a Broker cluster, comprises: The first receiving module is configured to receive connection requests sent by at least one Internet of Things (IoT) device, wherein each IoT device corresponds to a connection request. The verification module is used to determine whether the authentication service is available through the authentication plugin. The authentication service is a service independent of the Broker node, and the authentication plugin can access the authentication service by calling a preset interface. The authentication module is used to authenticate the IoT device using the authentication service when it is determined that the authentication service is available, and to determine whether to allow the IoT device to access the network based on the authentication result.

10. An Internet of Things (IoT) device access device, characterized in that, The device, applied to a scheduling server, includes: The second receiving module is used to receive a scheduling request sent by at least one Internet of Things (IoT) device, wherein the IoT device corresponds one-to-one with the scheduling request, and the scheduling request carries the device identifier and device type corresponding to the IoT device. The determination module is used to determine whether the IoT device is legitimate based on the device identifier and the device type, and if the IoT device is determined to be legitimate, generate the Broker node address and authentication information corresponding to the IoT device; The return module is used to return the Broker node address and the authentication information to the IoT device, so that the IoT device can send a connection request to the Broker node corresponding to the Broker node address. This allows each Broker node to determine whether the authentication service is available through the authentication plugin. If the authentication service is available, the authentication service is used to authenticate the IoT device, and the authentication result determines whether the IoT device is allowed to access the network. The authentication service is a service independent of the Broker node, and the authentication plugin can access the authentication service by calling a preset interface.

11. An Internet of Things (IoT) device access system, characterized in that, The system includes a Broker cluster, a scheduling server, and at least one Internet of Things (IoT) device. The Broker cluster includes multiple distributed Broker nodes, each of which is used to execute the IoT device access method according to any one of claims 1-6. The IoT device is connected to the scheduling server, and the scheduling server is used to execute the IoT device access method according to any one of claims 7-8.

12. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the IoT device access method according to any one of claims 1-6, or when it is executed, it implements the IoT device access method according to any one of claims 7-8.

Images