Login control method and device

Abstract

The invention discloses a login control method and device, and relates to the technical field of computers. A specific embodiment of the method comprises the following steps: in response to a login request, determining that an application is an unloaded and reloaded application under the condition that user identification information corresponding to the application exists and the application is installed for the first time; sending a voucher obtaining request to the service party to receive service voucher information returned by the service party; sending a login-free request to a management and control server based on the service certificate information and a historical login certificate corresponding to the application; and receiving a login credential returned by the management and control server under the condition that the login verification is passed, and updating the historical login credential based on the login credential. According to the embodiment, by detecting the unloading and reloading states of the application and combining a dual verification mechanism of the historical login credential and the real-time credential of the service party, identity authentication can be automatically completed on the premise of ensuring the safety, the tedious operation that a user repeatedly inputs an account password or a verification code is avoided, and the login convenience and the user experience are remarkably improved.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a login management method and apparatus. Background Technology

[0002] With the booming development of mobile internet, mobile applications commonly adopt diverse login methods such as account passwords, SMS verification codes, or OAuth to accurately identify users and provide personalized services. Among these, OAuth, as an open standard authorization protocol framework, provides users with a secure and standardized solution, enabling them to authorize third-party applications to access their resources on other service providers without exposing their usernames and passwords. However, when users uninstall and reinstall the application or switch devices, they must re-execute the entire authentication process, which is cumbersome and negatively impacts user experience. Summary of the Invention

[0003] In view of this, embodiments of the present invention provide a login management method and apparatus, which can at least solve the problem that in the prior art, a complete identity verification process still needs to be performed in the scenario of application uninstallation and reinstallation, which is cumbersome and affects the user experience.

[0004] To achieve the above objectives, according to one aspect of the present invention, a login management method for an application client is provided, comprising:

[0005] In response to a login request, if there is user identification information corresponding to the application and the application is being installed for the first time, it is determined that the application is uninstalled and reinstalled.

[0006] Send a request to the service provider to obtain credentials, and receive the service credential information returned by the service provider;

[0007] Based on the service credential information and the historical login credentials corresponding to the application, a login-free request is sent to the management server.

[0008] Receive the login credentials returned by the management and control server when the login verification is successful, and update the historical login credentials based on the login credentials.

[0009] To achieve the above objectives, according to one aspect of the present invention, a login management method applied to a management server is provided, comprising:

[0010] Receive a login-free request sent by an application client; wherein the application is an uninstalled and reinstalled application, and the login-free request includes service credential information and historical login credentials corresponding to the application, and the service credential information is obtained by requesting the service provider;

[0011] Login verification is performed based on the service credential information and the historical login credentials.

[0012] In response to a successful login verification, a login operation is performed based on the historical login credentials, and the login credentials are returned to the application client for updating and storage.

[0013] To achieve the above objectives, according to another aspect of the present invention, a login management device for application clients is provided, comprising:

[0014] The identification module is used to respond to login requests and determine whether the application is uninstalled and reinstalled if there is user identification information corresponding to the application and the application is being installed for the first time.

[0015] The service module is used to send a request to the service provider to obtain credentials, and to receive service credential information returned by the service provider.

[0016] The request module is used to send a login-free request to the management server based on the service credential information and the historical login credentials corresponding to the application.

[0017] The update module is used to receive the login credentials returned by the management server when the login verification is successful, and update the historical login credentials based on the login credentials.

[0018] To achieve the above objectives, according to another aspect of the present invention, a login management device applied to a management server is provided, comprising:

[0019] The receiving module is used to receive a login-free request sent by the application client; wherein the application is an uninstalled and reinstalled application, and the login-free request includes service credential information and historical login credentials corresponding to the application, and the service credential information is obtained by requesting the service provider;

[0020] The processing module is used to perform login verification processing based on the service credential information and the historical login credentials;

[0021] The generation module is used to respond to a successful login verification result by performing a login operation based on the historical login credentials, obtaining login credentials, and returning them to the application client for updating and storage.

[0022] To achieve the above objectives, according to another aspect of the present invention, a login management electronic device is provided.

[0023] The electronic device of this invention includes: one or more processors; and a storage device for storing one or more programs, which, when executed by the one or more processors, enable the one or more processors to implement any of the login control methods described above.

[0024] To achieve the above objectives, according to another aspect of the present invention, a computer-readable medium is provided having a computer program stored thereon, which, when executed by a processor, implements any of the login control methods described above.

[0025] To achieve the above objectives, according to another aspect of the present invention, a computing program product is provided. One such computing program product includes a computer program that, when executed by a processor, implements the login management method provided in this embodiment of the invention.

[0026] According to the solution provided by the present invention, one embodiment of the above invention has the following advantages or beneficial effects: it realizes a passwordless login experience that is imperceptible to users. By detecting the application uninstallation and reinstallation status and combining the dual verification mechanism of historical login credentials and real-time credentials of the service provider, it can automatically complete identity authentication while ensuring security. This avoids the tedious operation of users repeatedly entering account passwords or verification codes, significantly improves login convenience and user experience, and reduces the error rate and user churn risk caused by manual input.

[0027] The further effects of the aforementioned unconventional alternative methods will be explained below in conjunction with specific implementation methods. Attached Figure Description

[0028] The accompanying drawings are provided to better understand the invention and are not intended to unduly limit the scope of the invention. Wherein:

[0029] Figure 1 This is a schematic diagram of the main process of a login management method applied to an application client according to an embodiment of the present invention;

[0030] Figure 2 This is a schematic diagram of the main process of a login control method applied to a control server according to an embodiment of the present invention;

[0031] Figure 3 This is a schematic diagram of the main process of a login management method for interaction between an application client and a management server according to an embodiment of the present invention;

[0032] Figure 4 This is a schematic diagram of the main process of an optional login management method applied to an application client according to an embodiment of the present invention;

[0033] Figure 5 This is a schematic diagram of the main process of an optional login control method applied to a control server according to an embodiment of the present invention;

