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

Secure cross-domain login method, system and server Download PDF

Info

Publication number
CN112333198A
CN112333198A CN202011284833.7A CN202011284833A CN112333198A CN 112333198 A CN112333198 A CN 112333198A CN 202011284833 A CN202011284833 A CN 202011284833A CN 112333198 A CN112333198 A CN 112333198A
Authority
CN
China
Prior art keywords
application server
trust token
request
temporary trust
application
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN202011284833.7A
Other languages
Chinese (zh)
Other versions
CN112333198B (en
Inventor
胡小舟
王荣海
汤茂安
魏柯宁
林英觉
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
China Unionpay Co Ltd
Original Assignee
China Unionpay Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by China Unionpay Co Ltd filed Critical China Unionpay Co Ltd
Priority to CN202011284833.7A priority Critical patent/CN112333198B/en
Publication of CN112333198A publication Critical patent/CN112333198A/en
Application granted granted Critical
Publication of CN112333198B publication Critical patent/CN112333198B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0815—Network architectures or network communication protocols for network security for authentication of entities providing single-sign-on or federations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • H04L63/0838—Network architectures or network communication protocols for network security for authentication of entities using passwords using one-time-passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0863—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving passwords or one-time passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/088—Usage controlling of secret information, e.g. techniques for restricting cryptographic keys to pre-authorized uses, different access levels, validity of crypto-period, different key- or password length, or different strong and weak cryptographic algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
    • H04L9/3228—One-time or temporary data, i.e. information which is sent for every authentication or authorization, e.g. one-time-password, one-time-token or one-time-key
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

The invention provides a secure cross-domain login method, a secure cross-domain login system and a secure cross-domain login server, wherein the method comprises the following steps: the method comprises the steps that a first application server receives a login request which is sent by a first application client and used for requesting to login a target webpage provided by a second application server, user identity information corresponding to the first application client is obtained according to the login request, a request message is generated according to the user identity information, and the request message is sent to the second application server; the second application server generates a temporary trust token based on the request message and sends the temporary trust token to the first application client; the first application client sends a jump request carrying a temporary trust token to a target webpage provided by a second application server; and the second application server verifies the temporary trust token and logs in and trusts the first application client after the temporary trust token passes the verification. By the method, the non-inductive cross-site access can be realized without secondary login, better internet experience is provided for users, and jump links are protected based on the temporary trust token, so that the method is safer.

Description

Secure cross-domain login method, system and server
Technical Field
The invention belongs to the technical field of communication, and particularly relates to a secure cross-domain login method, a secure cross-domain login system and a secure cross-domain login server.
Background
This section is intended to provide a background or context to the embodiments of the invention that are recited in the claims. The description herein is 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 increasing, and most application software or websites often need to be registered and logged in to use related services. Between some applications, such as social applications, shopping applications, game applications, business systems in enterprises, etc., because of business integration needs, a user only needs to log in one application website, and can access other application websites in a login state, which is also called cross-system login authentication.
At present, a cross-system login authentication scheme is based on oauth2.0 user authentication, oauth2.0 allows a third-party application to skip a login page of the system, the user obtains an authorization code after authorization, obtains a token by using the authorization code, and finally obtains a protected resource from the system by using the token. However, this method requires that the user of the third party application must register in the system, which is more demanding for the third party application.
Therefore, one technical problem that needs to be urgently solved by those skilled in the art is: how to provide a safe cross-domain login mechanism to enhance the non-inductive safe cross-domain login experience of a user and ensure the safe cross-domain login.
Disclosure of Invention
In view of the above problems in the prior art, a secure cross-domain login method, a secure cross-domain login device, and a computer-readable storage medium are provided.
The present invention provides the following.
In a first aspect, a secure cross-domain login method is provided, including: the method comprises the steps that a first application server receives a login request sent by a first application client, wherein the login request is used for requesting to login a target webpage provided by a second application server; the first application server acquires 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 temporary trust token based on the request message and sends the temporary trust token to the first application client through the first application server; the first application client sends a jump request to a target webpage provided by a second application server, wherein the jump request at least carries a temporary trust token; and the second application server verifies the temporary trust token carried by the skip request and logs in and grants the first application client after the verification is passed.
In some embodiments, the login request includes device address information of the first application client, and the first application server obtains user identity information corresponding to the first application client according to the login request, further including: the first application server carries out local inquiry according to the equipment address information of the first application client so as to obtain the user identity information corresponding to the first application client.
In some embodiments, the first application server generates the request message according to the user identity information, further including: the first application server generates a request message based on a preset message specification; wherein the request message includes one or more of: the identity of the first application server, the device address information corresponding to the first application client and the user identity information.
In some embodiments, before the second application server generates the temporary trust token based on the request message, the method further comprises: the second application server searches a pre-configured server white list according to the identity of the first application server so as to verify the identity of the server; and if the server identity verification fails, the second application server refuses to generate the temporary trust token and returns first error report information 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 comprises: the second application server performs message verification on the request message according to a preset message specification; and if the message is not verified, the second application server refuses to generate the temporary trust token and returns second error report information to the first application server.
In some embodiments, the preset message specification indicates that the request message includes at least one message mandatory fill field, and the second application server performs message verification on the request message according to the preset message specification, including: the second application server judges whether the necessary message filling field in the request message is not empty and/or is filled according to a preset format.
In some embodiments, the method further comprises: the first application server generates a first key pair in advance based on an encryption algorithm, wherein the first key pair comprises 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 acquires a 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; and if the signature verification fails, the second application server refuses to generate the temporary trust token and returns third error information 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 of one or more items of user identity information to obtain a sensitive identity information segment, and the request message further comprises the sensitive identity information segment; the second application server acquires the sensitive information key provided by the first application server in advance, and sensitively decrypts the sensitive identity information segment in the received request message according to the sensitive information key to acquire the plaintext information of the user identity information; and if the sensitive decryption is not successfully realized, the second application server refuses to generate the temporary trust token and returns fourth error information to the first application server.
In some embodiments, the second application server generates the temporary trust token based on the request packet, further comprising: the second application server generates a globally unique temporary trust token according to the user identity information contained in the request message; and the second application server caches the temporary trust token and the corresponding user identity information to the memory database in a key-value pair mode, and sets a preset validity period for the temporary trust token, wherein the key-value pair corresponding to the temporary trust token is deleted from the memory database after the preset validity period is reached.
In some embodiments, the second application server generates a globally unique temporary trust token based on the user identity information, further comprising: the second application server generates a temporary trust token using a snowflow algorithm.
In some embodiments, after the second application server generates the temporary trust token based on the request packet, the method further includes: and the second application server performs user registration or user binding according to the user identity information contained in the request message.
In some embodiments, the method further comprises: the second application server generates a second secret key in advance based on an encryption algorithm, wherein the second secret key comprises 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 a second private key, and sends the signed response message to the first application server; and the first application server acquires a second public key provided by the second application server in advance, and signs and decrypts the received response message according to the second public key.
In some embodiments, the verifying, by the second application server, the temporary trust token carried by the skip request includes: if the second application server verifies that the skip request contains the temporary trust token and the memory database contains a value corresponding to the temporary trust token, logging in and authorizing the first application client; otherwise, the second application server refuses to log in and trust the first application client.
In some embodiments, the verifying, by the second application server, the temporary trust token carried by the skip request further includes: the second application server obtains a source domain name contained in the skip request, and searches a preset domain name white list according to the source domain name so as to check the source domain name for the skip request; and if the source domain name is not verified, the second application server refuses to log in and authorize the trust to the first application client.
In some embodiments, after the first application client is logged in and trusted, the method further comprises: the second application server extracts user identity information corresponding to the temporary trust token from the memory database; the second application server acquires corresponding historical transaction information according to the user identity information; and the second application server provides corresponding rights and interests information for the first application client based on the preset rights and interests rule, the historical transaction information and the user identity information.
In a second aspect, a secure cross-domain login method is provided, which is applied to a first application server, and includes: receiving a login request sent by a first application client, wherein the login request is used for requesting to login a target webpage provided by a second application server; acquiring 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 a temporary trust token sent by a second application server, wherein the temporary trust token is generated based on the request message; and sending the temporary trust token to the first application client, so that the first application client sends a jump request to a target webpage provided by the second application server, wherein the jump request at least carries the temporary trust token.
In some embodiments, the login request includes device address information of the first application client, and the obtaining of the user identity information corresponding to the first application client according to the login request further includes: performing local query according to the equipment address information of the first application client to obtain user identity information corresponding to the first application client; the first application client is pre-registered in 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, and includes: receiving a request message sent by a first application server, wherein the request message contains user identity information corresponding to a first application client which is in communication connection with the first application server; generating a temporary trust token based on the request message, and sending the temporary trust token to the first application client through the first application server so that the first application client sends a jump request to a target webpage provided by the second application server, wherein the jump request at least carries the temporary trust token; and verifying the temporary trust token carried by the skip request, and logging in and authorizing the first application client after the verification is passed.
In some embodiments, the request message includes one or more of: the identity of the first application server, the device address information corresponding to the first application client and the user identity information.
In some embodiments, the method further comprises: searching a pre-configured server white list according to the identity of the first application server to verify the identity of the server; and if the server identity verification fails, refusing to generate the temporary trust token and returning first error information to the first application server.
In some embodiments, the method further comprises: carrying out message verification on the request message according to a preset message specification; and if the message is not verified, refusing to generate the temporary trust token, and returning second error information to the first application server.
In some embodiments, the indicating, by the preset message specification, that the request message includes at least one message mandatory fill field, and performing message verification on the request message according to the preset message specification includes: and judging whether the necessary message filling field in the request message is not empty and/or is filled according to a preset format.
In some embodiments, the request message carries a first cryptographic signature generated from a first private key, the method further comprising: the method comprises the steps that a first public key provided by a first application server is obtained in advance, wherein the first public key and a first private key are a key pair generated by the first application server based on an encryption algorithm; performing signature verification on a first encrypted signature in the received request message according to the first public key; and if the signature verification fails, refusing to generate the temporary trust token, and returning third error information to the first application server.
In some embodiments, the request message further includes a sensitive identity information segment obtained by encrypting sensitive information of one or more items of user identity information, and the method further includes: the method comprises the steps of obtaining a sensitive information key provided by a first application server in advance, and carrying out sensitive decryption on a sensitive identity information segment in a request message according to the sensitive information key to obtain plaintext information of user identity information; and if the sensitive decryption is not successfully realized, refusing to generate the temporary trust token, and returning fourth error information to the first application server.
In some embodiments, generating the temporary trust token based on the request message further comprises: generating a globally unique temporary trust token according to the user identity information contained in the request message; caching the temporary trust token and the corresponding user identity information to a memory database in a key-value pair mode, and setting a preset valid period for the temporary trust token, wherein the key-value pair corresponding to the temporary trust token is deleted from the memory database after the preset valid period is reached.
In some embodiments, generating a globally unique temporary trust token based on user identity information further comprises: a temporary trust token is generated using the snowflow algorithm.
In some embodiments, after generating the temporary trust token based on the request packet, the method further comprises: and performing user registration or user binding according to the user identity information contained in the request message.
In some embodiments, after generating the temporary trust token based on the request packet, the method further comprises: generating a second secret key in advance based on an encryption algorithm, wherein the second secret key comprises a second public key and a second private key; and generating a response message according to the temporary trust token, signing the response message according to a second private key, and sending the signed response message to the first application server so that the first application server signs and decrypts the received response message based on a second public key provided by the second application server.
In some embodiments, verifying the temporary trust token carried by the skip request includes: if the skip request contains the temporary trust token and the memory database contains a value corresponding to the temporary trust token through verification, login credit authorization is carried out on the first application client; otherwise, the first application client is refused to log in and trust.
In some embodiments, verifying the temporary trust token carried by the skip request further includes: acquiring a source domain name contained in the skip request, and searching a preset domain name white list according to the source domain name so as to check the source domain name for the skip request; and if the source domain name is not verified, refusing to log in and trust the first application client.
In some embodiments, after the first application client is logged in and trusted, the method further comprises: extracting user identity information corresponding to the temporary trust token in the memory database; acquiring corresponding historical transaction information according to the user identity information; and providing corresponding right information for the first application client based on the preset right rule, the historical transaction information and the user identity information.
In a fourth aspect, a secure cross-domain login system is provided, comprising: the system comprises a user terminal, a first application server and a second application server; the user terminal is provided with a first application client, the first application client is used for sending a login request for requesting to login a target webpage page provided by a second application server to the first application server, and is also used for sending a jump request to the target webpage page provided by the second application server after receiving a temporary trust token, and the jump request at least carries the temporary trust token; the first application server is for performing the method of the second aspect; the second application server is for performing the method of the third aspect; the user terminal is also used for displaying the target webpage provided by the second application server.
In a fifth aspect, a first application server is provided for performing the method of the second aspect.
In a sixth aspect, a second application server is provided for performing the method of the third aspect.
The embodiment of the application adopts at least one technical scheme which can achieve the following beneficial effects: in the embodiment, the non-inductive cross-domain login can be realized without secondary login of the user, better internet experience is provided for the user, the jump link is protected based on the temporary trust token, and the safety performance is higher.
It should be understood that the above description is only an overview of the technical solutions of the present invention, so as to clearly understand the technical means of the present invention, and thus can be implemented according to the content of the description. In order to make the aforementioned and other objects, features and advantages of the present invention comprehensible, embodiments accompanied with figures are described in detail below.
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 purposes of illustrating exemplary embodiments and are not to be construed as limiting the invention. Also, like reference numerals are used to refer to like elements throughout. In the drawings:
FIG. 1 is a flow chart illustrating a secure cross-domain login method according to an embodiment of the present invention;
FIG. 2 is a flowchart illustrating a secure cross-domain login method according to another embodiment of the present invention;
FIG. 3 is a flowchart illustrating a secure cross-domain login method according to another embodiment of the present invention;
FIG. 4 is a flowchart illustrating a secure cross-domain login method according to 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 indicate the same or corresponding parts.
Detailed Description
Exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. While 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 to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.
In the present invention, it is to be understood that terms such as "including" or "having," or the like, are intended to indicate the presence of the disclosed features, numbers, steps, behaviors, components, parts, or combinations thereof, and are not intended to preclude the possibility of the presence of one or more other features, numbers, steps, behaviors, components, parts, or combinations thereof.
It should be noted that the embodiments and features of the embodiments may be combined with each other without conflict. The present invention will be described in detail below with reference to the embodiments with reference to the attached drawings.
The embodiment of the invention provides a secure cross-domain login method, and the inventive concept of the method is introduced firstly.
In addition to logging in to the system a through the account and the password registered on the system a, the user may also log in to the system B trusting the system a through the account and the password registered on the system a, and this login manner is called as trusting login. After the user on the system A trusts to log on the system B, the user of the system A can access and operate the corresponding service provided by the system B. For example, the system a may be a shopping application system, the system B may be a payment application system, and when a user uses a shopping application, the user often needs to jump to the payment application system to perform a payment operation, and the embodiment of the present invention provides a secure cross-domain login method, for example, the user clicks a "payment" button on an interface of a client (i.e., a first application client) of the shopping application, so as to send a login request for requesting to login a payment H5 page (i.e., a target web page) provided by a server (i.e., a second application server) of the shopping application (i.e., the first application server). The server of the shopping application acquires the user identity information of the user according to the login request, such as the mobile phone number, the bank card number, the identification card number and the like of the user, and further generates a request message according to the user identity information and sends the request message to the server of the payment application. Then the server of the payment application generates a globally unique temporary trust token based on user identity information such as a mobile phone number, a bank card number, an identity card number and the like in the request message and sends the globally unique temporary trust token to the client of the shopping application through the server of the shopping application, the temporary trust token fails after a period of time, then the client of the shopping application can carry the temporary trust token within the validity period of the token and send a jump request to a payment H5 page provided by the server of the payment application, at the moment, the server of the payment application verifies the temporary trust token carried by the jump request and logs in and grants a credit to the client of the shopping application after the verification is passed, and the user can safely jump and log in the payment H5 page for payment. The non-inductive cross-site access can be realized without secondary login of the user, and better internet experience is provided for the user. The background server generates a temporary trust token with an effective period to protect the jump link, and the safety performance is higher.
Those skilled in the art will appreciate that the described application scenario is only one example in which an embodiment of the present invention may be implemented. The scope of applicability of the embodiments of the present invention is not limited in any way. Having described the general principles of the invention, various non-limiting embodiments of the invention are described in detail below.
Fig. 1 is a schematic flowchart of a secure cross-domain login method 100 according to an embodiment of the present application, in which from a device perspective, an execution subject may be one or more electronic devices; from the program perspective, the execution main body may accordingly be a program loaded on these electronic devices.
As shown in fig. 1, the method 100 may include:
step 101, a first application server receives a login request sent by a corresponding first application client;
the login request may include device address information of the first application client, or may also include user identity information corresponding to the first application client, such as information of a user name. The login request is used for requesting to login the target webpage provided by the second application server.
For example, the first application server may be a backend server of a shopping application, the first application client may be a client of the shopping application, the second application server may be a server of a payment application, and the target web page may be a payment H5 page provided by the payment platform, which H5 page may be used to perform payment tasks for the shopping application. The user may click a button, such as "pay" on a first application client interface of the shopping application, thereby triggering a login request initiated by the first application client to the first application server requesting to login to a target web page provided by the second application server.
In a specific implementation, a user may 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 so on. As long as the first application client runs on the terminal devices, a browser for accessing web pages via the internet or a built-in mini 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.
The user can register in the first application server in advance according to the user identity information, and log in at the first application client corresponding to the first application server based on the registration information, at this time, the user can send a login request to the first application server only by triggering an appointed button of the first application client interface, and then the first application server can obtain the user identity information provided by the user corresponding to the first application client during registration. In another case, the user may also directly input the user identity information in the first application client interface, and the login request sent to the first application server carries the user identity information.
The user identity information may include one or more of a mobile phone number, a bank card number, an identification number, device address information, and biometric information (fingerprint information, face photos, etc.).
In some embodiments, the login request may include device address information of the first application client, and the obtaining, by the first application server in step 102, user identity information corresponding to the first application client according to the login request may further include: the first application server carries out local inquiry according to the equipment address information of the first application client so as to obtain the user identity information corresponding to the first application client. In other words, the user may be pre-registered in the first application server according to the user identity information, and after receiving the login request, the first application server may locally search according to the device address information in the login request, so as to obtain the user identity information provided by the first application client when the user registers. The login request can thus be issued by means of a trigger action, avoiding repeated information entry actions.
In some embodiments, the generating, by the first application server in step 102, the request message according to the user identity information further includes: the first application server generates a request message based on a preset message specification. In practical application, the request message received by the second application server may have a relatively large data volume, so that the first application server may be required to generate the request message according to a uniform preset message specification in advance, thereby facilitating the second application server to subsequently use the request message.
The request message may include one or more of the following items of information: the identity of the first application server, the device address information corresponding to the first application client and the user identity information. For example, one of the predetermined message specifications may require that the request message include: the system comprises a timestamp field, an identity identification field of a first application server, an equipment address information field of a first application client, a mobile phone number field, an identity card field and a bank card number field. The timestamp field may be a generation time and/or an issue time of the request message. For another example, the predetermined message specification may require that some fields may be message padding fields and some other fields may be non-message padding fields. The preset message specification can be set according to the actual application scene, and the message specifications corresponding to different application scenes may be different.
Step 103, the first application server sends the request message to the second application server.
In some embodiments, if any one of the servers may send a request packet to the second application server, the second application server may generate an overload when generating the temporary trust token according to a large number of received request packets. Therefore, the server white list can be configured in advance at the second application server, and then the server identity verification is carried out according to the server white list, and further the received request message is screened in advance.
For example, referring to fig. 2, before step 104, it may also be performed:
step 21, the second application server obtains the identity of the first application server, and searches a preconfigured server white list according to the identity of the first application server 10 to perform server identity verification.
And if the server identity verification fails, the second application server refuses to generate the temporary trust token and can return first error report information to the first application server. Conversely, if the server identity check passes, the second application server may continue to perform subsequent further 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 identifier to the second application server in advance to perform the server identity check, and after the server identity check is passed, the communication connection between the first application server and the second application server is established, and the first application server can send the request message to the second application server based on the communication connection, and it can be understood that step 21 in this case is performed before step 103. In another case, the request header of the request packet sent by the first application server to the second application server may also include the identity of the first application server, and further, after the second application server receives the request packet, the server identity check may be performed according to the identity of the first application server included in the request packet, and it can be understood that step 21 in this case is performed after step 103.
In some embodiments, since the first application server is a request message set according to a preset message specification, the message may be checked in advance according to the preset message specification, and then the request message that does not meet the preset message specification is filtered.
For example, referring to fig. 2, after step 103, it may also be performed:
and step 22, the second application server performs message verification on the request message according to the preset message specification.
If the message passes the verification, the second application server may continue to perform other subsequent verification steps, or may generate a temporary trust token. And if the message is not verified, the second application server refuses to generate the temporary trust token and returns second error report information to the first application server.
In some embodiments, the preset message specification may indicate that the request message includes at least one message mandatory fill field, based on which step 22 may specifically include: the second application server judges whether the necessary message filling field in the request message is not empty and/or is filled according to a preset format. For example, a predetermined message specification is given above, which requires that the request message includes: the system comprises a timestamp field, an identity identification field of a first application server, an equipment address information field of a first application client, a mobile phone number field, an identity card field and a bank card number field. The preset message specification may require that some fields may be message mandatory fill fields, such as a timestamp field and a bank card number field, and at this time, if the request message received by the second application server does not include these fields, the message may be considered as failed in verification.
In some embodiments, the request message may be transmitted in a signed encrypted transmission, since the request message may be tampered with during transmission from the first application server to the second application server. Specifically, the first application server may generate a first key pair including a first public key and a first private key based on a cryptographic algorithm in advance. Further, the first application server provides the first public key to the second application server in advance, after the first application server generates the request message, the first application server may sign the request message according to the first private key, and send the signed request message to the second application server to implement encrypted transmission, and after receiving the signed request message, the second application server may perform signature verification based on the first public key.
For example, referring to fig. 2, after step 103, it may also be performed:
and step 23, the second application server performs signature verification on the received request message according to the first public key provided by the first application server in advance.
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, the request message may be considered to have been tampered in the transmission process, so the second application server may refuse to generate the temporary trust token, and in this case, may return a third error message to the first application server to remind the user and the system of the risk of message tampering.
It can be understood that the signature refers to a ciphertext obtained by encrypting a digest of a text to be transmitted by using a private key by a sender. The signature verification means that a public key held by a receiver after receiving a transmission text decrypts a signature (data encrypted by one key in a key pair must be decrypted by the other key) to obtain a text digest, then a hash algorithm same as that of a sender is used for calculating a digest value, and the digest value is compared with the digest obtained by decryption, if the two are found to be completely consistent, the text is not tampered. If the two are not consistent, the text is indicated to be at risk of being tampered.
Optionally, the encryption algorithm may be a symmetric encryption algorithm or an asymmetric encryption algorithm, which is not particularly limited in this application. In addition, the encryptor may be used to hold the keys of the algorithm for the purpose of pursuing higher security.
In some embodiments, the user identity information may include sensitive information with high security requirements, such as a phone number, a bank card number, an identification number, and the like of the user, and privacy information of the user may be leaked in a plaintext transmission manner during transmission, so the method may further include: the first application server encrypts sensitive information of one or more items of user identity information to obtain sensitive identity information segments. Based on this, the request message further includes a sensitive identity information segment, and the second application server may 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 may also be performed:
and 24, the second application server sensitively decrypts the sensitive identity information segment in the request message according to the sensitive information key.
If the sensitive decryption is successfully realized, that is, the plaintext information of the user identity information is obtained, the plaintext information of the user identity information can be continuously followed to generate the temporary trust token. On the contrary, if the sensitive decryption is not successfully realized, the second application server refuses to generate the temporary trust token, and returns fourth error information to the first application server.
In the embodiment of the present disclosure, before the second application server generates the temporary trust token, any one or more of step 21, step 22, step 23, and step 24 may be executed, or each of the above steps may not be executed. In addition, the steps 21, 22, 23 and 24 may be performed in any execution order, and the execution order shown in fig. 2 is only an example, and the present application is not particularly limited thereto.
And 104, the second application server generates a temporary trust token based on the request message.
In some embodiments, 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; and the second application server caches the temporary trust token and the corresponding user identity information to a memory database in a key-value pair mode, and sets a preset validity period for the temporary trust token. For example, the predetermined valid time of the temporary trust token may be set to 5-10 seconds, and the key-value pair corresponding to the temporary trust token may be deleted from the in-memory database after the predetermined valid period is reached.
Optionally, in the process of generating a globally unique temporary trust token by the second application server, if a system error occurs, resulting in that the temporary trust token cannot be successfully generated, the second application server refuses to send the temporary trust token to the first application server, and sends fifth error-reporting information to the first application server.
Optionally, in the process that the second application server caches the temporary trust token and the corresponding user identity information in the form of a key-value pair to the in-memory database, if a device error occurs and the caching fails, the second application server refuses to send the temporary trust token to the first application server and sends sixth error-reporting information to the first application server.
In some embodiments, 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 a temporary trust token using a snowflow algorithm. The SnowFlake algorithm mainly comprises three parts of a time sequence, a machine identifier and a counting sequence number. Optionally, in a system with low concurrency degree, uuid (universal Unique Identifier) may be used to replace the temporary trust token, so as to generate the serial number simply and quickly.
In some embodiments, after step 104, the method may further include: and the second application server performs user registration or user binding according to the user identity information contained in the request message. When the second application server performs new user registration 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 performs the user registration after obtaining the permission of the user.
Optionally, in the process of user registration, if the user permission is not obtained, the second application server may refuse to send the temporary trust token to the first application server, and send seventh error information to the first application server.
Step 105, the second application server sends the temporary trust token to the first application server.
In some embodiments, step 105 may further specifically include: the second application server generates a response message according to the temporary trust token and sends the response message to the first application server, wherein the response message carries a second encryption signature generated by the second application server according to a second private key; the first application server acquires a second public key provided by the second application server in advance, and carries out signature decryption on a second encrypted signature in the received response message according to the second public key; wherein the second public key and the second private key are a key pair generated in advance by the second application server based on an encryption algorithm.
In particular, the response message may also be tampered during transmission from the second application server to the first application server, and may therefore be transmitted using a signed encrypted transmission. Specifically, the second application server may generate a second key pair including a second public key and a second private key based on the encryption algorithm in advance. 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, the second application server may sign the response message according to the second private key, and send the signed response message to the first application server to implement encrypted transmission, and 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 may be considered that the response message has been tampered in the transmission process, so the first application server may stop transmitting the temporary trust token included in the response message to the first application client, and in this case, may send an alarm message to remind the user and the system of the risk of message tampering. If the signature is verified, the response message is considered not tampered, and step 106 can be further executed.
Step 106, the first application server forwards the temporary trust token to the first application client.
And 107, the first application client sends a jump request to the target webpage, wherein the jump request at least carries the temporary trust token request.
For example, after the temporary trust token is issued to the first application client, the user may click a designated button, such as a "pay" button, of the interface of the first application client, and then send a jump request, which may be a URL request, to the target web page provided by the second application server along with the temporary trust token.
And step 108, the target webpage sends a calling request to the second application server to request to verify the jump request.
And step 109, the second application server verifies the temporary trust token carried by the skip request.
And the second application server provides a calling interface for verifying the jump request to the target webpage.
In some embodiments, step 109 may specifically include: if the second application server verifies that the skip request contains the temporary trust token and the memory database contains a value corresponding to the temporary trust token, logging in and authorizing the first application client; otherwise, the second application server refuses to log in and trust the first application client.
In some embodiments, step 109 may further comprise: the second application server obtains a source domain name contained in the skip request, and searches a preset domain name white list according to the source domain name so as to check the source domain name for the skip request; and if the source domain name is not verified, the second application server refuses to log in and authorize the trust to the first application client.
For example, if the jump request is a URL request, the second application server first checks whether a temporary trust token exists in the URL request, and checks a request header in the URL request to check whether a source domain name included in the URL request is in a preset domain name white list configured by the system. If the URL request does not include the temporary trust token or the source domain name included in the request header is not in the preset domain name white list configured by the system, the URL request may be considered as an illegal request, and the second application server may refuse to log in and trust the first application client, and may notify the user through the target web page. Secondly, if the URL request includes the temporary trust token and the source domain name included in the request header is in a preset domain name white list configured by the system, whether a value (value) exists in the memory database redis can be searched according to the fact that the received temporary trust token is used as a key (key), and if the value (value) exists, the temporary trust token is generated for the second application server within a preset validity period, and the login trust can be performed.
And step 110, the second application server logs in and grants the skip request after the verification is passed.
The first application client can successfully jump to the target webpage provided by the second application server, and obtain the login credit.
In some embodiments, after the first application client is logged in and trusted, the method further comprises: the second application server extracts user identity information corresponding to the temporary trust token from the memory database, acquires corresponding historical transaction information according to the user identity information, and provides corresponding rights and interests information for the first application client based on the preset rights and interests rule, the historical transaction information and the user identity information.
For example, the second application server may query the transaction data, determine whether the user meets the standard according to a preconfigured rule (for example, the card grade is platinum card or above, the number of transaction strokes is greater than 2 per month, the amount of a single transaction is not less than 10 yuan, etc.), if the user meets the standard, issue rights and interests (for example, merchant super discount coupon, car wash coupon, etc.), the user may see the rights and interests issued by each card on the target webpage, and then go to an offline store for consumption and use.
Based on the same technical concept, an embodiment of the present invention further provides a secure cross-domain login method, which is applied to a first application server, referring to fig. 3, and includes steps 301-305:
step 301, receiving a login request sent by a first application client. And the login request is used for requesting to login the target webpage provided by the second application server.
Step 302, obtaining user identity information corresponding to a first application client according to a login request;
step 303, generating a request message according to the user identity information, and sending the request message to a second application server;
step 304, receiving a temporary trust token sent by the second application server, wherein the temporary trust token is generated based on the request message;
and 305, sending the temporary trust token to the first application client, so that the first application client sends a jump request to a target webpage provided by the second application server, wherein the jump request at least carries the temporary trust token.
In some embodiments, the login request includes device address information of the first application client, and the obtaining of the user identity information corresponding to the first application client according to the login request further includes: performing local query according to the equipment address information of the first application client to obtain user identity information corresponding to the first application client; the first application client is pre-registered in the first application server based on the user identity information.
Based on the same technical concept, an embodiment of the present invention further provides a secure cross-domain login method, which is applied to a second application server, and referring to fig. 4, the method includes steps 401 and 403:
step 401, receiving 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, generating a temporary trust token based on the request message, and sending the temporary trust token to the first application client through the first application server, so that the first application client sends a jump request to a target webpage provided by the second application server, wherein the jump request at least carries the temporary trust token;
and 403, verifying the temporary trust token carried by the skip request, and performing login trust on the first application client after the verification is passed.
In some embodiments, the request message includes one or more of: the identity of the first application server, the device address information corresponding to the first application client and the user identity information.
In some embodiments, the method further comprises: searching a pre-configured server white list according to the identity of the first application server to verify the identity of the server; and if the server identity verification fails, refusing to generate the temporary trust token and returning first error information to the first application server.
In some embodiments, the method further comprises: carrying out message verification on the request message according to a preset message specification; and if the message is not verified, refusing to generate the temporary trust token, and returning second error information to the first application server.
In some embodiments, the indicating, by the preset message specification, that the request message includes at least one message mandatory fill field, and performing message verification on the request message according to the preset message specification includes: and judging whether the necessary message filling field in the request message is not empty and/or is filled according to a preset format.
In some embodiments, the request message carries a first cryptographic signature generated from a first private key, the method further comprising: the method comprises the steps that a first public key provided by a first application server is obtained in advance, wherein the first public key and a first private key are a key pair generated by the first application server based on an encryption algorithm; performing signature verification on a first encrypted signature in the received request message according to the first public key; and if the signature verification fails, refusing to generate the temporary trust token, and returning third error information to the first application server.
In some embodiments, the request message further includes a sensitive identity information segment obtained by encrypting sensitive information of one or more items of user identity information, and the method further includes: the method comprises the steps of obtaining a sensitive information key provided by a first application server in advance, and carrying out sensitive decryption on a sensitive identity information segment in a request message according to the sensitive information key to obtain plaintext information of user identity information; and if the sensitive decryption is not successfully realized, refusing to generate the temporary trust token, and returning fourth error information to the first application server.
In some embodiments, generating the temporary trust token based on the request message further comprises: generating a globally unique temporary trust token according to the user identity information contained in the request message; caching the temporary trust token and the corresponding user identity information to a memory database in a key-value pair mode, and setting a preset valid period for the temporary trust token, wherein the key-value pair corresponding to the temporary trust token is deleted from the memory database after the preset valid period is reached.
In some embodiments, generating a globally unique temporary trust token based on user identity information further comprises: a temporary trust token is generated using the snowflow algorithm.
In some embodiments, after generating the temporary trust token based on the request packet, the method further comprises: and performing user registration or user binding according to the user identity information contained in the request message.
In some embodiments, after generating the temporary trust token based on the request packet, the method further comprises: generating a second secret key in advance based on an encryption algorithm, wherein the second secret key comprises a second public key and a second private key; and generating a response message according to the temporary trust token, signing the response message according to a second private key, and sending the signed response message to the first application server so that the first application server signs and decrypts the received response message based on a second public key provided by the second application server.
In some embodiments, verifying the temporary trust token carried by the skip request includes: if the skip request contains the temporary trust token and the memory database contains a value corresponding to the temporary trust token through verification, login credit authorization is carried out on the first application client; otherwise, the first application client is refused to log in and trust.
In some embodiments, verifying the temporary trust token carried by the skip request further includes: acquiring a source domain name contained in the skip request, and searching a preset domain name white list according to the source domain name so as to check the source domain name for the skip request; and if the source domain name is not verified, refusing to log in and trust the first application client.
In some embodiments, after the first application client is logged in and trusted, the method further comprises: extracting user identity information corresponding to the temporary trust token in the memory database; acquiring corresponding historical transaction information according to the user identity information; and providing corresponding right information for the first application client based on the preset right rule, the historical transaction information and the user identity information.
Based on the same technical concept, an embodiment of the present invention further provides a secure cross-domain login system, referring to fig. 5, where the system includes: the system comprises a first application server, a second application server and a user terminal;
the user terminal is provided with a first application client, the first application client is used for sending a login request for requesting to login a target webpage page provided by a second application server to the first application server, and is also used for sending a jump request to the target webpage page provided by the second application server after receiving a temporary trust token, and the jump request at least carries the temporary trust token; the first application server is for performing the method as illustrated in fig. 3; the second application server is used to perform the method as illustrated in fig. 4. The user terminal is also used for displaying the target webpage 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 performing the method shown in fig. 3, and further provides a second application server for performing the method shown in fig. 4.
It should be noted that, the method, the system, and the server in the embodiment of the present application may implement each process of the embodiment of the method shown in fig. 1, and achieve the same effect and function, which are not described herein again.
As will be appreciated by one skilled in the art, embodiments of the present invention may be provided as a method, system, or computer program product. Accordingly, the present invention may 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, and the like) 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 will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
In a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.
Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The 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 Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. Moreover, while the operations of the method of the invention are depicted in the drawings in a particular order, this does not require or imply that the operations must be performed in this particular order, or that all of the illustrated operations must be performed, to achieve desirable results. Additionally or alternatively, certain steps may be omitted, multiple steps combined into one step execution, and/or one step broken down into multiple step executions.
While the spirit and principles of the invention have been described with reference to several particular embodiments, it is to be understood that the invention is not limited to the disclosed embodiments, nor is the division of aspects, which is for convenience only as the features in such aspects may not be combined to benefit. The invention is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims.

