Safe login method, device and system for applet account

Abstract

The invention provides a secure login method, device and system for an applet account, and relates to the technical field of computer communication. The secure login method comprises the following steps: after an applet account successfully logs in a login server, receiving a service request from the applet, the service request comprising an access token, field information in the access token comprises a user identifier generated by a platform server, an account identifier generated by the login server and login time of the applet account, and the account identifier corresponds to the applet account; determining whether the access token is invalid based on the user identifier, the login time of the applet account, a historical user identifier and historical account login time, wherein the historical user identifier and the historical account login time are determined based on the account identifier; and when the access token is invalid, returning a response that the login information of the applet account is expired to the applet.

Description

Technical Field

[0001] This specification relates to the field of computer communication technology, and in particular to a method, device, and system for securely logging into a mini-program account. Background Art

[0002] Mini programs are lightweight applications that can be used without downloading or installing, and can run on application platforms. Some mini programs can be used in the Internet of Things to control devices, for example, using mini programs to unlock a door or control smart appliances. Currently, the method for logging into a mini program account is "one-click login," that is, using the account registered by the user on the application platform to log in to the mini program. However, this will bind the mini program account to the application platform account one-to-one. When the user wants to log in to another mini program account, they need to switch the application platform account to switch the mini program account. Another way to log in to a mini program account is to register a mini program account separately, but the same mini program account may be logged in to different application platform accounts at the same time. Simultaneous operations on multiple terminals may cause session conflicts for the mini program account.

[0003] In view of this, some embodiments of this specification provide a method, device and system for secure login of a mini-program account, aiming to separate the mini-program account from the application platform account and resolve the session conflict problem of the mini-program account. Summary of the Invention

[0004] One or more embodiments of the present specification provide a method for securely logging into a mini-program account, the method comprising: after the mini-program account successfully logs in to the login server, receiving a business request from the mini-program, the business request including an access token, the field information in the access token including a user identifier generated by the platform server, an account identifier generated by the login server, and the login time of the mini-program account, wherein the account identifier corresponds to the mini-program account; determining whether the access token is invalid based on the user identifier, the login time of the mini-program account, the historical user identifier, and the historical account login time, the historical user identifier and the historical account login time being determined based on the account identifier; when the access token is invalid, returning a response to the mini-program indicating that the login information of the mini-program account has expired.

[0005] According to the method provided in one or more embodiments of this specification, whether the access token is invalid is determined based on the user identifier, the login time of the mini-program account, the historical user identifier and the historical account login time, including: when the user identifier is different from the historical user identifier, and the login time of the mini-program account has expired relative to the historical account login time, determining that the access token is invalid; when the user identifier is the same as the historical user identifier, or the login time of the mini-program account has not expired relative to the historical account login time, determining that the access token is not invalid.

[0006] According to the method provided in one or more embodiments of this specification, the login time of the mini program account has expired relative to the login time of the historical account, including: the login time of the mini program account is earlier than or equal to the login time of the historical account; the login time of the mini program account has not expired relative to the login time of the historical account, including: the login time of the mini program account is later than the login time of the historical account.

[0007] The method provided according to one or more embodiments of this specification further includes: when the access token has not expired, updating the historical user identification and historical account login time based on the user identification and the login time of the mini program account.

[0008] The method provided according to one or more embodiments of this specification further includes: when the access token is not invalid, returning a service response to the mini-program based on the service request from the mini-program.

[0009] According to the method provided in one or more embodiments of this specification, the field information in the access token also includes customized additional information and / or the request time of the business request; the field information in the access token is spliced ​​according to its corresponding preset position, and the field information is connected by a connector.

[0010] According to the method provided in one or more embodiments of this specification, the access token is an encrypted token; determining whether the access token is invalid based on the user identification, the login time of the mini-program account, the historical user identification, and the historical account login time includes: decrypting and verifying the access token; when the verification passes, determining whether the access token is invalid based on the user identification, the login time of the mini-program account, the historical user identification, and the historical account login time; when the verification fails, the access token is deemed to be invalid.

[0011] The method provided according to one or more embodiments of the present specification also includes: when receiving a business request from a mini program, detecting whether the received business request contains an access token; when it does not contain an access token, determining the business request that does not contain an access token as an invalid request; the access token is generated by the mini program after receiving a message that the mini program account has successfully logged in to the login server.

[0012] One or more embodiments of the present specification provide a method for securely logging into a mini-program account, the method comprising: receiving an account login success message from a login server, wherein the field information in the account login success message includes a user ID generated by the platform server, an account ID generated by the login server, and the login time of the mini-program account; generating an access token based on the field information in the account login success message; sending a service request containing the access token to a local server, so that the local server determines whether the access token is invalid based on the user ID, the login time of the mini-program account, the historical user ID, and the historical account login time, and returns a response to the mini-program that the login information of the mini-program account has expired when the access token is invalid; receiving response information from the local server, and controlling the mini-program account to go offline when a response is received that the login information of the mini-program account has expired; wherein the account ID corresponds to the mini-program account, and the historical user ID and the historical account login time are determined based on the account ID.

[0013] According to the method provided in one or more embodiments of this specification, whether the access token is invalid is determined based on the user identifier, the login time of the mini-program account, the historical user identifier and the historical account login time, including: when the user identifier is different from the historical user identifier, and the login time of the mini-program account has expired relative to the historical account login time, determining that the access token is invalid; when the user identifier is the same as the historical user identifier, or the login time of the mini-program account has not expired relative to the historical account login time, determining that the access token is not invalid.

[0014] According to the method provided in one or more embodiments of this specification, the login time of the mini program account has expired relative to the login time of the historical account, including: the login time of the mini program account is earlier than or equal to the login time of the historical account; the login time of the mini program account has not expired relative to the login time of the historical account, including: the login time of the mini program account is later than the login time of the historical account.

[0015] According to the method provided in one or more embodiments of the present specification, the field information in the account login success message also includes customized additional information, and generating an access token based on the field information in the account login success message includes: generating an access token based on the user ID, account ID, login time of the mini program account and at least one of the following information: customized additional information, request time of the business request; generating an access token includes: splicing the field information in the access token according to its corresponding preset position, and connecting the field information through a connector.

[0016] According to the method provided in one or more embodiments of this specification, before receiving the account login success message from the login server, it also includes: obtaining temporary login credentials; sending a login request to the login server, the login request including the temporary login credentials, the mini program account and the login password, so that the login server can perform verification based on the mini program account and login password, and when the verification is successful, obtain the user identification from the platform server based on the temporary login credentials, and send an account login success message to the mini program.

[0017] One or more embodiments of the present specification also provide a secure login device for a mini-program account, which includes: a receiving module for receiving a business request from the mini-program after the mini-program account successfully logs in to the login server, the business request including an access token, and the field information in the access token including the user ID generated by the platform server, the account ID generated by the login server, and the login time of the mini-program account, wherein the account ID corresponds to the mini-program account; a determination module for determining whether the access token is invalid based on the user ID, the login time of the mini-program account, the historical user ID, and the historical account login time, wherein the historical user ID and the historical account login time are determined based on the account ID; a response module for returning a response to the mini-program that the login information of the mini-program account has expired when the access token is invalid.