[0034] Figure 6 This is a schematic diagram of the main process of a login management method for interaction between an optional application client and a management server according to an embodiment of the present invention;

[0035] Figure 7 This is a schematic diagram of the main process of another optional login management method applied to an application client according to an embodiment of the present invention;

[0036] Figure 8 This is a schematic diagram of the main process of another optional login management method for interaction between an application client and a vendor SDK according to an embodiment of the present invention;

[0037] Figure 9 This is a schematic diagram of the main process of another optional login management method applied to an application client according to an embodiment of the present invention;

[0038] Figure 10 This is a schematic diagram of the main process of another optional login control method applied to a control server according to an embodiment of the present invention;

[0039] Figure 11 This is a schematic diagram of the main process of another optional login management method for interaction between an application client and a management server according to an embodiment of the present invention;

[0040] Figure 12 This is a schematic diagram of the main modules of a login management device applied to an application client according to an embodiment of the present invention;

[0041] Figure 13 This is a schematic diagram of the main modules of a login management device applied to a management server according to an embodiment of the present invention;

[0042] Figure 14 This is an exemplary system architecture diagram in which embodiments of the present invention can be applied;

[0043] Figure 15 This is a schematic diagram of the structure of a computer system suitable for implementing the embodiments of the present invention, such as a mobile device or server. Detailed Implementation

[0044] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of the present invention, including various details to aid understanding. These details should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the invention. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0045] It should be noted that in the embodiments of this application, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of this application. However, it does not mean that the applicant has used or necessarily used the solution.

[0046] Where there is no conflict, the embodiments and features in the embodiments of this invention can be combined with each other. The acquisition, transmission, storage, use, and processing of data in the technical solutions of this invention comply with the relevant provisions of national laws and regulations, are used for legal and reasonable purposes, and are not shared, disclosed, or sold outside of these legal uses, and are subject to supervision and management by regulatory authorities.

[0047] Regarding user information, necessary measures should be taken to prevent unauthorized access to such personal information data, ensure that personnel authorized to access such data comply with relevant laws and regulations, and safeguard the security of user personal information. Once this user personal information data is no longer needed, risks should be minimized by restricting or even prohibiting data collection and / or deleting the data. Where applicable, including in certain relevant applications, user privacy should be protected through data de-identification, such as by removing specific identifiers (e.g., date of birth), controlling the amount or specificity of stored data (e.g., collecting location data at the city level rather than the specific address level), controlling how data is stored, and / or other de-identification methods.

[0048] The following are explanations of the terms used in this plan:

[0049] Login SDK (Software Development Kit): A component integrated into the application used to initiate the login process.

[0050] Security SDK: A security component that provides device data collection, risk analysis, and signature capabilities.

[0051] Keychain: An encrypted data storage mechanism provided by the iOS system.

[0052] Uninstall without login: A mechanism that allows users to log in again without being aware of the process after uninstalling and reinstalling an app (Application).

[0053] Signature: Use the private key to encrypt the data and generate a digest to prove the authenticity of the data.

[0054] Login credentials: A structure representing a user's login state, typically containing information such as Token and validity period.

[0055] Currently, the mainstream login implementation methods in the industry include the following steps: 1. When users install the application for the first time, they need to manually enter their account information or complete the identity verification process via SMS verification code; 2. When the application is uninstalled and reinstalled, users need to go through the complete identity verification process again; 3. Login credentials are usually stored in the local cache in the form of Token or Session, and their validity is maintained by periodic refresh; 4. In order to enhance security, some platforms have introduced device fingerprint recognition, security module integration, or risk assessment mechanisms to improve the security protection level of the login process.

[0056] However, the existing solution still has several issues that urgently need to be optimized:

[0057] 1. Poor user experience: When users uninstall the application and reinstall it or switch devices, the entire authentication process must be repeated, which is cumbersome and can easily lead to user churn.

[0058] 2. Inadequate security mechanisms: Some local token mechanisms fail to be deeply integrated with device security features, posing a security risk of tampering or forgery. For example, applications may simply store login tokens locally (e.g., in a Keychain or sandbox environment), with the server only verifying the token's validity before assuming the user's identity is valid. However, such tokens lack a strong binding relationship with device hardware features and do not use the device's hardware key for digital signature verification, allowing anyone who obtains the token to impersonate a user on any device.

[0059] 3. Difficulty in ensuring the consistency of login credentials: In complex scenarios with multiple terminals and multiple services, the synchronization mechanism of login credentials cannot ensure complete consistency, which poses a security risk of "fake login credentials".

[0060] 4. Legality verification relies on a single link: Most current verification mechanisms only verify the validity of the token itself, lacking device-level dual signature protection mechanisms and user behavior feature analysis verification, resulting in relatively weak overall anti-attack capabilities.

[0061] See Figure 1 The diagram shows the main flowchart of a login management method for application clients provided by an embodiment of the present invention, which includes the following steps:

[0062] S101: In response to the login request, if there is user identification information corresponding to the application and the application is installed for the first time, determine that the application is uninstalled and reinstalled.

[0063] S102: Send a request to the service provider to obtain credentials, and receive the service credential information returned by the service provider;

[0064] S103: Based on the service credential information and the historical login credentials corresponding to the application, send a login-free request to the management server;

[0065] S104: Receive the login credentials returned by the management and control server when the login verification is successful, and update the historical login credentials based on the login credentials.

[0066] See Figure 2 The diagram shows the main flowchart of a login management method applied to a management server according to an embodiment of the present invention, which includes the following steps:

[0067] S201: Receive a login-free request sent by the application client; wherein, the application is an uninstalled and reinstalled application, and the login-free request includes service credential information and historical login credentials corresponding to the application, and the service credential information is obtained by requesting the service provider;

[0068] S202: Perform login verification based on the service credential information and the historical login credential;

[0069] S203: In response to the login verification result being successful, a login operation is performed based on the historical login credentials, the login credentials are obtained and returned to the application client for update and storage.

