Single sign-on method, system and device for terminal equipment, equipment, product and medium

Abstract

The invention relates to the technical field of single sign-on, and provides a terminal equipment single sign-on method, system and device, equipment, a product and a medium. The method comprises the following steps: a service server receives a resource access request sent by terminal equipment; performing offline verification on the legality of the authentication server of the terminal equipment; under the condition that the legality verification of the authentication server is passed, offline verification is carried out on the legality of the terminal equipment; under the condition that the validity verification of the terminal equipment is passed, offline verification is carried out on the integrity of the service data; and returning a resource access result to the terminal equipment under the condition that the integrity verification of the service data is passed. The decentralized authentication chain architecture is adopted, and the service server does not depend on real-time online interaction with the authentication server, so that the single-point fault risk, the security risk and the architecture complexity can be effectively reduced, and the applicability in the resource-limited Internet of Things environment is improved.

Description

Technical Field

[0001] This application relates to the field of single sign-on technology, specifically to a single sign-on method, system, device, equipment, product, and medium for terminal devices. Background Technology

[0002] In IoT environments, single sign-on (SSO) is a common authentication mechanism used to simplify the authentication process for users across multiple systems or services. Traditional SSO typically relies on a centralized authentication server. After authenticating through the server, users receive a token for use in other systems. Typical implementations include centralized authentication schemes based on security assertion markup languages, the Kerberos protocol, or the OAuth2 framework, as well as self-contained token mechanisms based on JWT (JSON Web Token).

[0003] However, the above single sign-on implementation methods generally rely heavily on the central authentication server, which poses a high risk of single point of failure and security risks. In addition, the architecture is complex and has poor applicability in resource-constrained IoT environments. Summary of the Invention

[0004] This application provides a single sign-on method, system, device, equipment, product, and medium for terminal devices, which solves the technical problems that existing single sign-on implementations generally have a strong dependence on a central authentication server, resulting in high single point of failure and security risks, complex architecture, and poor applicability in resource-constrained IoT environments.

[0005] In a first aspect, embodiments of this application provide a single sign-on method for a terminal device, applied to a business server, comprising: Receive a resource access request sent by a terminal device; the resource access request carries the service data of the terminal device; Based on the resource access request, the legitimacy of the authentication server of the terminal device is verified offline. If the authentication server verifies the legitimacy of the terminal device, an offline verification is performed based on the resource access request. If the legitimacy verification of the terminal device is passed, the integrity of the business data is verified offline based on the resource access request; If the integrity verification of the business data passes, the resource access result is returned to the terminal device.

[0006] In one embodiment, the resource access request also carries an authentication data block of the terminal device, the authentication data block of the terminal device including the identifier of the authentication server; The offline verification of the legitimacy of the authentication server of the terminal device based on the resource access request includes: Based on the identifier of the authentication server, the authentication data block of the authentication server is retrieved from the local cache; the authentication data block of the authentication server includes the first signature of the authentication server by the primary authorization server. The first signature is verified based on the public key of the primary authorization server cached locally. If the first signature verification passes, the legitimacy verification of the authentication server is deemed successful.

[0007] In one embodiment, the authentication data block of the authentication server further includes the public key of the authentication server, and the authentication data block of the terminal device further includes a second signature of the authentication server on the terminal device; The offline verification of the legitimacy of the terminal device based on the resource access request includes: The second signature is verified offline based on the public key of the authentication server; If the second signature verification passes, the legitimacy verification of the terminal device is deemed successful.

[0008] In one embodiment, the authentication data block of the terminal device further includes the public key of the terminal device, and the resource access request also carries a third signature of the terminal device on the business data or the hash value of the business data; The offline verification of the integrity of the business data based on the resource access request includes: The third signature is verified offline based on the public key of the terminal device; If the third signature verification passes, the integrity verification of the business data is deemed successful.

[0009] In one embodiment, the resource access request also carries a single sign-on token generated locally by the terminal device; If the integrity verification of the business data passes, the step of returning a resource access result to the terminal device includes: If the integrity verification of the business data passes, the validity of the single sign-on token is verified offline. If the validity period of the single sign-on token is verified, the resource access result is returned to the terminal device.

[0010] In one embodiment, the single sign-on token comprises a one-time random number; The offline verification of the validity of the single sign-on token includes: In the one-time use mode of the single sign-on token, offline verification is performed to determine whether the one-time random number has not been used. If the one-time random number is not used, the validity period verification of the single sign-on token is determined to be successful.

[0011] In one embodiment, the single sign-on token includes a current timestamp; The offline verification of the validity of the single sign-on token includes: In the single sign-on token's limited-use mode, offline verification is performed to determine whether the current timestamp is within its validity period; If the current timestamp is within its validity period, the validity verification of the single sign-on token is deemed successful.

[0012] In one embodiment, the resource access request also carries the identifier of the authentication data block of the terminal device, and the authentication data block of the terminal device further includes the identifier of the terminal device; The offline verification of the legitimacy of the authentication server of the terminal device based on the resource access request includes: Offline verification of the identifier of the authentication data block of the terminal device, and whether the identifier of the terminal device exists in the locally cached list of abnormal identifiers; If neither the identifier of the authentication data block of the terminal device nor the identifier of the terminal device exists in the locally cached list of abnormal identifiers, the legitimacy of the authentication server of the terminal device is verified offline based on the resource access request.

[0013] In one embodiment, the list of anomaly identifiers is either actively retrieved from the authentication server or periodically pushed to the local cache by the authentication server. The list of anomaly identifiers is generated based on settings configured by the administrator in the management interface of the authentication server, or based on the authentication server's response to reported security events, or based on the authentication server's own security policies.

[0014] In one embodiment, it also includes: The authentication data block of the authentication server is verified and then cached locally; If the authentication information of the authentication data block of the authentication server changes or the authentication data block of the authentication server becomes invalid, the latest authentication data block of the authentication server is obtained, and the local cache is updated after the latest authentication data block is verified.

[0015] In one embodiment, caching the authentication data block of the authentication server locally after verification includes: The first signature is verified based on the public key of the primary authorization server cached locally. If the first signature verification passes, the authentication data block of the authentication server is cached locally.

[0016] Secondly, embodiments of this application provide a single sign-on method for a terminal device, applied to a terminal device, including: Send a resource access request to the business server; the resource access request carries its own business data; Receive the resource access results returned by the service server; The resource access request is used by the business server to perform offline verification of the legitimacy of the authentication server of the terminal device, the legitimacy of the terminal device, and the integrity of the business data in sequence.

[0017] In one embodiment, before sending the resource access request to the business server, the following steps are included: Send an authentication request to the authentication server; Receive the authentication data block returned by the authentication server and obtain its own authentication data block; Generate a single sign-on token locally based on its own identifier, current timestamp, and a one-time random number; Sign the business data itself or the hash value of the business data to obtain a third signature; The single sign-on token is signed to obtain a fourth signature; The authentication data block, the identifier of the authentication data block, the business data, the third signature, the single sign-on token, and the fourth signature are encapsulated into a message for the resource access request.

[0018] Thirdly, embodiments of this application provide a single sign-on system for terminal devices, including: a business server, a terminal device, and an authentication server; The service server is used for: Receive a resource access request sent by the terminal device; the resource access request carries the service data of the terminal device; Based on the resource access request, the legitimacy of the authentication server of the terminal device is verified offline; If the authentication server verifies the legitimacy of the terminal device, an offline verification is performed based on the resource access request. If the legitimacy verification of the terminal device is passed, the integrity of the business data is verified offline based on the resource access request; If the integrity verification of the business data passes, a resource access result is returned to the terminal device; The terminal device is used for: Send a resource access request to the business server; Receive the resource access results returned by the business server.

[0019] In one embodiment, it further includes: a primary authorization server; The main authorization server is used for: Receive authentication requests sent by the authentication server; Based on the authentication request, an authentication data block for the authentication server is generated; Return the authentication data block of the authentication server to the authentication server.