[0018] One or more embodiments of the present specification also provide a secure login device for a mini-program account, the device comprising: a receiving module for receiving an account login success message from a login server, the field information in the account login success message including a user identifier generated by the platform server, an account identifier generated by the login server, and the login time of the mini-program account; a generating module for generating an access token based on the field information in the account login success message; a sending module for sending a business request containing an access token to a local server, so that the local server determines whether the access token is invalid based on the user identifier, the login time of the mini-program account, the historical user identifier, and the historical account login time, and returns a response to the mini-program that the login information of the mini-program account has expired when the access token is invalid; an offline module for receiving response information from the local server, and controlling the mini-program account to go offline when a response is received that the login information of the mini-program account has expired; wherein, the account identifier corresponds to the mini-program account, and the historical user identifier and the historical account login time are determined based on the account identifier.

[0019] One or more embodiments of the present specification also provide a secure login system for a mini-program account, the system comprising a mini-program, a login server, a local server, and a platform server; the login server is configured to receive a login request from the mini-program and verify the login request, and when the verification is successful, sends a request to the platform server to obtain a user ID, and sends an account login success message to the mini-program, wherein the field information in the account login success message includes the user ID generated by the platform server, the account ID generated by the login server, and the login time of the mini-program account; the mini-program is configured to receive the account login success message from the login server, and based on the account login success message, The platform server generates an access token based on the field information in the , and sends a business request containing the access token to the local server; the local server is used to receive business requests from the mini program, determine whether the access token is invalid based on the user ID, the login time of the mini program account, the historical user ID and the historical account login time, and return a response to the mini program that the login information of the mini program account has expired when the access token is invalid; the platform server is used to send the user ID to the login server when receiving a request to obtain the user ID sent by the login server; wherein, the account ID corresponds to the mini program account, and the historical user ID and the historical account login time are determined based on the account ID.

[0020] One or more embodiments of this specification also provide a computer program product, including a computer program, which, when at least a portion of the computer program is executed by a processor, can implement the secure login method for the mini-program account described in some embodiments of this specification. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] This specification will be further described in the form of exemplary embodiments, which will be described in detail with reference to the accompanying drawings. The same numbers in the drawings represent the same structures or steps.

[0022] Figure 1 This is a schematic diagram of a secure login system for a mini-program account according to some embodiments of this specification.

[0023] Figure 2 This is an exemplary flowchart of a method for securely logging into a mini-program account according to some embodiments of this specification.

[0024] Figure 3 This is an exemplary flowchart of another method for securely logging into a mini-program account according to some embodiments of this specification.

[0025] Figure 4 This is an exemplary flowchart of another method for securely logging into a mini-program account according to some embodiments of this specification.

[0026] Figure 5This is an exemplary block diagram of a secure login device for a mini-program account according to some embodiments of this specification.

[0027] Figure 6 This is an exemplary block diagram of another secure login device for a mini-program account according to some embodiments of this specification.

[0028] Figure 7 This is a schematic diagram of a secure login system for a mini-program account according to some embodiments of this specification. DETAILED DESCRIPTION

[0029] To more clearly illustrate the technical solutions of the embodiments of this specification, the embodiments will be described in detail below with reference to the accompanying drawings. Obviously, the following descriptions are some examples or embodiments of this specification, and those skilled in the art can apply the technical solutions or methods disclosed in this specification to other scenarios based on these technical contents without inventive effort.

[0030] It should be understood that the terms "system," "device," "unit," and / or "module" used in this specification are a method for distinguishing different components, elements, parts, portions, or assemblies at different levels. However, if other terms can achieve the same purpose, the terms may be replaced by other expressions.

[0031] Unless otherwise specified, technical terms used in this specification to describe components, elements, and the like do not necessarily refer to the singular but may include the plural. Generally speaking, terms such as "include" and "comprising" only indicate the inclusion of the steps, elements, or components specifically identified, and these steps, elements, and components do not constitute an exclusive list. For example, the method or device being described may also include other steps or components.

[0032] Mini programs are lightweight applications that can be used without downloading or installing. They can run on an application platform. The application platform can be an application that provides the operating environment and technical support for the mini program. For example, the application platform can be WeChat, and the mini program can run on WeChat. Some mini programs can be used in the Internet of Things to control devices, for example, using a mini program to unlock a door or control smart appliances.

[0033] In some relevant embodiments, the method for logging into a mini-program account may be "one-click login", that is, using the account registered by the user on the application platform to log in to the mini-program. However, this will bind the mini-program account to the application platform account one-to-one. When the user wants to log in to other mini-program accounts, it is necessary to switch the application platform account to achieve the switch of the mini-program account, and the "one-click login" method cannot share the use rights of the mini-program account. Another method of logging into a mini-program account may be to register a mini-program account separately to avoid binding with the application platform account, but the same mini-program account may be logged in to different application platform accounts at the same time, and simultaneous operation of multiple terminals may cause session conflicts of the mini-program account.

[0034] To this end, some embodiments of this specification provide a method, device, and system for securely logging into a mini-program account. After a mini-program account successfully logs in to a login server, the local server receives a service request from the mini-program. The service request includes an access token. The field information in the access token includes a user ID generated by the platform server, an account ID generated by the login server, and the login time of the mini-program account. Furthermore, the local server determines whether the access token is invalid based on the user ID, the login time of the mini-program account, the historical user ID, and the historical account login time. When the access token is invalid, a response is returned to the mini-program indicating that the login information of the mini-program account has expired. This controls the login status of the mini-program account, separates the mini-program account from the application platform account, and resolves the session conflict problem of the mini-program account.

[0035] Figure 1 This is a schematic diagram of a secure login system for a mini-program account according to some embodiments of this specification. Figure 1 As shown, the secure login system 100 for mini-program accounts may include a mini-program 110, a login server 120, a local server 130, a platform server 140, and a network 150. The mini-program 110, the login server 120, the local server 130, and the platform server 140 may perform data transmission via the network 150.

[0036] The network 150 may be any form of wired or wireless network, or any combination thereof. For example only, the network 150 may be a wired network, a fiber optic network, a telecommunications network, an intranet, the Internet, a local area network (LAN), a wide area network (WAN), a wireless local area network (WLAN), a metropolitan area network (MAN), a public switched telephone network (PSTN), a Bluetooth network, or a combination thereof. The network 150 may have multiple access points, and the mini-program 110, the login server 120, the local server 130, and the platform server 140 may access the network 150 through the access points.

[0037] The mini-program 110 can be a lightweight application that can be installed and run in a user terminal. The user terminal can support the installation and operation of an application platform, which can be a technical platform that can support the development and operation of a variety of lightweight applications. Exemplary, the application platform can be WeChat, which can support the development and operation of a variety of lightweight applications (such as the mini-program 110). In some embodiments, the user terminal can be a desktop computer, a smart phone, a laptop computer, and a tablet computer. The user can install the application platform in the user terminal, run the mini-program 110 in the application platform to enter the operation interface, and interact with the display interface of the mini-program 110 through an input device (such as a keyboard, mouse, touch screen, microphone, etc.). The mini-program 110 can store data based on the interactive operation, or transmit data to the login server 120, the local server 130, and the platform server 140 through the network 150. For example, the mini-program 110 can send a login request to the login server 120 and receive a response from the login server 120. When receiving the account login success message from the login server 120 , the mini program 110 can generate an access token based on the field information in the account login success message and send a service request containing the access token to the local server 130 .

