Equipment login method, equipment login device, electronic equipment and medium
By introducing a dual-token mechanism into smart home devices, setting tokens with different validity periods and combining them with risk assessment, the problem of smart scene interruption caused by the fixed validity period of a single token is solved, achieving seamless renewal and improved security.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- GREE ELECTRIC APPLIANCE INC OF ZHUHAI
- Filing Date
- 2025-12-25
- Publication Date
- 2026-05-01
AI Technical Summary
Existing smart home applications use a single token or simple session cookie authentication mechanism, which results in a fixed token validity period. After the token expires, users need to re-enter their account password, which can easily interrupt the continuous operation of the smart scene.
A dual-token mechanism is adopted, which sets first token information and second token information. The first token has a short validity period and is used for business interface authentication, while the second token has a long validity period and is used to refresh the first token. The two tokens are combined to execute business, and the tokens are dynamically updated according to the risk level.
It enables the elimination of frequent manual logins in smart home devices, ensuring the continuous operation of smart scenarios, improving user experience, and enhancing security through dynamic risk assessment to avoid the problem of single token expiration.
Smart Images
Figure CN121966946A_ABST
Abstract
Description
Device login method, device login device, electronic equipment and media Technical Field
[0001] This application belongs to the field of device login technology, specifically relating to a device login method, a device login apparatus, an electronic device, and a readable storage medium. Background Technology
[0002] Existing smart home applications generally use single token or simple session cookie authentication mechanisms, which have obvious drawbacks. Single tokens have a fixed validity period, and users need to re-enter their account password after they expire, which can easily interrupt the continuous operation of smart scenarios. Summary of the Invention
[0003] The purpose of this application is to provide a device login method, a device login device, an electronic device, and a readable storage medium, which can solve the problem that a single token has a fixed validity period and is prone to interrupting the operation of smart scenarios.
[0004] To address the aforementioned technical problems, this application provides the following: Firstly, embodiments of this application offer a device login method, comprising: responding to a login event triggered by a first device, acquiring login information of a target account entered by a target user in the login interface of the first device; after successful authentication based on the login information, acquiring first token information and second token information of the first device, wherein a first validity period of the first token information is shorter than a second validity period of the second token information, and the second token information is used to refresh the first token information within the second validity period; responding to a service request initiated in the first device, executing a target service in the first device according to the service request based on the first validity period and the second validity period.
[0005] Optionally, the step of responding to a service request initiated in the first device and executing the target service in the first device according to the service request based on the first validity period and the second validity period includes: responding to a service request initiated by the first device and determining whether the first token information is valid based on the first validity period; if the first token information is determined to be valid based on the first validity period, executing the target service corresponding to the service request; if the first token information is determined to be invalid based on the first validity period, then requesting to refresh the first token information based on the second token information within the second validity period; if the second token information successfully refreshes the first token information, then updating the first token information stored in the client based on the refreshed first token information.
[0006] Optionally, it further includes: when the second token information expires, performing a risk assessment on the first device to determine the risk level of the first device; and updating the first token information and / or the second token information according to the risk level.
[0007] Optionally, updating the first token information and / or the second token information according to the risk level includes: when the risk level is the first risk level, redirecting to the login interface to update the first token information and / or the second token information by logging in again.
[0008] Optionally, updating the first token information and / or the second token information according to the risk level includes: verifying the first device when the risk level is the second risk level; obtaining reissued first token information and second token information when the verification is successful; and redirecting to the login interface when the verification fails, so as to update the first token information and / or the second token information by logging in again.
[0009] Optionally, the method further includes: obtaining real-time login location information and historical login location information of the first device; performing a risk assessment on the first device based on the real-time login information and the historical login information to obtain a risk level; and updating the first token information and / or the second token information according to the risk level.
[0010] Optionally, it also includes: when a second device is detected to be logged into the target account, adding the second token information to a preset revocation list.
[0011] Optionally, it further includes: in response to the first device logging out of the target account, adding the second token information to a preset revocation list.
[0012] Optionally, the method further includes: when the first device is in a network interruption state, obtaining the target instruction to be executed from the local cache; determining the instruction type of the target instruction; when the instruction type is a preset non-sensitive instruction, continuing to execute the target instruction; when the instruction type is a preset sensitive instruction, performing password verification on the target account, and executing the target instruction when the password verification is successful.
[0013] Secondly, embodiments of this application provide a device login apparatus, the apparatus comprising: a login information acquisition module, configured to acquire login information of a target account entered by a target user in the login interface of the first device in response to a login event triggered by a first device; a token information acquisition module, configured to acquire first token information and second token information of the first device after successful authentication based on the login information, wherein the validity period of the first token information is shorter than the validity period of the second token information, and the second token information is used to refresh the first token information within the validity period; and a service execution module, configured to execute a target service in the first device according to the service request based on the validity periods of the first token information and the second token information in response to a service request initiated in the first device.
[0014] Thirdly, embodiments of this application provide an electronic device including a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the method described in the first aspect.
[0015] Fourthly, embodiments of this application provide a readable storage medium on which a program or instructions are stored, which, when executed by a processor, implement the steps of the method described in the first aspect.
[0016] Fifthly, embodiments of this application provide a chip, the chip including a processor and a communication interface, the communication interface being coupled to the processor, the processor being used to run programs or instructions to implement the method as described in the first aspect.
[0017] In this embodiment of the application, when logging into the device, a first token and a second token with different validity periods are set, and the second token with a long validity period can refresh the set of the first token within its validity period. The business is executed by combining the two tokens, thereby avoiding the problem of the execution scenario running out due to the interruption of the validity period of the existing single token. Attached Figure Description
[0018] Figure 1 is a flowchart of a device login method according to an embodiment of this application; Figure 2 is a flowchart of another device login method according to an embodiment of this application; Figure 3a is a flowchart of another device login method according to an embodiment of this application; Figure 3b is a flowchart of another device login method according to an embodiment of this application; Figure 4 is a flowchart of a device login method according to an embodiment of this application; Figure 5 is a schematic diagram of the structure of an electronic device according to an embodiment of this application. Detailed Implementation
[0019] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0020] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.
[0021] The device login provided in this application embodiment will be described in detail below with reference to the accompanying drawings, through specific embodiments and application scenarios.
[0022] Referring to Figure 1, a flowchart of a device login method according to an embodiment of this application is shown, which may include the following steps: Step S101, in response to a login event triggered by a first device, obtain the login information of the target account entered by the target user in the login interface of the first device; In this embodiment of the application, smart home devices can use dual token login. To realize smart home device login, a system architecture of client layer, gateway layer and cloud can be constructed. The client layer directly provides interactive services to customers, such as providing a login interface for applications used to control smart home devices; the gateway layer can realize data transmission, unified authentication and other functions; the cloud can provide cloud storage of user account, password and token related data, and can also set up a distributed revocation list, etc.
[0023] In practical applications, when a target user triggers a preset login event on the first device, a login interface can be displayed on the client. The target user can then input login information for their target account on the login interface. The client can then obtain the corresponding login information, such as login account information and password information, based on the target user's input, so as to realize login verification based on the login information.
[0024] In this application embodiment, the login event is a preset event that can trigger a re-login. For example, the login event may include, but is not limited to: (1) the first device logs in for the first time; (2) if the second device is logged in first and then the first device is used to log in, the login event will be triggered; (3) when the target user logs out of the target account and logs in again or switches from another account to the target account, the login event will be triggered.
[0025] Step S102: After successful authentication based on the login information, the first token information and the second token information of the first device are obtained. The first validity period of the first token information is shorter than the second validity period of the second token information, and the second token information is used to refresh the first token information within the second validity period. After obtaining the login information, the client layer can perform account authentication based on the login information to determine whether the login information is matching information of a previously registered account.
[0026] Specifically, the login information can be matched with the registered accounts stored in the client. If a matching target account is stored, the authentication is considered successful; otherwise, the authentication is considered to have failed.
[0027] Upon successful login authentication, the first token and second temporary token information of the first device can be obtained. The first token information can be used for access authentication. It has a short validity period (e.g., 30 minutes) and can be used for business interface authentication. It must be included in every request, meaning that the first token information can be used to verify whether execution is possible each time a business request is initiated. The second token information can be used to refresh the first token information. It has a longer validity period (e.g., 30 days) and is only used to exchange for a new Access-Token (i.e., the first token information). It does not directly participate in business requests. During the validity period of the second token information, the first token information can be automatically refreshed, thus eliminating the need for repeated logins during business execution and preventing business interruptions.
[0028] In one embodiment of this application, the client can obtain the first token information and the second token information issued by the system from the cloud.
[0029] Step S103: In response to the service request initiated in the first device, execute the target service in the first device according to the service request based on the first validity period and the second validity period.
[0030] When a service request is initiated in the first device, the client can execute the target service according to the service request by verifying the first validity period of the first token information and the second validity period of the second token information.
[0031] First, the validity of the token information is determined based on the current time and the first and second token information. Then, the target business is executed according to the business request based on the validity determination result. A processing flow can be pre-set based on different determination results. This processing flow needs to consider both the business execution logic and device security.
[0032] For example, user A logs into a smart home app on phone A. The system issues two tokens (i.e., a first token and a second token) (the first token, Access-Token, is valid for 30 minutes, and the second token, Refresh-Token, is valid for 30 days). Over the next 28 days, if user A does not manually log out, the Access-Token is automatically refreshed a total of 1344 times via Refresh-Token. During this period, the user does not need to enter a password, and smart scenes (such as timed light switching and temperature control) continue to run uninterrupted.
[0033] In this embodiment, a dual-Token lifecycle management system is adopted. By exchanging a Refresh-Token for an Access-Token when the Token expires, the problem of the app being forced to exit when the token expires is solved. This allows users to automatically and seamlessly renew their accounts, providing a more user-friendly experience.
[0034] In one embodiment of this application, the step of responding to a service request initiated in the first device and executing a target service in the first device according to the service request based on the first validity period and the second validity period includes: responding to a service request initiated by the first device and determining whether the first token information is valid based on the first validity period; if the first token information is determined to be valid based on the first validity period, executing the target service corresponding to the service request; if the first token information is determined to be invalid based on the first validity period, then requesting to refresh the first token information based on the second token information within the second validity period; if the second token information successfully refreshes the first token information, then updating the first token information stored in the client based on the refreshed first token information.
[0035] In practical applications, the validity of the first token can be determined based on its first expiration date. If the first token is valid, the target service corresponding to the business request can be executed immediately. If the first token is invalid, it needs to be refreshed. This refresh requires a request based on a valid second token. Specifically, the validity of the second token can be determined based on its second expiration date. When the second token successfully refreshes the first token, the refreshed first token can be stored, and then the target service corresponding to the business request can be executed based on the refreshed first token.
[0036] In one embodiment of this application, when the second token information expires, a risk assessment can be performed on the first device to determine the risk level of the first device; and the first token information and / or the second token information can be updated according to the risk level.
[0037] In practical applications, the client can determine the validity of the second token information based on its expiration date and the current time. When the second token information expires, i.e., the current information is not within its validity period, in order to ensure the security of the first device, a risk assessment of the first device is required to determine the current environmental risk level of the first device. Then, the corresponding first and second token information can be updated according to different risk levels.
[0038] Specifically, the update methods for the first and second token information are pre-set under different risk levels. Therefore, after determining the risk level, the corresponding update method can be used to update the first and second token information.
[0039] In one embodiment of this application, updating the first token information and / or the second token information according to the risk level includes: when the risk level is the first risk level, redirecting to the login interface to update the first token information and / or the second token information by logging in again.
[0040] In practical applications, the first risk level can be a high risk level. When the current first device is determined to be a high risk level, it can directly jump to the login interface to manually enter the password to log in. During the re-login process, it can be executed again to obtain the first token information and the second token information of the first device after successful authentication based on the login information.
[0041] In one embodiment of this application, updating the first token information and / or the second token information according to the risk level includes: verifying the first device when the risk level is the second risk level; obtaining reissued first token information and second token information when the verification is successful; and redirecting to the login interface when the verification fails, so as to update the first token information and / or the second token information by logging in again.
[0042] In practical applications, the second risk level can be a medium risk level. Under the second risk level, the first device can be verified, such as through biometric or gesture recognition verification.
[0043] Upon successful verification, the cloud can be notified to issue a first token and a second token, updating both. The updated first and second tokens are then used to execute business requests. During this process, the user does not need to re-enter their login information to log in again.
[0044] In one embodiment of this application, in the step of "the system issues a new "Refresh-Token" after the user passes the test", the cloud will immediately execute the following complete process to ensure that the new token is both secure and can seamlessly connect to subsequent automatic renewal: 1. Secondary verification: The risk engine re-verifies whether the credentials (such as fingerprint / face one-time signature) that were just passed by local biometrics are consistent with the current session ID and device fingerprint to prevent "false pass" replay.
[0045] 2. Generate a new token pair: Using an encrypted random number, timestamp, and device ID as a seed, generate a brand new Refresh-Token (which can only be decrypted on the server side). At the same time, generate a corresponding new Access-Token, which remains valid for 30 minutes and contains a new "token version number".
[0046] 3. Binding and Archiving: Add a new record to the "Token Fingerprint Table": userId New Refresh-Token Hash Device fingerprint This risk assessment Issuance time Version number.
[0047] The old Refresh-Token (if still alive) is immediately written to the CRL and marked "replaced by the new token", ensuring that the same user has at most one valid long token.
[0048] 4. Key Rotation: If the risk level triggered this time is ≥ "Medium", the server will synchronously rotate the "refresh key" dedicated to this device (used for subsequent Refresh-Token signature verification). The old key is retained for a grace period of 5 minutes to prevent concurrent request failures.
[0049] 5. Secure issuance: New token pairs are returned via HTTPS + TLS 1.3 channel, with a one-time "encapsulated random number" appended to the response header. The client SDK must verify the signature using the locally stored public key before decrypting and storing the token, thus preventing man-in-the-middle substitution.
[0050] 6. Client-side atomic write: After receiving the data, the SDK first writes it to a temporary cache → verifies the signature and device fingerprint → confirms that there are no errors before overwriting the old token in the Keychain / Keystore and immediately deletes the plaintext of the old token in memory, thus achieving "verification before switching". Even if the App crashes at this time, no residue will be left.
[0051] 7. Cloud Event Push: Push-Service sends a lightweight notification that "token has been refreshed" to other online devices under the same account, along with the new version number. If the version number is outdated when the old device makes the next request, it will receive a 409 conflict error and be forced to exit, thus completing the "silent account top-up".
[0052] Through the above seven steps, the new Refresh-Token completes issuance, binding, old token revocation, and key rotation within 2 seconds, ensuring both security isolation and allowing users to continue enjoying the automatic renewal experience without their awareness.
[0053] In one embodiment of this application, when the risk level is the third risk level, the first token information can be refreshed, and then the target service can be executed.
[0054] In this embodiment, the cloud can dynamically issue a "risk level" based on changes in IP address, geographic location, and device environment, and then implement differentiated strategies according to the risk level: Low risk: Token refresh is completed silently, without the user's awareness. Medium risk: Local biometric verification is required, and a new Refresh-Token is issued upon successful verification. High risk: Manual login (account and password + secondary verification) is mandatory.
[0055] The above solution can solve the problem of not being able to dynamically trigger secondary verification based on the risk of the login environment, and only being able to dynamically switch between security and convenience, thus further eliminating security risks.
[0056] In one embodiment of this application, when the second device is detected to be logged into the target account, the second token information can be added to a preset revocation list.
[0057] In practical applications, to ensure device security, when a second device logs into the target account, the cloud detects the new device login and can add the second token information in the first device to a preset revocation list, and can also clear the first token information and second token information in the first device.
[0058] The Token Revocation List (CRL) is a centrally managed token blacklist that can be queried by all authentication nodes (such as gateways and microservices). When multiple service instances or data centers need to synchronize their revocation status, the CRL can achieve second-level synchronization through distributed storage (such as Redis or databases), ensuring that all nodes can recognize the revoked tokens. After a token is added to the CRL, it does not immediately force all requests to fail; instead, it is identified as invalid on the next verification. Even if the client does not synchronize the revocation status in time (e.g., due to network latency or offline scenarios), as long as it attempts to use a token that has been added to the CRL, the system can still refuse and force re-authentication on the next request, preventing the abuse of old tokens. In short, the CRL is an asynchronous security barrier that "blacklists first in the cloud, then detects on the device," rather than a synchronous database write operation of "direct revocation," greatly increasing security.
[0059] In this embodiment of the application, the following effects can be achieved by adding the token to the revocation list: (1) Avoid service interruption and sudden drop in user experience: If all requests using the token are forced to fail immediately, the operation being performed by the user may be suddenly interrupted (such as device control failure). CRL allows the system to reject the request only when the token is used or refreshed next time, and guides the user through a reasonable process (such as pop-up prompts, redirection to login), resulting in a smoother experience.
[0060] (2) Support for offline and asynchronous scenarios: In weak network or offline scenarios, the client may not be able to receive the revocation command immediately. The CRL mechanism allows the token to be rejected on the first use after the network is restored. For example, when mobile phone A tries to refresh the token after the network is restored, the system queries the CRL and finds that it has been revoked, returns a 409 conflict code and prompts the user.
[0061] (3) Secure transition across multiple devices: Old devices still have the opportunity to notify the user after receiving a 409, rather than directly failing to control the device. Cloud-based coordination of token atomic cleanup: Even if local cleanup is delayed, cloud-based CRLs can prevent old tokens from continuing to be used.
[0062] (4) Reduce system complexity and performance overhead: "Immediate revocation" requires real-time push of revocation events to all sessions and nodes, which makes the system complex and costly.
[0063] As a lightweight query list, CRL only needs to be queried at key verification nodes (such as Auth-Gateway, Token-Exchange-Service), making it simple and efficient.
[0064] In one embodiment of this application, the second token information can be added to a preset revocation list in response to the first device logging out of the target account.
[0065] In practical applications, when a target user logs out or switches accounts on the first device, the client and cloud can simultaneously revoke both tokens. This results in a complete erasure of the local encrypted storage area (Keystore / Keychain), cookies, and WebView cache. The cloud adds the Refresh-Token to the CRL (Revocation List) to prevent the old token from being refreshed. In this embodiment, the client and cloud simultaneously revoke both tokens, and the local encrypted storage area (Keystore / Keychain), cookies, and WebView cache are completely erased, thoroughly clearing the local token and cache to prevent information leakage.
[0066] For example, after user C uses the smart home app on a home-sharing tablet and clicks "Logout," the client immediately sends a revocation request to the cloud. The cloud adds both tokens to the CRL and notifies all synchronization services. Simultaneously, the client clears the tokens, cookies, WebView cache, and offline command queue stored in the Keystore to ensure no information remains. Any subsequent requests using the old token are rejected.
[0067] In one embodiment of this application, when multiple devices simultaneously log in to the target account, a reminder message for the older devices can be generated and sent to them. The reminder message is used to notify the user account to log in on other devices.
[0068] For example: User A logs in to the same account on phone B. The cloud detects the new device login and immediately adds phone A's Refresh-Token to the Revocation List (CRL). In the next heartbeat request, phone A receives a 409 conflict code, the app automatically pops up a message: "Your account is already logged in on another device, please log in again," clears the local token, and redirects to the login page.
[0069] In this embodiment of the application, when logging into the device, a first token and a second token with different validity periods are set, and the second token with a long validity period can refresh the set of the first token within its validity period. The business is executed by combining the two tokens, thereby avoiding the problem of the execution scenario running out due to the interruption of the validity period of the existing single token.
[0070] Referring to Figure 2, a flowchart of another device login method according to an embodiment of this application is shown, which may include the following steps: Step S201, in response to a login event triggered by the first device, obtaining login information of the target account entered by the target user in the login interface of the first device; Step S202, after successful authentication based on the login information, obtaining first token information and second token information of the first device, wherein the first validity period of the first token information is shorter than the second validity period of the second token information, and the second token information is used to refresh the first token information within the second validity period; Step S203, in response to a service request initiated in the first device, executing the target service in the first device according to the service request based on the first validity period and the second validity period.
[0071] Step S204: Obtain the real-time login location information and historical login location information of the first device. In practical applications, the real-time login location information of the first device can be obtained based on the location information of the first device, and the historical login location information of the target account can be obtained from the cloud to facilitate risk assessment. The historical login location information can be the location with the most logins of the target account in the recent period.
[0072] Step S205: Perform a risk assessment on the first device based on the real-time login information and the historical login information to obtain a risk level; after obtaining the real-time login information and the historical login information, a risk assessment can be performed based on the acquired data to determine the risk level of the current login.
[0073] Step S206: Update the first token information and / or the second token information according to the risk level.
[0074] The system pre-sets the update methods for the first and second token information under different risk levels. After determining the risk level, the corresponding update method can be used to update the first and second token information. For example, user B travels to another city at night for business and logs into a smart home app using hotel Wi-Fi. The risk engine detects a significant difference between the IP address and the user's usual location, and based on the device fingerprint and login time, classifies it as "medium risk." The app automatically triggers local fingerprint verification; after successful verification, the system issues a new Refresh-Token, taking approximately 2 seconds and requiring no password. If the risk engine classifies it as "high risk," it mandates a second verification process requiring both the account password and an SMS verification code.
[0075] In one embodiment of this application, updating the first token information and / or the second token information according to the risk level includes: when the risk level is the first risk level, redirecting to the login interface to update the first token information and / or the second token information by logging in again.
[0076] In practical applications, the first risk level can be a high risk level. When the current first device is determined to be a high risk level, it can directly jump to the login interface to manually enter the password to log in. During the re-login process, it can be executed again to obtain the first token information and the second token information of the first device after successful authentication based on the login information.
[0077] In one embodiment of this application, updating the first token information and / or the second token information according to the risk level includes: verifying the first device when the risk level is the second risk level; obtaining reissued first token information and second token information when the verification is successful; and redirecting to the login interface when the verification fails, so as to update the first token information and / or the second token information by logging in again.
[0078] In practical applications, the second risk level can be a medium risk level. Under the second risk level, the first device can be verified, such as through biometric or gesture recognition verification.
[0079] Upon successful verification, the cloud can be notified to issue a first token and a second token, updating both tokens. The updated tokens are then used to execute business requests. During this process, the user does not need to re-enter their login information to log in again.
[0080] In one embodiment of this application, in the step of "the system issues a new "Refresh-Token" after the user passes the test", the cloud will immediately execute the following complete process to ensure that the new token is both secure and can seamlessly connect to subsequent automatic renewal: 1. Secondary verification: The risk engine re-verifies whether the credentials (such as fingerprint / face one-time signature) that were just passed by local biometrics are consistent with the current session ID and device fingerprint to prevent "false pass" replay.
[0081] 2. Generate a new token pair: Using an encrypted random number, timestamp, and device ID as a seed, generate a brand new Refresh-Token (which can only be decrypted on the server side). At the same time, generate a corresponding new Access-Token, which remains valid for 30 minutes and contains a new "token version number".
[0082] 3. Binding and Archiving: Add a new record to the "Token Fingerprint Table": userId New Refresh-Token Hash Device fingerprint This risk assessment Issuance time Version number.
[0083] The old Refresh-Token (if still alive) is immediately written to the CRL and marked "replaced by the new token", ensuring that the same user has at most one valid long token.
[0084] 4. Key Rotation: If the risk level triggered this time is ≥ "Medium", the server will synchronously rotate the "refresh key" dedicated to this device (used for subsequent Refresh-Token signature verification). The old key is retained for a grace period of 5 minutes to prevent concurrent request failures.
[0085] 5. Secure issuance: New token pairs are returned via HTTPS + TLS 1.3 channel, with a one-time "encapsulated random number" appended to the response header. The client SDK must verify the signature using the locally stored public key before decrypting and storing the token, thus preventing man-in-the-middle substitution.
[0086] 6. Client-side atomic write: After receiving the data, the SDK first writes it to a temporary cache → verifies the signature and device fingerprint → confirms that there are no errors before overwriting the old token in the Keychain / Keystore and immediately deletes the plaintext of the old token in memory, thus achieving "verification before switching". Even if the App crashes at this time, no residue will be left.
[0087] 7. Cloud Event Push: Push-Service sends a lightweight notification that "token has been refreshed" to other online devices under the same account, along with the new version number. If the version number is outdated when the old device makes the next request, it will receive a 409 conflict error and be forced to exit, thus completing the "silent account top-up".
[0088] Through the above seven steps, the new Refresh-Token completes issuance, binding, old token revocation, and key rotation within 2 seconds, ensuring both security isolation and allowing users to continue enjoying the automatic renewal experience without their awareness.
[0089] In one embodiment of this application, when the risk level is the third risk level, the first token information can be refreshed, and then the target service can be executed.
[0090] In this embodiment, the cloud can dynamically issue a "risk level" based on changes in IP address, geographic location, and device environment, and then implement differentiated strategies according to the risk level: Low risk: Token refresh is completed silently, without the user's awareness. Medium risk: Local biometric verification is required, and a new Refresh-Token is issued upon successful verification. High risk: Manual login (account and password + secondary verification) is mandatory.
[0091] The above solution can solve the problem of not being able to dynamically trigger secondary verification based on the risk of the login environment, and only being able to dynamically switch between security and convenience, thus further eliminating security risks.
[0092] In this embodiment of the application, risk assessment can be performed based on the login location to eliminate potential security risks.
[0093] Referring to Figure 3a, a flowchart of another device login method according to an embodiment of this application is shown, which may include the following steps: Step S301, in response to a login event triggered by the first device, obtaining login information of the target account entered by the target user in the login interface of the first device; Step S302, after successful authentication based on the login information, obtaining first token information and second token information of the first device, wherein the first validity period of the first token information is shorter than the second validity period of the second token information, and the second token information is used to refresh the first token information within the second validity period; Step S303, in response to a service request initiated in the first device, executing the target service in the first device according to the service request based on the first validity period and the second validity period.
[0094] Step S304: When the first device is in a network interruption state, obtain the target instruction to be executed from the local cache; Step S305: Determine the instruction type of the target instruction; wherein, the instruction type can be non-sensitive instructions and sensitive instructions classified according to the degree of sensitivity. For example, light switches and curtain controls are non-sensitive instructions, while door lock switches are sensitive instructions.
[0095] Step S306: When the instruction type is a preset non-sensitive instruction, continue to execute the target instruction; Step S307: When the instruction type is a preset sensitive instruction, perform password verification on the target account, and execute the target instruction when the password verification is successful.
[0096] For example, if User D's home network is temporarily interrupted and their Access-Token has expired, the system allows the execution of locally cached non-sensitive commands (such as light switches and curtain controls) for up to 24 hours. For high-risk operations such as door lock switches, a one-time signature mechanism is used to ensure tamper-proof protection even when offline. Once the network is restored, the system automatically reissues the Token and synchronizes all offline commands to the cloud.
[0097] In the embodiments of this application, it is possible to continue executing instructions according to the instruction type even when the device network is interrupted, so as to ensure the safe execution of instructions.
[0098] The above embodiments of this application are based on a system architecture of client layer-gateway layer-cloud service. The following describes each part of the system architecture: (I) Client layer: TokenManager: responsible for the full life cycle management of tokens (storage, refresh, revocation); LoginBridge: uniformly intercepts network request exceptions (401, 409), calls the system biometric identification or jumps to the login page; OfflineQueue: offline command caching and replay.
[0099] (ii) Gateway layer: Auth-Gateway: Unified authentication, verifies Access-Token and forwards business requests; Token-Exchange-Service: Dedicated refresh interface, verifies Refresh-Token fingerprint and revocation list; Risk-Engine: Calculates login risk in real time and returns secondary verification strategy.
[0100] (III) Cloud Services: User-Service: Account, password, and two-factor authentication management; CRL-Service: Distributed revocation list, supporting second-level synchronization; Push-Service: Pushing "top number" messages to old devices.
[0101] The above system architecture enables the implementation of a dual-Token mechanism, multi-terminal conflict detection, dynamic risk perception, and atomic cleanup strategies.
[0102] Referring to Figure 3b, a schematic diagram of a device login process in an embodiment of this application is shown, which may include the following process: When a new device logs in, the cloud revokes the token (adds it to the CRL), the old device requests a 409 conflict, reminds the user and clears the local token, and then jumps to the login interface.
[0103] When a user clicks to log out or switch accounts, the client clears the current token and cache, and notifies the cloud to add the token to the CRL, then redirects the user to the login page.
[0104] Enter your username and password on the login screen. After successful authentication, the cloud issues dual tokens, which are then securely stored on the client side, allowing you to access the application's main page.
[0105] The system determines whether to initiate a business request or perform a timed check, and verifies the validity of the first token. If the first token is valid, the business request is executed normally. If the first token is invalid or about to expire, a second token can be used to request a replacement first token, and the result of the replacement request is assessed. If the replacement request succeeds, the local first token information is updated. If the replacement request fails (i.e., the second token expires), a risk assessment is performed to determine the trustworthiness of the device. If the device is considered high-risk, a forced redirect to manual login can be initiated. If the device is considered trustworthy or low-risk, biometric and / or gesture verification can be triggered, and the verification result is determined.
[0106] If the request passes, a new dual token is reissued, the local first token information is updated, and then the business request is executed normally according to the first token information to complete the request.
[0107] This embodiment achieves a balance between security and convenience for smart home apps in complex network and multi-device environments through a dual-Token mechanism, multi-terminal conflict detection, dynamic risk perception, and atomic cleanup strategies. The system boasts high availability, high security, and easy scalability, making it suitable for the long-term evolution of the modern smart home ecosystem. In this embodiment, users do not need to manually enter passwords in 99% of scenarios, ensuring uninterrupted smart functionality and improving user experience. The long token (second token information) does not directly participate in business operations, while the short token (first token information) has a short lifespan and a small leakage window, thus ensuring security during device login. This embodiment supports the same token system for Android / iOS platforms, mini-programs, and the Web, demonstrating high compatibility. Furthermore, the risk engine can be integrated with risk control big data, allowing for adjustments to secondary verification strategies at any time, resulting in strong scalability. In this embodiment, the token lifecycle is decoupled from business code, and the SDK output requires zero modification from the integrating party, facilitating maintenance.
[0108] It should be noted that the device login method provided in this application embodiment can be executed by a device login device, or a control module in the device login device for executing the loading device login method. This application embodiment uses the execution of the loading device login method by a device login device as an example to illustrate the device login method provided in this application embodiment.
[0109] Referring to Figure 4, a schematic diagram of a device login apparatus according to an embodiment of this application is shown. Specifically, it may include the following modules: a login information acquisition module 401, used to acquire login information of a target account entered by a target user in the login interface of the first device in response to a login event triggered by the first device; a token information acquisition module 402, used to acquire first token information and second token information of the first device after successful authentication based on the login information, wherein the first validity period of the first token information is shorter than the second validity period of the second token information, and the second token information is used to refresh the first token information within the second validity period; and a service execution module 403, used to execute a target service in the first device according to the service request based on the first validity period and the second validity period in response to a service request initiated in the first device.
[0110] In one embodiment of this application, the service execution module 403 may include: a first token information determination submodule, configured to determine whether the first token information is valid based on the first validity period in response to a service request initiated by the first device; a target service execution submodule, configured to execute the target service corresponding to the service request when the first token information is determined to be valid based on the first validity period; a refresh request submodule, configured to request a refresh of the first token information based on the second token information within the second validity period when the first token information is determined to be invalid based on the first validity period; and a refresh submodule, configured to update the first token information stored in the client based on the refreshed first token information if the second token information request to refresh the first token information is successful.
[0111] In one embodiment of this application, the service execution module 403 may include: a risk level determination submodule, used to perform a risk assessment on the first device and determine the risk level of the first device when the second token information expires; and a token update submodule, used to update the first token information and / or the second token information according to the risk level.
[0112] In one embodiment of this application, the token update submodule may include: a login interface redirection unit, used to redirect to the login interface when the risk level is the first risk level, so as to update the first token information and / or the second token information by re-login.
[0113] In one embodiment of this application, the token update submodule may include: a first device verification unit, configured to verify the first device when the risk level is the second risk level; a verification pass unit, configured to obtain reissued first token information and second token information when the verification passes; and a verification fail unit, configured to redirect to the login interface when the verification fails, so as to update the first token information and / or the second token information by re-login.
[0114] In one embodiment of this application, the device further includes: a login location information acquisition module, used to acquire real-time login location information and historical login location information of the first device; a risk level determination module, used to perform a risk assessment on the first device based on the real-time login information and the historical login information to obtain a risk level; and a token information update module, used to update the first token information and / or the second token information according to the risk level.
[0115] In one embodiment of this application, the device may further include: a first revocation list addition module, used to add the second token information to a preset revocation list when the second device is detected to be logged into the target account.
[0116] In one embodiment of this application, the device may further include: a second revocation list addition module, used to add the second token information to a preset revocation list in response to the first device logging out of the target account.
[0117] In one embodiment of this application, the apparatus may further include: a target instruction acquisition module, configured to acquire a locally cached target instruction to be executed when the first device is in a network interruption state; an instruction type determination module, configured to determine the instruction type of the target instruction; a non-sensitive instruction execution module, configured to continue executing the target instruction when the instruction type is a preset non-sensitive instruction; and a sensitive instruction execution module, configured to perform password verification on the target account when the instruction type is a preset sensitive instruction, and execute the target instruction when the password verification is successful.
[0118] In this embodiment of the application, when logging into the device, a first token and a second token with different validity periods are set, and the second token with a long validity period can refresh the set of the first token within its validity period. The business is executed by combining the two tokens, thereby avoiding the problem of the execution scenario running out due to the interruption of the validity period of the existing single token.
[0119] The device login device in this application embodiment can be a device, or a component, integrated circuit, or chip in a terminal. The device can be a mobile electronic device or a non-mobile electronic device. For example, mobile electronic devices can be mobile phones, tablets, laptops, PDAs, in-vehicle electronic devices, wearable devices, ultra-mobile personal computers (UMPCs), netbooks, or personal digital assistants (PDAs), etc., while non-mobile electronic devices can be servers, network attached storage (NAS), personal computers (PCs), televisions (TVs), ATMs, or self-service machines, etc. This application embodiment does not impose specific limitations.
[0120] The device login device in this application embodiment can be a device with an operating system. This operating system can be Android, iOS, or other possible operating systems; this application embodiment does not specifically limit the specific operating system.
[0121] The device login device provided in this application embodiment can implement the various processes implemented by the device login device in the method embodiments of Figures 1 to 3b. To avoid repetition, these processes will not be described again here.
[0122] Optionally, this application embodiment also provides an electronic device, including a processor 1010, a memory 1009, and a program or instructions stored in the memory 1009 and executable on the processor 1010. When the program or instructions are executed by the processor 1010, they implement the various processes of the above-described device login method embodiment and achieve the same technical effect. To avoid repetition, they will not be described again here.
[0123] It should be noted that the electronic devices in the embodiments of this application include the mobile electronic devices and non-mobile electronic devices described above.
[0124] Figure 5 is a schematic diagram of the hardware structure of an electronic device implementing an embodiment of this application. The electronic device 1000 includes, but is not limited to, components such as: a radio frequency unit 1001, a network module 1002, an audio output unit 1003, an input unit 1004, a sensor 1005, a display unit 1006, a user input unit 1007, an interface unit 1008, a memory 1009, and a processor 1010.
[0125] The memory 1009 includes applications and an operating system; the user input unit 1007 may include a touch panel 10071 and other input devices 10072; the input unit 1004 may include an image processor 10041 and a microphone 10042; and the display unit 1006 may include a display panel 10061.
[0126] Those skilled in the art will understand that the electronic device 1000 may also include a power supply (such as a battery) for powering various components. The power supply can be logically connected to the processor 1010 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system. The electronic device structure shown in Figure 5 does not constitute a limitation on the electronic device. The electronic device may include more or fewer components than shown, or combine certain components, or have different component arrangements; these will not be elaborated further here. This application also provides a readable storage medium storing a program or instructions. When executed by a processor, this program or instructions implement the various processes of the above-described device login method embodiments and achieve the same technical effects; to avoid repetition, these will not be elaborated further here.
[0127] The processor is the processor in the electronic device described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.
[0128] This application embodiment also provides a chip, which includes a processor and a communication interface. The communication interface is coupled to the processor. The processor is used to run programs or instructions to implement the various processes of the above-described device login method embodiments and can achieve the same technical effect. To avoid repetition, it will not be described again here.
[0129] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.
[0130] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.
[0131] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, 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 is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.
[0132] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.
Claims
1. A device login method, characterized in that, The method includes: in response to a login event triggered by a first device, obtaining login information of a target account entered by a target user in the login interface of the first device; after successful authentication based on the login information, obtaining first token information and second token information of the first device, wherein a first validity period of the first token information is shorter than a second validity period of the second token information, and the second token information is used to refresh the first token information within the second validity period; in response to a service request initiated in the first device, executing a target service in the first device according to the service request based on the first validity period and the second validity period.
2. The method according to claim 1, characterized in that, The step of responding to a service request initiated by the first device and executing a target service in the first device according to the service request based on the first validity period and the second validity period includes: responding to a service request initiated by the first device and determining whether the first token information is valid based on the first validity period; if the first token information is valid based on the first validity period, executing the target service corresponding to the service request; if the first token information is invalid based on the first validity period, then requesting to refresh the first token information based on the second token information within the second validity period; if the second token information successfully refreshes the first token information, then updating the first token information stored in the client based on the refreshed first token information.
3. The method according to claim 2, characterized in that, Also includes: When the second token information expires, a risk assessment is performed on the first device to determine the risk level of the first device; Update the first token information and / or the second token information according to the risk level.
4. The method according to claim 3, characterized in that, The step of updating the first token information and / or the second token information according to the risk level includes: when the risk level is the first risk level, redirecting to the login interface to update the first token information and / or the second token information by logging in again.
5. The method according to claim 3, characterized in that, The step of updating the first token information and / or the second token information according to the risk level includes: verifying the first device when the risk level is the second risk level; obtaining reissued first token information and second token information when the verification is successful; and redirecting to the login interface when the verification fails, so as to update the first token information and / or the second token information by logging in again.
6. The method according to any one of claims 1 to 5, characterized in that, Also includes: Obtain the real-time login location information and historical login location information of the first device; Based on the real-time login information and the historical login information, a risk assessment is performed on the first device to obtain a risk level; Update the first token information and / or the second token information according to the risk level.
7. The method according to any one of claims 1 to 5, characterized in that, Also includes: When a second device is detected logging into the target account, the second token information is added to a preset revocation list.
8. The method according to any one of claims 1 to 5, characterized in that, Also includes: In response to the first device logging out of the target account, the second token information is added to a preset revocation list.
9. The method according to any one of claims 1 to 5, characterized in that, Also includes: When the first device is in a network interruption state, it obtains the target instruction to be executed from the local cache and determines the instruction type of the target instruction; When the instruction type is a preset non-sensitive instruction, the target instruction continues to be executed; when the instruction type is a preset sensitive instruction, the target account is password verified, and the target instruction is executed when the password verification is successful.
10. A device login device, characterized in that, The device includes: a login information acquisition module, configured to acquire login information of a target account entered by a target user in the login interface of the first device in response to a login event triggered by the first device; a token information acquisition module, configured to acquire first token information and second token information of the first device after successful authentication based on the login information, wherein the validity period of the first token information is shorter than the validity period of the second token information, and the second token information is used to refresh the first token information within the validity period; and a service execution module, configured to execute a target service in the first device according to the service request based on the validity periods of the first token information and the second token information in response to a service request initiated in the first device.
11. An electronic device, characterized in that, It includes a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the device login method as described in any one of claims 1-9.
12. A readable storage medium, characterized in that, The readable storage medium stores a program or instructions that, when executed by a processor, implement the steps of the device login method as described in any one of claims 1-9.