[0020] Fourthly, embodiments of this application provide a single sign-on device for a terminal device, comprising: The resource access request receiving module is configured to: receive a resource access request sent by a terminal device; the resource access request carries the service data of the terminal device; The authentication server offline verification module is used to: perform offline verification of the legitimacy of the authentication server of the terminal device based on the resource access request; The terminal device offline verification module is used to: perform offline verification of the legitimacy of the terminal device based on the resource access request, provided that the legitimacy verification by the authentication server is successful; The business data offline verification module is used to: perform offline verification of the integrity of the business data based on the resource access request, provided that the legality verification of the terminal device is passed; The resource access result return module is used to: return the resource access result to the terminal device if the integrity verification of the business data passes.

[0021] Fifthly, embodiments of this application provide a single sign-on device for a terminal device, comprising: The resource access request sending module is used to: send a resource access request to the business server; the resource access request carries its own business data. The resource access result receiving module is used to: receive the resource access result returned by the business server; The resource access request is used by the business server to perform offline verification of the legitimacy of the authentication server of the terminal device, the legitimacy of the terminal device, and the integrity of the business data in sequence.

[0022] Sixthly, embodiments of this application provide a terminal device, including a memory, a transceiver, and a processor; A memory for storing computer programs; a transceiver for sending and receiving data under the control of the processor; and a processor for reading the computer programs from the memory and performing the following operations: Send a resource access request to the business server; the resource access request carries its own business data; Receive the resource access results returned by the service server; The resource access request is used by the business server to perform offline verification of the legitimacy of the authentication server of the terminal device, the legitimacy of the terminal device, and the integrity of the business data in sequence.

[0023] In a seventh aspect, embodiments of this application provide an electronic device, including a processor and a memory storing a computer program, wherein the processor executes the program to implement the steps of the single sign-on method for terminal devices described in the first or second aspect.

[0024] Eighthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the steps of the single sign-on method for terminal devices described in the first or second aspect.

[0025] In a ninth aspect, embodiments of this application provide a non-transitory computer-readable storage medium, including a computer program, which, when executed by a processor, implements the steps of the single sign-on method for terminal devices described in the first or second aspect.

[0026] The single sign-on method, system, device, equipment, product, and medium provided in this application involve a business server receiving a resource access request from a terminal device. This resource access request carries the terminal device's business data. Based on the resource access request, the server performs offline verification of the legitimacy of the terminal device's authentication server. If the authentication server's legitimacy verification passes, the server performs offline verification of the terminal device's legitimacy based on the resource access request. If the terminal device's legitimacy verification passes, the server performs offline verification of the integrity of the business data based on the resource access request. If the business data integrity verification passes, the server returns the resource access result to the terminal device. This application adopts a decentralized authentication chain architecture. The business server does not rely on real-time online interaction with the authentication server. On the one hand, the business server can independently perform step-by-step offline verification of the authentication server's legitimacy, the terminal device's legitimacy, and the business data's integrity, effectively reducing the risk of single point of failure and architectural complexity. This allows business between the terminal device and the business server to continue normally even in resource-constrained IoT environments. On the other hand, due to the three-level verification method (authentication server, terminal device, and business data), failure at any level will result in single sign-on failure, effectively reducing security risks. In summary, this application adopts a decentralized authentication chain architecture, in which the business server does not rely on real-time online interaction with the authentication server, thereby effectively reducing the risk of single point of failure, security risks and architectural complexity, and improving its applicability in resource-constrained IoT environments. Attached Figure Description

[0027] To more clearly illustrate the technical solutions in 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, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0028] Figure 1 This is one of the flowcharts illustrating the single sign-on method for terminal devices provided in the embodiments of this application; Figure 2 This is a second flowchart illustrating the single sign-on method for terminal devices provided in this application embodiment; Figure 3 This is the third flowchart illustrating the single sign-on method for terminal devices provided in this application embodiment; Figure 4 This is the fourth flowchart illustrating the single sign-on method for terminal devices provided in this application embodiment; Figure 5 This is the fifth flowchart illustrating the single sign-on method for terminal devices provided in this application embodiment; Figure 6This is the sixth flowchart illustrating the single sign-on method for terminal devices provided in this application embodiment; Figure 7 This is a schematic diagram of the interaction process under the exception identifier list mechanism provided in the embodiments of this application; Figure 8 This is a schematic diagram of the interaction process under the authentication caching mechanism provided in the embodiments of this application; Figure 9 This is the seventh flowchart illustrating the single sign-on method for terminal devices provided in this application embodiment; Figure 10 This is the eighth flowchart illustrating the single sign-on method for terminal devices provided in this application embodiment; Figure 11 This is a schematic diagram of the architecture of the single sign-on system for terminal devices provided in the embodiments of this application; Figure 12 This is a schematic diagram of the interaction process for single sign-on on a terminal device provided in an embodiment of this application; Figure 13 This is one of the structural schematic diagrams of the single sign-on device for terminal equipment provided in the embodiments of this application; Figure 14 This is a second schematic diagram of the single sign-on device for terminal equipment provided in the embodiments of this application; Figure 15 This is a schematic diagram of the structure of a terminal device according to an embodiment of this application; Figure 16 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0029] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below with reference to the accompanying drawings of the embodiments. 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.

[0030] Figure 1 This is one of the flowcharts illustrating the single sign-on method for terminal devices provided in this application. (Refer to...) Figure 1 This application provides a single sign-on method for a terminal device, applied to a business server, which may include: Step 101: Receive resource access requests sent by the terminal device; Resource access requests carry business data from the terminal device; Step 102: Based on the resource access request, perform offline verification of the legitimacy of the authentication server of the terminal device; Step 103: If the authentication server verifies the legitimacy of the terminal device, perform offline verification based on the resource access request. Step 104: If the terminal device passes the legality verification, perform offline verification of the integrity of the business data based on the resource access request; Step 105: If the integrity verification of the business data passes, return the resource access result to the terminal device.

[0031] In step 101, the resource access request is sent in the form of a message, and the terminal device's business data is encapsulated in the message.

[0032] In step 102, the legitimacy of the authentication server of the terminal device is verified offline based on the information in the resource access request message. Since the terminal device has been authenticated by its corresponding authentication server, but if the authentication server itself is untrustworthy, even if the terminal device has been authenticated by the authentication server, it is impossible to determine whether the terminal device is trustworthy. Therefore, it is necessary to verify the legitimacy of the authentication server first. In this verification process, the business server does not rely on real-time online interaction with the authentication server and can complete the process offline.

[0033] In step 103, the legitimacy of the terminal device is verified offline based on the information in the resource access request message. Since the business data of the terminal device has been authenticated by the terminal device, but if the terminal device itself is untrustworthy, even if the business data has been authenticated by the terminal device, it is impossible to determine whether the business data is trustworthy. Therefore, it is necessary to further verify the legitimacy of the terminal device. In this verification process, the business server does not rely on real-time online interaction with the authentication server and can complete the process offline.

[0034] In step 104, the integrity of the business data is verified offline based on the information in the resource access request message. Even after the terminal device is determined to be trustworthy, it is still impossible to determine whether the business data has been tampered with during transmission. Therefore, it is necessary to further verify the integrity of the business data. In this verification process, the business server does not rely on real-time online interaction with the authentication server and can complete the verification in an offline state.

[0035] In step 105, the resource access result is returned to the terminal device only if the legitimacy of the authentication server, the legitimacy of the terminal device, and the integrity of the business data are all verified. If any verification fails, the resource access request of the terminal device is rejected, and the single sign-on of the terminal device fails.

