Multi-terminal non-sensing login access method based on token and device fingerprint and electronic device

Abstract

The application discloses a multi-terminal non-susceptible login access method based on tokens and device fingerprints and an electronic device, and relates to the technical field of electronic devices. The method comprises the following steps: when a first user accesses multiple servers through a first terminal, the first terminal obtains a first token for accessing a first server according to a device fingerprint of the first terminal and login information for the first server, and stores the device fingerprint of the first terminal in a user device fingerprint set of the first user; the first terminal generates a second token for accessing a second server according to the device fingerprint of the first terminal and the fact that the first token exists in the user device fingerprint set of the first user; the user device fingerprint set comprises device fingerprints of part or all terminal devices corresponding to part or all login information of the user, and the device fingerprint is a unique identifier of the terminal device. The application can realize non-susceptible login and access of the user in a multi-terminal multi-server system.

Description

Technical Field

[0001] This application relates to the field of Internet technology, specifically to the fields of Internet identity authentication, access control and security authentication, and in particular to a multi-terminal contactless login access method, electronic device and storage medium based on tokens and device fingerprints. Background Technology

[0002] With the rapid development of internet technology, people frequently access various resources online. For information security reasons, users need to enter their registered login information through a browser before successfully accessing these resources. When accessing a large number of websites, multiple login verifications are required, impacting user experience. To address this issue, the mainstream solution is to use OAuth 2.0 technology for seamless login. Under this framework, when accessing multiple different sites under the same root domain through a front-end browser, once login authentication is completed on any one site, seamless login and access can be performed across all sites. Therefore, this technology is also known as Single Sign-On (SSO) technology.

[0003] However, it should be noted that Single Sign-On (SSO) technology is only applicable to login via a browser, and not to login and access via mobile apps. This is because the technology framework uses cookies to store the browser's unified authentication credentials, and cookies only support browsers and not mobile devices. Therefore, when people want to extend the applicability of SSO to support seamless authentication for mobile apps, it cannot be achieved smoothly under the current technology framework. Summary of the Invention

[0004] In view of this, embodiments of this application provide a multi-terminal contactless login access method, electronic device, and computer-readable storage medium based on tokens and device fingerprints to solve at least one technical problem.

[0005] This application provides a multi-terminal contactless login access method based on tokens and device fingerprints, applied to terminal devices, the method comprising:

[0006] When a first user accesses multiple servers through a first terminal, the first terminal sends its device fingerprint and login information for the first server to the authentication server without logging into the first server, so that the authentication server returns a first token and stores the device fingerprint of the first terminal in the user device fingerprint set of the first user, wherein the first token is used for the first terminal to access the first server.

[0007] Without logging into the second server, the first terminal sends its device fingerprint to the authentication server, so that the authentication server can confirm the existence of the first token through the user device fingerprint set of the first user, generate a second token based on the first token, and send it to the first terminal. The second token is used by the first terminal to access the second server.

[0008] The user device fingerprint set includes device fingerprints of some or all terminal devices corresponding to some or all of the user's login information, wherein the device fingerprint is a unique identifier of the terminal device.

[0009] Optionally, according to the method provided in the embodiments of this application, when the first user accesses multiple servers through multiple terminals, the method further includes: a second terminal, without logging into the first server, sending its device fingerprint and login information for the first server to an authentication server, causing the authentication server to return a third token, and storing the second terminal's device fingerprint in the first user's user device fingerprint set; the third token being used by the second terminal to access the first server; a third terminal, without logging into the second server, sending its device fingerprint and login information for the second server to the authentication server, causing the authentication server to return a fourth token, and storing the third terminal's device fingerprint in the first user's user device fingerprint set; the fourth token being used by the third terminal to access the second server; and a second terminal, without logging into the second server, sending its device fingerprint to the authentication server, causing the authentication server to confirm that the third terminal is logged into the second server through the first user's user device fingerprint set, and then returning a fifth token to the second terminal; the fifth token being used by the second terminal to access the second server.

[0010] Optionally, according to the method provided in the embodiments of this application, the device fingerprint is a hash value, which is calculated based on at least one of the following: International Mobile Equipment Identity (IMEI), Browser User Agent (UA), and Character Set.

[0011] This application provides a multi-terminal seamless login access method based on tokens and device fingerprints, applied to an authentication server. The method includes: the authentication server receiving a device fingerprint of a first terminal and login information for the first server, wherein the first terminal is not logged into the first server; the authentication server sending a first token to the first terminal based on the device fingerprint and login information, and storing the device fingerprint of the first terminal in a user device fingerprint set of a first user, wherein the first token is used by the first terminal to access the first server; the authentication server receiving the device fingerprint of the first terminal; the authentication server confirming the existence of the first token through the user device fingerprint set of the first user; the authentication server generating a second token based on the first token and sending it to the first terminal, wherein the second token is used by the first terminal to access a second server; wherein the user device fingerprint set includes device fingerprints of some or all terminal devices corresponding to some or all of the user's login information, wherein the device fingerprint is a unique identifier for the terminal device.

[0012] Optionally, according to the method provided in the embodiments of this application, when the first user accesses multiple servers through multiple terminals, the method further includes: an authentication server receiving a device fingerprint of a second terminal and login information for a first server, wherein the second terminal is not logged in on the first server; the authentication server sending a third token to the second terminal based on the device fingerprint and login information, and storing the device fingerprint of the second terminal in the user device fingerprint set of the first user, wherein the third token is used for the second terminal to access the first server; the authentication server receiving a device fingerprint of a third terminal and login information for a second server, wherein the third terminal is not logged in on the second server; the authentication server sending a fourth token to the third terminal based on the device fingerprint and login information, and storing the device fingerprint of the third terminal in the user device fingerprint set of the first user, wherein the third token is used for the third terminal to access the second server; the authentication server receiving a device fingerprint of the second terminal, wherein the second terminal is not logged in on the second server; the authentication server confirming that the third terminal is logged in on the second server through the user device fingerprint set of the first user; and the authentication server returning a fifth token to the second terminal, wherein the fifth token is used for the second terminal to access the second server.

[0013] Optionally, the method provided in the embodiments of this application further includes: the authentication server recording the number of times the login information of the first user sent by the terminal is recorded, and storing the device fingerprints that have a number of times within a predetermined time period that are greater than a predetermined threshold in the user device fingerprint set of the first user.

[0014] Optionally, the method provided in the embodiments of this application further includes: the authentication server recording the number of occurrences of each device fingerprint of the first user received, and removing device fingerprints whose occurrences within a predetermined time period are less than a predetermined threshold from the user device fingerprint set of the first user.

[0015] Optionally, according to the method provided in the embodiments of this application, the device fingerprint is a hash value, which is calculated based on at least one of the following: International Mobile Equipment Identity (IMEI), Browser User Agent (UA), and Character Set.