[0070] This implementation method is specifically applied to the scenario of "uninstallation without login identification and login process triggering". It is used to identify whether the device application meets the conditions for login-free access and automatically trigger the uninstallation without login process. This method achieves a password-free login experience that is imperceptible to the user: by detecting the application's uninstallation and reinstallation status and combining a dual verification mechanism of historical login credentials and real-time credentials from the service provider, identity authentication can be automatically completed while ensuring security. This avoids the tedious operation of users repeatedly entering account passwords or verification codes, significantly improving login convenience and user experience, while reducing the error rate and user churn risk caused by manual input.

[0071] See Figure 3 The diagram shown is a main flowchart of a login management method for interaction between an application client and a management server, provided by an embodiment of the present invention. The application client integrates a login SDK (i.e., a login component) and includes the following steps:

[0072] Step 1: After the application starts, the login SDK reads the local persistent storage area to check for user identification information, such as `uid_hash` (an identifier obtained by hashing the user's unique ID) and `last_login_Token` (an authentication token recording the user's most recent login session). The specific type is not limited. This solution is applicable to multiple operating systems, such as Android, iOS, and Windows. In iOS, the local persistent storage area can be a Keychain. It is important to note that the local persistent storage area is one-to-one with each application; different applications have independent local persistent storage areas.

[0073] Step 2: If the user identification information is not present in the local persistent region, there is no need to check whether the application is being installed on the device for the first time. Instead, the normal login process is used, which means that the complete identity verification process is re-executed. The user needs to manually enter account information or complete the identity verification through SMS verification code or other means.

[0074] Step 3: If user identification information exists in the local persistent area, and it is detected that this is the first time the application has been installed on the current device, it indicates that the application has been uninstalled and then reinstalled. Uninstallation and reinstallation here includes two scenarios: one is uninstalling and then reinstalling the application on the same device, and the other is reinstalling after changing devices.

[0075] The situation differs slightly when switching devices. For example, if a user previously used device A and switched to device B, the information from device A needs to be synchronized to device B. Therefore, the information on device B must be completely consistent with the information on device A, and the information stored in the corresponding local persistent storage area must also be consistent with the information stored on device A. If the application was previously installed on device A, then the user's identifier information will be stored in the local persistent storage area of ​​that application on device B. However, if the application was not previously installed on device A, then the user's identifier information will not be present in the local persistent storage area of ​​that application on device B.

[0076] For "detecting whether the application is being installed on the current device for the first time" in steps 2 and 3 above, any of the following methods can be used:

[0077] Method 1: App Cache Directory Check: Check if the application's cache directory exists. If the application's cache directory is missing or empty, it can be determined that it is in the initial installation state.

[0078] Method 2: Login credential cache check: Check for the existence of cache files or data related to login credentials. If no login credential cache record is found, it indicates that this may be the first installation or that the cache has been cleared.

[0079] Method 3: Temporary File Detection: When a user uses the application for the first time, the application creates a dedicated folder on the device to store temporary files and runtime data. This temporary folder is usually created automatically when the application is first launched and is used continuously throughout the application's lifecycle. If this application-specific temporary folder is detected to be missing, or if the folder is missing necessary identification files, it can be determined that the application is being installed on the current device for the first time.

[0080] Method 4: System-level App Data Directory Detection: This method determines whether an app is being installed for the first time by checking the status of its system-level data directory. When an app is uninstalled, the system clears its corresponding data directory. These directories need to be recreated after reinstallation.

[0081] Method 5: Application Configuration File Detection: Checks if the application's core configuration files exist. These configuration files are not yet generated during the initial installation, and this method can help determine the installation status.

[0082] Method 6: Database Status Detection: If the application uses a local database to store information, the installation status can be determined by checking whether the database file exists and whether it contains initialization data.

[0083] Step 4: If the application is confirmed to be uninstalled and reinstalled, the login SDK will control the privacy agreement component in the application's UI layer to display the privacy agreement agreement consent option to the user. In response to the user clicking to agree to the privacy agreement, the login SDK calls the carrier SDK (i.e., the service provider) to initiate a number retrieval request (i.e., a credential acquisition request). The carrier SDK will return service credential information, such as a mobile phone number or carrier identifier. This service credential information is obtained through the carrier's official API (Application Programming Interface) and is deeply bound to the user's SIM (Service Mesh Interface) card information, possessing high security and tamper-proof characteristics, ensuring the authenticity and validity of the service credential information. Currently, it supports the three major carriers. The device can determine the currently used carrier type through relevant APIs and call the corresponding carrier SDK interface based on the determination result.

[0084] Step 5: The login SDK combines historical login credentials with service credentials returned by the carrier SDK, for example, binding the latest historical login credential with a mobile phone number. Based on this combined credential, the uninstallation login-free process is invoked, sending a passwordless login initialization request to the management server for passwordless login verification. Once the management server verifies the credentials, it returns a new login credential. Upon receiving this credential, the application updates the locally stored historical login credential by overwriting it, ensuring the timeliness and security of the credentials.

[0085] In the above implementation, the application's historical login credentials are stored in a local persistent area, possessing the characteristic of persistent retention after uninstallation. The entire process strictly relies on the user's active consent to the privacy agreement to trigger, fully protecting the user's right to know and right to choose, and ensuring compliance with relevant data privacy protection regulations. In this method, when a user uninstalls the application and reinstalls it or changes devices, the system can intelligently identify the user's identity and automatically complete passwordless login verification, eliminating the need to re-execute the cumbersome process of manually entering account passwords or SMS verification codes, significantly simplifying the user's operation steps and significantly improving login efficiency and user experience. Simultaneously, the dual verification mechanism using trusted service credentials obtained through the operator's SDK and historical login credentials ensures the security and reliability of the login process, avoids login failures due to the invalidation of a single credential, improves fault tolerance, and provides technical support for users to seamlessly switch between different devices.

[0086] See Figure 4 The diagram shows the main flowchart of an optional login management method for application clients provided by an embodiment of the present invention, which includes the following steps:

[0087] S401: In response to the login request, if there are historical login credentials corresponding to the application and the application is being installed for the first time, determine that the application is uninstalled and reinstalled.

[0088] S402: Send a request to the service provider to obtain credentials, and receive service credential information returned by the service provider;

[0089] S403: Obtain the current device environment information and the passwordless parameters corresponding to the application, and send a login-free request to the login server in combination with the service credential information and the historical login credentials corresponding to the application;

[0090] S404: Receive the login credentials returned by the management server after successful login verification, and update the historical login credentials based on the login credentials.

[0091] See Figure 5The diagram shows the main flowchart of an optional login management method applied to a management server provided by an embodiment of the present invention, which includes the following steps:

[0092] S501: Receive a login-free request sent by the application client; wherein the application is an uninstalled and reinstalled application, and the login-free request includes service credential information, current device environment information, historical login credentials corresponding to the application, and login-free parameters, and the service credential information is obtained by requesting the service provider;

[0093] S502: Determine the device risk level based on the current device environment information; in response to the device risk level being less than or equal to a preset level, perform login verification processing on the login-free parameters, the service authentication information, and the historical login credentials.

[0094] S503: In response to the login verification result being successful, a login operation is performed based on the historical login credentials, the login credentials are obtained and returned to the application client for update and storage.

[0095] See Figure 6 The diagram shown is a main flowchart of an optional login management method involving interaction between an application client and a management server, provided by an embodiment of the present invention. The application client also integrates a security SDK (i.e., a security component), and the management server integrates a security server and a login server. The process includes the following steps:

[0096] Step 1: When the login SDK invokes the uninstallation login-free process, it first comprehensively collects the current device's environmental information. This information includes, but is not limited to, key environmental parameters such as device ID, operating system version information, SIM card status information, and device timestamp. Then, based on the collected current device environmental information, the login SDK generates a structured login signature request and sends it to the security SDK for further processing.

[0097] Step 2: After receiving the login signature request, the security SDK forwards the current device environment information contained therein to the security server.

[0098] Step 3: Based on preset device risk control strategies and security rules, the security server performs in-depth analysis of the current device environment information to generate first device risk summary data. This summary data adopts a privacy-preserving design concept, avoiding the direct inclusion of any original sensitive information and retaining only derived indicators necessary for security decisions. In an optional implementation, the summary data is encapsulated in a structured JSON data format, and its specific content and field configuration can be flexibly adjusted and configured according to actual security needs.

[0099] Step 4: The security SDK receives the first device risk digest data returned by the security server and obtains the private key uniquely corresponding to the current device and the application. This private key is typically embedded within the SDK using a high-security encapsulation method, possessing characteristics of being unexportable and tamper-proof. The security SDK uses this private key to perform encrypted signing processing on the first device risk digest data, obtaining the encrypted and signed second device risk digest data, and returns the second device risk digest data to the login SDK.

[0100] Step 5: When the login SDK invokes the uninstallation login-free process, it retrieves login-free parameter information from the local machine, including but not limited to: 1) Device information: Device GUID (a unique identifier generated and persistently stored by the device), terminal type, operating system version number, device name, device model, etc.; 2) Client information: Client type, client operating system, client version number, client screen information, application name, network type, device basic identifier UUID, SDK version number, application channel information, etc. In addition, it may also include: 3) Login credential information: A2 ticket, user PIN, and other identity credential data; 4) Carrier information: Carrier type, carrier token, country type, and other carrier-related identification data. Therefore, in some cases, login-free parameters may include historical login credentials and service credential information.

[0101] Step 6: The login SDK securely integrates the information obtained above to generate a login-free request and sends it to the login server. This request includes: second device risk summary data, login-free parameters, service credential information returned by the operator's SDK, and historical login credentials. The login SDK can encapsulate this data according to a preset data structure and security protocol to form a complete verification request package.

[0102] Step 7: The login server forwards the second device risk digest data to the security server for security verification. The security server uses the public key corresponding to the private key to perform signature verification and decryption processing on the second device risk digest data, thereby restoring the original first device risk digest data. Subsequently, based on the built-in risk identification mechanism and security policy, the first device risk digest data is subjected to in-depth analysis and processing to determine the current device's risk level. Through this secure flow and verification mechanism of device risk digest data, the legality and security of the uninstallation login-free process can be effectively verified, ensuring the credibility of the entire login-free process.

[0103] Step 8: After receiving the device risk level assessment result from the security server, the login server compares this risk level with a preset level (e.g., set to low to medium risk) to determine whether login is allowed. When the device risk level is less than or equal to the preset level, the login server considers the current device environment secure and trustworthy, and then performs comprehensive login verification processing on the no-login parameters, service credential information, and historical login credentials. If all verification conditions are met (e.g., token validity, user status, device ID consistency, etc.), the login server performs the formal login operation based on the historical login credentials, generates a new login credential, and returns the login credential to the application client. After receiving the login credential, the application client updates and stores it in the local secure storage area for later use.

[0104] This implementation method is specifically applied to the scenario of "secure login credential generation and management server-side signature verification". During request processing, a strict legality verification mechanism ensures the authenticity and security of each login-free request. This solution, through multiple security verification mechanisms, enhances user experience while ensuring the security and reliability of the login process. It effectively solves core security problems existing in current technologies, such as "legality verification relying on a single link, resulting in weak attack resistance" and "the local token mechanism being easily tampered with or forged". By combining device risk analysis technology and local signature verification methods, login-free verification is only allowed when parsing is successful and the risk level is less than or equal to a preset level, significantly enhancing the system's attack resistance. This security architecture not only greatly reduces the risk of user churn due to cumbersome login processes but also improves the overall login success rate. Simultaneously, it effectively prevents illegal requests and malicious attacks, providing comprehensive protection for user account security.

[0105] See Figure 7 The diagram shows the main flowchart of another optional login management method for application clients provided by an embodiment of the present invention, which includes the following steps:

[0106] S701: Obtain the storage time of the login credential and determine the time difference between the storage time and the current time;