[0036] The single sign-on method for terminal devices provided in this embodiment involves a business server receiving a resource access request from a terminal device. This request carries the terminal device's business data. Based on the resource access request, the server performs offline verification of the legitimacy of the terminal device's authentication server. If the authentication server's legitimacy verification passes, the server performs offline verification of the terminal device's legitimacy based on the resource access request. If the terminal device's legitimacy verification passes, the server performs offline verification of the integrity of the business data based on the resource access request. If the integrity verification of the business data passes, the server returns the resource access result to the terminal device. This embodiment employs a decentralized authentication chain architecture. The business server does not rely on real-time online interaction with the authentication server. On one hand, the business server can independently perform step-by-step offline verification of the authentication server's legitimacy, the terminal device's legitimacy, and the business data's integrity, effectively reducing the risk of single point of failure and architectural complexity. This ensures that business communication between the terminal device and the business server can continue normally even in resource-constrained IoT environments. On the other hand, due to the three-level verification method involving the authentication server, terminal device, and business data, failure at any level will result in single sign-on failure, effectively reducing security risks. In summary, this embodiment adopts a decentralized authentication chain architecture, where the business server does not rely on real-time online interaction with the authentication server. This effectively reduces the risk of single point of failure, security risks, and architectural complexity, and improves its applicability in resource-constrained IoT environments.

[0037] Figure 2 This is the second flowchart illustrating the single sign-on method for terminal devices provided in this application. (Refer to...) Figure 2 In one embodiment, the resource access request also carries an authentication data block of the terminal device, which includes the identifier of the authentication server; step 102 may include: Step 201: Based on the identifier of the authentication server, retrieve the authentication data block of the authentication server from the local cache; The authentication data block of the authentication server includes the first signature of the authentication server by the primary authorizing server; Step 202: Verify the first signature based on the public key of the primary authorization server cached locally; Step 203: If the first signature verification passes, confirm that the authentication server's legitimacy verification has passed.

[0038] In step 201, the authentication data block of the terminal device is encapsulated in the resource access request message. The authentication data block of the terminal device is generated by the authentication server after signing and authenticating the terminal device using its own private key, and then sent to the terminal device. It includes the issuer field of the authentication server, from which the identifier of the authentication server can be obtained. The business server has pre-cached the authentication data block of the authentication server locally, so it can obtain the authentication data block of the authentication server from the local cache according to the identifier of the authentication server. Furthermore, the authentication data block of the authentication server is generated by the primary authorizing server after signing and authenticating the authentication server using its own private key, and then sent to the authentication server. It includes the primary authorizing server's first signature on the authentication server.

[0039] In steps 202 to 203, the business server has pre-cached the public key of the main authorization server locally. Therefore, it can use the locally cached public key of the main authorization server to verify the authenticity of the first signature. If the verification is successful, it can be determined that the authentication server is a legitimate entity certified by the main authorization server, that is, the authentication server is trustworthy.

[0040] In this embodiment, the business server pre-caches the public key of the main authorization server and the authentication data block of the authentication server locally. Upon receiving the authentication data block of the terminal device sent by the terminal device, and considering that the authentication data block of the terminal device is generated by the authentication server using its own private key to sign and authenticate the terminal device, the authentication data block of the terminal device includes the identifier of the authentication server. The authentication data block of the authentication server is generated by the main authorization server using its own private key to sign and authenticate the authentication server, and therefore includes the first signature of the main authorization server. Thus, the authentication data block of the authentication server can be obtained locally based on the identifier of the authentication server, and then the first signature of the main authorization server can be obtained from it. The authenticity of the first signature is then verified using the public key of the main authorization server cached locally to confirm whether the authentication server is a legitimate entity certified by the main authorization server. That is, the business server does not rely on real-time online interaction with the authentication server and can complete the verification of the legitimacy of the authentication server in an offline state.

[0041] Figure 3 This is the third flowchart illustrating the single sign-on method for terminal devices provided in this application. (Refer to...) Figure 3 In one embodiment, the authentication data block of the authentication server further includes the public key of the authentication server, and the authentication data block of the terminal device further includes a second signature of the authentication server on the terminal device; step 103 may include: Step 301: Verify the second signature offline based on the public key of the authentication server; Step 302: If the second signature verification is successful, the legitimacy verification of the terminal device is confirmed to be successful.

[0042] As mentioned earlier, the authentication data block of the terminal device is generated by the authentication server after signing and authenticating the terminal device using its own private key, and then sent to the terminal device. Therefore, it also includes the authentication server's second signature on the terminal device. Thus, the authenticity of the second signature can be verified offline using the authentication server's public key in the authentication data block. If the verification is successful, it can be determined that the terminal device is a legitimate entity certified by the authentication server, that is, the terminal device is trustworthy.

[0043] In this embodiment, the authentication data block of the terminal device is generated by the authentication server using its own private key to sign and authenticate the terminal device. Therefore, the authentication data block of the terminal device includes the second signature of the authentication server on the terminal device. Thus, the public key of the authentication server can be obtained from the authentication data block of the authentication server, and the authenticity of the second signature can be verified offline using the public key to confirm whether the terminal device is a legitimate entity certified by the authentication server. That is, the business server does not rely on real-time online interaction with the authentication server and can complete the verification of whether the terminal device is legitimate in an offline state.

[0044] Figure 4 This is the fourth flowchart illustrating the single sign-on method for terminal devices provided in this application. (Refer to...) Figure 4 In one embodiment, the authentication data block of the terminal device further includes the public key of the terminal device, and the resource access request also carries a third signature of the terminal device on the business data or the hash value of the business data; step 104 may include: Step 401: Verify the third signature offline based on the public key of the terminal device; Step 402: If the third signature verification is successful, the integrity verification of the business data is confirmed to be successful.

[0045] The terminal device will use its own private key to sign the business data or its hash value. The resulting third signature will also be encapsulated in the resource access request message. Therefore, the authenticity of the third signature can be verified offline using the terminal device's public key in the terminal device's authentication data block. If the verification is successful, it can be determined that the business data was indeed sent by the terminal device and that the business data was not tampered with during transmission.

[0046] In this embodiment, the business data or hash value of the terminal device is signed with the private key of the terminal device, and the resulting third signature is sent to the business server along with the resource access request. Therefore, the business server can obtain the public key of the terminal device from the authentication data block of the terminal device, and use the public key to verify the authenticity of the third signature offline to confirm whether the business data was sent by the terminal device and whether it was tampered with during transmission. That is, the business server does not rely on real-time online interaction with the authentication server and can complete the verification of whether the business data is complete in an offline state.

[0047] Figure 5 This is the fifth flowchart illustrating the single sign-on method for terminal devices provided in this application. (Refer to...) Figure 5 In one embodiment, the resource access request also carries a single sign-on token generated locally on the terminal device; step 105 may include: Step 501: After the integrity verification of the business data passes, verify the validity of the single sign-on token offline; Step 502: If the validity period of the single sign-on token is verified, return the resource access result to the terminal device.

[0048] The single sign-on token is encapsulated in the resource access request message. This token includes two usage modes, and step 501 specifically includes: 1. Single sign-on tokens include a one-time random number; In the one-time use mode of single sign-on tokens, offline verification is performed to determine whether the one-time random number has not been used. If the one-time random number has not been used, the validity verification of the single sign-on token is confirmed to be successful.

[0049] In one-time use mode, a single sign-on token is only valid for its first use after generation. Once it is used for a successful authentication, the application server will immediately mark the single sign-on token as used, and subsequent requests will not be able to use the single sign-on token again. Therefore, during this authentication, it is necessary to verify offline whether the single sign-on token is being used for the first time. Since the one-time random number is different for each authentication, it can be determined whether the single sign-on token is being used for the first time by verifying offline whether the one-time random number in the single sign-on token has not been used. If the one-time random number in the single sign-on token has not been used, it can be determined that the single sign-on token is being used for the first time, that is, the single sign-on token is valid.

[0050] This mode is suitable for scenarios with extremely high security requirements, ensuring that each single sign-on token can only be used once, preventing the single sign-on token from being reused, and avoiding replay attacks.

