Method for realizing automatic login of APP at swan mongolian side

Abstract

The invention provides a method for realizing automatic login of an APP (Application) at a swan Mongolia side, and belongs to the technical field of mobile terminal applications, when a user logs in for the first time, a client encrypts and signs a user name and a password and then sends the user name and the password to a server, and the server verifies, decrypts and completes authentication, generates a unique identity token, encrypts and returns the unique identity token; and the client decrypts the identity token, persistently stores the identity token in a local secure storage area, and establishes a local encryption pool to store a user basic information ciphertext. During subsequent starting, the client preferentially reads the identity token, initiates a token verification request to the server and encrypts and signs a communication message; and the server verifies the validity period of the token and equipment binding information after decryption and signature verification, if the token is valid, the client is allowed to unlock the local encryption pool and directly enter the application, and if the token is invalid, the client cleans the token and encryption pool data and prompts to log in again. According to the scheme, account passwords are prevented from being stored locally, the concurrent pressure of sensitive information transmission and login is reduced, and the safety and the user experience are improved.

Description

Technical Field

[0001] This invention belongs to the field of user authentication and session persistence technology for mobile terminal applications, and in particular relates to a method for implementing automatic login of HarmonyOS-based APP. Background Technology

[0002] With the increasing number of HarmonyOS-enabled devices and applications, users are usually required to enter their username and password to log in when using these applications. Some applications may repeatedly require users to log in again even after they have successfully logged in, affecting the user experience. Common login-free methods often achieve seamless login by persistently storing usernames and passwords locally and automatically calling the login interface when the application starts.

[0003] The above methods may force users to log in every time they open the application, interrupting their operation. On the other hand, if usernames and passwords are persistently stored locally, there are privacy and security risks. Furthermore, the repeated transmission of sensitive identity information during communication with the server will increase the exposure and risk of the communication link. Summary of the Invention

[0004] In view of this, the present invention aims to propose a method for automatic login of HarmonyOS-based APP, so as to at least solve one of the problems in the background art.

[0005] To achieve the above objectives, the technical solution of the present invention is implemented as follows: A method for implementing automatic login in a HarmonyOS-based app includes: When the application starts, it reads the encrypted identity token from the local persistent storage area; If the identity token does not exist, you will be redirected to the login page and receive your account credentials. The account credentials are encrypted and a signature is generated before being sent to the server. After verification, the server generates an identity token bound to the current terminal and returns it in encryption. The application decrypts the returned message to obtain the identity token and writes it to the local persistent area; When an identity token exists, the application constructs a verification request based on the identity token, encrypts and signs the verification request, and sends it to the server. The server determines the validity of the identity token and returns the determination result. If the determination result is valid, the application continues to retain the identity token and unlocks the user's basic information from the local encryption pool to enter the application; otherwise, the identity token is deleted and the user is taken to the login page.

[0006] Furthermore, the identity token includes at least a token identifier, a user identifier digest, a terminal binding information digest, and an expiration date field. The terminal binding information digest is obtained by hashing the unique identifier of the terminal. The server verifies the terminal binding information digest when determining the validity of the identity token.

[0007] Furthermore, the verification request includes at least an identity token, a timestamp, and a random number. When determining the validity of the identity token, the server simultaneously verifies the timestamp and the random number to reject duplicate messages.

[0008] Furthermore, the process of encrypting the account credentials and generating a signature includes: encrypting the account credentials using a first key to obtain ciphertext, and generating a signature value based on the ciphertext and a preset digest field using a second key; the server verifies the signature value using the corresponding key and decrypts the ciphertext to obtain the account credentials.

[0009] Furthermore, after the server generates an identity token, it encrypts the identity token, generates a signature, and returns it. The application verifies the signature of the returned message, and after successful verification, decrypts the identity token and stores it persistently.

[0010] Furthermore, the local persistent area is a terminal secure storage area, where the identity token is stored in encrypted form. The encryption key of the encrypted text is generated or managed by the terminal key management module, and the encryption key is bound to the terminal device.

[0011] Furthermore, the local encryption pool is used to store ciphertext of user basic information. Unlocking user basic information includes: deriving unlocking parameters based on the identity token, retrieving decryption materials from the terminal secure storage area using the unlocking parameters, and decrypting the ciphertext of user basic information to obtain the user basic information.

[0012] Furthermore, if the determination result is valid, the server returns a refreshed identity token, and the application uses the refreshed identity token to overwrite and update the identity token in the local persistent area.