Claims (34)

1. A secure cross-domain login method, the method comprising:
the method comprises the steps that a first application server receives a login request sent by a first application client, wherein the login request is used for requesting to login a target webpage provided by a second application server;
the first application server acquires 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 temporary trust token based on the request message and sends the temporary trust token to the first application client through the first application server;
the first application client sends a skip request to the target webpage provided by the second application server, wherein the skip request at least carries the temporary trust token;
and the second application server verifies the temporary trust token carried by the skip request and performs login credit authorization on the first application client after the verification is passed.
2. The method of claim 1, wherein the login request includes device address information of the first application client, and wherein the first application server obtains user identity information corresponding to the first application client according to the login request, further comprising:
the first application server performs 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 identity of the first application server, the equipment address information corresponding to the first application client and the user identity information.
4. The method of claim 3, wherein prior to the second application server generating a temporary trust token based on the request message, the method further comprises:
the second application server searches a pre-configured server white list according to the identity of the first application server so as to verify the identity of the server;
and if the server identity verification fails, the second application server refuses to generate the temporary trust token and returns first error report information to the first application server.
5. The method of claim 3, wherein prior to the second application server generating 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;
and if the message is not verified, the second application server refuses to generate the temporary trust token and returns second error report information to the first application server.
6. The method of claim 5, wherein the predetermined message specification indicates that the request message includes at least one message mandatory fill field, and wherein the second application server performs message verification on the request message according to the predetermined message specification, comprising:
and the second application server judges whether the necessary message filling domain in the request message is not empty and/or is filled according to a preset format.
7. The method of claim 1, further comprising:
the first application server generates a first key pair in advance based on an encryption algorithm, wherein the first key pair comprises 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 acquires 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;
and if the signature verification fails, the second application server refuses to generate the temporary trust token and returns third error information to the first application server.
8. The method of claim 3, wherein before the second application server generates a temporary trust token based on the request packet, the method further comprises:
the first application server encrypts sensitive information of one or more items of the user identity information to obtain a sensitive identity information segment, and the request message further comprises the sensitive identity information segment;
the second application server acquires a sensitive information key provided by the first application server in advance, and sensitively decrypts the sensitive identity information segment in the received request message according to the sensitive information key to acquire plaintext information of the user identity information;
and if the sensitive decryption is not successfully realized, the second application server refuses to generate the temporary trust token and returns fourth error information to the first application server.
9. The method of claim 3, wherein the second application server generates a temporary trust token based on the request packet, further comprising:
the second application server generates a globally unique temporary trust token according to the user identity information contained in the request message;
and the second application server caches the temporary trust token and the corresponding user identity information to an in-memory database in a key-value pair mode, and sets a preset validity period for the temporary trust token, wherein the key-value pair corresponding to the temporary trust token is deleted from the in-memory database after the preset validity period is reached.
10. The method of claim 1, wherein the second application server generates a globally unique temporary trust token based on the user identity information, further comprising:
the second application server generates the temporary trust token using a snowflow algorithm.
11. The method of claim 1, wherein after the second application server generates a temporary trust token based on the request packet, further comprising:
and the second application server performs user registration or user binding according to the user identity information contained in the request message.
12. The method of claim 1, further comprising:
the second application server generates a second secret key in advance based on an encryption algorithm, wherein the second secret key comprises 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 first application server;
and the first application server acquires the second public key provided by the second application server in advance, and signs and decrypts the received response message according to the second public key.
13. The method of claim 9, wherein the second application server verifying the temporary trust token carried by the skip request comprises:
if the second application server verifies that the skip request contains the temporary trust token and the memory database contains a value corresponding to the temporary trust token, logging in and authorizing the first application client;
otherwise, the second application server refuses to log in and authorize the first application client.
14. The method of claim 1, wherein the second application server verifies the temporary trust token carried by the skip request, further comprising:
the second application server obtains a source domain name contained in the skip request, and searches a preset domain name white list according to the source domain name so as to check the source domain name for the skip request;
and if the source domain name is not verified, the second application server refuses to log in and authorize the credit to the first application client.
15. The method of claim 13, wherein after the first application client is trusted to log in, the method further comprises:
the second application server extracts user identity information corresponding to the temporary trust token from the memory database;
the second application server acquires corresponding historical transaction information according to the user identity information; and the number of the first and second groups,
and the second application server provides corresponding right information for the first application client based on a preset right rule, the historical transaction information and the user identity information.
16. A secure cross-domain login method is applied to a first application server, and comprises the following steps:
receiving a login request sent by a first application client, wherein the login request is used for requesting to login a target webpage provided by a second application server;
acquiring 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 a temporary trust token sent by the second application server, wherein the temporary trust token is generated based on the request message;
and 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, wherein the jump request at least carries the temporary trust token.
17. The method of claim 16, wherein the login request includes device address information of the first application client, and wherein obtaining user identity information corresponding to the first application client according to the login request further comprises:
and performing local query according to the equipment address information of the first application client to obtain user identity information corresponding to the first application client.
18. A secure cross-domain login method is applied to a second application server, and comprises the following steps:
receiving a request message sent by a first application server, wherein the request message comprises user identity information corresponding to a first application client which is in communication connection with the first application server;
generating a temporary trust token based on the request message, and sending the temporary trust token to the first application client through the first application server so that the first application client sends a jump request to the target webpage provided by the second application server, wherein the jump request at least carries the temporary trust token;
and verifying the temporary trust token carried by the skip request, and performing login trust on the first application client after the verification is passed.
19. The method of claim 18, wherein the request message comprises one or more of: the identity of the first application server, the equipment address information corresponding to the first application client and the user identity information.
20. The method of claim 19, further comprising:
searching a pre-configured server white list according to the identity of the first application server so as to verify the identity of the server;
and if the server identity verification fails, refusing to generate the temporary trust token and returning first error information to the first application server.
21. The method of claim 19, further comprising:
performing message verification on the request message according to the preset message specification;
and if the message is not verified, refusing to generate the temporary trust token and returning second error information to the first application server.
22. The method according to claim 21, wherein the predetermined message specification indicates that the request message includes at least one message required fill field, and,
performing message verification on the request message according to a preset message specification, wherein the message verification comprises the following steps:
and judging whether the necessary message filling field in the request message is not empty and/or is filled according to a preset format.
23. The method of claim 18, wherein the request message carries a first cryptographic signature generated from a first private key, the method further comprising:
the first public key provided by the first application server is obtained in advance, 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;
and if the signature verification fails, refusing to generate the temporary trust token, and returning third error information to the first application server.
24. The method according to claim 18, wherein the request message further includes a sensitive identity information segment obtained by encrypting sensitive information of one or more items of the user identity information, and the method further comprises:
a sensitive information key provided by the first application server is obtained in advance, and the sensitive identity information segment in the request message is sensitively decrypted according to the sensitive information key so as to obtain plaintext information of the user identity information;
and if the sensitive decryption is not successfully realized, refusing to generate the temporary trust token, and returning fourth error information to the first application server.
25. The method of claim 18, wherein generating a temporary trust token based on the request message further comprises:
generating a globally unique temporary trust token according to the user identity information contained in the request message;
caching the temporary trust token and the corresponding user identity information to a memory database in a key-value pair mode, and setting a preset valid period for the temporary trust token, wherein the key-value pair corresponding to the temporary trust token is deleted from the memory database after the preset valid period is reached.
26. The method of claim 25, wherein generating a globally unique temporary trust token based on the user identity information further comprises:
and generating the temporary trust token by utilizing a SnowFlake algorithm.
27. The method of claim 18, wherein after generating a temporary trust token based on the request message, the method further comprises:
and performing user registration or user binding according to the user identity information contained in the request message.
28. The method of claim 18, wherein after generating a temporary trust token based on the request message, the method further comprises:
generating a second secret key in advance based on an encryption algorithm, wherein the second secret key comprises a second public key and a second private key;
and 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 so that the first application server signs and decrypts the received response message based on the second public key provided by the second application server.
29. The method of claim 25, wherein verifying the temporary trust token carried by the skip request comprises:
if the skip request is verified to contain the temporary trust token and the memory database contains a value corresponding to the temporary trust token, performing login credit authorization on the first application client;
and if not, refusing to log in and authorize the first application client.
30. The method of claim 18, wherein verifying the temporary trust token carried by the skip request further comprises:
acquiring a source domain name contained in the skip request, and searching a preset domain name white list according to the source domain name so as to verify the source domain name of the skip request;
and if the source domain name is not verified, refusing to log in and authorize the first application client.
31. The method of claim 25, wherein after the first application client is trusted to log in, the method further comprises:
extracting the user identity information corresponding to the temporary trust token in the memory database;
acquiring corresponding historical transaction information according to the user identity information; and the number of the first and second groups,
and providing corresponding right information for the first application client based on a preset right rule, the historical transaction information and the user identity information.
32. A secure cross-domain login system, comprising: the system comprises a user terminal, a first application server and a second application server; wherein the content of the first and second substances,
the user terminal is provided with a first application client, the first application client is used for sending a login request for requesting to login a target webpage page provided by a second application server to the first application server, and is also used for sending a jump request to the target webpage page provided by the second application server after receiving a temporary trust token, and the jump request at least carries the temporary trust token;
the first application server is configured to perform the method of any of claims 16-17;
the second application server is configured to perform the method of any of claims 18-31;
the user terminal is also used for displaying the target webpage provided by the second application server.
33. A first application server, arranged to perform the method of any of claims 16-17.
34. A second application server, characterized in that it is adapted to perform the method according to any of claims 18-31.
CN202011284833.7A 2020-11-17 2020-11-17 Secure cross-domain login method, system and server Active CN112333198B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202011284833.7A CN112333198B (en) 2020-11-17 2020-11-17 Secure cross-domain login method, system and server

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202011284833.7A CN112333198B (en) 2020-11-17 2020-11-17 Secure cross-domain login method, system and server