[0051] 2. The single sign-on token includes the current timestamp; In the limited-use mode of single sign-on tokens, the system offline verifies whether the current timestamp is within the validity period. If the current timestamp is within the validity period, the validity verification of the single sign-on token is confirmed to be successful.

[0052] In the limited-use mode, a single sign-on token is assigned a specific validity period upon generation. As long as the token is valid, the terminal device can use it multiple times for authentication. The application server checks the token's validity period each time it is authenticated to ensure it hasn't expired. Therefore, during this authentication, offline verification of the token's validity is required. Since the current timestamp effectively represents the token's time status, its validity can be determined by verifying whether the current timestamp is within the validity period. If the current timestamp is within the validity period, the token is valid.

[0053] This mode is suitable for scenarios where resources need to be accessed multiple times within a certain period of time, providing greater flexibility and convenience.

[0054] It should be noted that the terminal device can also use its own private key to sign the single sign-on token and then encapsulate the resulting fourth signature in the resource access request message and send it to the business server. In the one-time use mode of the single sign-on token, the business server can use the terminal device's public key to verify the authenticity of the fourth signature offline, and then verify offline whether the one-time random number has not been used. In the time-limited use mode of the single sign-on token, in order to prevent replay supply, the authenticity of the fourth signature can be not verified offline, and the current timestamp can be directly verified offline to see if it is within the time limit.

[0055] In step 502, if the single sign-on token is found to be valid, a resource access result is returned to the terminal device; otherwise, if the single sign-on token is found to be invalid in any mode, the resource access request of the terminal device is rejected, and the single sign-on of the terminal device fails.

[0056] This embodiment designs two usage modes for single sign-on tokens to adapt to scenarios with extremely high security requirements and scenarios that require multiple accesses to resources within a certain period of time, respectively. Based on this, a one-time random number and the current timestamp are added to the single sign-on token structure, so that the single sign-on token can be verified offline in a timely manner in any single sign-on scenario. Only when the verification is successful will the resource access result be returned to the terminal device, further reducing the security risks of single sign-on.

[0057] Figure 6This is the sixth flowchart illustrating the single sign-on method for terminal devices provided in this application. (Refer to...) Figure 6 In one embodiment, the resource access request also carries an identifier of the terminal device's authentication data block, which further includes the identifier of the terminal device; step 101 may include: Step 601: Offline verification of the identifier of the authentication data block of the terminal device, and whether the identifier of the terminal device exists in the local cache of abnormal identifiers; Step 602: If neither the identifier of the authentication data block of the terminal device nor the identifier of the terminal device exists in the local cached list of abnormal identifiers, perform offline verification of the legitimacy of the authentication server of the terminal device based on the resource access request.

[0058] The identifier of the terminal device's authentication data block is encapsulated in the resource access request message. Before offline verification of the legitimacy of the terminal device's authentication server, it can be determined whether the identifier of the terminal device's authentication data block and the identifier of the terminal device exist in the locally cached list of abnormal identifiers. If either identifier exists in the list of abnormal identifiers, the resource access request of the terminal device is immediately rejected, and the single sign-on of the terminal device fails. Only when neither the identifier of the terminal device's authentication data block nor the identifier of the terminal device exists in the list of abnormal identifiers will the subsequent offline verification steps be executed.

[0059] This embodiment introduces an anomaly identifier list, which dynamically identifies and blocks access to invalid or revoked terminal devices and their authentication data blocks by using the identifiers of the terminal devices and their authentication data blocks, thereby preventing potential security threats and further reducing the security risks of single sign-on.

[0060] In one embodiment, the list of exception identifiers is either actively retrieved from the authentication server or periodically pushed to the local cache by the authentication server. This list of anomaly identifiers is generated based on settings configured by the administrator in the authentication server's management interface, or based on the authentication server's response to reported security events, or based on the authentication server's own security policies.

[0061] In this embodiment, the anomaly identifier list mainly includes the identifier of the terminal device, the identifier of the authentication data block of the terminal device, the reason for the anomaly of the relevant identifier, and the timestamp of the relevant identifier being added to the list. This list is generated and maintained by the authentication server and mainly comes from three sources: The first method is based on administrator settings: Administrators manually add the identifiers of specific terminal devices to the abnormal identifier list through the management interface provided by the authentication server (such as a web management portal, command-line tools, or API interfaces). This is typically applicable to explicit device deregistration commands, such as when an employee leaves the company, and the administrator manually adds the identifiers of their issued IoT terminal devices (such as smart work cards or business tablets) to the abnormal identifier list; or when a batch of terminal device hardware is scrapped due to malfunction, and the administrator batch enters the identifiers of these terminal devices on the management interface and adds them to the abnormal identifier list.

[0062] The second method is response generation based on security events reported by the business server: The authentication server automatically generates an anomaly identifier list based on the security events reported by the business server. For example, if a business server detects multiple abnormal accesses or attacks from the same terminal device within a short period of time, it can report the suspicious situation of the terminal device to the authentication server through an internal interface. After receiving the report, the authentication server can automatically add the terminal device's identifier to the anomaly identifier list according to a preset policy (such as "automatically add to the anomaly identifier list after receiving 3 reports").

[0063] The third method is based on the authentication server's own security policy: The authentication server automatically generates an anomaly identifier list according to the system's configured security policy. For example, if the authentication server detects that the authentication data block of a certain terminal device has expired, or according to its security policy (such as the terminal device failing to authenticate multiple times consecutively), it automatically adds the identifier of the terminal device's authentication data block and / or the identifier of the terminal device to the anomaly identifier list.

[0064] Furthermore, after the authentication server generates or updates the list of anomaly identifiers, it periodically (e.g., every hour) pushes the incremental and updated information of the anomaly identifier list to all associated business servers. Simultaneously, the business servers proactively pull the latest full list of anomaly identifiers from the authentication server upon startup. This "push-pull" mechanism ensures that business servers receive the latest anomaly identifier information in a timely manner, and even if a push is missed, it will be synchronized upon startup or the next retrieval.

[0065] It should be noted that the abnormal identifier list can be pre-cached to the local business server after it is generated to enable offline verification of the relevant identifiers. However, if the multi-source generation and push-pull management mechanism of the abnormal identifier list is required in a closed network environment, the authentication server must be deployed in this closed network environment to ensure that the generation and management functions of the abnormal identifier list are available.

[0066] Furthermore, referring to Figure 7 Briefly describe the interaction process under the exception identifier list mechanism: During the generation and updating of the anomaly identifier list: 1. The administrator sets up an anomaly flag list on the authentication server side; 2. The business server reports the list of abnormal identifiers to the authentication server; 3. The authentication server generates or updates the list of abnormal identifiers; During the distribution and synchronization phase of the anomaly identifier list: 4. The authentication server distributes the list of abnormal identifiers to the business server periodically or on demand. Depending on the specific configuration, the authentication server can periodically push the list of abnormal identifiers, or the business server can actively pull the list of abnormal identifiers. 5. The business server caches the list of exception identifiers locally; During the anomaly flag list check phase: 6. The terminal device sends a resource access request to the service server; 7. The business server checks whether the identifier of the terminal device and the identifier of the authentication data block of the terminal device carried in the resource access request are in the list of abnormal identifiers; 8. If any identifier is in the abnormal identifier list, the service server will reject the terminal device's resource access request and return an error message to the terminal device; 9. If neither of the two identifiers is in the list of abnormal identifiers, the business server will proceed to the subsequent verification process normally. 10. If all subsequent verifications pass, the business server returns the resource access result to the terminal device.