[0107] S702: In response to the time difference reaching a preset validity period, a login-free request is generated based on the login credentials and sent to the management server; wherein, the management server performs login verification processing based on the login credentials;

[0108] S703: Receive the new login credentials returned by the management and control server, and update the login credentials based on the new login credentials.

[0109] See Figure 8The diagram shown is a main flowchart of another optional login management method for interaction between an application client and a vendor SDK provided in an embodiment of the present invention. The process includes the following steps:

[0110] Step 1: After successfully uninstalling the login-free installation, the login SDK will use a secure storage module provided by the application vendor (such as iOS Keychain, Android EncryptedSharedPreferences, etc.) to perform local encrypted persistent storage of the login credential information returned by the login server, such as Access_Token, User ID, and validity period. The aforementioned local persistent storage area and the secure storage module mentioned here are functionally equivalent; both are trusted storage areas used to securely store user login credentials.

[0111] Step 2: The login SDK records the timestamp information of the login credentials returned by the management server as the storage time (also known as the write time) of the login credentials. The login SDK continuously monitors the validity of the login credentials. When it detects that the difference between the storage time and the current time reaches the preset validity period (supports dynamic configuration and can be set to half a year, one year or other suitable time period according to business needs), that is, when it is determined that the login credentials are about to expire, the login SDK triggers an automatic refresh mechanism or responds to the user's manual login operation, and initiates a new round of login-free requests to the management server based on the latest login credentials stored in the secure storage module.

[0112] Step 3: After receiving the login-free request from the login SDK, the management server verifies the login operation based on the login credentials carried in the request. Upon successful login verification, the management server generates a new login credential and returns it to the login SDK. Upon receiving the new login credential, the login SDK immediately updates and stores it in the secure storage module, replacing the original expired (or soon-to-expire) login credential. This completes the closed-loop process of automatic login credential refresh and update, ensuring the continuity and security of user login credentials.

[0113] This implementation method is used in the "login state storage and dynamic refresh" scenario to achieve local secure storage and intelligent refresh mechanism for login credentials. By monitoring the validity of login credentials in real time, it triggers a login-free request to refresh the credentials when they are about to expire, effectively avoiding login failures due to expired credentials, reducing the risk of login interruption, and significantly improving application availability and user satisfaction. It supports both user-triggered refresh and automatic refresh modes, with automatic refresh being imperceptible to the user. Simultaneously, the login credential storage area has an application-level protection mechanism to ensure that credentials are securely protected from access by other applications, effectively solving the problem of "difficulty in ensuring consistency of login credentials across multiple terminals and services, and the risk of 'fake login credentials'."

[0114] As an optimized implementation, the login credentials issued by the login server also include device authentication information, and the login SDK binds the login credentials to this device authentication information. Before sending a login-free request to the management server, the login SDK pre-determines whether the device information of the user's currently operating device matches the device authentication information. Only if there is a complete match will a login-free request be generated based on the login credentials and sent to the management server. If the determination result is a mismatch, the login operation will be refused. This device binding verification mechanism effectively prevents the illegal reuse of login credentials across different devices, further improving account security and the credibility of the login process.

[0115] See Figure 9 The diagram shows the main flowchart of another optional login management method for application clients provided by an embodiment of the present invention, which includes the following steps:

[0116] S901: In response to a business request, the login credential is hashed and encrypted with the current device environment information to generate a device signature;

[0117] S902: The device signature and login credentials are sent to the management server for verification via the gateway server. If the verification result is successful, the service request is sent to the service server.

[0118] S903: Receive the business processing result returned by the business server.

[0119] See Figure 10 The diagram shows the main flowchart of another optional login management method applied to a management server provided by an embodiment of the present invention, which includes the following steps:

[0120] S1001: The security server receives a device signature sent by the gateway server; wherein, the device signature is obtained by the application client encrypting and signing the current device environment information and the hash processing result of the login credential;

[0121] S1002: The security server parses the device signature to obtain the current device environment information and the hash processing result, determines the device risk level based on the current device environment information, and returns it to the gateway server.

[0122] S1003: The login server receives a verification request sent by the gateway server when the device risk level is less than or equal to a preset level, and determines that the verification result is passed when the login credential and the hash processing result correspond.

[0123] See Figure 11The diagram shown is a main flowchart of another optional login management method for interaction between an application client and a management server provided by an embodiment of the present invention. The process includes the following steps:

[0124] Step 1: After logging into the application, the user clicks on the corresponding business function module to initiate a specific business request to the application.

[0125] Step 2: The application obtains the currently valid login credentials from the secure storage module provided by the application vendor's SDK through the login SDK, and also obtains the current device environment information; in addition, business components also need to independently obtain the current login credentials from the secure storage module provided by the application vendor's SDK to ensure the independence and security of credential acquisition.

[0126] Step 3: The application performs a hash operation on the "current login credential" obtained by the login SDK to generate a unique login credential hash value. Then, it sends the combined data of the "login credential hash value and current device environment information" to the security SDK. The security SDK uses the private key that uniquely corresponds to the current device and the application to perform encryption and signature processing on the combined data, generate a device signature, and return it to the application.

[0127] Step 4: The application packages the current login credentials obtained by the business components, the device signature generated by the security SDK, and the business request together and sends them to the gateway server.

[0128] Step 5: After receiving the above information, the gateway server forwards the device signature to the security server. The security server uses the public key paired with the private key to parse the device signature, restoring the original login credential hash value and current device environment information. Then, based on the current device environment information, it performs real-time risk assessment analysis to determine the risk level of the current device and returns it to the gateway server. As an optimization method, the processing of the current device environment information here can be found in [reference needed]. Figure 6 The description shown is not repeated here.

[0129] Step 6: The gateway server determines whether the device risk level is less than or equal to the preset level. If the security requirements are met, it forwards the login credential hash value and the current login credential obtained by the business component to the login server for login credential validity verification.