[0016] This application provides an electronic device, which includes a processor and a memory storing computer program instructions; when the processor executes the computer program instructions, it implements the steps of the method described above.

[0017] This application provides a computer-readable storage medium storing computer program instructions, which, when executed by a processor, implement the steps of the method described above.

[0018] Compared to previous methods, this application sets up a user device fingerprint set, thus eliminating the need to send an authorization code and verify it before issuing a token. Instead, it confirms the user's identity based on the user device fingerprint set. This allows for the direct issuance of a new target server token based on the user's existing tokens from other servers, enabling seamless login and access to the target server. Since it no longer relies on cookies to store the user's login account information but instead completes authentication through the user device fingerprint set, this application's solution is no longer limited to browser login scenarios but is applicable to seamless login on various types of terminal devices. The embodiments of this application can extend seamless login, previously limited to browsers, to seamless login on any type of terminal device, providing significant convenience, especially for mobile device users. Attached Figure Description

[0019] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings of the embodiments of this application will be briefly described below.

[0020] Figure 1 This is a schematic diagram of the system architecture of an embodiment of this application.

[0021] Figure 2 This is a schematic diagram of a multi-terminal seamless login access method in the existing technology.

[0022] Figure 3 This is a flowchart of a multi-terminal seamless login access method based on tokens and device fingerprints according to an embodiment of this application.

[0023] Figure 4This is a flowchart illustrating the application of the token- and device fingerprint-based multi-terminal seamless login access method of this application to an authentication server.

[0024] Figure 5 This is a flowchart of another method for seamless multi-terminal login access based on tokens and device fingerprints, according to an embodiment of this application.

[0025] Figure 6 This is a flowchart illustrating another method for seamless multi-terminal login access based on tokens and device fingerprints applied to an authentication server, as described in this application.

[0026] Figure 7 This is a schematic diagram of a multi-terminal seamless login access method in one embodiment of this application.

[0027] Figure 8 This is a schematic diagram of a multi-terminal seamless login access method in another embodiment of this application.

[0028] Figure 9 This is a schematic diagram of an electronic device used to implement the multi-terminal seamless login access method of the embodiments of this application. Detailed Implementation

[0029] The principles and spirit of this application will be described below with reference to several exemplary embodiments. It should be understood that these embodiments are provided to make the principles and spirit of this application clearer and more thorough, enabling those skilled in the art to better understand and implement the principles and spirit of this application. The exemplary embodiments provided herein are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments described herein without inventive effort are within the scope of protection of this application.

[0030] Embodiments of this application relate to terminal devices and / or servers. Those skilled in the art will understand that embodiments of this application can be implemented as a system, apparatus, device, method, computer-readable storage medium, or computer program product. Therefore, this disclosure can be specifically implemented in at least one of the following forms: entirely hardware, entirely software, or a combination of hardware and software. According to embodiments of this application, this application claims protection for a method, apparatus, electronic device, and computer-readable storage medium for obtaining portal website announcements. Figure 1 A schematic diagram of a system architecture according to an embodiment of this application is shown. For example... Figure 1As shown, the system includes a terminal device 102 and a server 104. The terminal device 102 can include at least one of the following: a smartphone, tablet, laptop, desktop computer, smart TV, various wearable devices, augmented reality (AR) devices, virtual reality (VR) devices, etc. A client can be installed on the terminal device 102. For example, the client can be a client specifically designed to perform a particular function (such as an application app), or a client with multiple embedded application applets (with different functions), or a client authenticated through a browser. Users can operate on the terminal device 102. For example, a user can open the client installed on the terminal device 102 and input commands through the client, or a user can open the browser installed on the terminal device 102 and input commands through the browser. After receiving the user's input command, the terminal device 102 sends a request message containing the command to the server 104. After receiving the request message, the server 104 performs the corresponding processing and then returns the processing result information to the terminal device 102. The user command is completed through a series of data processing and information interaction.

[0031] In this document, terms such as first, second, and third are used only to distinguish one entity (or operation) from another, and are not intended to require or imply any order or relationship between these entities (or operations).

[0032] Figure 2 This is a schematic diagram of a multi-terminal seamless login access method in existing technology, such as... Figure 2 As shown, the general process of initial SSO login is as follows: a user requests resources on their terminal. Resource server 1 detects that the user is not logged in and redirects to the CAS server for verification. CAS verifies that the user is not logged in and therefore requires the user to provide login information for authentication. The user enters the login information and submits it to CAS for login. If the login is successful, CAS returns an authorization code and the user's personal information, and writes the terminal fingerprint information to a cookie. Then, CAS redirects back to resource server 1. After receiving the authorization code, resource server 1 sends an authorization request to CAS to obtain a token and the user's detailed information. After CAS verifies the authorization code and passes the verification, it issues a token and returns the user's detailed information. Finally, resource server 1 obtains the necessary permissions and user information to provide services to the user. This embodiment differs significantly from the general process of existing technologies, which will be described in detail below.

[0033] Figure 3 The diagram illustrates a flowchart of a multi-terminal seamless login access method based on tokens and device fingerprints according to an embodiment of this application. The method is applied to a terminal device and includes the following steps:

[0034] S101: When a first user accesses multiple servers through a first terminal, the first terminal sends its device fingerprint and login information for the first server to the authentication server without logging into the first server, so that the authentication server returns a first token and stores the device fingerprint of the first terminal in the user device fingerprint set of the first user, wherein the first token is used for the first terminal to access the first server.

[0035] S102: Without logging into the second server, the first terminal sends its device fingerprint to the authentication server, so that the authentication server can confirm the existence of a first token through the user device fingerprint set of the first user, generate a second token based on the first token, and send it to the first terminal. The second token is used by the first terminal to access the second server. The user device fingerprint set includes device fingerprints of some or all terminal devices corresponding to some or all of the user's login information, and the device fingerprint is a unique identifier of the terminal device.

[0036] According to embodiments of this application, during the process of a terminal device (e.g., a PC or mobile phone) requesting access to a first server, it not only sends the user's login information (such as account password) to the authentication server so that the authentication server issues a token, but also sends its own device fingerprint information (e.g., the mobile phone's IMEI code or the hash value of the IMEI code) to the authentication server so that the authentication server records the device fingerprint. The authentication server is a server used for user verification and token issuance; for example, CAS (Central Authentication Service) is an open-source authentication protocol and service used to simplify the cross-domain single sign-on (SSO) process. A token is a resource credential required to access a resource interface, and it can include user identity information, a timestamp, and a secure signature. In this embodiment, the device fingerprint refers to the terminal's unique identity representation to the authentication server, and can be in the form of a string of IDs or a hash value.