[0038] The login server 120 can be a computer device with high computing performance. In some embodiments, the login server 120 can be a cloud server, which can be a single computer device or a computing cluster composed of multiple computer devices, thereby providing more powerful computing power and more efficient response to user service requests. In some embodiments, the login server 120 can transmit data with the mini program 110 and the platform server 140 to maintain, manage and store data related to the mini program 110. For example, the login server 120 can receive a login request from the mini program 110 and verify the login request. When the verification is successful, it receives a user identification from the platform server 140 and sends an account login success message to the mini program 110.

[0039] The local server 130 can be another server that is set up independently of the login server 120. According to different service requirements, local servers corresponding to the area can be deployed in one or more areas. In some embodiments, the local server 130 can transmit data with the mini program 110, and the local server 130 can be used to perform business operations related to high real-time, high security or hardware interaction. For example, the local server 130 can receive a business request from the mini program 110, and determine whether the access token in the business request is invalid based on the user identifier in the business request, the login time of the mini program account, and the historical user identifier and historical account login time pre-stored in the local server 130, thereby judging the validity of the business request locally. When the access token is invalid, the local server 130 can return a response to the mini program 110 that the login information of the mini program account has expired. In other embodiments, the local server 130 can also be integrated with the login server 120 to transmit data with the mini program 110 and the platform server 140 as a whole server.

[0040] The platform server 140 may be a server that provides services for the application platform. In some embodiments, the platform server 140 may return corresponding data according to the request initiated by the login server 120, thereby performing data transmission with the login server 120.

[0041] Figure 2 This is an exemplary flow chart of a method for securely logging into a mini-program account according to some embodiments of this specification. In some embodiments, Figure 2 The process 200 shown can be implemented by multiple execution devices. Specifically, the process 200 can be implemented by the mini program 110, the login server 120, the local server 130 and the platform server 140 in the secure login system 100 of the mini program account. Figure 2 As shown, the process 200 may include the following steps.

[0042] In step 210, the applet obtains temporary login credentials and sends a login request to the login server.

[0043] In some embodiments, the temporary login credential can be a character string with a certain validity period that is dynamically generated by the platform server 140. For example, the mini program 110 can call the login interface provided by the application platform to request the platform server 140 to obtain the temporary login credential. The login interface can be, for example, wx.login(). The platform server 140 can respond to the request, generate a temporary login credential, and return the temporary login credential to the mini program 110. For example, the platform server 140 can return a temporary login credential code to the mini program 110. The validity period of the temporary login credential code can be, for example, five minutes.

[0044] In some embodiments, the login request may include temporary login credentials, a mini-program account, and a login password. The mini-program account may be an identifier used for login, such as a mobile phone number, email address, or custom username. The login password may correspond to the mini-program account, allowing the login server 120 to perform verification based on the mini-program account and the corresponding login password.

[0045] In step 220, the login server performs verification based on the mini-program account and login password, and when the verification is successful, sends a request to the platform server to obtain the user identification based on the temporary login credentials.

[0046] In some embodiments, the database of login server 120 may store user-registered mini-program accounts and corresponding login passwords. Upon receiving a login request from mini-program 110, login server 120 may compare the mini-program account and login password in the login request with the mini-program account and login password pre-stored in the database. If the comparison results are consistent, verification of the mini-program account and login password is determined to be successful.

[0047] In some embodiments, when the verification of the mini program account and login password is passed, the login server 120 can send a request to obtain the user identification to the platform server 140 using the temporary login credentials, the mini program identifier, and the mini program key corresponding to the mini program identifier as parameters. Among them, the request to obtain the user identification can be sent by calling the interface provided by the platform server 140 (such as code2Session in WeChat). The mini program identifier (such as appId) can be used to identify the mini program identity, and the mini program key (such as appSecret) can correspond to the mini program identifier for legitimacy authentication. In some embodiments, when the verification of the mini program account and login password fails, the login server 120 can return a login failure response to the mini program.

[0048] By setting up a login server and verifying the Mini Program account and login password on the login server, the Mini Program account is separated from the application platform account, avoiding the binding of the Mini Program account to the application platform account. Users can switch Mini Program accounts without having to switch application platform accounts. Because the Mini Program account is separated from the application platform account, different application platform accounts can share the use rights of the same Mini Program account.

[0049] Step 230: The platform server sends the user ID to the login server.

[0050] In some embodiments, after the platform server 140 receives the request for obtaining the user identifier sent by the login server 120, it can perform a legitimacy authentication based on the mini-program identifier and the mini-program key. When the authentication is successful, the platform server 140 can further determine whether the temporary login credential is within the validity period. If the temporary login credential is within the validity period, it searches for the corresponding user identifier based on the temporary login credential and sends the user identifier to the login server 120. In some embodiments, when generating the temporary login credential, the platform server 140 can establish a mapping relationship between the temporary login credential and the user identifier, and return the corresponding user identifier when receiving a request for obtaining the user identifier within the validity period of the temporary login credential.

[0051] In some embodiments, a user ID can be generated by the platform server 140 and corresponds to an application platform account and a mini-program running on the application platform, representing the unique identity of a user within a particular mini-program of a particular application platform account. For the same mini-program, different application platform accounts correspond to different user IDs. For example, a user ID can be openId1 corresponding to WeChat account A and mini-program a. When WeChat account A switches to B, the identity ID corresponding to WeChat account B and mini-program a switches to openId2.

[0052] Step 240: The login server sends a successful account login message to the mini program.

[0053] In some embodiments, the login server 120 sends an account login success message to the mini program 110, and accordingly, the mini program 110 receives the account login success message from the login server 120. In some embodiments, the field information in the account login success message may include the user identifier generated by the platform server 140, the account identifier generated by the login server 120, and the login time of the mini program account. In some embodiments, the account identifier can be generated by the login server 120 and corresponds to the mini program account, indicating the unique identity of the user in a certain mini program. Exemplarily, the account identifier can be userId1 corresponding to the mini program account 1. In some embodiments, the login time of the mini program account can be the time when the login server 120 successfully verifies the mini program account and login password.

[0054] In some embodiments, the field information in the successful account login message may also include customized additional information. The customized additional information may be determined based on business needs, for example, the additional information may be a mobile phone number, ID number, information related to the encryption algorithm, etc.

[0055] In step 250 , the mini program generates an access token based on the field information in the account login success message, and sends a service request containing the access token to the local server.

[0056] In some embodiments, the mini program 110 generates an access token based on the field information in the account login success message, and sends a business request containing the access token to the local server 130. Accordingly, the local server 130 receives the business request from the mini program 110.

[0057] In some embodiments, the mini program 110 can generate an access token based on the user identifier, account identifier and login time of the mini program account in the account login success message. Among them, the account identifier can correspond to the historical user identifier and historical account login time stored in the local server 130, so that the local server 130 can find the corresponding historical user identifier and historical account login time based on the account identifier when determining whether the access token is invalid. The user identifier and account identifier are added to the access token, and the access token is carried when sending a business request. Subsequently, the local server 130 can determine whether the access token is invalid based on the user identifier and account identifier, thereby determining whether the mini program account currently sending the business request needs to be forced offline, thereby solving the session conflict problem of the mini program account.

