CN112333198B - Secure cross-domain login method, system and server - Google Patents

Abstract

The present invention provides a secure cross-domain login method, system and server, wherein the method includes: the first application server receives the login request sent by the first application client for requesting login to the target web page provided by the second application server, and according to the login Request to obtain the user identity information corresponding to the first application client, generate a request message according to the user identity information and send it to the second application server; the second application server generates a temporary trust token based on the request message, and send it to the first application client end; the first application client sends a jump request carrying a temporary trust token to the target web page provided by the second application server; the second application server verifies the temporary trust token, and after passing Perform login authorization. Using the above method, non-sensing cross-site access can be realized without secondary login, providing users with a better Internet experience, and the jump link is protected based on the temporary trust token, which is more secure.

Description

Secure cross-domain login method, system and server

technical field

The invention belongs to the technical field of communications, and in particular relates to a secure cross-domain login method, system and server.

Background technique

This section is intended to provide a background or context for implementations of the invention that are recited in the claims. The descriptions herein are not admitted to be prior art by inclusion in this section.

With the rapid development of Internet technology, the number of application software and websites is also increasing day by day, and most application software or websites often require registration and login before using related services. Between certain applications, such as social networking applications, shopping applications, game applications, internal business systems of enterprises, etc., due to business integration needs, users only need to log in to one application website, that is, they can log in to other application websites, which is also called It is cross-system login authentication.

At present, there is a cross-system login authentication scheme based on OAuth2.0 user authentication. OAuth2.0 allows third-party applications to jump to the login page of the system, and the user obtains an authorization code after authorization, and then uses the authorization code to obtain a token. , and finally go to the system to obtain protected resources through the token. However, this method requires users of third-party applications to register in this system, which is more demanding for third-party applications.

Therefore, a technical problem urgently needed by those skilled in the art is: how to propose a secure cross-domain login mechanism to enhance the user's senseless secure cross-domain login experience and ensure secure cross-domain login.

Contents of the invention

Aiming at the above-mentioned problems in the prior art, a secure cross-domain login method, device, and computer-readable storage medium are proposed, and the above-mentioned problems can be solved by using the method, device, and computer-readable storage medium.

The present invention provides the following solutions.

In the first aspect, a secure cross-domain login method is provided, including: the first application server receives a login request sent by the first application client, and the login request is used to request to log in to the target web page provided by the second application server; the first application server Obtaining user identity information corresponding to the first application client according to the login request, generating a request message according to the user identity information, and sending the request message to the second application server; the second application server generates a temporary trust token based on the request message, and sent to the first application client through the first application server; the first application client sends a jump request to the target webpage provided by the second application server, and the jump request carries at least a temporary trust token; The temporary trust token carried in the transfer request is verified, and after the verification is passed, the login authorization is performed to the first application client.

In some implementations, the login request includes device address information of the first application client, and the first application server acquires user identity information corresponding to the first application client according to the login request, and further includes: the first application server obtains the user identity information corresponding to the first application client according to the Perform a local query on the device address information to obtain user identity information corresponding to the first application client.

In some implementations, the first application server generates the request message according to the user identity information, and further includes: the first application server generates the request message based on the preset message specification; wherein the request message includes one or more of the following Item: the identity of the first application server, the device address information and user identity information corresponding to the first application client.

In some implementations, before the second application server generates the temporary trust token based on the request message, the method further includes: the second application server searches a pre-configured server whitelist according to the identity of the first application server to identify the server identity verification; where, if the server identity verification fails, the second application server refuses to generate a temporary trust token, and returns the first error message to the first application server.

In some embodiments, before the second application server generates the temporary trust token based on the request message, the method further includes: the second application server performs message verification on the request message according to the preset message specification; If the text verification fails, the second application server refuses to generate a temporary trust token, and returns a second error message to the first application server.

In some implementations, the preset message specification indicates that the request message includes at least one message mandatory field, and the second application server performs message verification on the request message according to the preset message specification, including: the second The application server judges whether the mandatory field in the request message is not empty and/or is filled in according to a preset format.

In some embodiments, the method further includes: the first application server generates a first key pair in advance based on an encryption algorithm, including a first public key and a first private key; Sign, and send the signed request message to the second application server; the second application server obtains the first public key provided by the first application server in advance, and performs signature verification on the received request message according to the first public key; Wherein, if the signature verification fails, the second application server refuses to generate the temporary trust token, and returns a third error message to the first application server.

In some embodiments, before the second application server generates the temporary trust token based on the request message, the method further includes: the first application server encrypts sensitive information on one or more pieces of user identity information to obtain sensitive identity information segments , the request message also includes a sensitive identity information segment; the second application server pre-acquires the sensitive information key provided by the first application server, and performs sensitive decryption on the sensitive identity information segment in the received request message according to the sensitive information key, The plaintext information of the user identity information is obtained; wherein, if the sensitive decryption is not successfully implemented, the second application server refuses to generate a temporary trust token, and returns a fourth error message to the first application server.

In some embodiments, the second application server generates a temporary trust token based on the request message, and further includes: the second application server generates a globally unique temporary trust token according to the user identity information contained in the request message; the second application server Cache the temporary trust token and corresponding user identity information to the memory database in the form of key-value pairs, and set a predetermined validity period for the temporary trust token, where the key-value pair corresponding to the temporary trust token will be Deleted from the in-memory database.

In some implementations, the second application server generates a globally unique temporary trust token according to the user identity information, and further includes: the second application server generates the temporary trust token by using a SnowFlake algorithm.

In some embodiments, after the second application server generates the temporary trust token based on the request message, it further includes: the second application server performs user registration or user binding according to the user identity information contained in the request message.

In some implementations, the method further includes: the second application server pre-generates a second key based on an encryption algorithm, including a second public key and a second private key; the second application server generates a response message according to the temporary trust token, and Sign the response message according to the second private key, and send the signed response message to the first application server; the first application server obtains the second public key provided by the second application server in advance, and according to the second public key Signature decryption is performed on the received response message.

In some implementations, the second application server verifies the temporary trust token carried in the redirect request, including: if the second application server verifies that the redirect request contains the temporary trust token, and contains the corresponding value of the temporary trust token, the first application client is authenticated for login; otherwise, the second application server refuses to be authenticated for login of the first application client.