[0037] Specifically, the device fingerprint is stored in the current user's device fingerprint set (a user may own multiple terminal devices, such as smartphones or tablets, and the device fingerprints of these terminal devices can constitute the user's device fingerprint set, that is, the user's device fingerprint set represents the set of device fingerprints corresponding to multiple terminals, and the corresponding device fingerprints point to the same user identity). Based on this, the current user can not only successfully access the first server using the token, but also, when the current user wants to access the second server, without needing the user's login information, the authentication server can confirm through the user's device fingerprint set that the current user already has a token (i.e., the token previously issued for logging into the first server). At this time, the authentication server will directly issue a token for logging into the second server to the current user, without requiring the user to enter login account information again. The process of logging into the third server is the same, which can realize seamless login between multiple servers.

[0038] As can be seen, the above authentication process no longer relies on cookies to store the user's login account information, but instead completes authentication by setting a "user device fingerprint set". Therefore, the above solution is no longer limited to browser login scenarios. More importantly, the above solution of this application is applicable to seamless login of various types (mobile or non-mobile) terminal devices. In other words, the embodiments of this application can extend the seamless login that was originally limited to browsers to seamless login of any type of terminal device. For example, it can seamlessly log in to multiple resource servers through a mobile APP to obtain resources. Compared with the previous operation that required authentication based on browser cookies, or the operation that required repeatedly providing login account information on the APP, the seamless login solution of this application embodiment can realize seamless login of the APP to multiple resource servers. The solution of this application can provide great convenience for mobile device users.

[0039] As an example, according to the processing method of this application embodiment, step S101 can be implemented through the following process: A first user initiates an access request to a first server through a first terminal. If the first server indicates that the user is not logged in, the first terminal sends a first message to the authentication server. The first message includes the device fingerprint of the first terminal, wherein the device fingerprint is a unique identifier of the terminal device. The authentication server confirms the token under the device fingerprint of the first terminal. If the authentication server reports that there is no token corresponding to the device fingerprint of the first terminal, the authentication server requests the first terminal to enter the login information used by the first user to log in to the first server. Then, the first terminal sends the login information to the authentication server. After the authentication server verifies the login information, it issues a first token to the first terminal for accessing the first server and stores the device fingerprint of the first terminal in the user's device fingerprint set. After receiving the first token, the first terminal uses the first token to access the first server.

[0040] For example, suppose a user on phone A uses application A to access a server to obtain resources. If the user hasn't logged in before, or if their previous login session has expired or been cleared, the server doesn't detect the user's login activity. In this case, the server reports this to application A. Application A then accesses the authentication server using the phone's device fingerprint. The authentication server checks for tokens associated with that fingerprint. If no tokens are found, the user enters their login information (username and password) on application A. The authentication server verifies this information to confirm access rights to the server. If successful, it issues a first token to application A and records the phone's device fingerprint. Subsequently, within the first token's validity period, the user can directly access the server using application A to obtain resources without needing to re-enter login information.

[0041] As an example, step S102 can be implemented through the following process: a first user initiates an access request to a second server through a first terminal; if the second server indicates that the user is not logged in, the first terminal sends a second message to the authentication server, the second message including the device fingerprint of the first terminal, so that the authentication server determines that there is a first token corresponding to the device fingerprint of the first terminal based on the device fingerprint of the first terminal, and sends a second token to the first terminal for accessing the second server; after receiving the second token returned by the authentication server, the first terminal uses the second token to access the second server.

[0042] For example, suppose a first user uses app B on phone A to access a second server to obtain resources. If the first user hasn't logged in before, or if their previous login session has expired or been cleared, the second server doesn't detect the first user's login status. In this case, the second server reports this to app B. App B then accesses the authentication server using the phone's device fingerprint. The authentication server checks the tokens associated with that fingerprint. Assuming the first token is still valid, the authentication server issues a second token to app B. At this point, the device fingerprint has both the first and second tokens. Subsequently, during the validity period of the second token, the first user can directly access the second server using app B to obtain resources without entering login information.

[0043] In the embodiments of this application, "device fingerprint" can be understood as a unique identifier for the terminal to the authentication server, which can be a string of characters, an ID, or a hash value. Optionally, the device fingerprint can use existing unique identification information of the device, such as the International Mobile Equipment Identity (IMEI), the browser user agent (UA), or a character set. Preferably, the device fingerprint can use a hash value, such as a hash value calculated based on the IMEI, UA, and / or character set, where the character set can be one or more combinations of the terminal's IP address, MAC address, or screen resolution.

[0044] For example, a mobile phone's device fingerprint can be its IMEI. A mobile phone IMEI is typically a 15-digit number divided into four parts: TAC (Type Approval Code): the first 6 digits; FAC (Final Assembly Code): the middle 2 digits; SNR (Serial Number): the next 6 digits; and SP (Spare Number): the last digit. For example, a mobile phone's IMEI code is 35-123456-789101-2. Inputting this IMEI code into a hash function, such as SHA-256, yields a unique hash value, for example: a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9t0u1v2w3x4y5z6. This hash value can be used as the mobile phone's device fingerprint.

[0045] For example, a browser's device fingerprint can be a User Agent (UA) string, such as: Mozilla / 5.0 (Windows NT10.0; Win64; x64) AppleWebKit / 537.36 (KHTML, like Gecko) C / 91.0.4472.124 Safari / 537.36. This UA string indicates that the request was initiated by a 64-bit C browser running on Windows 10. Similarly, hashing this UA string yields a unique hash value, such as: b1c2d3e4f5g6h7i8j9k0l1m2n3o4p5q6r7s8t9u0v1w2x3y4z5a6. This hash value can be used as the device fingerprint of the device (which could be a PC or a mobile device) on which the browser is located.

[0046] For example, a character set can be one or more combinations of the terminal's IP address, MAC address, or screen resolution. For instance, a character set might be 192.168.1.100 (IP address) plus 1024x768 (the current device's screen resolution), resulting in 192.168.1.100_1024x768. Performing a hash operation on this character set yields a unique hash value, for example: c1d2e3f4g5h6i7j8k9l0m1n2o3p4q5r6s7t8u9v0w1x2y3z4a5b6. This hash value can be used as the device fingerprint of the terminal (which could be a PC or a mobile device).

[0047] In the embodiments of this application, the "user device fingerprint set" includes device fingerprints of some or all terminal devices corresponding to some or all of the user's login information. Therefore, in a user device fingerprint set corresponding to multiple terminal devices, each device fingerprint points to the same user.

[0048] For example, when a user registers a personal account on a resource server, they fill in personal information (such as username, password, mobile phone number, ID card number, or email address). This information can constitute the user's login information. The authentication server can associate the user's login information sent by the terminal with the personal information filled in by the user during registration.