[0058] In other embodiments, the mini program 110 may also generate an access token based on the user ID, account ID, login time of the mini program account, and at least one of the following information: customized additional information, request time of the business request. Among them, the request time of the business request may be the time when the mini program 110 initiates the business request. Adding customized additional information to the access token can improve the flexibility and scalability of the access token. Adding the request time of the business request to the access token can increase the randomness of the access token. After the access token is encrypted, the predictability of the ciphertext token can be reduced, thereby improving the security of the access token.

[0059] In some embodiments, the mini-program 110 can concatenate the information of each field according to a preset structure to form an access token. For example, the mini-program 110 can concatenate the information of each field in the access token according to its corresponding preset position, and the information of each field can be connected by a connector to form a string. The connector can be any custom character, such as "&", "-", etc.

[0060] In some embodiments, the preset positions corresponding to the information in each field may be fixed character positions in the access token. For example, the mth character position to the m+Nth character position in the access token are determined as the position of the account identifier, the m+N+1th character position in the access token is determined as the connector, and the m+N+2th character position to the m+2N+2th character position in the access token is determined as the position of the user identifier. In some embodiments, a start character may be added to the head of the access token and a terminator may be added to the tail of the access token. The start character and terminator may be used to identify the boundaries of the access token to ensure data integrity.

[0061] For example, assuming that in the access token, the first two characters are used to store the start character, followed by an N-character account identifier (userId), an N-character user identifier (openId), a 10-digit login time of the mini-program account (loginDate), N-character additional information (extInfo), and a 10-digit request time (timestamp) of the business request, and the last two characters are used to store the terminator. The information in each field is connected by a 1-bit connector. The structure of the access token can be as shown in Table 1.

[0062] Table 1:

[0063] It should be noted that the information in the first row of Table 1 is the information actually stored in the access token, and the information in the second row of Table 1 is only used to illustrate the specific number of bits occupied by the field information, connectors, start characters, and end characters in the first row, and is not the information actually stored in the access token.

[0064] In some embodiments, the preset position corresponding to each field information may also be the order in which the field information is arranged. For example, the above field information is spliced ​​together in the order of account ID, user ID, mini program account login time, customized additional information, and service request time. The field information can be connected by a connector, and a start symbol is added to the head of the access token and a terminator is added to the tail of the access token.

[0065] In some embodiments, the mini-program 110 may also encrypt the access token according to an agreed encryption algorithm and corresponding key to obtain a ciphertext token. For example, the encryption algorithm may be AES, DES, SM3, SM4, etc. When the mini-program 110 initiates a service request to the local server 130, the encrypted access token may be added to the request header of the service request. In some embodiments, the service request may be a request to unlock a door, add a magnetic card, etc.

[0066] In step 260 , the local server determines whether the access token is invalid based on the user ID, the login time of the mini program account, the historical user ID, and the historical account login time.

[0067] In some embodiments, when the local server 130 receives a service request from the mini-program 110, the local server 130 may first detect whether the request header contains an access token. If the request header does not contain an access token, the service request without an access token is deemed invalid and no further processing is performed. If the request header contains an access token, the access token may be decrypted and verified.

[0068] In some embodiments, the local server 130 can decrypt the encrypted access token according to the agreed encryption algorithm and corresponding key to obtain a plaintext token. Exemplary encryption algorithms can be AES, DES, SM3, SM4, etc., which can be the same encryption algorithm used by the mini-program 110 to encrypt the access token.

[0069] In some embodiments, after the local server 130 decrypts the access token, it can further perform a regular check on the structure of the decrypted access token. Exemplarily, the local server 130 can verify the length, character type, specific prefix and suffix (such as the start and end characters in the access token), connector, etc. of the decrypted access token to ensure the validity of the access token and exclude illegal access tokens. When the verification fails, the access token can be considered invalid, and the local server 130 can return a response to the mini program 110 that the login information has expired and needs to be re-logined. When the verification passes, the local server 130 can determine whether the access token is invalid based on the user ID, the login time of the mini program account, the historical user ID, and the historical account login time.

[0070] In some embodiments, the historical user identifier and the historical account login time can be the user identifier and the login time of the mini-program account saved when the local server 130 last determined that the access token was not expired, and a correspondence between the historical user identifier, the historical account login time and the account identifier is established when saving, so that the corresponding historical user identifier and the historical account login time can be found based on the account identifier when determining whether the access token is expired next time.

[0071] In some embodiments, when the user identifier is different from the historical user identifier and the login time of the mini program account has expired relative to the login time of the historical account, it can be determined that the access token has expired. Among them, determining that the login time of the mini program account has expired relative to the login time of the historical account can be that the login time of the mini program account is earlier than or equal to the login time of the historical account. Exemplarily, assuming that the login time of the mini program account is 12:00:00 and the login time of the historical account is 12:05:00, it is determined that the login time of the mini program account has expired relative to the login time of the historical account.

[0072] In some embodiments, when the user identifier is the same as the historical user identifier, or the login time of the mini program account has not expired relative to the login time of the historical account, it is determined that the access token has not expired. Among them, the login time of the mini program account has not expired relative to the login time of the historical account can be that the login time of the mini program account is later than the login time of the historical account. For example, assuming that the login time of the mini program account is 12:00:00 and the login time of the historical account is 11:30:00, it is determined that the login time of the mini program account has not expired relative to the login time of the historical account.

[0073] Since the user ID corresponds to the application platform account and the mini program, when the user ID is different from the historical user ID, it means that the same mini program account has successfully logged in to the mini program of the new application platform account. At this time, it is necessary to combine the login time of the mini program account to determine whether the mini program account currently sending the business request is the original logged-in mini program account or the newly logged-in mini program account. When the login time of the mini program account has expired, it means that the mini program account currently sending the business request is the original logged-in mini program account, then it is determined that the access token has expired. When the login time of the mini program account has not expired, it means that the mini program account currently sending the business request is the newly logged-in mini program account, then it is determined that the access token has not expired. When the user ID is the same as the historical user ID, it means that the current mini program account has logged in to the mini program of the same application platform account twice, and there will not be a situation where the mini program account is logged in in multiple places at the same time, then it is determined that the access token has not expired.

[0074] In step 270 , when the access token expires, the local server returns a response to the mini program indicating that the login information of the mini program account has expired.

[0075] In some embodiments, when the access token expires, the local server 130 may return a response to the mini-program 110 indicating that the login information of the mini-program account has expired. For example, the local server 130 may return a relevant error code to the mini-program 110, indicating that the login information of the mini-program account has expired and that re-login is required.

[0076] Step 280: When the access token is not expired, the local server returns a service response to the mini program based on the service request from the mini program.

[0077] In some embodiments, the service request may be a request to unlock a door, add a magnetic card, etc. The local server 130 may perform corresponding service processing based on the service request, for example, controlling the smart door lock to unlock, adding a magnetic card, etc., and return a corresponding service response to the mini program based on the service processing result.