In some implementations, the second application server verifies the temporary trust token carried in the redirection request, and further includes: the second application server obtains the source domain name included in the redirection request, searches the preset domain name whitelist according to the source domain name, and Perform source domain name verification on the redirection request; if the source domain name verification fails, the second application server refuses to perform login authorization for the first application client.

In some implementations, after performing login authorization on the first application client, the method further includes: the second application server extracts the user identity information corresponding to the temporary trust token in the memory database; the second application server obtains the corresponding and, the second application server provides corresponding equity information to the first application client based on preset equity rules, historical transaction information, and user identity information.

In the second aspect, a secure cross-domain login method is provided, which is applied to a first application server, including: receiving a login request sent by a first application client, where the login request is used to request login to a target web page provided by a second application server; according to The login request obtains the user identity information corresponding to the first application client, generates a request message according to the user identity information, and sends the request message to the second application server; receives the temporary trust token sent by the second application server, and the temporary trust token The card is generated based on the request message; the temporary trust token is sent to the first application client, so that the first application client sends a jump request to the target web page provided by the second application server, and the jump request carries at least the temporary trust token .

In some implementations, the login request includes the device address information of the first application client, and obtaining the user identity information corresponding to the first application client according to the login request further includes: performing a local query according to the device address information of the first application client to obtain Obtaining user identity information corresponding to the first application client; wherein, the first application client is pre-registered with the first application server based on the user identity information.

In a third aspect, a secure cross-domain login method is provided, which is applied to a second application server, including: receiving a request message sent by the first application server, the request message including the first application client communicating with the first application server Corresponding user identity information; generate a temporary trust token based on the request message, and send it to the first application client through the first application server, so that the first application client sends a jump to the target web page provided by the second application server request, and the redirection request carries at least a temporary trust token; verify the temporary trust token carried in the redirection request, and perform login authorization for the first application client after the verification is passed.

In some implementations, the request message includes one or more of the following: the identity of the first application server, device address information corresponding to the first application client, and user identity information.

In some implementations, the method further includes: searching a pre-configured server whitelist according to the identity of the first application server to perform server identity verification; wherein, if the server identity verification fails, refusing to generate a temporary trust token , and return the first error message to the first application server.

In some implementations, the method further includes: performing message verification on the request message according to the preset message specification; wherein, if the message verification fails, refusing to generate a temporary trust token, and sending the request to the first application server Return the second error message.

In some implementations, the preset message specification indicates that the request message includes at least one message mandatory field, and performing message verification on the request message according to the preset message specification includes: judging the Whether the mandatory field of the message is not empty and/or whether it is filled in according to the preset format.

In some implementations, the request message carries the first encrypted signature generated according to the first private key, and the method further includes: obtaining in advance the first public key provided by the first application server, where the first public key and the first private key are The first application server generates a key pair based on an encryption algorithm; performs signature verification on the first encrypted signature in the received request message according to the first public key; wherein, if the signature verification fails, then refuses to generate a temporary trust token, And return the third error message to the first application server.

In some embodiments, the request message further includes a sensitive identity information segment obtained by encrypting sensitive information on one or more pieces of user identity information, and the method further includes: obtaining in advance the sensitive information key provided by the first application server, And according to the sensitive information key, sensitively decrypt the sensitive identity information segment in the request message to obtain the plaintext information of the user identity information; if the sensitive decryption is not successfully realized, then refuse to generate a temporary trust token, and submit to the first The application server returns the fourth error message.

In some implementations, generating a temporary trust token based on the request message further includes: generating a globally unique temporary trust token according to the user identity information contained in the request message; combining the temporary trust token and the corresponding user identity information with The key-value pair is cached in the memory database, and a predetermined validity period is set for the temporary trust token, wherein, after the predetermined validity period is reached, the key-value pair corresponding to the temporary trust token is deleted from the memory database.

In some implementation manners, generating a globally unique temporary trust token according to user identity information further includes: generating the temporary trust token by using a SnowFlake algorithm.

In some embodiments, after the temporary trust token is generated based on the request message, the method further includes: performing user registration or user binding according to the user identity information contained in the request message.

In some implementations, after the temporary trust token is generated based on the request message, the method further includes: pre-generating a second key based on an encryption algorithm, including a second public key and a second private key; generating a response message based on the temporary trust token The response message is signed according to the second private key, and the signed response message is sent to the first application server, so that the first application server pairs the received information based on the second public key provided by the second application server. The response message is signed and decrypted.

In some implementations, verifying the temporary trust token carried in the redirect request includes: if the verification determines that the redirect request contains the temporary trust token and contains a value corresponding to the temporary trust token in the memory database, then Perform login authorization for the first application client; otherwise, refuse to perform login authorization for the first application client.

In some embodiments, verifying the temporary trust token carried in the redirection request further includes: obtaining the source domain name included in the redirection request, and searching the preset domain name whitelist according to the source domain name, so as to verify the source domain name in the redirection request. verification; if the verification of the source domain name fails, the login credit authorization for the first application client is refused.

In some implementations, after performing login authorization on the first application client, the method further includes: extracting user identity information corresponding to the temporary trust token in the memory database; obtaining corresponding historical transaction information according to the user identity information; and, based on The preset equity rules, historical transaction information and user identity information provide corresponding equity information for the first application client.

In a fourth aspect, a secure cross-domain login system is provided, including: a user terminal, a first application server, and a second application server; wherein, the user terminal is equipped with a first application client, and the first application client is used to log in to the first application server. The application server sends a login request for requesting to log in to the target web page provided by the second application server, and is also used to send a jump request to the target web page provided by the second application server after receiving the temporary trust token, and the jump request Carry at least a temporary trust token; the first application server is used to execute the method as in the second aspect; the second application server is used to execute the method as in the third aspect; the user terminal is also used to display the target web page provided by the second application server .

In a fifth aspect, a first application server is provided, configured to execute the method as in the second aspect.

In a sixth aspect, a second application server is provided for executing the method in the third aspect.

The above-mentioned at least one technical solution adopted in the embodiment of the present application can achieve the following beneficial effects: In this embodiment, the non-inductive cross-domain login can be realized without the user's second login, providing users with a better Internet experience, and based on the temporary trust token The card protects the jump link, which has higher security performance.