[0013] Furthermore, when the remaining validity period of the identity token is less than a preset threshold, a refresh process is triggered. In the refresh process, the verification request carries the current identity token and a refresh flag. The server generates a new identity token based on the refresh flag and returns it.

[0014] Furthermore, when the server determines that the identity token is invalid, it returns an invalidity reason code. The invalidity reason code includes at least one of the following: expired, terminal mismatch, and signature verification failure. The application deletes the identity token and clears the unlocking materials related to the user's basic information based on the invalidity reason code.

[0015] Furthermore, the communication between the verification request and the server takes place in an encrypted channel, and the establishment of the encrypted channel is independent of the signing of the verification request.

[0016] Furthermore, the application supports users to actively log out. When logging out, the identity token is deleted from the local persistent storage area, and a token cancellation request is sent to the server to invalidate the identity token.

[0017] Furthermore, when the application detects a terminal system version upgrade, application package update, or security policy change, it triggers an identity token verification request; if the verification fails, the identity token is deleted and the user is redirected to the login page.

[0018] Furthermore, the server stores the correspondence between identity tokens and terminal binding information. When the same identity token is verified under different terminal binding information, the server determines that the identity token is invalid.

[0019] Furthermore, the identity token is generated on the server side according to preset rules, which at least include token uniqueness constraints and validity period constraints.

[0020] Furthermore, this solution discloses an automatic login method for HarmonyOS-based apps, including: The token reading module is used to read the encrypted identity token from the local persistent area when the application starts; The login interaction module is used to receive account credentials and trigger a login request when the identity token does not exist; The encryption and signature module is used to encrypt account credentials or verification requests and generate signatures, as well as to verify and decrypt the signatures of messages returned by the server. The token verification module is used to construct a verification request and send it to the server to obtain the judgment result when the identity token exists; The token management module is used for persistent storage, overwriting, updating, and deleting identity tokens; The information unlocking module is used to unlock basic user information from the local encryption pool when the determination result is valid.

[0021] Furthermore, the token management module stores the identity token in the terminal's secure storage area and calls the terminal key management module to obtain the encryption and decryption keys for the identity token ciphertext.

[0022] Furthermore, the token verification module carries a timestamp and a random number in the verification request, and sends the digest and signature of the verification request to the server to support replay verification on the server side.

[0023] Furthermore, this solution discloses a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the method described.

[0024] Compared with existing technologies, the automatic login method for HarmonyOS-based apps described in this invention has the following advantages: (1) This invention only stores the encrypted identity token locally and does not save the username and password on the terminal side, thereby reducing the risk of account password leakage after the application is decompiled or local data is stolen; (2) The present invention improves the user experience by starting the process of reading the token and directly entering the application if the token is valid; (3) This invention transforms the login process on each startup into token verification and refresh when necessary, reducing the concurrent pressure of login interface calls and server authentication; (4) This invention reduces the number of times usernames and passwords are transmitted during communication, thereby reducing the risk of sensitive information being exposed during transmission; (5) The present invention makes it more difficult for the token to be copied to other devices and abused by means of encryption, signature and decryption design in the token generation stage and communication stage, as well as the constraint of binding the token to the current device. Attached Figure Description

[0025] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an undue limitation of the invention. In the drawings: Figure 1 This is a schematic diagram of the method described in an embodiment of the present invention. Detailed Implementation

[0026] It should be noted that, unless otherwise specified, the embodiments and features described in the present invention can be combined with each other.

[0027] In the description of this invention, it should be understood that the terms "center," "longitudinal," "lateral," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," and "outer," etc., indicating orientations or positional relationships based on the orientations or positional relationships shown in the accompanying drawings, are only for the convenience of describing the invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the invention. Furthermore, the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined with "first," "second," etc., may explicitly or implicitly include one or more of that feature. In the description of this invention, unless otherwise stated, "a plurality of" means two or more.

[0028] In the description of this invention, it should be noted that, unless otherwise explicitly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art will understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0029] The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0030] The following embodiment uses "automatic login of HarmonyOS APP" as an example to illustrate the present invention. The system in this embodiment includes at least: a HarmonyOS APP client, an authentication server, a local secure storage area, and a local encryption pool. The local secure storage area is used to persistently store the identity token and necessary session parameters; the local encryption pool is used to store encrypted data of the user's basic information (such as user identifier, nickname, permission summary, most recent session information, etc.), which is unlocked and read when the token is valid, and cleared when the token is invalid or the user exits. Correspondingly, the authentication server includes at least a login authentication module, a token generation module, a token verification module, and a token expiration management module. The overall approach is: when a user completes authentication for the first time with their account and password, the server generates and returns an encrypted identity token, which the client persistently stores; upon subsequent startups, the client prioritizes reading the token and verifies its validity with the server. If valid, the user information is unlocked from the local encryption pool and the user directly enters the application; if invalid, the persistent data is deleted and the user is guided to log in again.