[0049] Suppose that the first user first accesses the first server through an application on phone A and provides the authentication server with the device fingerprint and login information of phone A. At this time, the device fingerprint of phone A is stored in the user's device fingerprint set. Then, the first user attempts to access the second server using application A on phone A and provides the device fingerprint of phone A to the authentication server. At this time, the authentication server can confirm that the device fingerprint of phone A already exists in the user's device fingerprint set. Therefore, it can determine that the first user is legitimate and allows the issuance of a token from the second server to the first user.

[0050] The above situations meet the requirements Figure 3 The embodiment describes the seamless login process. In other embodiments of this application, there is also a situation where the first user continues to access the first and second servers through mobile phone B. The authentication and seamless login process using the user device's fingerprint set will be described in detail below.

[0051] Figure 4 This illustration shows a flowchart of a multi-terminal seamless login access method based on tokens and device fingerprints, as described in an embodiment of this application, on the authentication server side. Figure 4 The steps shown are as follows:

[0052] S201, The authentication server receives the device fingerprint of the first terminal and login information for the first server, wherein the first terminal is not logged in on the first server;

[0053] S202, the authentication server sends a first token to the first terminal based on the device fingerprint and login information of the first terminal, and stores the device fingerprint of the first terminal in the user device fingerprint set of the first user, wherein the first token is used for the first terminal to access the first server;

[0054] S203, The authentication server receives the device fingerprint of the first terminal;

[0055] S204, the authentication server confirms the existence of a first token through the user device fingerprint set of the first user; the authentication server generates a second token based on the first token and sends it to the first terminal, the second token being used by the first terminal to access the second server; wherein, the user device fingerprint set includes device fingerprints of some or all terminal devices corresponding to some or all of the user's login information, wherein the device fingerprint is a unique identifier of the terminal device.

[0056] As an example, in this application embodiment, multiple servers (such as the first server and the second server) belong to the same authentication server and perform login authentication through the same authentication server. For example, a centralized authentication service (CAS) can be used to configure CAS according to the process of this application embodiment to provide user authentication, token issuance, and maintenance of user device fingerprint sets for multiple servers, thereby enabling seamless login for users.

[0057] This application sets up a user device fingerprint set, eliminating the need to send an authorization code and omitting the authorization code verification step before issuing a token. The user's identity is confirmed through the user device fingerprint set, and a new target server token can be directly issued based on the user's existing tokens from other servers. This enables seamless login and access to the target server for the user. The above process does not require authorization code verification before issuing the token and requires no user participation, thus realizing seamless multi-server login on mobile terminals.

[0058] According to the embodiments of this application, refer to Figure 5 If the first user needs to access multiple servers through multiple terminals, the multi-terminal seamless login access method of this application includes the following processing on the terminal side:

[0059] S301, the second terminal sends its device fingerprint and login information for the first server to the authentication server without logging into the first server, so that the authentication server returns a third token and stores the device fingerprint of the second terminal in the user device fingerprint set of the first user. The third token is used by the second terminal to access the first server.

[0060] S302, the third terminal sends its device fingerprint and login information for the second server to the authentication server without logging into the second server, so that the authentication server returns a fourth token and stores the device fingerprint of the third terminal in the user device fingerprint set of the first user. The fourth token is used by the third terminal to access the second server.

[0061] S303, the second terminal sends its device fingerprint to the authentication server without logging into the second server. After the authentication server confirms that the third terminal is logged into the second server using the user device fingerprint set of the first user, it returns a fifth token to the second terminal. The fifth token is used by the second terminal to access the second server.

[0062] Correspondingly, refer to Figure 6 If the first user needs to access multiple servers through multiple terminals, the multi-terminal seamless login access method of this application includes the following processing on the authentication server side:

[0063] S401, The authentication server receives the device fingerprint of the second terminal and the login information used by the first server, wherein the second terminal is not logged in on the first server;

[0064] S402, the authentication server sends a third token to the second terminal based on the device fingerprint and login information of the second terminal, and stores the device fingerprint of the second terminal in the user device fingerprint set of the first user, wherein the third token is used for the second terminal to access the first server;

[0065] S403, The authentication server receives the device fingerprint of the third terminal and login information for the second server, wherein the third terminal is not logged in on the second server;

[0066] S404, the authentication server sends a fourth token to the third terminal based on the device fingerprint and login information of the third terminal, and stores the device fingerprint of the third terminal in the user device fingerprint set of the first user, wherein the third token is used for the third terminal to access the second server.

[0067] S405, The authentication server receives the device fingerprint of the second terminal, where the second terminal is not logged in on the second server;

[0068] S406, the authentication server confirms that the third terminal is logged in on the second server by using the user device fingerprint set of the first user;

[0069] S407, the authentication server returns a fifth token to the second terminal, which is used by the second terminal to access the second server.

[0070] In other words, according to the embodiments of this application, when a user accesses the first server and the second server through multiple terminal devices, the device fingerprints and related login information of these terminal devices are stored in the current user's device fingerprint set. Moreover, when a user accesses the second server using a terminal device, without requiring user login information, the seamless login is not only based on the login status of the terminal device on the first server. For example, if the login status of the terminal device on the first server fails, the authentication server can confirm through the current user's device fingerprint set that the current user already has a token on another terminal device. In this case, the authentication server will directly issue a token for the current user to log in to the second server without requiring the user to re-enter login account information. The process of logging into the third server is similar, which can realize seamless login between multiple servers.

[0071] As can be seen, the above authentication process further expands the seamless login for users across terminal devices. Compared with the method of authenticating and conveniently accessing different servers through a "user device fingerprint set" on the same terminal device, the seamless login solution of this application embodiment can achieve seamless login to multiple resource servers on multiple different terminal devices, further bringing convenience to mobile device users.

[0072] As an example, the above embodiments of this application can be implemented through the following process: In step 301, the first user initiates an access request to the first server through a second terminal. If the first server indicates that the user is not logged in, the second terminal sends a first message to the authentication server, which includes the device fingerprint of the second terminal. The authentication server verifies the token under the device fingerprint of the second terminal. If the authentication server reports that there is no token corresponding to the device fingerprint of the second terminal, the authentication server requests the second terminal to enter the login information used by the first user to log in to the first server. Then, the second terminal sends the login information to the authentication server. After the authentication server verifies the login information, it issues a third token to the second terminal for accessing the first server and stores the device fingerprint of the second terminal in the user's device fingerprint set. After receiving the third token, the second terminal uses the third token to access the first server.

[0073] For example, suppose a user on phone B uses application A to access a server to obtain resources. If the user hasn't logged in before, or if their previous login session has expired or been cleared, the server doesn't detect the user's login status. In this case, the server reports this to application A. Application A then accesses the authentication server using the phone's device fingerprint. The authentication server checks for tokens associated with that fingerprint. If no tokens are found, the user enters their login information (username and password) on application A. The authentication server verifies this information to confirm access rights to the server. If successful, it issues a third token to application A and records the phone's device fingerprint. Subsequently, during the validity period of the third token, the user can directly access the server using application A to obtain resources without needing to re-enter login information.