It should be understood that the above description is only an overview of the technical solution of the present invention, so as to understand the technical means of the present invention more clearly, and thus implement it according to the contents of the description. In order to make the above and other objects, features and advantages of the present invention more comprehensible, specific embodiments of the present invention are illustrated below.

Description of drawings

The advantages and benefits described herein, as well as other advantages and benefits, will be apparent to those of ordinary skill in the art upon reading the following detailed description of the exemplary embodiments. The drawings are only for the purpose of illustrating exemplary embodiments and are not to be considered as limiting the invention. Also throughout the drawings, the same reference numerals are used to denote the same parts. In the attached picture:

FIG. 1 is a schematic flow diagram of a secure cross-domain login method according to an embodiment of the present invention;

FIG. 2 is a schematic flow diagram of a secure cross-domain login method according to another embodiment of the present invention;

FIG. 3 is a schematic flowchart of a secure cross-domain login method according to yet another embodiment of the present invention;

4 is a schematic flowchart of a secure cross-domain login method according to yet another embodiment of the present invention;

FIG. 5 is a schematic structural diagram of a secure cross-domain login system according to an embodiment of the present invention.

In the drawings, the same or corresponding reference numerals denote the same or corresponding parts.

Detailed ways

Exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be embodied in various forms and should not be limited by the embodiments set forth herein. Rather, these embodiments are provided for more thorough understanding of the present disclosure and to fully convey the scope of the present disclosure to those skilled in the art.

In the present invention, it should be understood that terms such as "comprising" or "having" are intended to indicate the presence of features, numbers, steps, acts, components, parts or combinations thereof disclosed in the specification, and are not intended to exclude one or multiple other features, numbers, steps, acts, parts, parts or combinations thereof.

In addition, it should be noted that, in the case of no conflict, the embodiments of the present invention and the features in the embodiments can be combined with each other. The present invention will be described in detail below with reference to the accompanying drawings and examples.

An embodiment of the present invention provides a secure cross-domain login method. In the following, the inventive concept of the method is firstly introduced.

In addition to logging in to system A through the account and password registered on system A, users can also log in to system B that trusts system A through the account and password registered on system A. This login method is called trust Log in. After the user on system A trusts to log in to system B, the user of system A can access and operate the corresponding services provided by system B. For example, system A can be a shopping application system, and system B can be a payment application system. When users use shopping applications, they often need to jump to log in to the payment application system for payment operations. Embodiments of the present invention provide a secure cross-domain login method For example, the user clicks the "Payment" button on the interface of the client of the shopping application (ie, the first application client), thereby sending a server request for logging in to the payment application to the server of the shopping application (ie, the first application server). (that is, the second application server) provides a login request for the payment H5 page (that is, the target web page). The server of the shopping application obtains the user's user identity information according to the login request, such as the user's mobile phone number, bank card number, ID number, etc., and then generates a request message according to the user's identity information and sends it to the payment application server. Then the server of the payment application generates a globally unique temporary trust token based on the user identity information such as the mobile phone number, bank card number, and ID number in the request message, and sends it to the client of the shopping application through the server of the shopping application. The card expires after a period of time, and then the client of the shopping application can send a jump request to the payment H5 page provided by the payment application server with the temporary trust token within the validity period of the token. The temporary trust token carried in the jump request is verified, and after the verification is passed, the client of the shopping application is granted login credit, and the user can safely jump and log in to the payment H5 page to make payment. No sense of cross-site access can be realized without the need for users to log in again, providing users with a better Internet experience. The background server generates a temporary trust token with a valid period to protect the jump link, which has higher security performance.

Those skilled in the art may understand that the described application scenario is only an example in which the embodiments of the present invention may be implemented. The scope of application of the embodiments of the present invention is not limited in any way. After introducing the basic principles of the present invention, various non-limiting embodiments of the present invention are described in detail below.

Fig. 1 is a schematic flow diagram of a secure cross-domain login method 100 according to an embodiment of the present application. In this flow, from the perspective of equipment, the execution subject may be one or more electronic devices; from the perspective of program, the execution subject Correspondingly, it may be a program carried on these electronic devices.

As shown in Figure 1, the method 100 may include:

Step 101, the first application server receives a login request sent by the corresponding first application client;

Wherein, the login request may include device address information of the first application client, and may also include user identity information corresponding to the first application client, such as user name and other information. The login request is used to request to log in to the target web page provided by the second application server.

For example, the first application server can be the background server of the shopping application, the first application client can be the client of the shopping application, the second application server can be the server of the payment application, and the target web page can be the payment H5 page provided by the payment platform , the H5 page can be used to execute the payment task of the shopping application. The user can click a button such as "pay" on the first application client interface of the shopping application, thereby triggering a login request initiated by the first application client to the first application server, and the login request is used to request to log in to the second application The landing page page served by the server.

In a specific implementation, the user can access the first application server from any terminal device, such as a mobile phone, a smart wearable device, a notebook computer, a tablet computer, a computer, and the like. As long as these terminal devices run the first application client that accesses web pages through the Internet or the first application client with a built-in micro-browser.

Step 102, the first application server obtains user identity information corresponding to the first application client according to the login request, and generates a request message according to the user identity information.

Wherein, the user can register in the first application server in advance according to the user identity information, and log in the first application client corresponding to the first application server based on the registration information. At this time, the user only needs to trigger the designation of the first application client interface. button to send a login request to the first application server, and then the first application server can obtain the user identity information provided by the corresponding user of the first application client during registration. In another case, the user may also directly input the user identity information on the first application client interface, and carry the user identity information in the login request sent to the first application server.

Wherein, the user identity information may include one or more of mobile phone number, bank card number, ID card number, device address information, and biometric information (fingerprint information, face photo, etc.).

In some implementations, the login request may include the device address information of the first application client, and the first application server in step 102 obtains the user identity information corresponding to the first application client according to the login request, and may also include: the first application server A local query is performed according to the device address information of the first application client to obtain user identity information corresponding to the first application client. In other words, the user can pre-register with the first application server according to the user identity information, and after the first application server receives the login request, it can search locally according to the device address information in the login request, so as to obtain the corresponding information of the first application client. User identity information provided by the user during registration. In this way, the login request can be issued through a trigger action, avoiding repeated information input actions.