[0130] Step 7: The login server reverse-engineers the login credential based on the received login credential hash value, and then performs a consistency comparison and verification between the login credential and the current login credential obtained by the business component, or it performs hash processing on the current login credential obtained by the business component and completes the credential validity verification by comparing whether the two hash values ​​are the same.

[0131] Step 8: The gateway server receives the credential verification result returned by the login server. Only if the verification result is successful will the original business request be sent to the target business server for specific business logic processing. After completing the business processing, the target business server directly returns the processing result to the application client, forming a complete business processing closed loop.

[0132] This implementation is applied to the "joint verification of legitimacy" scenario, used to jointly verify the legitimacy of the current login credentials and device status before a business request, effectively preventing login credential forgery and improving security levels. This solution implements an end-to-end security verification mechanism for business requests: by combining the login credential hash value with device environment information to generate a device signature, and using asymmetric encryption technology to ensure the authenticity and integrity of the request, this multi-layered security verification method significantly improves the security and reliability of business processing without increasing the user's operational burden. Simultaneously, the collaborative verification mechanism between the gateway server and the management server reduces security risks on the business server side, ensuring the trusted execution of the entire business process.

[0133] As an optimized implementation, the login server can also consider the timestamp information of the login credentials when verifying them, effectively preventing replay attacks through a timestamp verification mechanism. Furthermore, login credentials can be securely bound to device signatures; if the login credentials are detected being used on an unbound device, the request will be rejected, effectively preventing the unauthorized transfer and use of tokens and further enhancing the system's security capabilities.

[0134] In summary, this invention proposes a comprehensive login process that integrates application clients (including login SDK and security SDK), management servers (including security server and login server), carrier SDK, application vendor SDK, gateway server, and business server. This invention comprises four core mechanisms: 1) An uninstallation-based login identification mechanism, which detects user identification information and whether the application is being installed for the first time to determine if the application has been uninstalled and reinstalled, achieving secure login without user awareness; 2) A multi-source login verification mechanism, which integrates device information, risk level, encrypted signatures, and other multi-source data to verify login legitimacy, improving verification accuracy; 3) A trusted login credential storage mechanism, which uses vendor SDKs to ensure encrypted persistent storage and intelligent dynamic updates of login credentials, ensuring system security and data consistency; 4) A legality chain verification mechanism, which achieves a multi-terminal collaborative authentication system through collaborative authentication of the login SDK, security SDK, and server links, providing a "legal, continuous, and secure" passwordless login experience while strictly protecting user privacy.

[0135] This solution also provides several flexible alternative implementation schemes: 1. The one-click login function of the operator can be flexibly replaced with mainstream account systems such as Apple ID and Google ID to adapt to the login requirements of different platforms; 2. The signature generation process of the security SDK can be replaced with a hardware-level signature mechanism based on the device hardware security module (such as Secure Enclave, TEE, etc.), further improving signature security and anti-tampering capabilities; 3. The persistent storage of login credentials can use an encrypted local database (such as SQLite combined with AES encryption algorithm) to replace the vendor SDK, providing developers with more flexibility in technology selection; 4. The legitimacy verification link can be simplified to a single-end verification mode according to actual security needs. Although the security is reduced, it can meet the application scenarios with high performance requirements and relatively low security levels.

[0136] See Figure 12 The diagram shows a schematic of the main modules of a login management device 1200 for application clients provided in an embodiment of the present invention, including:

[0137] The identification module 1201 is used to respond to a login request and determine whether the application is an uninstalled and reinstalled application if there is user identification information corresponding to the application and the application is being installed for the first time.

[0138] Service module 1202 is used to send a request to the service provider to obtain credentials, and to receive service credential information returned by the service provider.

[0139] Request module 1203 is used to send a login-free request to the management server based on the service credential information and the historical login credentials corresponding to the application;

[0140] The update module 1204 is used to receive the login credentials returned by the management server when the login verification is successful, and update the historical login credentials based on the login credentials.

[0141] In the device of this invention, the management server integrates a security server and a login server, and the request module 1203 is used for:

[0142] Obtain the current device environment information and the passwordless parameters corresponding to the application, and send a login-free request to the login server in combination with the service credential information and the historical login credentials;

[0143] The application is installed on the device; the security server determines the device risk level based on the current device environment information, and the login server responds when the device risk level is less than or equal to a preset level, and performs login verification processing on the login-free parameters, the service credential information and the historical login credentials.

[0144] In the apparatus of this invention, the request module 1203 is used for:

[0145] Obtain current device environment information and send it to the security server to receive the first device risk summary data returned by the security server;

[0146] The first device risk digest data is encrypted and signed to obtain the encrypted and signed second device risk digest data.

[0147] Obtain the login-free parameters corresponding to the application, and send a login-free request to the login server in combination with the second device risk summary data, the service credential information, and the historical login credentials; wherein, the security server receives the second device risk summary data sent by the login server and performs parsing processing to obtain the first device risk summary data to determine the device risk level.

[0148] The apparatus for implementing this invention further includes a refresh module, used for:

[0149] Obtain the storage time of the login credential and determine the time difference between the storage time and the current time;

[0150] In response to the time difference reaching a preset validity period, a login-free request is generated based on the login credentials and sent to the management server; wherein, the management server performs login verification processing based on the login credentials;

[0151] Receive the new login credentials returned by the management and control server, and update the login credentials based on the new login credentials.

[0152] In the implementation device of the present invention, the login credential issued by the management and control server also includes device authentication information, and the device further includes: binding and storing the login credential and the device authentication information;

[0153] The refresh module is used to: in response to a user login operation or trigger an automatic refresh operation, obtain current device information, and if the current device information and the device authentication information match, generate a login-free request based on the login credentials and send it to the management and control server.

[0154] In the device of this invention, the management server integrates a security server and a login server. The device also includes a business processing module for:

[0155] In response to a business request, the login credentials are hashed and then encrypted and signed in conjunction with the current device environment information to generate a device signature.

[0156] The gateway server sends the device signature and login credentials to the management server for verification. If the verification result is successful, the business request is sent to the business server.