[0067] This embodiment introduces a fine-grained anomaly flag list mechanism, supporting multiple methods such as manual commands from administrators, reports from business servers, or automatic triggering by system policies. This allows the revocation of a specific terminal device or its authentication data block to be quickly synchronized to all business servers. Furthermore, the scalability of traditional centralized architectures is limited by the performance bottleneck of the central authentication server, resulting in weak dynamic management capabilities. This embodiment can horizontally scale by adding authentication servers to manage terminal devices in different regions or of different types, thereby providing more flexible and timely security management capabilities. It can quickly respond to security threats and effectively address the needs of the rapidly growing number of IoT terminal devices.

[0068] In one embodiment, it also includes: The authentication data block of the authentication server is verified and then cached locally; If the authentication information in the authentication data block of the authentication server changes or the authentication data block of the authentication server becomes invalid, the latest authentication data block of the authentication server is obtained, and the local cache is updated after the latest authentication data block is verified.

[0069] The process of verifying the authentication data block from the authentication server and caching it locally can include: The first signature is verified based on the public key of the primary authorization server cached locally. If the first signature is verified, the authentication data block of the authentication server is cached locally.

[0070] This embodiment introduces an authentication caching mechanism, which allows the business server to cache authentication data blocks from the authentication server, the public key of the primary authorization server, and an anomaly identifier list locally. This avoids real-time interaction with the authentication server when verifying resource access requests from terminal devices, enabling rapid offline verification. The mechanism mainly includes the following steps: 1. Initial distribution and caching of authentication data blocks: The business server pre-caches the public key of the primary authorization server and, upon going online, proactively sends a request to the authentication server, or the authentication server proactively pushes its authentication data block to it. The business server receives, verifies, and caches these authentication data blocks. Specifically, the business server verifies the authentication data block by using the locally cached public key of the primary authorization server to verify the authenticity of the signature in the authentication data block. This ensures the validity of the authentication data block itself, and the information in the authentication data block can then be used to verify subsequent resource access requests from terminal devices.

[0071] 2. Updating and redistributing authentication data blocks: When the authentication information on the authentication server changes (e.g., key pair rotation, expiration and re-signing of authentication data blocks), the authentication server, upon obtaining the latest authentication data block, will proactively push it to the application server. After receiving and verifying the latest authentication data block, the application server updates its local cache, replacing the old authentication data block, ensuring that subsequent verifications use the latest and most valid trust chain root.

[0072] 3. Cache verification: When a terminal device sends a resource access request to the business server, the business server executes a subsequent three-level verification process based on the verified authentication data block from the authentication server stored in its local cache. If all three levels of verification pass, the business server returns the resource access result to the terminal device. This process is completed entirely locally on the business server and does not require real-time communication with the authentication server.

[0073] 4. Cache invalidation handling: The business server checks the validity period of the cached authentication data block. If it finds that the data block is about to expire, it will proactively request the latest authentication data block from the authentication server, verify it, and then update the cache. If the cached authentication data block is found to be invalid during the third-level verification (such as signature verification failure or expiration), the business server can request the latest authentication data block from the authentication server again, verify it, update the cache, and then process the resource access request from the terminal device, or directly reject the resource access request and return an error message.

[0074] Reference Figure 8 Briefly describe the interaction process under the authentication caching mechanism: 1. The authentication server sends the authentication data block to the business server; 2. The business server caches the authentication data block after verifying it; 3. The terminal device sends a resource access request to the service server; 4. The business server checks whether the authentication data block in the local cache is valid; 5. If the authentication data block is valid, the business server will execute the subsequent three-level verification process based on the authentication data block; 6. If all three levels of verification pass, the business server returns the resource access result to the terminal device; 7. If the authentication data block expires, the business server requests the latest authentication data block from the authentication server; 8. The authentication server sends the latest authentication data block to the business server; 9. The business server re-verifies the latest authentication data block and then updates the cache; 10. Execute the subsequent three-level verification process based on this latest certified data block; 11. If all three levels of verification pass, the business server returns the resource access result to the terminal device.

[0075] This embodiment employs an authentication caching mechanism, enabling the business server to pre-cachate authentication data blocks from the authentication server, the public key of the primary authorization server, and the list of abnormal identifiers. Furthermore, it verifies the cached authentication data blocks during caching to ensure their validity. This allows the business server to perform subsequent three-level verifications based on the pre-verified valid authentication data blocks without real-time interaction with the authentication server. This ensures verification security while significantly reducing network communication overhead, achieving an efficient verification process. Compared to traditional single sign-on processes, this embodiment significantly reduces verification latency, network bandwidth consumption, and server computational load, enabling efficient operation in IoT environments where computing power, storage space, and power supply are limited.

[0076] Figure 9This is the seventh flowchart illustrating the single sign-on method for terminal devices provided in this application. (Refer to...) Figure 9 This application provides a single sign-on method for a terminal device, which is applied to a terminal device and may include: Step 901: Send a resource access request to the business server; Resource access requests carry their own business data; Step 902: Receive the resource access results returned by the business server.

[0077] Resource access requests are used by the business server to perform offline verification of the legitimacy of the authentication server of the terminal device, the legitimacy of the terminal device, and the integrity of the business data in sequence.

[0078] The single sign-on method for terminal devices provided in this embodiment adopts a decentralized authentication chain architecture. During the process of the terminal device sending a resource access request to the business server and receiving a resource access request returned by the business server, the business server does not rely on real-time online interaction with the authentication server. It can independently perform step-by-step offline verification of the authentication server's legitimacy, the terminal device's legitimacy, and the integrity of the business data, effectively reducing the risk of single point of failure and architectural complexity. This allows business between the terminal device and the business server to continue normally even in resource-constrained IoT environments. Furthermore, due to the three-level verification method involving the authentication server, terminal device, and business data, failure at any level will result in single sign-on failure for the terminal device, effectively reducing security risks. In summary, this embodiment adopts a decentralized authentication chain architecture, where the business server does not rely on real-time online interaction with the authentication server, thereby effectively reducing the risk of single point of failure, security risks, and architectural complexity, and improving applicability in resource-constrained IoT environments.

[0079] Figure 10 This is the eighth flowchart illustrating the single sign-on method for terminal devices provided in this application. (Refer to...) Figure 10 In one embodiment, prior to step 901, the following may be included: Step 1001: Send an authentication request to the authentication server; Step 1002: Receive the authentication data block returned by the authentication server and obtain your own authentication data block; Step 1003: Generate a single sign-on token locally based on its own identifier, current timestamp, and a one-time random number; Step 1004: Sign your own business data or the hash value of your business data to obtain a third signature; Step 1005: Sign the single sign-on token to obtain the fourth signature; Step 1006: Encapsulate the self-authentication data block, the identifier of the self-authentication data block, the business data, the third signature, the single sign-on token, and the fourth signature into a resource access request message.

[0080] In step 1001, when the terminal device performs its first single sign-on or the authentication data block expires, the terminal device sends an authentication request to the authentication server. The authentication request may carry the terminal device's identifier, the terminal device's public key, etc., where the terminal device's identifier may be a device identity identifier or a device serial number.

[0081] In step 1002, after verifying the identity and permissions of the terminal device based on the terminal device's identifier, the authentication server uses its own private key to perform authentication signature on the terminal device's public key and other information to obtain a second signature, and then generates the terminal device's authentication data block. The terminal device's authentication data block includes the terminal device's public key, the terminal device's identifier, the second signature, the validity period of the authentication data block, etc. After that, the authentication server sends the terminal device's authentication data block to the terminal device.

[0082] Furthermore, the authentication server can also add the identifier of the authentication data block of the terminal device or the identifier of the terminal device to the list of valid identifiers. If the terminal device or its authentication data block is revoked, the relevant identifier will be added to the list of abnormal identifiers.

[0083] In step 1003, the terminal device can generate a single sign-on token locally based on the following formula: Token = Base64(SM3(DevSN + AppId + t0 + Nonce)); Among them, DevSN is the device serial number of the terminal device, AppId is the device identity identifier of the terminal device, t0 is the current timestamp, and Nonce is a one-time random number. After encrypting the above information using the SM3 encryption algorithm, the encrypted information is then encoded using the Base64 encoding algorithm to obtain the single sign-on token.