[0074] In step 302, the first user initiates an access request to the second server through a third terminal. If the second server indicates that the user is not logged in, the third terminal sends a second message to the authentication server. This second message includes the device fingerprint of the third terminal, which is a unique identifier for the terminal device. The authentication server verifies the token associated with the third terminal's device fingerprint. If the authentication server reports that no token corresponds to the third terminal's device fingerprint, it requests the third terminal to enter the login information used by the first user to log in to the second server. The third terminal then sends the login information to the authentication server. After successful verification, the authentication server issues a fourth token to the third terminal for accessing the second server and stores the third terminal's device fingerprint in the first user's user device fingerprint set. Upon receiving the fourth token, the third terminal uses it to access the second server.

[0075] For example, suppose a user on computer A uses browser A to access a second server to obtain resources. If the user hasn't logged in before, or if their previous login session has expired or been cleared, the second server doesn't detect the user's login status. In this case, the second server reports this to browser A. Browser A then accesses the authentication server with its device fingerprint. The authentication server checks for tokens under this device fingerprint. If no tokens are found, the user enters login information (username and password) on browser A. The authentication server verifies the login information to confirm access to the second server. If successful, it issues a fourth token to browser A and records the device fingerprint. Now, based on the user's login information when accessing the first server on phone B and the login information when accessing the second server on browser A, which points to the user's unique identity, the authentication server performs a union of the device fingerprints of phone B and browser A, including both in the user's device fingerprint set. This device fingerprint set now contains both a third and a fourth token. Subsequently, during the validity period of the fourth token, the user can directly access the first server using browser A to obtain resources without needing to re-enter login information.

[0076] In step 303, the first user initiates an access request to the second server through the second terminal. If the second server indicates that the user is not logged in, the second terminal sends a third message to the authentication server. The third message includes the device fingerprint of the second terminal, so that the authentication server can determine the existence of a fourth token corresponding to the device fingerprint of the third terminal based on the device fingerprint of the second terminal, and send a fifth token to the second terminal for accessing the second server. After receiving the fifth token returned by the authentication server, the second terminal uses the fifth token to access the second server.

[0077] For example, suppose a user on phone B uses application B to access a second server to obtain resources. If the user hasn't logged in before, or if their previous login session has expired or been cleared, the second server doesn't detect the user's login status. In this case, the second server reports this to application B. Application B then accesses the authentication server with the phone's device fingerprint. The authentication server checks the tokens associated with that device fingerprint. Assuming the third token associated with that device fingerprint has expired, but the fourth token associated with browser A's device fingerprint is still valid, the authentication server will issue a fifth token to application B. At this point, the user's device fingerprint set contains both the fourth and fifth tokens. Subsequently, during the validity period of the fifth token, the user can directly access the second server using application B to obtain resources without needing to enter login information.

[0078] The advantage of this setup is that, since this application sets a user device fingerprint set, it can verify the user's legitimacy based on the user's login status on other devices on other servers. This allows for the direct issuance of a new token to the user's current device. As can be seen, by setting a user device fingerprint set, seamless login across terminals and domains can be achieved. It supports the same user logging into different servers using different terminals, and there are no restrictions on the type of terminal device. Seamless login and access to the target server can be easily achieved through PC browsers and mobile apps.

[0079] According to an embodiment of this application, optionally, when the tokens under the device fingerprints of the second terminal and the third terminal are both valid in the user device fingerprint set of the first user, the first user selects one of them to issue a new token to the corresponding terminal access resource server.

[0080] For example, suppose a first user accesses a first server using application A on phone A and accesses a second server using browser A on computer A. The device fingerprints of phone A and browser A are stored in the first user's device fingerprint set. When the first user accesses the second server using application B on phone A, and both the device fingerprints of phone A and browser A are valid, the first user can choose which device fingerprint to use to issue a new token for application B to access the second server.

[0081] According to an embodiment of this application, optionally, the authentication server records the number of times the login information of the first user sent by the terminal is received, and stores the device fingerprints that have been received more than a predetermined threshold within a predetermined time period in the user device fingerprint set of the first user.

[0082] For example, suppose the authentication server sets a threshold of 2 times within 10 days. When user A first accesses the server using app A on phone A, they obtain a token by entering login information and then access the server. At this time, user device fingerprints do not store phone A's device fingerprint. If user A accesses the server a second time within 10 days using app A on phone A, again obtaining a token by entering login information and then accessing the server, phone A is determined to be user A's frequently used phone, and the device fingerprint of phone A is then added to user device fingerprints.

[0083] Login information typically represents an access request initiated by the user. By determining the number of times the user accesses the device based on their login information, it can be determined whether the corresponding terminal belongs to the user's frequently used device, and further, it can be determined whether to record the device fingerprint, thereby improving the security of single sign-on based on device fingerprint.

[0084] According to an embodiment of this application, optionally, the authentication server records the number of times each device fingerprint of the first user appears, and removes device fingerprints that appear less than a predetermined threshold within a predetermined time period from the user device fingerprint set of the first user.

[0085] For example, suppose the authentication server sets a threshold of 2 times within 10 days. If phone A accesses the authentication server only once within 10 days with its device fingerprint, it is determined that phone A is no longer the primary user's preferred phone. Therefore, it is removed from the primary user's device fingerprint set to improve the security of single sign-on using device fingerprints.

[0086] The implementation methods and advantages of the embodiments of this application have been described above through multiple examples. The specific processing procedures of the embodiments of this application are described in detail below with reference to specific examples.

[0087] Example 1: A single terminal logs into multiple servers

[0088] 1. First-time login to the "Recruitment Platform" via browser

[0089] Suppose we have a system called a "recruitment platform" with the domain name ehire.51job.com. Before accessing the platform, user Xiao Zhang needs to register an account. After Xiao Zhang enters his email address (e.g., xiaozhang@a.com) and password (e.g., 123456) as login information, the recruitment platform stores this information in its database.

[0090] Figure 7 This is a schematic diagram of a multi-terminal seamless login access method in one embodiment of this application, as shown below. Figure 7 As shown in this application, Xiao Zhang wants to access the job list on a recruitment platform. He opens a browser and enters the URL. The browser sends a request to the recruitment platform. When the recruitment platform receives the access request, since Xiao Zhang is not logged in, the platform detects the lack of a login status and returns a redirection instruction and the address of the CAS server to the browser. The browser then uses this instruction to access the CAS server for authentication, carrying UserAgent-1. The CAS server determines the token status under UserAgent-1. Since this is the first login, there are no tokens under UserAgent-1, and the CAS server returns this information to the browser.