[0157] Receive the business processing results returned by the business server.

[0158] In the device of this invention, the application client integrates a login component and a security component, wherein,

[0159] The login component is used to perform one or more of the following functions: obtain login credentials, current device environment information, login-free parameters, and perform login verification operations;

[0160] The security component is used to perform one or more of the following functions: performing cryptographic signing operations and parsing operations.

[0161] See Figure 13 The diagram shows the main modules of a login management device 1300 applied to a management server according to an embodiment of the present invention, including:

[0162] The receiving module 1301 is used to receive a login-free request sent by an application client; wherein the application is an uninstalled and reinstalled application, and the login-free request includes service credential information and historical login credentials corresponding to the application, and the service credential information is obtained by requesting the service provider;

[0163] Processing module 1302 is used to perform login verification processing based on the service credential information and the historical login credential;

[0164] The generation module 1303 is used to respond to the login verification result being successful, perform a login operation based on the historical login credentials, obtain login credentials, and return them to the application client for updating and storage.

[0165] In the apparatus of this invention, the login-free request further includes current device environment information and login-free parameters corresponding to the application. The processing module 1302 is used for:

[0166] Based on the current device environment information, the device risk level is determined. In response to the device risk level being less than or equal to a preset level, login verification processing is performed on the login-free parameters, the service authentication information, and the historical login credentials.

[0167] In the apparatus of this invention, the control server integrates a security server and a login server. Before receiving the login-free request sent by the application client, the apparatus further includes a digest data module, used for:

[0168] The security server receives the current device environment information transmitted by the application client and generates first device risk summary data based on the preset device risk control strategy; wherein, the application client performs encryption and signature processing on the first device risk summary data to obtain second device risk summary data;

[0169] The security server receives the second device risk summary data sent by the login server, parses and processes it to obtain the first device risk summary data, determines the device risk level, and returns it to the login server.

[0170] The apparatus for implementing this invention further includes a service verification module, used for:

[0171] The security server receives a device signature sent by the gateway server; wherein, the device signature is obtained by the application client encrypting and signing the current device environment information and the hash processing result of the login credential.

[0172] The security server parses the device signature to obtain the current device environment information and the hash processing result. Based on the current device environment information, it determines the device risk level and returns it to the gateway server.

[0173] The login server receives a verification request sent by the gateway server when the device risk level is less than or equal to a preset level. In response to the login credentials and the hash processing result, the server determines that the verification result is passed.

[0174] Furthermore, the specific implementation details of the device described in the embodiments of the present invention have been described in detail in the above-described method, so the details will not be repeated here.

[0175] Figure 14 An exemplary system architecture 1400 to which embodiments of the present invention can be applied is shown, including terminal devices 1401, 1402, 1403, network 1404, and server 1405 (this is merely an example).

[0176] Terminal devices 1401, 1402, and 1403 can be various electronic devices with displays and support web browsing, and have various communication client applications installed. Users can use terminal devices 1401, 1402, and 1403 to interact with server 1405 through network 1404 to receive or send messages, etc.

[0177] Network 1404 is a medium used to provide a communication link between terminal devices 1401, 1402, 1403 and server 1405. Network 1404 may include various connection types, such as wired or wireless communication links or fiber optic cables, etc.

[0178] Server 1405 can be a server providing various services, such as a backend management server supporting shopping websites browsed by users using terminal devices 1401, 1402, and 1403 (this is just an example). The backend management server can analyze and process received data such as product information query requests, and feed back the processing results (such as target push information and product information—this is just an example) to the terminal devices. It should be noted that the method provided in this embodiment of the invention is generally executed by server 1405, and correspondingly, the apparatus is generally set in server 1405.

[0179] It should be understood that Figure 14 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0180] The following is for reference. Figure 15 It shows a schematic diagram of the structure of a computer system 1500 suitable for implementing a terminal device of the present invention. Figure 15 The terminal device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0181] like Figure 15 As shown, the computer system 1500 includes a central processing unit (CPU) 1501, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 1502 or programs loaded from storage section 1508 into random access memory (RAM) 1503. The RAM 1503 also stores various programs and data required for the operation of the system 1500. The CPU 1501, ROM 1502, and RAM 1503 are interconnected via a bus 1504. An input / output (I / O) interface 1505 is also connected to the bus 1504.

[0182] The following components are connected to I / O interface 1505: an input section 1506 including a keyboard, mouse, etc.; an output section 1507 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 1508 including a hard disk, etc.; and a communication section 1509 including a network interface card such as a LAN card, modem, etc. The communication section 1509 performs communication processing via a network such as the Internet. A drive 1510 is also connected to I / O interface 1505 as needed. Removable media 1511, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 1510 as needed so that computer programs read from them can be installed into storage section 1508 as needed.

[0183] In particular, according to embodiments disclosed in this invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 1509, and / or installed from removable medium 1511. When the computer program is executed by central processing unit (CPU) 1501, it performs the functions defined above in the system of this invention.

[0184] It should be noted that the computer-readable medium shown in this invention can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this invention, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0185] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0186] The modules described in the embodiments of the present invention can be implemented in software or hardware. The described modules can also be housed in a processor; for example, a processor may be described as including an identification module, a service module, a request module, and an update module. The names of these modules do not necessarily limit the module itself; for example, a service module may also be described as a "credential module."

[0187] In another aspect, the present invention also provides a computer-readable medium, which may be included in the device described in the above embodiments; or it may exist independently and not assembled into the device. The computer-readable medium carries one or more programs that, when executed by the device, cause the device to perform any of the login control methods described above.

[0188] The computer program product of the present invention includes a computer program that, when executed by a processor, implements the login management method in the embodiments of the present invention.

[0189] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can occur depending on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A login control method, characterized in that, Applied to an application client, the method includes: In response to a login request, if there is user identification information corresponding to the application and the application is being installed for the first time, it is determined that the application is uninstalled and reinstalled. Send a request to the service provider to obtain credentials, and receive the service credential information returned by the service provider; Based on the service credential information and the historical login credentials corresponding to the application, a login-free request is sent to the management server. Receive the login credentials returned by the management and control server when the login verification is successful, and update the historical login credentials based on the login credentials.