[0031] (i) Initial Login and Token Issuance. In the initial login scenario, the client displays a login page. After the user enters their username and password, the client encrypts and signs the identity information before sending it to the server. The server first verifies the signature, then decrypts the username and password and performs verification. Upon successful verification, a unique identity token is generated according to preset rules and returned to the client in encrypted form. The client receives the returned message, decrypts it to obtain the identity token, and persistently stores it in its local secure storage area.

[0032] To enhance security and auditability, identity tokens can structurally include: user ID (user_id), device hash (dev_hash), issue time (issue_time), expire time (expire_time), nonce, token version (token_ver), and optional scope digest (scope_digest). The server signs the token's plaintext payload (e.g., using a key-based message authentication code or an asymmetric key-based digital signature) and returns the token or its sensitive fields after encryption. During client-side token persistence, the encrypted token can be bound to local device security capabilities (e.g., using keys generated or managed by system security capabilities to re-encapsulate the token), preventing it from being decrypted and used after being copied to other devices, thus ensuring the token is only valid on the currently logged-in device.

[0033] (II) Initiating Automatic Login and Token Verification. Each time the client starts, it first reads the persistent identity token locally. If no token is found, or the token format verification fails, the client proceeds to the login page. If a token is found, the client sends a token validity verification request to the server. This request includes at least the identity token (or token index information), a timestamp, and a random number, and the request message is encrypted and signed. Upon receiving the request, the server performs decryption, signature verification, and anti-replay checks (e.g., verifying the timestamp window and temporarily caching the random number). The token verification module then checks the token signature validity, expiration time, device binding information, and whether the token is on the invalidation list. If the server returns a valid token, the client retains and updates the persistent token if necessary, unlocks the user's basic information from the local encryption pool, and directly enters the application. If the server returns an invalid token, the client deletes the local persistent token and local encryption pool data, and prompts the user to log in again.

[0034] (III) Local Encryption Pool Unlocking and Minimized Disk Deployment. To further reduce the exposure of sensitive data, the client does not store usernames and passwords locally, but only stores encrypted identity tokens, and unlocks the user's basic information in the local encryption pool when the token is valid.

[0035] In practice, the local encryption pool can adopt a method of "binding the encrypted data encryption key (DEK) with the device key or token-derived key": After the first successful login, the client generates or obtains the DEK, which is used to encrypt the user's basic information and write it to the encryption pool. The DEK is not written to disk in plaintext, but is encapsulated and stored through the device's security capabilities, or derived from a field of the token and the device identifier. Upon subsequent startup, the DEK is only decapsulated and the user's basic information is read when the token passes server verification (or meets local verification conditions within an optional short-term offline tolerance policy). If the user actively logs out, the token expires, or verification fails, the encapsulated DEK, the encrypted pool ciphertext, and the persistent token data are cleaned up to avoid residue.

[0036] (iv) Token Refresh and Expiration Control (Optional). When a token is about to expire, the client can trigger a refresh process in the background: sending a refresh request to the server with the current token, timestamp, and random number; after the server verifies the request, it generates a new token and returns it. The client then atomically replaces the locally persistent token and updates the encapsulation material bound to it. For scenarios such as password changes, account freezing, and remote risk triggering, the server can add the existing token to the invalidation list; upon receiving an invalid result during the next startup or verification, the client will clean up the list according to the aforementioned process and require re-login, thereby ensuring session security and controllability.

[0037] (V) Key Points of Communication Encryption and Signature Implementation. Considering that the key technical points of this invention include "encryption and signature during the token generation stage" and "encryption, signature, and decryption during the token communication stage," the following combination can be used in this embodiment to form an alternative implementation: First, the login message uses the server's public key to encrypt sensitive fields and signs the entire message; second, the token verification message uses a symmetric key for encryption and includes a message authentication code; third, a timestamp and a random number are introduced, and a short-term random number cache is established on the server side to suppress replay; fourth, the consistency of the token and device binding information is verified to ensure that the token cannot pass verification after being migrated to other devices. The above implementation methods can be selected or combined according to security level, performance constraints, and available system security capabilities, without affecting the core idea of ​​this invention.