[0091] Xiao Zhang enters his login information to log in. The browser sends the login information to the CAS server for verification. After the CAS server verifies that the information is correct, it issues access token 1, which is valid for a certain period. The CAS server will also perform an initial binding operation and record the correspondence between UserAgent, user account information, and token, as shown in Table 1 below:

[0092] Table 1

[0093]

[0094] After obtaining access token 1, the browser uses token 1 to send an access request to the recruitment platform. The recruitment platform redirects to the CAS server to verify the validity of token 1, including checking whether token 1 has expired or been revoked. After confirming that token 1 is valid, the server returns the verification result to the recruitment platform. Based on this result, the recruitment platform returns resources from the recruitment platform to the browser, such as a job list.

[0095] 2. First-time login to the "Online Store" via browser

[0096] Suppose we have another system called "Online Mall" with the domain name mall.51job.com. Before accessing the platform, user Xiao Zhang needs to register an account. After Xiao Zhang enters his email address (e.g., xiaozhang@a.com) and password (e.g., 123456) as login information, the Online Mall stores this information in its database.

[0097] like Figure 2 As shown, the existing technology (taking OAuth2.0_SSO as an example) operates as follows: When a user accesses resource server 2 via a terminal, since a login operation has already been performed and the terminal fingerprint information is stored in the cookie, the process involves: the user requesting resources on the terminal; resource server 2 discovering that the user is not logged in but has terminal fingerprint information in the cookie, it redirects to the CAS server, carrying this terminal fingerprint information. After receiving the request with the terminal fingerprint information, the CAS server verifies the validity of the terminal fingerprint. If the fingerprint is valid, it means that the user has already completed the login operation elsewhere, so the CAS server directly returns an authorization code to resource server 2. After receiving the authorization code, resource server 2 sends an authorization request to the CAS server to obtain a token and the user's detailed information. After the CAS server verifies the authorization code and passes the verification, it issues a token and returns the user's detailed information. Finally, resource server 2 obtains the necessary permissions and user information to provide services to the user.

[0098] This embodiment differs significantly from the typical process of existing technologies. The following example illustrates this: Xiao Zhang wants to access a product list on an online shopping mall. He opens a browser (C browser) and enters the URL. The browser sends a request to the online shopping mall. When the online shopping mall receives the access request, since Xiao Zhang is not logged in, it detects the lack of a login status and returns a redirection instruction and the address of the CAS server to the browser. The browser then uses this instruction, carrying UserAgent-1, to access the CAS server for authentication. The CAS server determines the token status based on UserAgent-1.

[0099] At this point, while token 1 is still valid, the CAS server verifies the token. Upon successful verification, it issues token 2, belonging to the online store, to the browser. This access token is valid for a certain period. The CAS server will also perform an initial binding operation, recording the correspondence between the UserAgent, user account information, and token, as shown in Table 2 below. At this time, a set of user device IDs will be formed based on the UserAgent, as shown in Table 3 below.

[0100] Table 2

[0101]

[0102] Table 3

[0103]

[0104]

[0105] After obtaining access token 2, the browser uses token 2 to send an access request to the online store. The online store redirects to the CAS server to verify the validity of token 2. Once the validity of token 2 is confirmed, the CAS server returns the verification result to the online store, which then returns resources from the online store, such as a product list, to the browser.

[0106] When the recruitment platform's token 1 expires, it displays that there are no tokens under the UserAgent. The CAS server returns this information to the browser, and Xiao Zhang needs to enter his login information to log in and obtain token 2 for access. Similarly, the CAS server records the correspondence between the UserAgent, user account information, and tokens.

[0107] 3. Non-first-time logins to "recruitment platforms" or "online shopping malls"

[0108] Whether it's a recruitment platform or an online shopping mall, the same C browser is still used for access during subsequent login processes. If the browser's token is still valid, it directly uses the token to send an access request to the corresponding resource server. After the CAS server verifies the token's validity, the corresponding resource server returns the corresponding resource to the browser.

[0109] If your own token has expired, you can access the CAS server for authentication by carrying the UserAgent. The CAS server will determine the token status of the UserAgent based on it. If there are other valid tokens for resource servers under the UserAgent, you can obtain a new token for access.

[0110] Assuming token 2 has expired, when Xiao Zhang uses browser C to access the online mall, since he is not logged in, the browser sends UserAgent-1 to the CAS server. The CAS server queries the device ID set based on UserAgent-1 and finds that token 1 for the recruitment platform is still valid. After successful verification, the CAS server issues token 3 for the online mall and updates the device ID set.

[0111] Of course, this is not limited to recruitment platforms and online shopping malls. When Xiao Zhang accesses any other resource server through the C browser and is issued a token, the browser's UserAgent can be bound to the token to form a set of device IDs. Based on this set of device IDs, Xiao Zhang can obtain a convenient, secure, and efficient single sign-on experience.

[0112] To further enhance security, it's possible to determine whether the user is indeed the same person as the login information, i.e., Xiao Zhang, based on browser usage habits. For example, when a user accesses any resource server, the UserAgent, login information, and corresponding token are only bound after the user has entered their login information more than twice; that is, the token is added to the device ID set.

[0113] Example 2: Multiple terminals log in to multiple servers

[0114] Figure 8 This is a schematic diagram of a multi-terminal seamless login access method in another embodiment of this application, as shown below. Figure 8 As shown:

[0115] In this embodiment, the interaction logic between the terminal and the resource server and CAS server is basically the same as in Embodiment 1. The difference lies in the cross-device single sign-on between multiple terminals and its specific implementation method. Compared with the ordinary process of the prior art, such as Figure 2As mentioned above, existing technologies can only achieve single sign-on on different resource servers on a single terminal, while the embodiments of this application can achieve cross-device single sign-on across multiple terminals.

[0116] 1. First-time login to the "Recruitment Platform" via mobile application

[0117] Suppose we have a system called a "recruitment platform" with the website ehire.51job.com, which can be accessed through various methods such as a computer browser, mobile application, and mobile browser. Before accessing the platform, user Xiao Zhang needs to register an account. During account registration, the information that the user needs to fill in is pre-set, such as username, password, mobile phone number, ID card number, or email address. In this embodiment, Xiao Zhang fills in an email address (e.g., xiaozhang@a.com) and a password (e.g., 123456) as login information. In addition, an ID card number (e.g., 3303...1234) is also included for unique identification. The recruitment platform stores this information in its database, and this information will serve as the key to cross-device user identification.

[0118] Xiao Zhang wants to access the job list on a recruitment platform. He opens an app on phone A. The app sends a request to the recruitment platform. When the recruitment platform receives the access request, since Xiao Zhang is not logged in, it detects the lack of a login status and returns a redirection instruction and the address of the CAS server to the app. The app then uses this instruction to access the CAS server for authentication, carrying the IMEI of phone A (e.g., 123456-78-901234-5). The CAS server determines the token status based on the IMEI. Since it is the first login, there is no token under the IMEI, and the CAS server returns this information to the app.

[0119] Xiao Zhang enters his login information to log in. The app sends the login information to the CAS server for verification. After verifying that the information is correct, the CAS server issues access token 1, which is valid for a certain period. The CAS server also performs an initial binding operation, recording the correspondence between the IMEI, user account, and token, as shown in Table 4 below:

[0120] Table 4

[0121]

[0122] After obtaining access token 1, the APP uses token 1 to send an access request to the recruitment platform. The recruitment platform redirects to the CAS server to verify the validity of token 1. After confirming that token 1 is valid, the CAS server returns the verification result to the recruitment platform. Based on this result, the recruitment platform returns resources from the recruitment platform, such as a job list, to the browser.

[0123] 2. First-time login to the "Online Store" via a computer browser.

[0124] Suppose we have another system called "Online Mall" with the website mall.51job.com. Before accessing the platform, user Xiao Zhang needs to register an account. During account registration, Xiao Zhang fills in his email address (e.g., xiaozhang@a.com) and password (e.g., 123456) as login information, and also includes his ID card number (e.g., 3303...1234) for unique identification. The Online Mall stores this information in its database.

[0125] Xiao Zhang wants to access the product list on an online shopping mall. He opens browser C on computer A. The browser sends a request to the online shopping mall. When the online shopping mall receives the access request, since Xiao Zhang is not logged in, the online shopping mall detects that he is not logged in and returns a redirect instruction and the address of the CAS server to the browser. The browser then uses this instruction to access the CAS server for authentication, carrying UserAgent-1. The CAS server determines the token status under UserAgent-1. Since it is the first login, there are no tokens under this UserAgent, and the CAS server returns this information to the browser.

[0126] Xiao Zhang enters his login information to log in. The browser sends the login information to the CAS server for verification. After verifying that the information is correct, the CAS server issues access token 2, which is valid for a certain period. The CAS server will also perform an initial binding operation, recording the correspondence between UserAgent-1 and the user account and token, as shown in Table 5 below:

[0127] Table 5

[0128]

[0129] At this point, the CAS server will also determine the user's unique identity based on the consistency of user account information, such as the ID card number in the account information. This results in a set of IMEI, UserAgent, user account, and token, i.e., a set of device IDs, as shown in Table 6 below:

[0130] Table 6

[0131]

[0132] Of course, this is not limited to recruitment platforms and online shopping malls. When Xiao Zhang accesses any other resource server through a browser and is issued a token, the browser's UserAgent can be bound to the token to form a set of device IDs. Based on this set of device IDs, Xiao Zhang can obtain a convenient, secure, and efficient single sign-on experience.

[0133] 3. Non-first-time logins to "recruitment platforms" or "online shopping malls"

[0134] Whether it's a recruitment platform or an online shopping mall, if the terminal used for the initial login is used again during subsequent logins, and if the terminal's token is still valid, the terminal will directly use the token to initiate an access request to the corresponding resource server. After the CAS server verifies the token's validity, the corresponding resource server will return the corresponding resource to the browser.

[0135] There are two other scenarios: First, Xiao Zhang accesses the recruitment platform through the APP on mobile phone A, but his own token has expired (or Xiao Zhang accesses the online mall through browser C on computer A, but his own token has expired); second, Xiao Zhang accesses the online mall through the APP on mobile phone A, but the recruitment platform's token has expired (or Xiao Zhang accesses the recruitment platform through browser C on computer A, but the online mall's token has expired).

[0136] In the first scenario, for example, if the recruitment platform's token 1 has expired, the APP uses the IMEI of phone A to access the CAS server for authentication. The CAS server queries the token status in the device ID set based on the IMEI. If there are other resource servers in the device ID set that still have valid tokens, such as token 2 under UserAgent-1, a new token 3 can be issued to the recruitment platform for access, and the device ID set can be updated.

[0137] In the second scenario, when the APP on phone A accesses the online mall, it can find the token 1 used to access the recruitment platform based on the IMEI of phone A. However, since token 1 has expired, the CAS server queries the token status in the device ID set based on the IMEI. If there are other valid tokens from other resource servers in the device ID set, such as token 2 under UserAgent-1, a new token 4 can be issued for phone A to access the online mall, and the device ID set can be updated.

[0138] To further enhance security, it's possible to determine whether the user is indeed the same person as the login information, i.e., Xiao Zhang, based on browser usage habits. For example, when a user accesses any resource server, the UserAgent, login information, and corresponding token are only bound after the user has entered their login information more than twice; that is, the token is added to the device ID set.

[0139] The electronic device in this application embodiment may be a user terminal device, a server, other computing devices, or a cloud server. Figure 9 A schematic diagram of an electronic device for implementing the multi-terminal seamless login access method of the embodiments of this application is shown. The electronic device may include a processor 601 and a memory 602 storing computer program instructions. When the processor 601 executes the computer program instructions, it implements the process or function of the method of any of the above embodiments.

[0140] Specifically, processor 601 may include a central processing unit (CPU), or an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application. Memory 602 may include mass storage for data or instructions. For example, memory 602 may be at least one of the following: hard disk drive (HDD), read-only memory (ROM), random access memory (RAM), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, universal serial bus (USB) drive, or other physical / tangible memory storage device. Alternatively, memory 602 may include removable or non-removable (or fixed) media. Furthermore, memory 602 may be internal or external to the integrated gateway disaster recovery device. Memory 602 may be non-volatile solid-state memory. In other words, typically memory 602 includes a tangible (non-transitory) computer-readable storage medium (such as a memory device) encoded with computer-executable instructions, and when the software is executed (e.g., by one or more processors), it can perform the operations described in the methods of the embodiments of this application. The processor 601 implements the process or function of any of the methods described in the above embodiments by reading and executing computer program instructions stored in the memory 602.

[0141] In one example Figure 9The illustrated electronic device may also include a communication interface 603 and a bus 610. The processor 601, memory 602, and communication interface 603 are connected via bus 610 and communicate with each other. Communication interface 603 is primarily used to enable communication between modules, devices, units, and / or equipment in the embodiments of this application. Bus 610 may include hardware, software, or both, and can couple components of the online data traffic billing device together. For example, the bus may include at least one of the following: Accelerated Graphics Port (AGP) or other graphics bus, Enhanced Industry Standard Architecture (EISA) bus, Front Side Bus (FSB), HyperTransport (HT) Interconnect, Industry Standard Architecture (ISA) bus, Infinite Bandwidth Interconnect, Low Pin Count (LPC) bus, memory bus, Microchannel Architecture (MCA) bus, Peripheral Component Interconnect (PCI) bus, PCI-Express (PCI-X) bus, Serial Advanced Technology Attachment (SATA) bus, Video Electronics Standards Association Local (VLB) bus, or other suitable buses. Bus 610 may include one or more buses. Although specific buses are described or illustrated in the embodiments of this application, any suitable bus or interconnection method may be considered in the embodiments of this application.