[0084] In steps 1004 and 1005, the terminal device uses its own private key to sign its own business data or the hash value of the business data and the single sign-on token respectively, to obtain the third signature and the fourth signature.

[0085] In step 1006, the terminal device encapsulates its own authentication data block, its own authentication data block identifier, business data, third signature, single sign-on token, and fourth signature into a resource access request message.

[0086] In this embodiment, a single sign-on token is generated locally by the terminal device and signed. This token contains only the minimum information required for verification and is completely separated from the specific business data. It is protected by an independent digital signature. Compared with traditional tokens, which are a coupling of verification information and business data, once intercepted, the business data is easily tampered with for replay attacks and may also lead to the leakage of sensitive business data, the token in this embodiment decouples the verification information from the business data. Even if the token is intercepted, attackers cannot obtain or tamper with sensitive business data, which greatly reduces the attack surface and improves the overall security.

[0087] Figure 11 This is a schematic diagram of the architecture of a single sign-on system for terminal devices provided in an embodiment of this application. (Refer to...) Figure 11 This application provides a single sign-on system for terminal devices, which may include: a business server, a terminal device, and an authentication server; Business server, used for: Receive resource access requests sent by terminal devices; the resource access requests carry the service data of the terminal devices; Based on resource access requests, the legitimacy of the authentication server of the terminal device is verified offline. If the authentication server verifies the legitimacy of the terminal device, offline verification is performed based on the resource access request. If the terminal device passes the legitimacy verification, the integrity of the business data is verified offline based on the resource access request; If the integrity verification of the business data passes, the resource access result is returned to the terminal device; Terminal equipment, used for: Send a resource access request to the business server; Receive resource access results returned by the business server.

[0088] Furthermore, the system may also include: a main authorization server; The primary authorization server is used for: Receive authentication requests sent by the authentication server; Based on the authentication request, generate the authentication data block for the authentication server; Return the authentication data block from the authentication server to the authentication server.

[0089] Reference Figure 11 The following is a detailed description of each part of the system: Primary Authorization Server: Located at the top level of the architecture, it is the root of trust in the system.

[0090] Authentication servers: Multiple servers are connected to the main authorization server and receive authentication server certificates issued by it. These certificates can be traditional certificates or simplified authentication data blocks in this embodiment.

[0091] Business servers: Multiple, each associated with one or more authentication servers.

[0092] Terminal devices: Multiple, belonging to a specific authentication server, and capable of initiating access to multiple business servers.

[0093] Entity Relationships and Interactions: 1. A primary authorization server is responsible for authenticating all authentication servers in the system.

[0094] 2. One authentication server is responsible for authenticating multiple terminal devices belonging to it.

[0095] 3. Once a terminal device is authenticated, it can access resources provided by multiple business servers.

[0096] 4. A business server can receive access requests from terminal devices authenticated by multiple authentication servers. The business server needs to obtain and cache the authentication data blocks of these authentication servers and the public key of the main authorization server in advance from its associated authentication server or through the main authorization server to verify the legitimacy of the terminal device's resource access request.

[0097] Furthermore, the responsibilities of each part of the system are as follows: The primary authorizing server holds the system's master key pair and serves as the system's trust anchor. It is responsible for signing the authentication server's public key, generating and distributing authentication data blocks (containing the authentication server's public key, the block's validity period, and the primary authorizing server's signature) to verify the legitimacy of the authentication server and terminal devices. The primary authorizing server does not directly participate in the daily authentication process of terminal devices, thus achieving decentralization.

[0098] The authentication server holds its own asymmetric key pair and authentication data blocks signed by the primary authorization server. It is responsible for receiving and processing authentication requests from terminal devices. Based on business logic (such as device identity identifier AppID, device serial number DevSN, etc.), it authenticates the terminal devices, signs the public key of authenticated terminal devices, and generates and distributes the authentication data blocks for the terminal devices (containing the terminal device's public key, the validity period of the authentication data block, the authentication server's signature, etc.). The authentication server is also responsible for generating and managing anomaly identifier lists and distributing these lists to associated business servers periodically or as needed.

[0099] Business Server: Responsible for providing access to resources to authenticated terminal devices. It pre-caches authentication data blocks from its trusted authentication servers, the public key of the primary authorization server, and the latest list of exception identifiers. When it receives a resource access request from a terminal device, the business server does not directly interact with the authentication server or the primary authorization server in real time. Instead, it uses the locally cached information to independently verify the legitimacy of the authentication server, the legitimacy of the terminal device, and the integrity of the business data.

[0100] Terminal device: It holds its own asymmetric key pair and an authentication data block issued by the authentication server. When it needs to access business server resources, it signs the business data using its own private key and sends its own authentication data block, its own authentication data block identifier, the business data, the terminal device's signature on the business data, a single sign-on token, and the terminal device's signature on the single sign-on token to the business server for verification.

[0101] Reference Figure 12 Briefly describe the interaction process of single sign-on on terminal devices: During the system initialization phase: 1. The primary authorizing server distributes its public key to the authentication server; 2. The primary authorization server distributes its public key to the business servers; During the authentication phase on the authentication server: 3. The authentication server sends an authentication request to the primary authorization server, which includes the authentication server's public key, etc. 4. The primary authorizing server signs the authentication server's public key using its own private key, generates the authentication data block for the authentication server, and returns the authentication data block to the authentication server. The authentication data block includes the signature of the primary authorizing server. During the terminal device certification stage: 5. The terminal device sends an authentication request to the authentication server. This request includes the device serial number (DevSN), the terminal device's public key, and the device identity identifier (AppID). 6. After the authentication server signs the public key of the terminal device with its own private key, it generates the authentication data block of the terminal device and returns the authentication data block to the terminal device. The authentication data block includes the signature of the authentication server. 7. The terminal device generates and saves the single sign-on token locally; The stage of terminal device accessing business server resources: 8. The terminal device sends a resource access request to the business server; the request carries the terminal device's business data, single sign-on token, etc. 9. The business server performs an anomaly flag list check; 10. The business server uses the public key of the primary authorization server to verify the signature in the authentication data block of the authentication server; 11. The business server uses the authentication server's public key to verify the signature in the authentication data block of the terminal device; 12. The business server uses the public key of the terminal device to verify the signature of the business data; 13. If all the above verifications pass, the business server returns the resource access result to the terminal device; 14. If any of the above verifications fails, the business server will reject the resource access request from the terminal device and return an error message to the terminal device.

[0102] The authentication data blocks of the authentication server and the terminal device only include the most concise and essential fields (such as public key, validity period, and signature), rather than traditional heavy certificates, which can further reduce verification latency and improve verification efficiency. At the same time, the business server can also cache, check for expiration, and update the authentication data blocks based on the validity period field.

[0103] Traditional single sign-on processes heavily rely on a central authentication server. All authentication must be performed through the central authentication server. If the central authentication server fails or there are network problems, the entire system will not function properly. The system structure is highly complex, requiring the establishment of complex communication mechanisms to ensure the validity of tokens. The security risks are high, as the central authentication server stores a large amount of authentication information from terminal devices. If attacked, it may lead to the leakage of terminal device information.

[0104] This embodiment, through the above process, implements a decentralized, lightweight single sign-on mechanism in an IoT environment that can operate in closed network environments lacking a primary authorization server and authentication server. Even if the primary authorization server or authentication server goes offline due to maintenance, network partitioning, or attacks, business between the authenticated terminal device and the business server can still proceed normally, ensuring the security and efficiency of the verification process. It also meets the independent operation requirements of the business server without external authentication server support, making it particularly suitable for IoT environments with unstable or closed networks, and greatly improving system reliability and business continuity.