[0078] In some embodiments, when the access token is not expired, the local server 130 may also update the historical user identifier and historical account login time based on the user identifier and the login time of the mini-program account. For example, assuming that the account identifier is userId1, the user identifier in the access token and the login time of the mini-program account are openId1 and 12:00:00 respectively, and the historical user identifier and historical account login time corresponding to userId1 are openId2 and 11:00:00 respectively. When the access token is not expired, the historical user identifier and historical account login time corresponding to userId1 may be updated to openId1 and 12:00:00 respectively.

[0079] In step 290, the mini program receives a response from the local server. When a response is received indicating that the login information of the mini program account has expired, the mini program account is controlled to go offline.

[0080] In some embodiments, mini-program 110 can receive a response from local server 130. When the response is a business response, mini-program 110 can perform different processing based on the content of the business response, such as updating the door lock status to "unlocked" or displaying "failed to add magnetic card." If the response indicates that the login information has expired, the mini-program account can be logged off, thereby resolving session conflicts.

[0081] The following is a further explanation of the secure login method for a mini-program account with reference to specific examples. Assume that the mini-program account corresponding to the mini-program a of a user A in the application platform account A is mini-program account 1, the user identifier corresponding to the mini-program a in the application platform account A is openId1, and the account identifier corresponding to the mini-program account 1 is userId1. When the mini-program account 1 successfully logs in, the mini-program 110 generates an access token 1, the user identifier in the access token 1 is openId1, the account identifier is userId1, and the login time of the mini-program account is 12:00:00. The historical user identifier and historical account login time corresponding to userId1 stored in the local server 130 are openId1 and 11:00:00 respectively. Since the user identifier in the access token 1 is the same as the historical user identifier corresponding to userId1, the local server 130 determines that the access token 1 has not expired, and updates the historical user identifier and historical account login time corresponding to userId1 to openId1 and 12:00:00. Assume that user A's classmate user B also successfully logs into user A's mini program account in mini program a in application platform account B, that is, mini program account 1. The user identifier corresponding to mini program a in application platform account B is openId2. Mini program 110 generates access token 2. The user identifier in access token 2 is openId2, the account identifier is userId1, and the login time of the mini program account is 12:10:00. At this time, the historical user identifier and historical account login time corresponding to userId1 stored in the local server 130 are openId1 and 12:00:00 respectively. The user identifier openId2 is different from the historical user identifier openId1, but the login time of the mini program account 12:10:00 has not expired relative to the historical account login time 12:00:00. The local server 130 determines that the access token 2 has not expired, and updates the historical user identifier and historical account login time corresponding to userId1 to openId2 and 12:10:00. The local server 130 performs corresponding business processing based on the business request (such as unlocking) and returns a business response to the mini program 110. The mini program 110 receives the business response and updates the door lock status to "unlocked".At this time, the mini program account 1 of user A is still in the login state, and the information in the access token 1 has not changed. When the mini program 110 corresponding to user A sends a business request containing the access token 1 to the local server 130 again (for example, unlocking), the user identifier openId1 in the access token 1 is different from the historical user identifier openId2 corresponding to userId1. The login time of the mini program account in the access token 1, 12:00:00, has expired relative to the login time of the historical account corresponding to userId1, 12:10:00. Then the local server 130 determines that the access token 1 is invalid, and returns a response to the mini program 110 that the login information of the mini program account has expired. The mini program 110 controls the mini program account of user A to go offline. It can be seen that by adding the access token to the business request and comparing the user identifier and the login time of the mini program account with the historical user identifier and the historical account login time, it is determined whether the current access token is invalid. In this way, it is possible to determine whether the current mini program account is logged in to the new platform account, and at the same time determine whether the current mini program account is the mini program account that needs to be offline, thereby solving the session conflict problem of the mini program account. In addition, when the same mini program account successfully logs in at multiple locations at the same time, the local server does not directly determine that the access token has expired. Instead, when the mini program account that needs to go offline issues a business request containing the access token again, the local server determines that the access token is invalid, and then the mini program controls the mini program account to go offline, thus achieving progressive session transfer. The local server also does not need to maintain the session status of all devices. Instead, when receiving a business request, it determines whether to respond to the business request or determine that the access token is invalid, and then determines whether to go offline the current mini program account. This simplifies the data processing operations of the local server and improves the efficiency of the local server in processing data.

[0082] Some embodiments of this specification adapt to scenarios requiring localized services, such as unlocking a door with a mini-program or controlling smart appliances, by verifying the mini-program account on a login server and determining whether the access token has expired on a local server. The local server can also store sensitive data, avoiding uploading it to the cloud and improving data security and privacy. Furthermore, by having the local server determine whether the access token has expired and, if so, performing corresponding business processing based on the business request, the real-time nature of business request processing can be improved.

[0083] Figure 3 This is an exemplary flow chart of another method for securely logging into a mini-program account according to some embodiments of this specification. In some embodiments, Figure 3 The process 300 shown can be executed by the local server 130. Figure 3 As shown, the process 300 may include the following steps.

[0084] Step 310 : After the mini program account successfully logs in to the login server, a service request from the mini program is received. In some embodiments, step 310 may be implemented by the first receiving module 510 .

[0085] In some embodiments, the business request may include an access token, and the field information in the access token may include a user identifier generated by the platform server 140, an account identifier generated by the login server 120, and the login time of the mini-program account, wherein the account identifier corresponds to the mini-program account. In other embodiments, the field information in the access token also includes customized additional information and / or the request time of the business request. For relevant instructions on the access token, the field information in the access token, the business request, and how the mini-program account logs in to the login server, please refer to the description of steps 210 to 250 above and will not be repeated here.

[0086] In some embodiments, the access token can be generated by mini-program 110 after receiving a message indicating that the mini-program account has successfully logged in from login server 120. In some embodiments, mini-program 110 can generate the access token based on the field information in the successful account login message and send a service request containing the access token to local server 130. In response, local server 130 receives the service request from mini-program 110. For a detailed description of this part, please refer to the description of step 250 above and will not be repeated here.

[0087] In some embodiments, when the local server 130 receives a business request from the mini program 110, the local server 130 can first detect whether the received business request contains an access token. If it does not contain an access token, the business request is determined to be an invalid request and no subsequent processing is performed.

[0088] Step 320 : Determine whether the access token is invalid based on the user ID, the login time of the mini program account, the historical user ID, and the historical account login time. In some embodiments, step 320 may be implemented by the determination module 520 .

[0089] In some embodiments, the historical user ID and historical account login time can be determined based on the account ID. In some embodiments, the local server 130 determines whether the access token is invalid based on the user ID, the login time of the mini program account, the historical user ID, and the historical account login time. For a detailed description of this part, please refer to the description of step 260 above and will not be repeated here.

[0090] Step 330 : When the access token expires, a response is returned to the mini program indicating that the login information of the mini program account has expired. In some embodiments, step 330 may be implemented by the response module 530 .

[0091] In some embodiments, when the access token expires, the local server 130 may return a response to the mini program 110 indicating that the login information of the mini program account has expired. For a detailed description of this part, please refer to the description of step 270 above and will not be repeated here.