In some implementations, the first application server in step 102 generates the request message according to the user identity information, and further includes: the first application server generates the request message based on a preset message specification. In practical applications, the request message received by the second application server may have a relatively large amount of data, so the first application server may be required in advance to generate the request message according to a unified preset message specification, thereby facilitating the second application server to generate the request message. The server subsequently uses the request message.

Wherein, the request message may include one or more of the following information: the identity of the first application server, the device address information corresponding to the first application client, and user identity information. For example, one of the preset message specifications may require that the request message include: a timestamp field, an identity field of the first application server, a device address information field of the first application client, a mobile phone number field, an ID card field, Bank card number field. Wherein, the timestamp field may be the generation time and/or sending time of the request message. For another example, the preset message specification may require that some of the fields may be mandatory fields for the message, and some other fields may be non-mandatory fields for the message. Preset message specifications can be set according to actual application scenarios, and message specifications corresponding to different application scenarios may be different.

Step 103, the first application server sends the request packet to the second application server.

In some implementations, if any server can send a request message to the second application server, then the second application server may be overloaded when generating a temporary trust token based on a large number of received request messages. Therefore, the server whitelist can be pre-configured at the second application server, and then the server identity verification is performed according to the server whitelist, and then the received request message is screened in advance.

For example, referring to FIG. 2, before step 104, it is also possible to execute:

Step 21, the second application server obtains the identity of the first application server, and searches the pre-configured server whitelist according to the identity of the first application server 10 to perform server identity verification.

Wherein, if the server identity verification fails, the second application server refuses to generate the temporary trust token, and may return the first error message to the first application server. On the contrary, if the server identity verification passes, the second application server may continue to perform other subsequent verification steps based on the request message, or may generate a temporary trust token.

In one case, the first application server may send the server identification to the second application server in advance to perform the above server identity verification, and establish a connection between the first application server and the second application server after the above server identity verification is passed. Only through the communication connection, the first application server can send the request message to the second application server based on the communication connection. It can be understood that step 21 in this case is executed before step 103 . In another case, the request header of the request message sent by the first application server to the second application server may also contain the identity of the first application server, and then the request message may also be received by the second application server Afterwards, server identity verification is performed according to the identity of the first application server contained in the request message. It can be understood that step 21 in this case is executed after step 103 .

In some embodiments, since the first application server is a request message set according to the preset message specification, the message verification can be performed in advance with the preset message specification, and then the request that does not meet the preset message specification Packets are filtered out.

For example, referring to Fig. 2, after step 103, it is also possible to execute:

Step 22, the second application server performs message verification on the request message according to the preset message specification.

Wherein, if the message verification passes, the second application server may continue to perform other subsequent verification steps, or may generate a temporary trust token. On the contrary, if the message verification fails, the second application server refuses to generate the temporary trust token, and returns a second error message to the first application server.

In some implementations, the preset message specification may indicate that the request message includes at least one message mandatory field. Based on this, step 22 may specifically include: the second application server judging whether the message mandatory field in the request message is Is not empty and/or is filled in according to the preset format. For example, a preset message specification is given above, which requires that the request message include: a timestamp field, an identity field of the first application server, a device address information field of the first application client, a mobile phone number field, an identity Certificate field and bank card number field. Among them, the preset message specification may require that some of the fields may be mandatory fields of the message, such as the timestamp field and the bank card number field. At this time, if the request message received by the second application server does not contain these fields Then it can be considered that the message verification fails.

In some implementation manners, since the request message may be tampered with during transmission from the first application server to the second application server, the request message may be transmitted in a signed encrypted transmission manner. Specifically, the first application server may generate a first key pair in advance based on an encryption algorithm, including a first public key and a first private key. Further, the first application server provides the first public key to the second application server in advance, and after the first application server generates the request message, it can sign the request message according to the first private key, and the signed The signed request message is sent to the second application server to implement encrypted transmission, and the second application server may perform signature verification based on the first public key after receiving the signed request message.

For example, referring to Fig. 2, after step 103, it is also possible to execute:

Step 23: The second application server performs signature verification on the received request message according to the first public key pre-provided by the first application server.

Wherein, if the signature verification passes, the second application server may continue to generate the temporary trust token, or may continue to perform other subsequent verification steps. On the contrary, if the signature verification fails, it can be considered that the request message has been tampered with during transmission, so the second application server can refuse to generate a temporary trust token, and in this case can return the first application server to the first application server. 3. Report an error message to remind users and the system that there is a risk of message tampering.

It can be understood that the signature refers to the ciphertext obtained after the sender uses the private key to encrypt the digest of the text to be transmitted. Signature verification means that the recipient decrypts the signature with the public key it holds after receiving the transmitted text (the data encrypted by one key in the key pair must be decrypted by another key), and then obtain the text digest , and then use the same hash algorithm as the sender to calculate the digest value, and then compare it with the decrypted digest. If the two are found to be exactly the same, it means that the text has not been tampered with. If the two are found to be inconsistent, it means that the text is at risk of being tampered with.

Optionally, the encryption algorithm may be a symmetric encryption algorithm or an asymmetric encryption algorithm, which is not specifically limited in this application. In addition, in order to pursue higher security, an encryption machine can be used to save the key of the algorithm.

In some implementations, the user identity information may contain sensitive information with high security requirements such as the user's phone number, bank card number, and ID card number. If the transmission process is carried out in plain text, the user's private information may be leaked. , therefore, the above method may further include: the first application server encrypts sensitive information on one or more pieces of user identity information to obtain sensitive identity information segments. Based on this, the request message also includes the sensitive identity information segment, and the second application server can obtain the sensitive information key provided by the first application server in advance, and perform sensitive decryption on the sensitive identity information end after receiving the request message.

For example, referring to Fig. 2, after step 103, it is also possible to execute:

Step 24, the second application server performs sensitive decryption on the sensitive identity information segment in the request message according to the sensitive information key.

Among them, if the sensitive decryption is successfully implemented, that is, the plaintext information of the user identity information is obtained, then the plaintext information of the user identity information can be followed up to generate a temporary trust token. On the contrary, if the sensitive decryption is not successfully implemented, the second application server refuses to generate the temporary trust token, and returns a fourth error message to the first application server.

In the embodiments of the present disclosure, before the second application server generates the temporary trust token, any one or more of steps 21, 22, 23 and 24 may be performed, or the above steps may not be performed. In addition, the above step 21, step 22, step 23 and step 24 may be performed in any execution sequence, and the execution sequence shown in FIG. 2 is only an example, and the present application does not make specific limitations on this.

Step 104, the second application server generates a temporary trust token based on the request message.

In some implementations, step 104 may further include: the second application server generates a globally unique temporary trust token according to the user identity information contained in the request message; the second application server uses the temporary trust token and the corresponding user identity Information is cached to an in-memory database as key-value pairs, with a predetermined expiration date set for temporary trust tokens. For example, the predetermined valid time of the temporary trust token can be set to 5-10 seconds, and the key-value pair corresponding to the temporary trust token is deleted from the memory database after the predetermined valid period is reached.

Optionally, in the process of generating the globally unique temporary trust token by the second application server, if a system error occurs and the temporary trust token cannot be successfully generated, the second application server refuses to send the temporary trust token to the first application server. Trust the token, and send the fifth error message to the first application server.

Optionally, during the process of the second application server caching the temporary trust token and corresponding user identity information into the memory database in the form of key-value pairs, if a device error occurs, resulting in failure to cache successfully, the second application server rejects Send the temporary trust token to the first application server, and send the sixth error message to the first application server.

In some implementations, the second application server generates a globally unique temporary trust token according to the user identity information, and may further include: the second application server generates the temporary trust token by using a SnowFlake algorithm. The SnowFlake algorithm mainly includes three parts: time series, machine identification, and counting sequence number. Optionally, a uuid (Universally Unique Identifier) can also be used in a system with a low degree of concurrency instead of the temporary trust token to generate a serial number simply and quickly.

In some implementations, after step 104, it may further include: the second application server performs user registration or user binding according to the user identity information contained in the request message. Wherein, when the second application server registers a new user according to the user identity information, the second application server needs to send a registration request to the first application client through the first application server, and perform the user registration after obtaining the user's permission.

Optionally, during the above user registration process, if the user's permission is not obtained, the second application server may refuse to send the temporary trust token to the first application server, and send a seventh error message to the first application server.

Step 105, the second application server sends the temporary trust token to the first application server.

In some implementations, step 105 may also specifically include: the second application server generates a response message according to the temporary trust token and sends it to the first application server, and the response message carries the second private key generated by the second application server according to the second private key. Two encrypted signatures; the first application server pre-acquires the second public key provided by the second application server, and performs signature decryption on the second encrypted signature in the received response message according to the second public key; wherein, the second public key and The second private key is a key pair pre-generated by the second application server based on an encryption algorithm.

Specifically, during transmission from the second application server to the first application server, the response message may also be tampered with, so the response message may be transmitted in a signed encrypted transmission manner. Specifically, the second application server may generate a second key pair in advance based on an encryption algorithm, including a second public key and a second private key. Further, the second application server provides the second public key to the first application server in advance, and after the second application server generates the response message, it can sign the response message according to the second private key, and the signed After receiving the signed response message, the first application server may perform signature verification based on the second public key. It can be understood that if the signature verification fails, it can be considered that the response message has been tampered with during transmission, so the first application server can stop transmitting the temporary trust token contained in the response message to the first application client , and in this case, an alarm message can be issued to remind the user and the system that there is a risk of packet tampering. On the contrary, if the signature verification passes, it can be considered that the response message has not been tampered with, and step 106 can be further performed.

Step 106, the first application server forwards the temporary trust token to the first application client.

Step 107, the first application client sends a redirection request to the target web page, and the redirection request carries at least the temporary trust token request.

For example, after the temporary trust token is issued to the first application client, the user can bring the temporary trust token to the second application client by clicking the designated button on the interface of the first application client, such as the "Payment" button. The target web page provided by the application server sends a jump request, where the jump request may be a URL request.

Step 108, the target web page sends a call request to the second application server to request verification of the jump request.

Step 109, the second application server verifies the temporary trust token carried in the jump request.

Wherein, the second application server provides a calling interface for verifying the jump request to the target web page.

In some implementations, step 109 may specifically include: if the second application server verifies that the jump request contains a temporary trust token and contains a value corresponding to the temporary trust token in the memory database, the first application client The terminal performs login authorization; otherwise, the second application server refuses to perform login authorization for the first application client.

In some implementations, step 109 may also include: the second application server obtains the source domain name included in the redirect request, searches the preset domain name whitelist according to the source domain name, and verifies the source domain name for the redirect request; if the source domain name If the verification fails, the second application server refuses to perform login authorization for the first application client.

For example, if the redirection request is a URL request, the second application server first checks whether there is a temporary trust token in the URL request, and checks the request header in the URL request to check whether the source domain name contained therein is in the system configuration The default domain name whitelist. Wherein, if the URL request does not contain the temporary trust token or the source domain name contained in the request header is not in the preset domain name whitelist configured by the system, the URL request can be considered as an illegal request, and the second application server can reject the request. The first application client performs login credentialing, and can notify the user through the target web page. Secondly, if the URL request contains the temporary trust token, and the source domain name contained in the request header is in the preset domain name whitelist configured by the system, the memory can be searched based on the received temporary trust token as the key. Whether there is a value (value) in the database redis, if it exists, it means that the temporary trust token is generated by the second application server within the preset validity period and is legal, and the login credit can be performed.

Step 110, the second application server performs login authorization for the jump request after the above verification is passed.

Then the first application client can successfully jump to the target web page provided by the second application server, and obtain login authorization.

In some implementations, after performing login authorization on the first application client, the method further includes: the second application server extracts the user identity information corresponding to the temporary trust token in the memory database, and obtains the corresponding historical transaction information according to the user identity information , and provide corresponding equity information to the first application client based on preset equity rules, historical transaction information, and user identity information.

For example, the second application server can query the transaction data, and judge whether the user is If the standard is met, the benefits (such as discount coupons for supermarkets, car wash coupons, etc.) are issued, and users can see the benefits issued by each card on the target webpage, and then go to offline stores for consumption and use.

Based on the same technical concept, the embodiment of the present invention also provides a secure cross-domain login method, which is applied to the first application server, see Figure 3, including steps 301-305:

Step 301. Receive a login request sent by a first application client. Wherein, the login request is used to request to log in to the target web page provided by the second application server.

Step 302, acquiring user identity information corresponding to the first application client according to the login request;

Step 303, generating a request message according to the user identity information, and sending the request message to the second application server;

Step 304, receiving the temporary trust token sent by the second application server, where the temporary trust token is generated based on the request message;

Step 305: Send the temporary trust token to the first application client, so that the first application client sends a redirect request to the target web page provided by the second application server, and the redirect request carries at least the temporary trust token.

In some implementations, the login request includes the device address information of the first application client, and obtaining the user identity information corresponding to the first application client according to the login request further includes: performing a local query according to the device address information of the first application client to obtain Obtaining user identity information corresponding to the first application client; wherein, the first application client is pre-registered with the first application server based on the user identity information.

Based on the same technical concept, the embodiment of the present invention also provides a secure cross-domain login method, which is applied to the second application server, see Figure 4, including steps 401-403:

Step 401: Receive a request message sent by a first application server, where the request message includes user identity information corresponding to a first application client communicatively connected to the first application server.

Step 402, generate a temporary trust token based on the request message, and send it to the first application client through the first application server, so that the first application client sends a jump request to the target web page provided by the second application server, and jumps to The transfer request carries at least a temporary trust token;

Step 403: Verify the temporary trust token carried in the jump request, and perform login authorization for the first application client after the verification is passed.

In some implementations, the request message includes one or more of the following: the identity of the first application server, device address information corresponding to the first application client, and user identity information.

In some implementations, the method further includes: searching a pre-configured server whitelist according to the identity of the first application server to perform server identity verification; wherein, if the server identity verification fails, refusing to generate a temporary trust token , and return the first error message to the first application server.

In some implementations, the method further includes: performing message verification on the request message according to the preset message specification; wherein, if the message verification fails, refusing to generate a temporary trust token, and sending the request to the first application server Return the second error message.

In some implementations, the preset message specification indicates that the request message includes at least one message mandatory field, and performing message verification on the request message according to the preset message specification includes: judging the Whether the mandatory field of the message is not empty and/or whether it is filled in according to the preset format.

In some implementations, the request message carries the first encrypted signature generated according to the first private key, and the method further includes: obtaining in advance the first public key provided by the first application server, where the first public key and the first private key are The first application server generates a key pair based on an encryption algorithm; performs signature verification on the first encrypted signature in the received request message according to the first public key; wherein, if the signature verification fails, then refuses to generate a temporary trust token, And return the third error message to the first application server.

In some embodiments, the request message further includes a sensitive identity information segment obtained by encrypting sensitive information on one or more pieces of user identity information, and the method further includes: obtaining in advance the sensitive information key provided by the first application server, And according to the sensitive information key, sensitively decrypt the sensitive identity information segment in the request message to obtain the plaintext information of the user identity information; if the sensitive decryption is not successfully realized, then refuse to generate a temporary trust token, and submit to the first The application server returns the fourth error message.

In some implementations, generating a temporary trust token based on the request message further includes: generating a globally unique temporary trust token according to the user identity information contained in the request message; combining the temporary trust token and the corresponding user identity information with The key-value pair is cached in the memory database, and a predetermined validity period is set for the temporary trust token, wherein, after the predetermined validity period is reached, the key-value pair corresponding to the temporary trust token is deleted from the memory database.

In some implementation manners, generating a globally unique temporary trust token according to user identity information further includes: generating the temporary trust token by using a SnowFlake algorithm.

In some embodiments, after the temporary trust token is generated based on the request message, the method further includes: performing user registration or user binding according to the user identity information contained in the request message.

In some implementations, after the temporary trust token is generated based on the request message, the method further includes: pre-generating a second key based on an encryption algorithm, including a second public key and a second private key; generating a response message based on the temporary trust token The response message is signed according to the second private key, and the signed response message is sent to the first application server, so that the first application server pairs the received information based on the second public key provided by the second application server. The response message is signed and decrypted.

In some implementations, verifying the temporary trust token carried in the redirect request includes: if the verification determines that the redirect request contains the temporary trust token and contains a value corresponding to the temporary trust token in the memory database, then Perform login authorization for the first application client; otherwise, refuse to perform login authorization for the first application client.

In some embodiments, verifying the temporary trust token carried in the redirection request further includes: obtaining the source domain name included in the redirection request, and searching the preset domain name whitelist according to the source domain name, so as to verify the source domain name in the redirection request. verification; if the verification of the source domain name fails, the login credit authorization for the first application client is refused.

In some implementations, after performing login authorization on the first application client, the method further includes: extracting user identity information corresponding to the temporary trust token in the memory database; obtaining corresponding historical transaction information according to the user identity information; and, based on The preset equity rules, historical transaction information and user identity information provide corresponding equity information for the first application client.

Based on the same technical concept, the embodiment of the present invention also provides a secure cross-domain login system, see Figure 5, the system includes: a first application server, a second application server, and a user terminal;

Wherein, the user terminal is equipped with a first application client, and the first application client is used to send a login request to the first application server for requesting to log in to the target web page provided by the second application server, and is also used to After the token, send a jump request to the target web page provided by the second application server, the jump request at least carries a temporary trust token; the first application server is used to execute the method shown in Figure 3; the second application server uses to perform the method shown in FIG. 4 . The user terminal is also used to display the target web page provided by the second application server.

Based on the same technical concept, the embodiment of the present invention further provides a first application server for executing the method shown in FIG. 3 and a second application server for executing the method shown in FIG. 4 .

It should be noted that the above-mentioned method, system, and server in the embodiment of the present application can realize each process of the embodiment of the method shown in FIG. 1 above, and achieve the same effect and function, which will not be repeated here.

Those skilled in the art should understand that the embodiments of the present invention may be provided as methods, systems or computer program products. Accordingly, the present invention can take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein.

The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It should be understood that each procedure and/or block in the flowchart and/or block diagram, and a combination of procedures and/or blocks in the flowchart and/or block diagram can be realized by computer program instructions. These computer program instructions may be provided to a general purpose computer, special purpose computer, embedded processor, or processor of other programmable data processing equipment to produce a machine such that the instructions executed by the processor of the computer or other programmable data processing equipment produce a An apparatus for realizing the functions specified in one or more procedures of the flowchart and/or one or more blocks of the block diagram.