[0142] In conjunction with the methods in the above embodiments, this application also provides a computer-readable storage medium storing computer program instructions, which, when executed by a processor, implement the process or function of any of the methods in the above embodiments.

[0143] In addition, this application also provides a computer program product that stores computer program instructions, which, when executed by a processor, implement the process or function of any of the methods described above.

[0144] The flowcharts and / or block diagrams of methods, apparatuses, systems, and computer program products according to embodiments of this application have been exemplarily described above, and related aspects have been described. It should be understood that each block or combination thereof in the flowcharts and / or block diagrams may be implemented by computer program instructions, by dedicated hardware performing a specified function or action, or by a combination of dedicated hardware and computer instructions. For example, these computer program instructions may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to form a machine that enables the implementation of the function / action specified in each block or combination thereof in the flowcharts and / or block diagrams, executable via such processor. Such a processor may be a general-purpose processor, a dedicated processor, a special-purpose application processor, or a field-programmable logic circuit.

[0145] The functional blocks shown in the structural block diagrams of this application can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc.; when implemented in software, they are programs or code segments used to perform the required tasks. Programs or code segments can be stored in memory or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. Code segments can be downloaded via computer networks such as the Internet or intranets.

[0146] It should be noted that this application is not limited to the specific configurations and processes described above or shown in the figures. The above descriptions are merely specific embodiments of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the described systems, devices, modules, or units can be referred to the corresponding processes in the method embodiments, and need not be repeated here. It should be understood that the scope of protection of this application is not limited thereto. Any person skilled in the art can conceive of various equivalent modifications or substitutions within the scope of the technology disclosed in this application, and these modifications or substitutions should all be covered within the scope of protection of this application.

Claims

1. A multi-terminal seamless login access method based on tokens and device fingerprints, characterized in that, Applied to a terminal device, the method includes: When a first user accesses multiple servers through a first terminal, the first terminal sends its device fingerprint and login information for the first server to the authentication server without logging into the first server, so that the authentication server returns a first token and stores the device fingerprint of the first terminal in the user device fingerprint set of the first user, wherein the first token is used for the first terminal to access the first server. Without logging into the second server, the first terminal sends its device fingerprint to the authentication server, so that the authentication server can confirm the existence of the first token through the user device fingerprint set of the first user, generate a second token based on the first token, and send it to the first terminal. The second token is used by the first terminal to access the second server. The user device fingerprint set includes device fingerprints of some or all terminal devices corresponding to some or all of the user's login information, wherein the device fingerprint is a unique identifier of the terminal device.

2. The multi-terminal seamless login access method according to claim 1, further comprising, when the first user accesses multiple servers through multiple terminals: Without logging into the first server, the second terminal sends its device fingerprint and login information for the first server to the authentication server, so that the authentication server returns a third token and stores the device fingerprint of the second terminal in the user device fingerprint set of the first user. The third token is used by the second terminal to access the first server. Without logging into the second server, the third terminal sends its device fingerprint and login information for the second server to the authentication server, so that the authentication server returns a fourth token and stores the device fingerprint of the third terminal in the user device fingerprint set of the first user. The fourth token is used by the third terminal to access the second server. Without logging into the second server, the second terminal sends its device fingerprint to the authentication server. After the authentication server confirms that the third terminal is logged into the second server using the user device fingerprint set of the first user, it returns a fifth token to the second terminal. The fifth token is used by the second terminal to access the second server.

3. The multi-terminal seamless login access method according to any one of claims 1 or 2, wherein the device fingerprint is a hash value, and the hash value is calculated based on at least one of the following: International Mobile Equipment Identity (IMEI) code, browser User Agent (UA), terminal IP address, MAC address, or screen resolution.

4. A multi-terminal seamless login access method based on tokens and device fingerprints, applied to an authentication server, characterized in that, include: The authentication server receives the device fingerprint of the first terminal and login information for the first server, wherein the first terminal is not logged in on the first server; The authentication server sends a first token to the first terminal based on the device fingerprint and login information of the first terminal, and stores the device fingerprint of the first terminal in the user device fingerprint set of the first user, wherein the first token is used for the first terminal to access the first server; The authentication server receives the device fingerprint from the first terminal. The authentication server confirms the existence of the first token by using the user device fingerprint set of the first user; The authentication server generates a second token based on the first token and sends it to the first terminal. The second token is used by the first terminal to access the second server. The user device fingerprint set includes device fingerprints of some or all terminal devices corresponding to some or all of the user's login information, wherein the device fingerprint is a unique identifier of the terminal device.

5. The multi-terminal seamless login access method according to claim 4, further comprising, when the first user accesses multiple servers through multiple terminals: The authentication server receives the device fingerprint of the second terminal and login information for the first server, wherein the second terminal is not logged in on the first server; The authentication server sends a third token to the second terminal based on the device fingerprint and login information of the second terminal, and stores the device fingerprint of the second terminal in the user device fingerprint set of the first user, wherein the third token is used for the second terminal to access the first server; The authentication server receives the device fingerprint of the third terminal and login information for the second server, wherein the third terminal is not logged in on the second server; The authentication server sends a fourth token to the third terminal based on the device fingerprint and login information of the third terminal, and stores the device fingerprint of the third terminal in the user device fingerprint set of the first user. The fourth token is used by the third terminal to access the second server. The authentication server receives the device fingerprint of the second terminal, where the second terminal is not logged in on the second server. The authentication server uses the user device fingerprint set of the first user to confirm that the third terminal is logged in on the second server; The authentication server returns a fifth token to the second terminal, which is used by the second terminal to access the second server.

6. The multi-terminal seamless login access method according to any one of claims 4 or 5 further includes: The authentication server records the number of times the first user's login information is sent by the terminal, and stores the device fingerprints that have been sent more than a predetermined threshold within a predetermined time period in the first user's user device fingerprint set.

7. The multi-terminal seamless login access method according to any one of claims 4 or 5 further includes: The authentication server records the number of times each device fingerprint of the first user appears, and removes device fingerprints that appear less than a predetermined threshold within a predetermined time period from the first user's user device fingerprint set.

8. The multi-terminal seamless login access method according to any one of claims 4 or 5, wherein the device fingerprint is a hash value, and the hash value is calculated based on at least one of the following: International Mobile Equipment Identity (IMEI) code, browser User Agent (UA), terminal IP address, MAC address, or screen resolution.

9. An electronic device, characterized in that, The electronic device includes a processor and a memory storing computer program instructions; when the electronic device executes the computer program instructions, it implements the method as described in any one of claims 1-8.

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

Images