[0092] In some embodiments, when the access token is not expired, the local server 130 returns a business response to the mini program 110 based on the business request from the mini program 110. For a specific description of this part, please refer to the description in step 280 above, which will not be repeated here. In some embodiments, when the access token is not expired, the local server 130 updates the historical user ID and historical account login time based on the user ID and the login time of the mini program account. For a specific description of this part, please refer to the description in step 280 above, which will not be repeated here.

[0093] Figure 4 This is an exemplary flow chart of another method for securely logging into a mini-program account according to some embodiments of this specification. In some embodiments, Figure 4 The process 400 shown can be executed by the applet 110. Figure 4 As shown, process 400 may include the following steps.

[0094] Step 410 , receiving a successful account login message from the login server. In some embodiments, step 410 may be implemented by the second receiving module 610 .

[0095] In some embodiments, the field information in the successful account login message may include the user ID generated by the platform server 140, the account ID generated by the login server 120, and the login time of the mini-program account. For a detailed description of this part, please refer to the description of step 240 above and will not be repeated here.

[0096] In some embodiments, the login server 120 may send a successful account login message to the mini program 110. Accordingly, the mini program 110 receives the successful account login message from the login server 120. For a detailed description of this part, please refer to the description of step 240 above and will not be repeated here.

[0097] In some embodiments, before receiving the successful account login message from the login server 120, the mini program 110 may also obtain temporary login credentials and send a login request to the login server 120. For a detailed description of this part, please refer to the description of step 210 above and will not be repeated here.

[0098] In some embodiments, the login request may include temporary login credentials, mini-program account and login password, so that the login server 120 performs verification based on the mini-program account and login password, and when the verification is successful, obtains the user identification from the platform server 140 based on the temporary login credentials, and sends an account login success message to the mini-program 110. For more descriptions about the login request, please refer to the description in step 210 above, which will not be repeated here. For a specific description about the login server 120 performing verification based on the mini-program account and login password, and when the verification is successful, sending a request to obtain the user identification to the platform server 140 based on the temporary login credentials, please refer to the description in step 220 above, which will not be repeated here. For a specific description about the login server 120 sending an account login success message to the mini-program 110, please refer to the description in step 240 above, which will not be repeated here.

[0099] Step 420 : Generate an access token based on the field information in the account login success message. In some embodiments, step 420 may be implemented by the generation module 620 .

[0100] In some embodiments, the mini-program 110 generates an access token based on the field information in the account login success message. For a detailed description of this part, please refer to the description of step 250 above and will not be repeated here.

[0101] Step 430 : Send a service request including the access token to the local server. In some embodiments, step 430 may be implemented by the first sending module 630 .

[0102] In some embodiments, the mini program 110 sends a business request containing an access token to the local server 130, so that the local server 130 determines whether the access token is invalid based on the user identifier, the login time of the mini program account, the historical user identifier, and the historical account login time, and returns a response to the mini program that the login information of the mini program account has expired when the access token is invalid. For a specific description of the mini program 110 sending a business request containing an access token to the local server 130, please refer to the description in step 250 above, which will not be repeated here. For a specific description of the local server 130 determining whether the access token is invalid based on the user identifier, the login time of the mini program account, the historical user identifier, and the historical account login time, and returning a response to the mini program that the login information of the mini program account has expired when the access token is invalid, please refer to the description in steps 260 to 270 above, which will not be repeated here.

[0103] Step 440 , receiving a response from the local server, and when receiving a response indicating that the login information of the mini program account has expired, controlling the mini program account to go offline. In some embodiments, step 440 can be implemented by the offline module 640 .

[0104] In some embodiments, the mini program 110 receives a response from the local server 130. When receiving a response indicating that the login information of the mini program account has expired, the mini program account is controlled to go offline. For a detailed description of this part, please refer to the description of step 290 above and will not be repeated here.

[0105] This manual also provides a secure login device for a mini-program account. Figure 5 This is an exemplary block diagram of a secure login device for a mini-program account according to some embodiments of this specification. In some embodiments, the secure login device 500 for a mini-program account can be deployed in the local server 130. Figure 5 As shown, in some embodiments, the secure login device 500 for a mini-program account may include a first receiving module 510 , a determination module 520 and a response module 530 .

[0106] The first receiving module 510 is used to receive a business request from the mini program after the mini program account successfully logs in to the login server. The business request includes an access token. The field information in the access token includes the user ID generated by the platform server, the account ID generated by the login server, and the login time of the mini program account, where the account ID corresponds to the mini program account.

[0107] The determination module 520 is used to determine whether the access token is invalid based on the user identifier, the login time of the mini program account, the historical user identifier and the historical account login time. The historical user identifier and the historical account login time are determined based on the account identifier.

[0108] The response module 530 is used to return a response to the mini program indicating that the login information of the mini program account has expired when the access token expires.

[0109] In some optional embodiments, the determination module 520 can also be used to determine that the access token has expired when the user identifier is different from the historical user identifier and the login time of the mini program account has expired relative to the login time of the historical account; when the user identifier is the same as the historical user identifier, or the login time of the mini program account has not expired relative to the login time of the historical account, determine that the access token has not expired.

[0110] In some optional embodiments, the access token is an encrypted token; the determination module 520 can also be used to decrypt and verify the access token; when the verification passes, it is determined whether the access token is invalid based on the user ID, the login time of the mini program account, the historical user ID and the historical account login time; when the verification fails, the access token is deemed to be invalid.

[0111] In some optional embodiments, the response module 530 may also be configured to return a service response to the mini-program based on the service request from the mini-program when the access token is not expired.

[0112] In some optional embodiments, the secure login device 500 for the mini-program account may further include an update module 540 for updating the historical user ID and historical account login time based on the user ID and the login time of the mini-program account when the access token has not expired.

[0113] In some optional embodiments, the secure login device 500 for the mini program account may further include a detection module 550 for detecting whether an access token is included in a business request received from the mini program. If the access token is not included, the business request not including the access token is determined to be an invalid request.

[0114] This manual also provides a secure login device for a mini-program account. Figure 6 This is an exemplary block diagram of another secure login device for a mini-program account according to some embodiments of this specification. In some embodiments, the secure login device 600 for a mini-program account can be deployed in a user terminal, in which the mini-program 110 can be installed and run. Figure 6 As shown, in some embodiments, the secure login device 600 for a mini program account may include a second receiving module 610 , a generating module 620 , a first sending module 630 , and an offline module 640 .

[0115] The second receiving module 610 is used to receive an account login success message from the login server. The field information in the account login success message includes the user identifier generated by the platform server, the account identifier generated by the login server, and the login time of the mini program account.

[0116] The generation module 620 is used to generate an access token based on the field information in the account login success message.

[0117] The first sending module 630 is used to send a business request containing an access token to the local server, so that the local server can determine whether the access token is invalid based on the user identifier, the login time of the mini program account, the historical user identifier and the historical account login time, and return a response to the mini program that the login information of the mini program account has expired when the access token is invalid, wherein the account identifier corresponds to the mini program account, and the historical user identifier and the historical account login time are determined based on the account identifier.

[0118] The offline module 640 is used to receive response information from the local server, and when a response is received indicating that the login information of the mini program account has expired, control the mini program account to go offline.