These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing apparatus to operate in a specific manner, such that the instructions stored in the computer-readable memory produce an article of manufacture comprising instruction means, the instructions The device realizes the function specified in one or more procedures of the flowchart and/or one or more blocks of the block diagram.

These computer program instructions can also be loaded onto a computer or other programmable data processing device, causing a series of operational steps to be performed on the computer or other programmable device to produce a computer-implemented process, thereby The instructions provide steps for implementing the functions specified in the flow chart or blocks of the flowchart and/or the block or blocks of the block diagrams.

In a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

Memory may include non-permanent storage in computer readable media, in the form of random access memory (RAM) and/or nonvolatile memory such as read only memory (ROM) or flash RAM. Memory is an example of computer readable media.

Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can be implemented by any method or technology for storage of information. Information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read only memory (ROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Flash memory or other memory technology, Compact Disc Read-Only Memory (CD-ROM), Digital Versatile Disc (DVD) or other optical storage, Magnetic tape cartridge, tape magnetic disk storage or other magnetic storage device or any other non-transmission medium that can be used to store information that can be accessed by a computing device. In addition, while operations of the methods of the present invention are depicted in the figures in a particular order, there is no requirement or implication that these operations must be performed in that particular order, or that all illustrated operations must be performed, to achieve desirable results. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step for execution, and/or one step may be decomposed into multiple steps for execution.

Although the spirit and principles of the invention have been described with reference to a number of specific embodiments, it should be understood that the invention is not limited to the specific embodiments disclosed, nor does division of aspects imply that features in these aspects cannot be combined to achieve optimal performance. Benefit, this division is only for the convenience of expression. The present invention is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims.

Claims (32)

1. A secure cross-domain login method, characterized in that the method comprises: The first application server receives a login request sent by the first application client, and the login request is used to request to log in to a target web page provided by the second application server; The first application server obtains user identity information corresponding to the first application client according to the login request, generates a request message according to the user identity information, and sends the request message to the second application server; The second application server generates a globally unique temporary trust token based on the user identity information contained in the request message, and caches the temporary trust token and corresponding user identity information in the form of a key-value pair to an in-memory database, And set a predetermined validity period for the temporary trust token, and send it to the first application client through the first application server; The first application client sends a jump request to the target web page provided by the second application server, and the jump request carries at least the temporary trust token; The second application server verifies the temporary trust token carried in the jump request, and performs login authorization for the first application client after the verification is passed, wherein if the second application server verifies that If the jump request includes the temporary trust token, and the memory database key-value pair includes a value corresponding to the temporary trust token, then login authorization is performed on the first application client. 2. The method according to claim 1, wherein the login request includes device address information of the first application client, and the first application server obtains the device address information corresponding to the first application according to the login request. The client's user identity information also includes: The first application server performs a local query according to the device address information of the first application client to obtain the user identity information corresponding to the first application client. 3. The method according to claim 1, wherein the first application server generates a request message according to the user identity information, further comprising: The first application server generates the request message based on a preset message specification; Wherein, the request message includes one or more of the following: the identity of the first application server, the device address information corresponding to the first application client, and the user identity information. 4. The method according to claim 3, wherein, before the second application server generates a temporary trust token based on the request message, the method further comprises: The second application server searches a pre-configured server whitelist according to the identity of the first application server to perform server identity verification; Wherein, if the server identity verification fails, the second application server refuses to generate the temporary trust token, and returns first error message to the first application server. 5. The method according to claim 3, wherein, before the second application server generates a temporary trust token based on the request message, the method further comprises: The second application server performs message verification on the request message according to the preset message specification; Wherein, if the message verification fails, the second application server refuses to generate the temporary trust token, and returns a second error message to the first application server. 6. The method according to claim 5, wherein the preset message specification indicates that the request message includes at least one message mandatory field, and the second application server according to the preset message The specification performs message verification on the request message, including: The second application server determines whether the mandatory field in the request message is not empty and/or is filled in according to a preset format. 7. The method according to claim 1, further comprising: The first application server generates a first key pair in advance based on an encryption algorithm, including a first public key and a first private key; The first application server signs the request message according to the first private key, and sends the signed request message to the second application server; The second application server pre-obtains the first public key provided by the first application server, and performs signature verification on the received request message according to the first public key; Wherein, if the signature verification fails, the second application server refuses to generate the temporary trust token, and returns a third error message to the first application server. 8. The method according to claim 3, wherein before the second application server generates a temporary trust token based on the request message, the method further comprises: The first application server encrypts sensitive information on one or more items of the user identity information to obtain a sensitive identity information segment, and the request message also includes the sensitive identity information segment; The second application server obtains in advance the sensitive information key provided by the first application server, and performs sensitive decryption on the sensitive identity information segment in the received request message according to the sensitive information key, so as to Obtain the plaintext information of the user identity information; Wherein, if the sensitive decryption is not successfully implemented, the second application server refuses to generate the temporary trust token, and returns a fourth error message to the first application server. 9. The method according to claim 1, wherein the second application server generates a globally unique temporary trust token according to the user identity information, further comprising: The second application server uses a SnowFlake algorithm to generate the temporary trust token. 10. The method according to claim 1, wherein after the second application server generates a temporary trust token based on the request message, further comprising: The second application server performs user registration or user binding according to the user identity information included in the request message. 11. The method of claim 1, further comprising: The second application server pre-generates a second key based on an encryption algorithm, including a second public key and a second private key; The second application server generates a response message according to the temporary trust token, signs the response message according to the second private key, and sends the signed response message to the the first application server; The first application server pre-obtains the second public key provided by the second application server, and performs signature decryption on the received response message according to the second public key. 12. The method according to claim 1, wherein the second application server verifies the temporary trust token carried in the jump request, comprising: If the second application server has not verified that the jump request contains the temporary trust token and contains a value corresponding to the temporary trust token in the memory database, the second application The server refuses to perform login authorization for the first application client. 13. The method according to claim 1, wherein the second application server verifies the temporary trust token carried in the jump request, further comprising: The second application server obtains the source domain name included in the redirect request, and searches a preset white list of domain names according to the source domain name, so as to verify the source domain name of the redirect request; If the verification of the source domain name fails, the second application server refuses to perform login authorization for the first application client. 14. The method according to claim 12, characterized in that after performing login authorization on the first application client, the method further comprises: The second application server extracts user identity information corresponding to the temporary trust token in the memory database; The second application server obtains corresponding historical transaction information according to the user identity information; and, The second application server provides corresponding equity information for the first application client based on preset equity rules, the historical transaction information, and the user identity information. 15. A secure cross-domain login method, characterized in that it is applied to a first application server, the method comprising: receiving a login request sent by the first application client, where the login request is used to request to log in to a target web page provided by the second application server; Obtaining user identity information corresponding to the first application client according to the login request; generating a request message according to the user identity information, and sending the request message to the second application server; receiving the temporary trust token sent by the second application server, the temporary trust token is globally uniquely generated based on the user identity information contained in the request message, and the temporary trust token and the corresponding user identity information are keyed The value pair is cached to the memory database, and the temporary trust token is set with a predetermined validity period; sending the temporary trust token to the first application client, so that the first application client sends a jump request to the target webpage provided by the second application server, and the jump request is at least Carry the temporary trust token, wherein if the second application server verifies that the jump request contains the temporary trust token, and the memory database key-value pair contains the key value corresponding to the temporary trust token value of the card, perform login authorization for the first application client. 16. The method according to claim 15, wherein the login request includes device address information of the first application client, and the user identity information corresponding to the first application client is obtained according to the login request, Also includes: Perform a local query according to the device address information of the first application client to obtain user identity information corresponding to the first application client. 17. A secure cross-domain login method, characterized in that it is applied to a second application server, the method comprising: receiving a request message sent by a first application server, where the request message includes user identity information corresponding to a first application client that is communicatively connected to the first application server; Generate a globally unique temporary trust token based on the user identity information contained in the request message, cache the temporary trust token and corresponding user identity information in the memory database in the form of key-value pairs, and store the temporary trust token Set a predetermined validity period and send it to the first application client through the first application server, so that the first application client sends a jump request to the target web page provided by the second application server, so The jump request carries at least the temporary trust token, verifies the temporary trust token carried in the jump request, and performs login authorization for the first application client after the verification is passed; Wherein if the second application server verifies that the jump request contains the temporary trust token and the memory database key-value pair contains a value corresponding to the temporary trust token, then the The first application client performs login authorization. 18. The method according to claim 17, wherein the request message includes one or more of the following: the identity of the first application server, the corresponding The device address information and the user identity information. 19. The method of claim 18, further comprising: Searching for a pre-configured server whitelist according to the identity of the first application server to perform server identity verification; Wherein, if the server identity verification fails, then refuse to generate the temporary trust token, and return a first error message to the first application server. 20. The method of claim 18, further comprising: Performing message verification on the request message according to a preset message specification; Wherein, if the message verification fails, refuse to generate the temporary trust token, and return a second error message to the first application server. 21. The method according to claim 20, wherein the preset message specification indicates that the request message includes at least one message mandatory field, and, Carrying out message verification on the request message according to the preset message specification, including: Judging whether the required fields in the request message are not empty and/or filled in according to a preset format. 22. The method according to claim 17, wherein the request message carries a first encrypted signature generated according to the first private key, and the method further comprises: Acquiring in advance the first public key provided by the first application server, wherein the first public key and the first private key are a key pair generated by the first application server based on an encryption algorithm; performing signature verification on the first encrypted signature in the received request message according to the first public key; Wherein, if the signature verification fails, refuse to generate the temporary trust token, and return a third error message to the first application server. 23. The method according to claim 17, wherein the request message further includes a sensitive identity information segment obtained by encrypting sensitive information on one or more items of the user identity information, and the method further includes include: Obtaining in advance the sensitive information key provided by the first application server, and sensitively decrypting the sensitive identity information segment in the request message according to the sensitive information key to obtain the plaintext of the user identity information information; Wherein, if the sensitive decryption is not successfully implemented, then refuse to generate the temporary trust token, and return fourth error information to the first application server. 24. The method according to claim 17, wherein generating a globally unique temporary trust token according to the user identity information further comprises: The temporary trust token is generated using the SnowFlake algorithm. 25. The method according to claim 17, wherein after the temporary trust token is generated based on the request message, the method further comprises: Perform user registration or user binding according to the user identity information included in the request message. 26. The method according to claim 17, wherein after the temporary trust token is generated based on the request message, the method further comprises: Pre-generate a second key based on an encryption algorithm, including a second public key and a second private key; generating a response message according to the temporary trust token, signing the response message according to the second private key, and sending the signed response message to the first application server, making the first application server perform signature decryption on the received response message based on the second public key provided by the second application server. 27. The method according to claim 17, wherein verifying the temporary trust token carried in the jump request comprises: If it is not verified that the jump request contains the temporary trust token and the memory database contains a value corresponding to the temporary trust token, then refuse to log in to the first application client credit. 28. The method according to claim 17, wherein verifying the temporary trust token carried in the jump request further comprises: Obtaining the source domain name included in the redirect request, and searching a preset domain name whitelist according to the source domain name, so as to verify the source domain name for the redirect request; If the verification of the source domain name fails, refuse to perform login authorization for the first application client. 29. The method according to claim 17, characterized in that after performing login authorization on the first application client, the method further comprises: extracting the user identity information corresponding to the temporary trust token in the memory database; Obtain corresponding historical transaction information according to the user identity information; and, Providing corresponding equity information to the first application client based on preset equity rules, the historical transaction information, and the user identity information. 30. A secure cross-domain login system, characterized by comprising: a user terminal, a first application server, and a second application server; wherein, The user terminal is equipped with a first application client, and the first application client is used to send to the first application server a login request for requesting to log in to the target web page provided by the second application server, and is also used to receive After the temporary trust token, send a jump request to the target web page provided by the second application server, the jump request at least carries the temporary trust token; The first application server is configured to execute the method according to any one of claims 15-16; The second application server is configured to execute the method according to any one of claims 17-29; The user terminal is further configured to display the target web page provided by the second application server. 31. The first application server, characterized in that it is configured to execute the method according to any one of claims 15-16. 32. The second application server is configured to execute the method according to any one of claims 17-29.