[0038] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for implementing automatic login in a HarmonyOS-based app, characterized in that, include: When the application starts, it reads the encrypted identity token from the local persistent storage area; If the identity token does not exist, you will be redirected to the login page and receive your account credentials. The account credentials are encrypted and a signature is generated before being sent to the server. After verification, the server generates an identity token bound to the current terminal and returns it in encryption. The application decrypts the returned message to obtain the identity token and writes it to the local persistent area; When an identity token exists, the application constructs a verification request based on the identity token, encrypts and signs the verification request, and sends it to the server. The server determines the validity of the identity token and returns the determination result. If the determination result is valid, the application continues to retain the identity token and unlocks the user's basic information from the local encryption pool to enter the application; otherwise, the identity token is deleted and the user is taken to the login page.

2. The method according to claim 1, characterized in that: The identity token includes at least a token identifier, a user identifier digest, a terminal binding information digest, and an expiration date field. The terminal binding information digest is obtained by hashing the unique identifier of the terminal. The server verifies the terminal binding information digest when determining the validity of the identity token.

3. The method according to claim 1, characterized in that: The verification request includes at least an identity token, a timestamp, and a random number. When determining the validity of the identity token, the server also verifies the timestamp and the random number to reject duplicate messages. The process of encrypting account credentials and generating a signature includes: encrypting the account credentials with a first key to obtain ciphertext, and generating a signature value based on the ciphertext and a preset digest field using a second key; the server uses the corresponding key to verify the signature value and decrypts the ciphertext to obtain the account credentials.

4. The method according to claim 1, characterized in that: After generating an identity token, the server encrypts the identity token, generates a signature, and returns it. The application verifies the signature of the returned message, and after successful verification, decrypts the identity token and stores it persistently. The local persistent area is a terminal secure storage area. The identity token is stored in encrypted form. The encryption key of the encrypted text is generated or managed by the terminal key management module, and the encryption key is bound to the terminal device. The local encryption pool is used to store ciphertext of user basic information. Unlocking user basic information includes: deriving unlocking parameters based on the identity token, retrieving decryption materials from the terminal secure storage area using the unlocking parameters, and decrypting the ciphertext of user basic information to obtain the user basic information.

5. The method according to claim 1, characterized in that: When the determination result is valid, the server returns a refreshed identity token, and the application uses the refreshed identity token to overwrite and update the identity token in the local persistent area. When the remaining validity period of the identity token is less than a preset threshold, a refresh process is triggered. In the refresh process, the verification request carries the current identity token and a refresh flag. The server generates a new identity token based on the refresh flag and returns it.

6. The method according to claim 1, characterized in that: When the server determines that the identity token is invalid, it returns an invalid reason code. The invalid reason code includes at least one of the following: expired, terminal mismatch, and signature verification failure. The application deletes the identity token and clears the unlocking materials related to the user's basic information based on the invalid reason code.

7. The method according to claim 1, characterized in that: The communication between the verification request and the server takes place in an encrypted channel, and the establishment of the encrypted channel is independent of the signing of the verification request. The application supports users to actively log out. When logging out, the identity token is deleted from the local persistent area, and a token cancellation request is sent to the server to invalidate the identity token.

8. The method according to claim 1, characterized in that: When the application detects a terminal system version upgrade, application package update, or security policy change, it triggers an identity token verification request. If verification fails, the identity token will be deleted and the user will be redirected to the login page. The server stores the correspondence between identity tokens and terminal binding information. When the same identity token is verified under different terminal binding information, the server determines that the identity token is invalid. The identity token is generated on the server side according to preset rules, which include at least token uniqueness constraints and validity period constraints.

9. An automatic login method for HarmonyOS-based apps, characterized in that: include: The token reading module is used to read the encrypted identity token from the local persistent area when the application starts; The login interaction module is used to receive account credentials and trigger a login request when the identity token does not exist; The encryption and signature module is used to encrypt account credentials or verification requests and generate signatures, as well as to verify and decrypt the signatures of messages returned by the server. The token verification module is used to construct a verification request and send it to the server to obtain the judgment result when the identity token exists; The token management module is used for persistent storage, overwriting, updating, and deleting identity tokens; The information unlocking module is used to unlock basic user information from the local encryption pool when the determination result is valid.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method described in any one of claims 1 to 8.

Images