[0119] In some optional embodiments, the field information in the account login success message also includes customized additional information, and the generation module 620 can also be used to generate an access token based on the user ID, account ID, login time of the mini program account and at least one of the following information: customized additional information, request time of the business request.

[0120] In some optional embodiments, the generation module 620 may also be configured to splice each field information in the access token according to its corresponding preset position, and each field information is connected by a connector.

[0121] In some optional embodiments, the secure login device 600 for the mini-program account may further include a second sending module 650, which is used to obtain temporary login credentials before receiving a successful account login message from the login server; send a login request to the login server, the login request including temporary login credentials, the mini-program account and login password, so that the login server can perform verification based on the mini-program account and login password, and when the verification is successful, obtain a user identifier from the platform server based on the temporary login credentials, and send a successful account login message to the mini-program.

[0122] This manual also provides a secure login system for mini program accounts. Figure 7 This is a schematic diagram of a secure login system for a mini-program account according to some embodiments of this specification. Figure 7 As shown, in some embodiments, the secure login system 700 for the mini program account may include a mini program 110 , a login server 120 , a local server 130 , and a platform server 140 .

[0123] The login server 120 is used to receive a login request from the mini program and verify the login request. When the verification is successful, it receives a request to obtain a user ID from the platform server, and sends an account login success message to the mini program. The field information in the account login success message includes the user ID generated by the platform server, the account ID generated by the login server, and the login time of the mini program account. The account ID corresponds to the mini program account.

[0124] Mini program 110 is used to receive an account login success message from the login server, generate an access token based on the field information in the account login success message, and send a service request containing the access token to the local server.

[0125] The local server 130 is used to receive business requests from the mini program, determine whether the access token is invalid based on the user ID, the login time of the mini program account, the historical user ID and the historical account login time, and return a response to the mini program when the access token is invalid, indicating that the login information of the mini program account has expired. The historical user ID and the historical account login time are determined based on the account ID.

[0126] The platform server 140 is configured to send the user identification to the login server upon receiving a request for obtaining the user identification from the login server.

[0127] For more information about each module, device and system, please refer to Figures 1 to 4 The relevant description of , will not be repeated here. It should be understood that, Figures 5-7 The devices, systems and modules shown can be implemented in various ways. For example, in some embodiments, they can be implemented by hardware, software or a combination of software and hardware. Among them, the hardware part can be implemented using dedicated logic; the software part can be stored in a memory and executed by an appropriate instruction execution system, such as a microprocessor or dedicated hardware. Those skilled in the art will understand that the above methods, devices and systems can be implemented using computer-executable instructions and / or control codes contained in a processor, such as a carrier medium such as a disk, CD or DVD-ROM, or a memory of a programmable device. The devices and modules of this specification can be implemented not only by hardware circuits such as very large-scale integrated circuits or gate arrays, semiconductors such as logic chips, transistors, or programmable hardware devices such as field programmable gate arrays, programmable logic devices, but can also be implemented by software executed by various types of processors, or by a combination of the above hardware circuits and software (for example, firmware).

[0128] It should be noted that the above descriptions of the device, system, and modules are for ease of description only and do not limit this specification to the embodiments described. It is understood that those skilled in the art, after understanding the principles of the device, can arbitrarily combine the modules to form sub-devices connected to other modules without departing from these principles. Alternatively, some modules can be split to obtain more modules or multiple units within a module. Such variations are within the scope of this specification.

[0129] Some embodiments of this specification also provide a computer program product, including a computer program, which, when at least part of the computer program is executed by a processor, can implement the following embodiments of this specification. Figures 2-4In some embodiments, the computer program product may simply be a computer program, which may be carried by a storage medium or a processing device. In other embodiments, the computer program product may also be a storage medium or a processing device containing the aforementioned computer program. The processing device may include one or more processors and a storage medium.

[0130] In some embodiments, the processor may be a combination of one or more of the following processors: a central processing unit (CPU), an application-specific integrated circuit (ASIC), an application-specific instruction set processor (ASIP), a graphics processing unit (GPU), a physical processing unit (PPU), a digital signal processor (DSP), a field-programmable gate array (FPGA), a programmable logic device (PLD), a programmable logic controller (PLC), a reduced instruction set computer (RISC), and a microprocessor.