[0105] Furthermore, this embodiment employs a three-level chained signature verification: the business server must verify the certificate chain signature of "main authorization server → authentication server → terminal device" step by step, that is, verify the "legitimacy of the authentication server → legitimacy of the terminal device → integrity of the business data" step by step. The invalidation of the signature at any link will lead to verification failure, thus constructing a robust integrity protection defense.

[0106] The single sign-on device for terminal devices provided in the embodiments of this application are described below. The single sign-on device for terminal devices described below can be referred to in correspondence with the single sign-on method for terminal devices described above.

[0107] Figure 13 This is one of the structural schematic diagrams of the single sign-on device for terminal equipment provided in the embodiments of this application. (Refer to...) Figure 13 This application provides a single sign-on device for a terminal device, which may include: The resource access request receiving module 1301 is configured to: receive a resource access request sent by a terminal device; the resource access request carries the service data of the terminal device; The authentication server offline verification module 1302 is used to: perform offline verification of the legitimacy of the authentication server of the terminal device based on the resource access request; The terminal device offline verification module 1303 is used to: perform offline verification of the legitimacy of the terminal device based on the resource access request, provided that the legitimacy verification by the authentication server is successful; The business data offline verification module 1304 is used to: perform offline verification of the integrity of the business data based on the resource access request, provided that the legality verification of the terminal device is passed; The resource access result return module 1305 is used to: return the resource access result to the terminal device if the integrity verification of the business data passes.

[0108] Figure 14 This is the second structural schematic diagram of the single sign-on device for terminal equipment provided in this application embodiment. (Refer to...) Figure 14 This application provides a single sign-on device for a terminal device, which may include: The resource access request sending module 1401 is used to: send a resource access request to the business server; the resource access request carries its own business data. The resource access result receiving module 1402 is used to: receive the resource access result returned by the business server; The resource access request is used by the business server to perform offline verification of the legitimacy of the authentication server of the terminal device, the legitimacy of the terminal device, and the integrity of the business data in sequence.

[0109] The terminal device involved in the embodiments of this application may be a device that provides voice and / or data connectivity to a user, a handheld device with wireless connectivity, or other processing devices connected to a wireless modem. The name of the terminal device may differ in different systems; for example, in a 5G system, the terminal device may be called User Equipment (UE).

[0110] Figure 15 This is a schematic diagram of the structure of a terminal device according to an embodiment of this application, with reference to... Figure 15 This application embodiment also provides a terminal device, which may include: a memory 1510, a transceiver 1520 and a processor 1530; The memory 1510 is used to store computer programs; the transceiver 1520 is used to send and receive data under the control of the processor 1530; the processor 1530 is used to read the computer program in the memory 1510 and perform the following operations: Send a resource access request to the business server; the resource access request carries its own business data; Receive the resource access results returned by the service server; The resource access request is used by the business server to perform offline verification of the legitimacy of the authentication server of the terminal device, the legitimacy of the terminal device, and the integrity of the business data in sequence.

[0111] Among them, Figure 15 In this context, the bus architecture can include any number of interconnected buses and bridges, specifically linking various circuits together, such as one or more processors represented by processor 1530 and memory represented by memory 1510. The bus architecture can also link together various other circuits, such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. The bus interface provides an interface. Transceiver 1520 can be multiple elements, including transmitters and receivers, providing a unit for communicating with various other devices over a transmission medium. For different user equipment, user interface 1540 can also be an interface capable of connecting external or internal devices as needed.

[0112] Processor 1530 is responsible for managing the bus architecture and general processing, while memory 1510 can store data used by processor 1530 when performing operations.

[0113] The processor 1530 executes any of the methods described in the embodiments of this application by calling a computer program stored in the memory 1510, according to the obtained executable instructions. The processor and the memory may also be physically separated.

[0114] Figure 16 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application, such as... Figure 16 As shown, the electronic device may include: a processor 1610, a communication interface 1620, a memory 1630, and a communication bus 1640, wherein the processor 1610, the communication interface 1620, and the memory 1630 communicate with each other via the communication bus 1640. The processor 1610 can call a computer program in the memory 1630 to execute the steps of the single sign-on method for the terminal device, such as including: Receive a resource access request sent by a terminal device; the resource access request carries the service data of the terminal device; Based on the resource access request, the legitimacy of the authentication server of the terminal device is verified offline. If the authentication server verifies the legitimacy of the terminal device, an offline verification is performed based on the resource access request. If the legitimacy verification of the terminal device is passed, the integrity of the business data is verified offline based on the resource access request; If the integrity verification of the business data passes, a resource access result is returned to the terminal device; or Send a resource access request to the business server; the resource access request carries its own business data; Receive the resource access results returned by the service server; The resource access request is used by the business server to perform offline verification of the legitimacy of the authentication server of the terminal device, the legitimacy of the terminal device, and the integrity of the business data in sequence.

[0115] Furthermore, the logical instructions in the aforementioned memory 1630 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0116] On the other hand, this application also provides a computer program product, which includes a computer program that can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can perform the steps of the single sign-on method for terminal devices provided in the above embodiments, such as including: Receive a resource access request sent by a terminal device; the resource access request carries the service data of the terminal device; Based on the resource access request, the legitimacy of the authentication server of the terminal device is verified offline. If the authentication server verifies the legitimacy of the terminal device, an offline verification is performed based on the resource access request. If the legitimacy verification of the terminal device is passed, the integrity of the business data is verified offline based on the resource access request; If the integrity verification of the business data passes, a resource access result is returned to the terminal device; or Send a resource access request to the business server; the resource access request carries its own business data; Receive the resource access results returned by the service server; The resource access request is used by the business server to perform offline verification of the legitimacy of the authentication server of the terminal device, the legitimacy of the terminal device, and the integrity of the business data in sequence.

[0117] On the other hand, embodiments of this application also provide a non-transitory computer-readable storage medium storing a computer program thereon, the computer program being used to cause a processor to execute the steps of the single sign-on method for terminal devices provided in the above embodiments, for example including: Receive a resource access request sent by a terminal device; the resource access request carries the service data of the terminal device; Based on the resource access request, the legitimacy of the authentication server of the terminal device is verified offline. If the authentication server verifies the legitimacy of the terminal device, an offline verification is performed based on the resource access request. If the legitimacy verification of the terminal device is passed, the integrity of the business data is verified offline based on the resource access request; If the integrity verification of the business data passes, a resource access result is returned to the terminal device; or Send a resource access request to the business server; the resource access request carries its own business data; Receive the resource access results returned by the service server; The resource access request is used by the business server to perform offline verification of the legitimacy of the authentication server of the terminal device, the legitimacy of the terminal device, and the integrity of the business data in sequence.

[0118] The non-transitory computer-readable storage medium can be any available medium or data storage device that the processor can access, including but not limited to magnetic memory (e.g., floppy disk, hard disk, magnetic tape, magneto-optical disk (MO)), optical memory (e.g., CD, DVD, BD, HVD), and semiconductor memory (e.g., ROM, EPROM, EEPROM, non-volatile memory (NAND FLASH), solid-state drive (SSD)).

[0119] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. 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. Those skilled in the art can understand and implement this without any creative effort.

[0120] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, 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.

[0121] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A single sign-on method for a terminal device, characterized in that, Applied to business servers, including: Receive a resource access request sent by a terminal device; the resource access request carries the service data of the terminal device; Based on the resource access request, the legitimacy of the authentication server of the terminal device is verified offline. If the authentication server verifies the legitimacy of the terminal device, the legitimacy of the terminal device is verified offline based on the resource access request. If the legitimacy verification of the terminal device is passed, the integrity of the business data is verified offline based on the resource access request; If the integrity verification of the business data passes, the resource access result is returned to the terminal device.