2. The method according to claim 1, characterized in that, The management server integrates a security server and a login server. The step of sending a login-free request to the management server based on the service credential information and the historical login credentials corresponding to the application includes: Obtain the current device environment information and the passwordless parameters corresponding to the application, and send a login-free request to the login server in combination with the service credential information and the historical login credentials; The application is installed on the device; the security server determines the device risk level based on the current device environment information, and the login server responds when the device risk level is less than or equal to a preset level, and performs login verification processing on the login-free parameters, the service credential information and the historical login credentials.

3. The method according to claim 2, characterized in that, The step of obtaining the current device environment information and the passwordless parameters corresponding to the application, and combining them with the service credential information and the historical login credentials, to send a login-free request to the login server includes: Obtain current device environment information and send it to the security server to receive the first device risk summary data returned by the security server; The first device risk digest data is encrypted and signed to obtain the encrypted and signed second device risk digest data. Obtain the login-free parameters corresponding to the application, and send a login-free request to the login server in combination with the second device risk summary data, the service credential information, and the historical login credentials; wherein, the security server receives the second device risk summary data sent by the login server and performs parsing processing to obtain the first device risk summary data to determine the device risk level.

4. The method according to claim 1, characterized in that, After updating the historical login credentials based on the login credentials, the method further includes: Obtain the storage time of the login credential and determine the time difference between the storage time and the current time; In response to the time difference reaching a preset validity period, a login-free request is generated based on the login credentials and sent to the management server; wherein, the management server performs login verification processing based on the login credentials; Receive the new login credentials returned by the management and control server, and update the login credentials based on the new login credentials.

5. The method according to claim 4, characterized in that, The login credentials issued by the control server also include device authentication information, and the method further includes: binding and storing the login credentials and the device authentication information; The step of generating a login-free request based on the login credentials and sending it to the management and control server includes: in response to a user login operation or triggering an automatic refresh operation, obtaining current device information, and if the current device information and the device authentication information match, generating a login-free request based on the login credentials and sending it to the management and control server.

6. The method according to claim 1, characterized in that, The management server integrates a security server and a login server. After updating the historical login credentials based on the login credentials, the method further includes: In response to a business request, the login credentials are hashed and then encrypted and signed in conjunction with the current device environment information to generate a device signature. The gateway server sends the device signature and login credentials to the management server for verification. If the verification result is successful, the business request is sent to the business server. Receive the business processing results returned by the business server.

7. The method according to claim 1, characterized in that, The application client integrates login and security components, among which, The login component is used to perform one or more of the following functions: obtain login credentials, current device environment information, login-free parameters, and perform login verification operations; The security component is used to perform one or more of the following functions: performing cryptographic signing and parsing operations.

8. A login control method, characterized in that, Applied to the management and control server, the method includes: Receive a login-free request sent by an application client; wherein the application is an uninstalled and reinstalled application, and the login-free request includes service credential information and historical login credentials corresponding to the application, and the service credential information is obtained by requesting the service provider; Login verification is performed based on the service credential information and the historical login credentials. In response to a successful login verification, a login operation is performed based on the historical login credentials, and the login credentials are returned to the application client for updating and storage.

9. The method according to claim 8, characterized in that, The login-free request also includes current device environment information and login-free parameters corresponding to the application. The login verification process based on the service credential information and the historical login credentials includes: Based on the current device environment information, the device risk level is determined. In response to the device risk level being less than or equal to a preset level, login verification processing is performed on the login-free parameters, the service authentication information, and the historical login credentials.

10. The method according to claim 9, characterized in that, The management server integrates a security server and a login server. Before receiving the login-free request sent by the application client, the method further includes: The security server receives the current device environment information transmitted by the application client and generates first device risk summary data based on the preset device risk control strategy; wherein, the application client performs encryption and signature processing on the first device risk summary data to obtain second device risk summary data; The step of determining the device risk level based on the current device environment information includes: the security server receiving the second device risk summary data sent by the login server and parsing it to obtain the first device risk summary data to determine the device risk level and returning it to the login server.

11. The method according to claim 9, characterized in that, After obtaining the login credentials and returning them to the application client for storage update, the method further includes: The security server receives a device signature sent by the gateway server; wherein, the device signature is obtained by the application client encrypting and signing the current device environment information and the hash processing result of the login credential. The security server parses the device signature to obtain the current device environment information and the hash processing result. Based on the current device environment information, it determines the device risk level and returns it to the gateway server. The login server receives a verification request sent by the gateway server when the device risk level is less than or equal to a preset level. In response to the login credentials and the hash processing result, the server determines that the verification result is passed.

12. A login control device, characterized in that, The device, used in application clients, includes: The identification module is used to respond to login requests and determine whether the application is uninstalled and reinstalled if there is user identification information corresponding to the application and the application is being installed for the first time. The service module is used to send a request to the service provider to obtain credentials, and to receive service credential information returned by the service provider. The request module is used to send a login-free request to the management server based on the service credential information and the historical login credentials corresponding to the application. The update module is used to receive the login credentials returned by the management server when the login verification is successful, and update the historical login credentials based on the login credentials.

13. A login control device, characterized in that, The device, used in a management and control server, includes: The receiving module is used to receive a login-free request sent by the application client; wherein the application is an uninstalled and reinstalled application, and the login-free request includes service credential information and historical login credentials corresponding to the application, and the service credential information is obtained by requesting the service provider; The processing module is used to perform login verification processing based on the service credential information and the historical login credentials; The generation module is used to respond to a successful login verification result by performing a login operation based on the historical login credentials, obtaining login credentials, and returning them to the application client for updating and storage.

14. An electronic device, characterized in that, include: One or more processors; Storage device for storing one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 1-11.

15. A computer-readable medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1-11.

16. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1-11.

Images