[0131] In some embodiments, the storage medium may include one or more of the following combinations: mass storage, removable storage, volatile read-write memory, read-only memory (ROM). Exemplary mass storage may include a magnetic disk, an optical disk, a solid-state hard disk, etc. Exemplary removable storage may include a flash drive, a floppy disk, an optical disk, a memory card, a compressed hard disk, a magnetic tape, etc. Exemplary volatile read-write memory may include a random access memory (RAM). Exemplary random access memory may include a dynamic random access memory (DRAM), a double data rate synchronous dynamic random access memory (DDRSDRAM), a static random access memory (SRAM), a thyristor random access memory (T-RAM), and a zero-capacitance random access memory (Z-RAM). Exemplary read-only memory may include a masked read-only memory (MROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a compact disk read-only memory (CD-ROM), and a digital versatile hard disk read-only memory, etc.

[0132] The beneficial effects that may be brought about by the embodiments of this specification include but are not limited to: (1) After the mini program account successfully logs in to the login server, the local server receives a business request from the mini program, and the business request includes an access token. The field information in the access token includes the user ID generated by the platform server, the account ID generated by the login server, and the login time of the mini program account. Furthermore, the local server determines whether the access token is invalid based on the user ID, the login time of the mini program account, the historical user ID, and the historical account login time. When the access token is invalid, it returns a response to the mini program indicating that the login information of the mini program account has expired, thereby controlling the login status of the mini program account, separating the mini program account from the application platform account, and resolving the session conflict problem of the mini program account; (2) By setting up a login server and verifying the mini program account and login password on the login server, the mini program account is separated from the application platform account, avoiding binding the mini program account to the application platform account, and the user can switch the mini program account without switching the application platform account. Since the mini program account is separated from the application platform account, different application platform accounts can share the right to use the same mini program account; (3) by adding an access token to the business request and comparing the user ID and the login time of the mini program account with the historical user ID and the historical account login time, it is determined whether the current access token is invalid. In this way, it is possible to determine whether the current mini program account is logged in to the new platform account and whether the current mini program account is the mini program account that needs to be offline, thereby solving the session conflict problem of the mini program account; (4) by adding customized additional information to the access token, the flexibility and scalability of the access token are improved; (5) by adding the request time of the business request to the access token, the randomness of the access token is increased. After the access token is encrypted, the predictability of the ciphertext token can be reduced, thereby improving the security of the access token. It should be noted that different embodiments may produce different beneficial effects. In different embodiments, the beneficial effects that may be produced may be any one or a combination of the above, or any other possible beneficial effects.

[0133] While the basic concepts have been described above, it will be apparent to those skilled in the art that the detailed disclosure is merely illustrative and does not limit this specification. Although not explicitly stated herein, various modifications, improvements, and revisions to this specification may be made by those skilled in the art. Such modifications, improvements, and revisions are taught in this specification and remain within the spirit and scope of the exemplary embodiments of this specification.

Claims

1. A secure login method for a mini-program account, characterized in that: The method comprises: After the mini program account successfully logs in to the login server, a service request from the mini program is received, the service request including an access token, the field information in the access token including a user identifier generated by the platform server, an account identifier generated by the login server, and the login time of the mini program account, wherein the account identifier corresponds to the mini program account; Determining whether the access token is invalid based on the user identifier, the login time of the mini-program account, historical user identifiers, and historical account login times, where the historical user identifiers and historical account login times are determined based on the account identifier; When the access token is invalid, a response is returned to the mini program indicating that the login information of the mini program account has expired.

2. The method according to claim 1, characterized in that The determining whether the access token is invalid based on the user identifier, the login time of the mini-program account, the historical user identifier, and the historical account login time includes: When the user identifier is different from the historical user identifier, and the login time of the mini program account has expired relative to the historical account login time, determining that the access token has expired; When the user identifier is the same as the historical user identifier, or the login time of the mini program account is not expired relative to the historical account login time, it is determined that the access token is not expired.

3. The method according to claim 2, characterized in that The login time of the mini program account has expired relative to the login time of the historical account, including: the login time of the mini program account is earlier than or equal to the login time of the historical account; The login time of the mini program account is not expired relative to the historical account login time includes: the login time of the mini program account is later than the historical account login time.

4. The method according to any one of claims 1 to 3, characterized in that Also includes: When the access token is not expired, the historical user identifier and the historical account login time are updated based on the user identifier and the login time of the mini-program account.

5. The method according to any one of claims 1 to 3, characterized in that Also includes: When the access token is not invalid, a service response is returned to the applet based on the service request from the applet.

6. The method according to claim 1, characterized in that The field information in the access token also includes customized additional information and / or the request time of the service request; The field information in the access token is spliced ​​according to its corresponding preset position, and the field information is connected by a connector.

7. The method according to claim 1, characterized in that The access token is an encrypted token; Determining whether the access token is invalid based on the user identifier, the login time of the mini-program account, the historical user identifier, and the historical account login time includes: decrypting and verifying the access token; when the verification passes, determining whether the access token is invalid based on the user identifier, the login time of the mini-program account, the historical user identifier, and the historical account login time; When the verification fails, the access token is deemed invalid.

8. The method according to claim 1, characterized in that Also includes: When receiving the service request from the mini program, detecting whether the received service request contains the access token, and when the access token is not contained, determining the service request not containing the access token as an invalid request; The access token is generated by the mini program after receiving a message indicating that the mini program account has successfully logged in to the login server.

9. A secure login method for a mini-program account, characterized in that: The method comprises: Receive a successful account login message from the login server, where the field information in the successful account login message includes a user ID generated by the platform server, an account ID generated by the login server, and a login time of the mini program account; Generate an access token based on the field information in the account login success message; Sending a service request including the access token to the local server, so that the local server determines whether the access token is invalid based on the user identifier, the login time of the mini program account, the historical user identifier, and the historical account login time, and returns a response to the mini program indicating that the login information of the mini program account has expired when the access token is invalid; Receive a response from the local server, and when receiving a response indicating that the login information of the mini program account has expired, control the mini program account to go offline; Among them, the account identifier corresponds to the mini program account, and the historical user identifier and the historical account login time are determined based on the account identifier.

10. The method according to claim 9, characterized in that The determining whether the access token is invalid based on the user identifier, the login time of the mini-program account, the historical user identifier, and the historical account login time includes: When the user identifier is different from the historical user identifier, and the login time of the mini program account has expired relative to the historical account login time, determining that the access token has expired; When the user identifier is the same as the historical user identifier, or the login time of the mini program account is not expired relative to the historical account login time, it is determined that the access token is not expired.

11. The method according to claim 10, characterized in that The login time of the mini program account has expired relative to the login time of the historical account, including: the login time of the mini program account is earlier than or equal to the login time of the historical account; The login time of the mini program account is not expired relative to the historical account login time includes: the login time of the mini program account is later than the historical account login time.

12. The method according to claim 9, characterized in that The field information in the account login success message also includes customized additional information, and generating an access token based on the field information in the account login success message includes: The access token is generated based on the user identifier, the account identifier, the login time of the mini program account, and at least one of the following information: the customized additional information, the request time of the service request; the generating of the access token includes: The field information in the access token is spliced ​​according to its corresponding preset position, and the field information is connected by a connector.

13. The method according to claim 9, characterized in that Before receiving the account login success message from the login server, the method further includes: Obtain temporary login credentials; A login request is sent to the login server, wherein the login request includes the temporary login credentials, the mini-program account and the login password, so that the login server can perform verification based on the mini-program account and the login password, and when the verification is successful, obtain the user identifier from the platform server based on the temporary login credentials, and send a successful account login message to the mini-program.

14. A secure login device for a mini-program account, characterized in that: The device comprises: A receiving module, configured to receive a service request from the mini program after the mini program account successfully logs in to the login server, the service request including an access token, wherein the field information in the access token includes a user identifier generated by the platform server, an account identifier generated by the login server, and the login time of the mini program account, wherein the account identifier corresponds to the mini program account; a determination module, configured to determine whether the access token is invalid based on the user identifier, the login time of the mini-program account, historical user identifiers, and historical account login times, wherein the historical user identifiers and the historical account login times are determined based on the account identifier; A response module is used to return a response to the mini program indicating that the login information of the mini program account has expired when the access token expires.

15. A secure login device for a mini-program account, characterized in that: The device comprises: A receiving module, configured to receive a successful account login message from the login server, wherein the field information in the successful account login message includes a user identifier generated by the platform server, an account identifier generated by the login server, and a login time of the mini program account; A generation module, configured to generate an access token based on the field information in the account login success message; A sending module, configured to send a service request including the access token to a local server, so that the local server determines whether the access token is invalid based on the user identifier, the login time of the mini-program account, the historical user identifier, and the historical account login time, and returns a response to the mini-program indicating that the login information of the mini-program account has expired when the access token is invalid; An offline module, configured to receive a response message from the local server, and control the offline of the mini-program account when receiving a response indicating that the login information of the mini-program account has expired; Among them, the account identifier corresponds to the mini program account, and the historical user identifier and the historical account login time are determined based on the account identifier.

16. A secure login system for a mini-program account, characterized in that: The system includes a mini-program, a login server, a local server, and a platform server; The login server is configured to receive a login request from the mini-program and verify the login request. When the verification is successful, the server sends a request to the platform server to obtain a user ID, and sends a successful account login message to the mini-program. The field information in the successful account login message includes the user ID generated by the platform server, the account ID generated by the login server, and the login time of the mini-program account; The mini program is configured to receive the account login success message from the login server, generate an access token based on field information in the account login success message, and send a service request containing the access token to the local server; The local server is configured to receive the service request from the mini program, determine whether the access token is invalid based on the user identifier, the login time of the mini program account, the historical user identifier, and the historical account login time, and return a response to the mini program indicating that the login information of the mini program account has expired when the access token is invalid; The platform server is configured to send the user identification to the login server upon receiving the request for obtaining the user identification sent by the login server; Among them, the account identifier corresponds to the mini program account, and the historical user identifier and the historical account login time are determined based on the account identifier.

17. A computer program product, characterized in that The invention comprises a computer program, and when at least a part of the computer program is executed by a processor, the method according to any one of claims 1 to 13 can be implemented.

Images