2. The single sign-on method for terminal devices according to claim 1, characterized in that, The resource access request also carries the authentication data block of the terminal device, and the authentication data block of the terminal device includes the identifier of the authentication server; The offline verification of the legitimacy of the authentication server of the terminal device based on the resource access request includes: Based on the identifier of the authentication server, the authentication data block of the authentication server is retrieved from the local cache; the authentication data block of the authentication server includes the first signature of the authentication server by the primary authorization server. The first signature is verified based on the public key of the primary authorization server cached locally. If the first signature verification passes, the legitimacy verification of the authentication server is deemed successful.

3. The single sign-on method for terminal devices according to claim 2, characterized in that, The authentication data block of the authentication server also includes the public key of the authentication server, and the authentication data block of the terminal device also includes the second signature of the authentication server on the terminal device; The offline verification of the legitimacy of the terminal device based on the resource access request includes: The second signature is verified offline based on the public key of the authentication server; If the second signature verification passes, the legitimacy verification of the terminal device is deemed successful.

4. The single sign-on method for terminal devices according to claim 2, characterized in that, The authentication data block of the terminal device also includes the public key of the terminal device, and the resource access request also carries the third signature of the terminal device on the business data or the hash value of the business data. The offline verification of the integrity of the business data based on the resource access request includes: The third signature is verified offline based on the public key of the terminal device; If the third signature verification passes, the integrity verification of the business data is deemed successful.

5. The single sign-on method for terminal devices according to claim 1, characterized in that, The resource access request also carries a single sign-on token generated locally on the terminal device. If the integrity verification of the business data passes, the step of returning a resource access result to the terminal device includes: If the integrity verification of the business data passes, the validity of the single sign-on token is verified offline. If the validity period of the single sign-on token is verified, the resource access result is returned to the terminal device.

6. The single sign-on method for terminal devices according to claim 5, characterized in that, The single sign-on token includes a one-time random number; The offline verification of the validity of the single sign-on token includes: In the one-time use mode of the single sign-on token, offline verification is performed to determine whether the one-time random number has not been used. If the one-time random number is not used, the validity period verification of the single sign-on token is determined to be successful.

7. The single sign-on method for terminal devices according to claim 5, characterized in that, The single sign-on token includes the current timestamp; The offline verification of the validity of the single sign-on token includes: In the single sign-on token's limited-use mode, offline verification is performed to determine whether the current timestamp is within its validity period; If the current timestamp is within its validity period, the validity verification of the single sign-on token is deemed successful.

8. The single sign-on method for terminal devices according to claim 2, characterized in that, The resource access request also carries the identifier of the authentication data block of the terminal device, and the authentication data block of the terminal device further includes the identifier of the terminal device; The offline verification of the legitimacy of the authentication server of the terminal device based on the resource access request includes: Offline verification of the identifier of the authentication data block of the terminal device, and whether the identifier of the terminal device exists in the locally cached list of abnormal identifiers; If neither the identifier of the authentication data block of the terminal device nor the identifier of the terminal device exists in the locally cached list of abnormal identifiers, the legitimacy of the authentication server of the terminal device is verified offline based on the resource access request.

9. The single sign-on method for terminal devices according to claim 8, characterized in that, The list of anomaly identifiers is either actively retrieved from the authentication server or periodically pushed to the local cache by the authentication server. The list of anomaly identifiers is generated based on settings configured by the administrator in the management interface of the authentication server, or based on the authentication server's response to reported security events, or based on the authentication server's own security policies.

10. The single sign-on method for terminal devices according to claim 2, characterized in that, Also includes: The authentication data block of the authentication server is verified and then cached locally; If the authentication information of the authentication data block of the authentication server changes or the authentication data block of the authentication server becomes invalid, the latest authentication data block of the authentication server is obtained, and the local cache is updated after the latest authentication data block is verified.

11. The single sign-on method for terminal devices according to claim 10, characterized in that, The step of verifying the authentication data block of the authentication server and caching it locally includes: The first signature is verified based on the public key of the primary authorization server cached locally. If the first signature verification passes, the authentication data block of the authentication server is cached locally.

12. A single sign-on method for a terminal device, characterized in that, Applied to terminal devices, including: Send a resource access request to the business server; the resource access request carries its own business data; Receive the resource access results returned by the service server; The resource access request is used by the business server to perform offline verification of the legitimacy of the authentication server of the terminal device, the legitimacy of the terminal device, and the integrity of the business data in sequence.

13. The single sign-on method for terminal devices according to claim 12, characterized in that, Before sending the resource access request to the business server, the following steps are included: Send an authentication request to the authentication server; Receive the authentication data block returned by the authentication server and obtain its own authentication data block; Generate a single sign-on token locally based on its own identifier, current timestamp, and a one-time random number; Sign the business data itself or the hash value of the business data to obtain a third signature; The single sign-on token is signed to obtain a fourth signature; The authentication data block, the identifier of the authentication data block, the business data, the third signature, the single sign-on token, and the fourth signature are encapsulated into a message for the resource access request.

14. A single sign-on system for terminal devices, characterized in that, include: Business servers, terminal devices, and authentication servers; The service server is used for: Receive resource access requests sent by the terminal device; The resource access request carries the service data of the terminal device. Based on the resource access request, the legitimacy of the authentication server of the terminal device is verified offline; If the authentication server verifies the legitimacy of the terminal device, the legitimacy of the terminal device is verified offline based on the resource access request. If the legitimacy verification of the terminal device is passed, the integrity of the business data is verified offline based on the resource access request; If the integrity verification of the business data passes, a resource access result is returned to the terminal device; The terminal device is used for: Send a resource access request to the business server; Receive the resource access results returned by the business server.

15. The single sign-on system for terminal devices according to claim 14, characterized in that, Also includes: Main authorization server; The main authorization server is used for: Receive authentication requests sent by the authentication server; Based on the authentication request, an authentication data block for the authentication server is generated; Return the authentication data block of the authentication server to the authentication server.

16. A single sign-on device for a terminal device, characterized in that, include: The resource access request receiving module is used to: receive resource access requests sent by terminal devices; The resource access request carries the service data of the terminal device. The authentication server offline verification module is used to: perform offline verification of the legitimacy of the authentication server of the terminal device based on the resource access request; The terminal device offline verification module is used to: perform offline verification of the legitimacy of the terminal device based on the resource access request, provided that the legitimacy verification by the authentication server is successful; The business data offline verification module is used to: perform offline verification of the integrity of the business data based on the resource access request, provided that the legality verification of the terminal device is passed; The resource access result return module is used to: return the resource access result to the terminal device if the integrity verification of the business data passes.

17. A single sign-on device for a terminal device, characterized in that, include: The resource access request sending module is used to send resource access requests to the business server. The resource access request carries its own business data; The resource access result receiving module is used to: receive the resource access result returned by the business server; The resource access request is used by the business server to perform offline verification of the legitimacy of the authentication server of the terminal device, the legitimacy of the terminal device, and the integrity of the business data in sequence.

18. A terminal device, characterized in that, Includes memory, transceiver, and processor; A memory for storing computer programs; a transceiver for sending and receiving data under the control of the processor; and a processor for reading the computer programs from the memory and performing the following operations: Send a resource access request to the business server; the resource access request carries its own business data; Receive the resource access results returned by the service server; The resource access request is used by the business server to perform offline verification of the legitimacy of the authentication server of the terminal device, the legitimacy of the terminal device, and the integrity of the business data in sequence.

19. An electronic device comprising a processor and a memory storing a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the single sign-on method for terminal devices according to any one of claims 1 to 11, or implements the steps of the single sign-on method for terminal devices according to any one of claims 12 to 13.

20. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the single sign-on method for terminal devices according to any one of claims 1 to 11, or implements the steps of the single sign-on method for terminal devices according to any one of claims 12 to 13.

21. A non-transitory 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 steps of the single sign-on method for terminal devices according to any one of claims 1 to 11, or implements the steps of the single sign-on method for terminal devices according to any one of claims 12 to 13.

Images