Publications (2)

Publication Number Publication Date
CN112333198A true CN112333198A (en) 2021-02-05
CN112333198B CN112333198B (en) 2023-09-05

Family

ID=74320810

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202011284833.7A Active CN112333198B (en) 2020-11-17 2020-11-17 Secure cross-domain login method, system and server

Country Status (1)

Country Link
CN (1) CN112333198B (en)

Cited By (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112953965A (en) * 2021-03-18 2021-06-11 杭州网易云音乐科技有限公司 Client login method and system, client, medium and computing device
CN113065160A (en) * 2021-04-12 2021-07-02 浙江环玛信息科技有限公司 Intelligent court data transmission method and system
CN113079175A (en) * 2021-04-14 2021-07-06 上海浦东发展银行股份有限公司 Authorization system and method based on oauth2 protocol enhancement
CN113179254A (en) * 2021-04-01 2021-07-27 杭州数跑科技有限公司 System login method and device, electronic equipment and storage medium
CN113190724A (en) * 2021-05-31 2021-07-30 中国银行股份有限公司 User bank information query method, mobile terminal and server
CN113347190A (en) * 2021-06-10 2021-09-03 北京字节跳动网络技术有限公司 Authentication method, system, slave station server, client, device and medium
CN113569229A (en) * 2021-09-18 2021-10-29 北京金堤科技有限公司 Synchronous login method and device, storage medium and electronic equipment
CN113965352A (en) * 2021-09-18 2022-01-21 网宿科技股份有限公司 Third-party website login method and device, electronic equipment and storage medium
CN114124430A (en) * 2021-08-31 2022-03-01 青岛海尔智能技术研发有限公司 Token replacement method, device and storage medium
CN114285815A (en) * 2021-12-21 2022-04-05 中国农业银行股份有限公司 Application skipping method and application skipping device
CN114363088A (en) * 2022-02-18 2022-04-15 京东科技信息技术有限公司 Method and device for requesting data
CN114553480A (en) * 2022-01-13 2022-05-27 中国科学院信息工程研究所 Cross-domain single sign-on method and device
CN115102724A (en) * 2022-06-06 2022-09-23 珠海格力电器股份有限公司 Login method and system of double Token cross-end skip system
CN116962092A (en) * 2023-09-21 2023-10-27 畅捷通信息技术股份有限公司 Ecological integrated login method, system, electronic equipment and storage medium

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002039237A2 (en) * 2000-11-09 2002-05-16 International Business Machines Corporation Method and system for web-based cross-domain single-sign-on authentication
CN102098158A (en) * 2009-12-10 2011-06-15 北大方正集团有限公司 Cross-domain name single sign on and off method and system as well as corresponding equipment
CN104378376A (en) * 2014-11-18 2015-02-25 深圳中兴网信科技有限公司 SOA-based single-point login method, authentication server and browser
CN105472052A (en) * 2014-09-03 2016-04-06 阿里巴巴集团控股有限公司 Login method and system of cross-domain server
CN107026847A (en) * 2017-02-09 2017-08-08 阿里巴巴集团控股有限公司 One kind trusts login method, server and system
CN110781482A (en) * 2019-10-12 2020-02-11 广州酷旅旅行社有限公司 Login method, login device, computer equipment and storage medium
CN111241555A (en) * 2019-12-30 2020-06-05 北京顺达同行科技有限公司 Access method and device for simulating user login, computer equipment and storage medium

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002039237A2 (en) * 2000-11-09 2002-05-16 International Business Machines Corporation Method and system for web-based cross-domain single-sign-on authentication
CN102098158A (en) * 2009-12-10 2011-06-15 北大方正集团有限公司 Cross-domain name single sign on and off method and system as well as corresponding equipment
CN105472052A (en) * 2014-09-03 2016-04-06 阿里巴巴集团控股有限公司 Login method and system of cross-domain server
CN104378376A (en) * 2014-11-18 2015-02-25 深圳中兴网信科技有限公司 SOA-based single-point login method, authentication server and browser
CN107026847A (en) * 2017-02-09 2017-08-08 阿里巴巴集团控股有限公司 One kind trusts login method, server and system
CN110781482A (en) * 2019-10-12 2020-02-11 广州酷旅旅行社有限公司 Login method, login device, computer equipment and storage medium
CN111241555A (en) * 2019-12-30 2020-06-05 北京顺达同行科技有限公司 Access method and device for simulating user login, computer equipment and storage medium

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
JUN WU等: "A Fine-Grained Cross-Domain Access Control Mechanism for Social Internet of Things", IEEE *
徐辉;: "基于.NET Web服务的跨域单点登录系统的实现", 电脑知识与技术, no. 20 *

Cited By (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112953965A (en) * 2021-03-18 2021-06-11 杭州网易云音乐科技有限公司 Client login method and system, client, medium and computing device
CN113179254A (en) * 2021-04-01 2021-07-27 杭州数跑科技有限公司 System login method and device, electronic equipment and storage medium
CN113065160A (en) * 2021-04-12 2021-07-02 浙江环玛信息科技有限公司 Intelligent court data transmission method and system
CN113079175A (en) * 2021-04-14 2021-07-06 上海浦东发展银行股份有限公司 Authorization system and method based on oauth2 protocol enhancement
CN113190724A (en) * 2021-05-31 2021-07-30 中国银行股份有限公司 User bank information query method, mobile terminal and server
CN113190724B (en) * 2021-05-31 2024-02-27 中国银行股份有限公司 User bank information query method, mobile terminal and server
CN113347190A (en) * 2021-06-10 2021-09-03 北京字节跳动网络技术有限公司 Authentication method, system, slave station server, client, device and medium
CN114124430B (en) * 2021-08-31 2024-03-01 青岛海尔科技有限公司 Token replacement method, device and storage medium
CN114124430A (en) * 2021-08-31 2022-03-01 青岛海尔智能技术研发有限公司 Token replacement method, device and storage medium
CN113569229A (en) * 2021-09-18 2021-10-29 北京金堤科技有限公司 Synchronous login method and device, storage medium and electronic equipment
CN113965352A (en) * 2021-09-18 2022-01-21 网宿科技股份有限公司 Third-party website login method and device, electronic equipment and storage medium
CN113965352B (en) * 2021-09-18 2023-12-01 网宿科技股份有限公司 Third-party website login method and device, electronic equipment and storage medium
CN114285815A (en) * 2021-12-21 2022-04-05 中国农业银行股份有限公司 Application skipping method and application skipping device
CN114285815B (en) * 2021-12-21 2024-05-14 中国农业银行股份有限公司 Application jump method and application jump device
CN114553480A (en) * 2022-01-13 2022-05-27 中国科学院信息工程研究所 Cross-domain single sign-on method and device
CN114363088A (en) * 2022-02-18 2022-04-15 京东科技信息技术有限公司 Method and device for requesting data
CN114363088B (en) * 2022-02-18 2024-04-16 京东科技信息技术有限公司 Method and device for requesting data
CN115102724B (en) * 2022-06-06 2023-12-08 珠海格力电器股份有限公司 Login method and system of double Token cross-end jump system
CN115102724A (en) * 2022-06-06 2022-09-23 珠海格力电器股份有限公司 Login method and system of double Token cross-end skip system
CN116962092B (en) * 2023-09-21 2023-12-26 畅捷通信息技术股份有限公司 Ecological integrated login method, system, electronic equipment and storage medium
CN116962092A (en) * 2023-09-21 2023-10-27 畅捷通信息技术股份有限公司 Ecological integrated login method, system, electronic equipment and storage medium

Also Published As

Publication number Publication date
CN112333198B (en) 2023-09-05

Similar Documents

Publication Publication Date Title
CN112333198B (en) Secure cross-domain login method, system and server
US11757641B2 (en) Decentralized data authentication
CN110086768B (en) Service processing method and device
CN111353903B (en) Network identity protection method and device, electronic equipment and storage medium
CN103380592B (en) Method, server and system for personal authentication
CN110246039B (en) Transaction monitoring method and device based on alliance chain and electronic equipment
US20180077147A1 (en) Attributed network enabled by search and retreival of privity data from a registry and packaging of the privity data into a digital registration certificate for attributing the data of the attributed network
CN113486122A (en) Data sharing method and electronic equipment
CN109740319B (en) Digital identity verification method and server
CN115276978A (en) Data processing method and related device
CN112100689B (en) Trusted data processing method, device and equipment
KR102211033B1 (en) Agency service system for accredited certification procedures
Jordan et al. Viceroy: Gdpr-/ccpa-compliant enforcement of verifiable accountless consumer requests
CN117375986A (en) Application access method, device and server
CN113239853A (en) Biological identification method, device and equipment based on privacy protection
CN106888200B (en) Identification association method, information sending method and device
CN116049802B (en) Application single sign-on method, system, computer equipment and storage medium
US20230308277A1 (en) Anonymous authentication with token redemption
CN115811412A (en) Communication method and device, SIM card, electronic equipment and terminal equipment
CN106533685B (en) Identity authentication method, device and system
US20220311617A1 (en) Cryptographic signing of a data item
CN106411826A (en) Data access method and equipment thereof
CN114826616B (en) Data processing method, device, electronic equipment and medium
CN114553570B (en) Method, device, electronic equipment and storage medium for generating token
US11849041B2 (en) Secure exchange of session tokens for claims-based tokens in an extensible system

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant