Identity authentication method, device and related equipment

Abstract

The embodiment of the present application provides an identity authentication method, apparatus and related equipment, wherein the method includes: the service provider's server receives a message that the user's user identity has been authenticated by the identity provider's server, and the message includes the user's bound verification method information; the service provider's server sends a verification request to the user terminal according to the verification method information; the service provider's server receives the verification code sent by the user terminal and verifies the verification code; when the service provider's server verifies the verification code, the service provider's server generates an access credential corresponding to the user and sends the access credential to the user terminal, and the access credential indicates that the user has the right to access the service provider's server. By implementing the above method, in the process of realizing federated identity authentication, the user's identity is confirmed through multi-factor authentication to prevent the risk of user data security caused by the leakage of identity credentials of a single system.

Description

[0001] This application is a divisional application. The application number of the original application is 201911417640.1, and the original application date is December 31, 2019. The entire content of the original application is incorporated into this application by reference. Technical Field

[0002] The present application relates to the field of computer technology, and in particular to an identity authentication method, apparatus, and related equipment. Background Art

[0003] With the development of network technology, users often need to use services provided by different service providers (SPs). However, each SP generally has its own independent identity authentication system. When users need to use services provided by different SPs, they need to pass the verification of the identity authentication system of each SP before they can use the service.

[0004] Currently, it's possible to federate the authentication systems of different service providers (SPs). Using single sign-on (SSO) technology, users can authenticate in a single authentication system and use the services provided by the SPs across the federated authentication systems. However, when multiple authentication systems are federated, only a single authentication credential is required for authentication. If this single credential is leaked, an attacker could use the credentials from a single system to access the services of multiple SPs, seriously threatening user information security. Summary of the Invention

[0005] The embodiments of the present application disclose an identity authentication method, apparatus, and related equipment. During the process of federal identity authentication, the user's identity is confirmed through multi-factor authentication, preventing the risk of user data security caused by the leakage of identity credentials of a single system, and improving the security of federal identity authentication.

[0006] In a first aspect, an embodiment of the present application provides a federated identity authentication method, comprising:

[0007] The service provider's server receives a message that the user's identity has been authenticated by the identity provider's server, the message including verification method information bound to the user;

[0008] The service provider's server sends a verification request to the user terminal according to the verification method information;

[0009] The server of the service provider receives the verification code sent by the user terminal and verifies the verification code;

[0010] When the service provider's server successfully verifies the verification code, the service provider's server generates access credentials corresponding to the user and sends the access credentials to the user terminal. The access credentials indicate that the user has the authority to access the service provider's server.

[0011] By implementing the above method, during federated identity authentication, after the identity provider's server successfully authenticates the user's identity for the first time, the service provider's server needs to authenticate the user's identity a second time. Only after the user passes the second authentication on the service provider's server will the service provider's server allow the user to access the service provider's resources. Authenticating user identities through multi-factor authentication prevents the use of identity credentials from a single system during federated identity authentication, which could pose risks to user data security if the identity credentials of a single system are leaked, thereby improving the security of federated identity authentication.

[0012] In a specific embodiment, the server of the service provider sends a verification request to the user terminal according to the verification method information, including:

[0013] The server of the service provider determines, based on the verification method information, a method for the user to receive the verification code, wherein the method for the user to receive the verification code includes receiving the verification code via email or receiving the verification code via a short message;

[0014] The server of the service provider sends a verification request to the user terminal, generates the verification code, and sends the verification code to the electronic device used by the user through the determined method for the user to receive the verification code.

[0015] In a specific embodiment, the verification code is generated by a multi-factor authentication device used by the user, and the message includes the multi-factor authentication key of the user;

[0016] The server of the service provider receives the verification code sent by the user terminal and verifies the verification code, including:

[0017] The server of the service provider receives a first verification code generated by a multi-factor authentication device and sent by the user terminal;

[0018] The service provider's device generates a second verification code according to the multi-factor authentication key, and verifies the first verification code according to the second verification code.

[0019] In a specific embodiment, before the service provider's server receives a message indicating that the user's user identity has been authenticated by the identity provider's server, the method further includes:

[0020] The server of the service provider receives a first access request sent by the user terminal, where the first access request includes an identifier of the identity provider;

[0021] The server of the service provider generates an authentication request according to the first access request, where the authentication request includes an identifier of the service provider;

[0022] The service provider's server determines the address of the identity provider's server based on the identity provider's identifier, and sends the authentication request to the identity provider's server. The authentication request instructs the identity provider's server to authenticate the user's identity and sends the message to the user terminal based on the authentication result.

[0023] In a specific embodiment, the method further includes: the server of the service provider receiving a second access request sent by the user terminal, the second access request including the access credential;

[0024] When the service provider's server determines that the access credential is a legitimate access credential issued by it, the service provider's server sends the data accessed by the second access request to the user terminal, wherein the service provider may be a cloud service provider.

[0025] In a second aspect, an embodiment of the present application provides an identity authentication device, comprising:

[0026] A receiving unit, configured to receive a message indicating that the user identity of the user has been authenticated by a server of an identity provider, the message including verification method information bound to the user;

[0027] a sending unit, configured to send a verification request to a user terminal according to the verification mode information;

[0028] The receiving unit is further configured to receive a verification code sent by the user terminal;

[0029] a processing unit configured to verify the verification code; and if the verification code passes verification, generate an access credential corresponding to the user, the access credential indicating that the user has permission to access the service provider's server;

[0030] The sending unit is further configured to send the access credential to the user terminal.

[0031] In a specific embodiment, the processing unit is further configured to determine, based on the verification method information, a method in which the user receives the verification code, and generate the verification code, wherein the method in which the user receives the verification code includes receiving the verification code via an email or receiving the verification code via a short message;

[0032] The sending unit is specifically configured to send a verification request to the user terminal, and send the verification code to the electronic device used by the user through a determined method for the user to receive the verification code.

[0033] In a specific embodiment, the verification code is generated by a multi-factor authentication device used by the user, and the message includes the multi-factor authentication key of the user;

[0034] The receiving unit is further configured to receive a first verification code generated by a multi-factor authentication device and sent by the user terminal;

[0035] The processing unit is specifically configured to generate a second verification code according to the multi-factor authentication key, and verify the first verification code according to the second verification code.

[0036] In a specific embodiment, the receiving unit is further configured to receive an access request sent by the user terminal, wherein the access request includes an identifier of the identity provider;

[0037] The processing unit is further configured to generate an authentication request according to the access request, wherein the authentication request includes an identifier of the service provider;

[0038] Determining an address of a server of the identity provider according to the identifier of the identity provider;

[0039] The sending unit is further configured to send the authentication request to the server of the identity provider, where the authentication request instructs the server of the identity provider to authenticate the user identity of the user and send the message to the user terminal according to the authentication result.

[0040] In a third aspect, an embodiment of the present application provides a server comprising a processor and a memory, wherein the memory is used to store instructions, and the processor is used to execute the instructions. When the processor executes the instructions, the server executes the method described in the first aspect or any specific embodiment of the first aspect.

[0041] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program. When the computer program is executed by a processor, the processor executes the method described in the first aspect or any specific embodiment of the first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] Figure 1 is a schematic diagram of a federated identity authentication system provided in an embodiment of the present application;

[0043] Figure 2This is an interactive diagram of a federated identity authentication provided in an embodiment of the present application;

[0044] Figure 3 This is a schematic diagram of a multi-factor authentication page provided in an embodiment of the present application;

[0045] Figure 4 This is an interactive diagram of another federated identity authentication system provided by an embodiment of the present application;

[0046] Figure 5 This is a structural diagram of an identity authentication device provided in an embodiment of the present application;

[0047] Figure 6 This is a structural diagram of a server provided in an embodiment of the present application. DETAILED DESCRIPTION

[0048] In order to help those skilled in the art better understand the technical solution of the present application, some concepts involved in the embodiments of the present application are first introduced.

[0049] Multi-factor authentication (MFA) is a computer access control method that requires users to pass two or more authentication methods before they can be authorized to use computer resources.

[0050] A time-based one-time password (TOTP) algorithm is an algorithm that calculates a one-time password based on a secret key and the current time. The TOTP algorithm uses a cryptographic hash function to combine a secret key and the current timestamp to generate a one-time password. The TOTP algorithm is often used in MFA systems. When a user logs into a system, they obtain a verification code to be confirmed generated by a virtual MFA device or a physical MFA device using the TOTP algorithm. The user terminal sends the verification code to the system server that needs to log in. After the system server receives the verification code to be confirmed sent by the user terminal, it generates a verification code based on the user's corresponding secret key and the current time. If the system server determines that the verification code to be confirmed is the same as the verification code generated by the server itself, it confirms that the user is a legitimate user.

[0051] An identity provider (IDP) is a service provider responsible for collecting and storing user identity information and providing an identity management system for enterprises. The IDP's servers store the identity information of enterprise system users, including usernames, passwords, email addresses, and mobile phone numbers. When an enterprise user logs in, the IDP's servers authenticate the user. The identity management system provided by the IDP serves as the enterprise's own identity management system.

[0052] A service provider (SP) is a provider of various services, such as a cloud service provider. To use an SP's services, a user must register with the SP. After successful registration, the SP's servers store the user's identity information. When a user logs in to the SP's system, the SP's authentication system verifies the user's identity.

[0053] When users need to access services provided by different systems, they must authenticate through different identity authentication systems when logging into each system. For example, if a user needs to access an enterprise system, they must log into the enterprise system, and the IDP's identity management system will authenticate the user's identity during login. When they need to access the SP's services, they must log into the SP's system, and the SP's identity authentication system will also authenticate the user's identity during login. This method of logging into a single system with identity credentials to access a single system's services requires users to keep track of their account numbers, passwords, and other credentials for different application systems, leading to low work efficiency.

[0054] For example, an enterprise is a user of a cloud service provider. The enterprise has applied for cloud service resources from the cloud service provider, and the enterprise has a corresponding enterprise account and password for the cloud service. If users of the enterprise system need to use the cloud service resources applied for by the enterprise, the administrator of the enterprise account can create user groups and sub-accounts for users of the enterprise system under the enterprise account, and assign user groups to each sub-account, where each user group has different permissions, and each sub-account can join one or more user groups. When using the enterprise system, users of the enterprise system need to log in to the enterprise system using the account and password registered in the enterprise system, and need to authenticate their identity through the IDP's identity management system when logging in. When users of the enterprise system need to use the enterprise's cloud service resources, they need to log in to the cloud service system using the enterprise account and the sub-account assigned to the user by the enterprise, and need to authenticate through the cloud service system's identity authentication system when logging in.

[0055] Federated identity authentication refers to the process of establishing a trust relationship between an IDP and a service provider (SP), completing the interaction process, and achieving single sign-on (SSO). SSO means that after logging in to the IDP's identity management system, users of an enterprise system can access the SP system with which they have established a trusted relationship through a redirect link. For example, after an enterprise's IDP establishes a trust relationship with a cloud service provider, users of the enterprise system can log in to the IDP's identity management system through the login portal provided by the cloud service provider using their enterprise system account and password. This allows them to access the cloud service provider's system and use the cloud service resources the enterprise has applied for from the cloud service provider.

[0056] When establishing a trust relationship between the above-mentioned IDP and SP, it is necessary for the IDP and SP to exchange metadata. The IDP's metadata includes the IDP's IDP identifier, the address of the IDP's server, the IDP's public key, and the protocols supported by the IDP, etc. The SP's metadata includes the SP's SP identifier, the address of the SP's server, the SP's public key, and the protocols supported by the SP, etc. In the embodiment of the present application, the protocol supported by the IDP and the protocol supported by the SP are described as the Security Assertion Markup Language (SAML) protocol.

[0057] SAML is an open-source standard data format based on Extensible Markup Language (XML). It is primarily used for exchanging data between IDPs and Service Providers (SPs) to address identity authentication issues during federated identity authentication. For example, when a user needs to use a cloud service but logs in through the IDP's identity management system, the IDP, after verifying the user's enterprise system account and password, generates a SAML-formatted assertion containing the user's information and sends it to the cloud system's server. The cloud system's server then converts the users, user groups, and access rights in the enterprise system into users, user groups, and access rights in the cloud system based on pre-configured identity conversion rules.

[0058] Federated identity authentication can achieve single sign-on for two or more systems, making it easier for users to use multiple systems and improving work efficiency. However, during the above-mentioned federated identity authentication process, users only need to use the identity credentials of a single system. After being verified by the IDP's identity management system, they can log in to the systems of two or more service providers. If the identity credentials of a single system are leaked, it will pose a risk to user data security.

[0059] The embodiment of the present application provides a federated identity authentication method, which introduces a multi-factor identity authentication mechanism in the federated identity authentication process to improve the security of user data. Figure 1 As shown, Figure 1 This is a system diagram provided by an embodiment of the present application. Figure 1 The system includes a user terminal, an IDP server, and multiple SP servers. These SPs have established a trust relationship with the IDP, enabling single sign-on (SSO) through federated identity authentication. When a user needs to log in to any SP system, they can access the SP's resources by logging in to the IDP. In this embodiment of the application, the user can initiate federated identity authentication from either the IDP or the SP. The following describes how to initiate federated identity authentication from the SP. Figure 2This is an interactive diagram of a federated identity authentication provided by an embodiment of the present application, such as Figure 2 As shown in the figure, the federated identity authentication process initiated from the SP side is as follows:

[0060] S201: A user terminal sends an access request to a server of an SP.

[0061] When a user needs to access the resources of an SP, the user enters the login link of the SP in the browser of the user terminal. After receiving the login link entered by the user, the user terminal initiates an access request to the SP's server through the browser, wherein the access request includes the IDP identifier of the IDP.

[0062] S202: After receiving the access request, the SP server generates an authentication request and determines the address of the IDP server according to the IDP identifier.

[0063] After receiving the access request, the SP's server determines the need for federated identity authentication based on the IDP identifier in the request. Since the SP's server stores the IDP's metadata file, the SP's server determines the address of the IDP server corresponding to the IDP identifier based on the IDP identifier and the metadata file. The SP's server also generates a SAML-formatted authentication request, which includes the SP's identifier and instructs the IDP server to authenticate the user.

[0064] S203: The SP's server sends the address of the IDP's server and an authentication request to the user terminal.

[0065] After generating the authentication request and determining the address of the IDP server, the SP server sends the address of the IDP server and the authentication request to the user terminal, so that the user terminal forwards the authentication request to the IDP server according to the address of the IDP server.

[0066] S204: The user terminal receives the authentication request and the address of the IDP server, and sends the authentication request to the IDP server according to the address of the IDP server.

[0067] S205: The IDP server receives the authentication request and sends a first verification request to the user terminal according to the authentication request.

[0068] After receiving the authentication request sent by the user terminal, the IDP server sends a first authentication request to the user terminal. The first authentication request includes an IDP login page, which is used to instruct the user to enter authentication credentials. The authentication credentials include a user name and a user password. The above-mentioned IDP login page includes a user name input box and a user password input box for the user to enter the user name and user password.

[0069] S206: The user terminal sends the authentication credentials to the IDP server.

[0070] The user terminal displays the above-mentioned IDP login interface on the browser page, receives the authentication credentials entered by the user, and sends the authentication credentials to the IDP server.

[0071] S207: The IDP server receives the authentication credentials sent by the user terminal, authenticates the authentication credentials, generates a response message based on the authentication credentials if the authentication credentials are successfully authenticated, and sends the response message to the user terminal.

[0072] After receiving the above authentication credentials, the IDP server matches the username and password in the authentication credentials with the username and password of the registered user stored by the IDP. If the username and password in the authentication credentials match in the IDP server, the IDP server determines that the authentication credentials have been verified and confirms that the user is a legitimate user.

[0073] After determining that the user is a legitimate user, the IDP server determines the user information of the user based on the username. The user information includes the user's username, the user group to which the user belongs, and the MFA verification method bound to the user. The above-mentioned MFA verification method indicates the method in which the user receives the verification code when using verification code verification. The IDP server generates a response message to the authentication request sent by the SP server based on the user's user information. The response message includes the IDP identifier and the user's username, the user group to which the username belongs, and the MFA verification method bound to the user. The MFA verification method includes authentication through email, authentication through mobile phone number, or authentication through a dynamic verification code generated by an MFA device. The user can bind one or more MFA authentication methods. If the user has bound multiple MFA verification methods, the above-mentioned response message includes the multiple MFA verification methods bound to the user. The MFA device can be a virtual MFA device or a hardware MFA device, and the embodiments of the present application do not impose specific restrictions.

[0074] The IDP server stores the metafile of the SP. After generating the authentication request, the IDP server determines the public key corresponding to the above-mentioned SP and the address of the SP's server based on the SP identifier in the authentication request. The IDP server can first use the IDP's private key to sign the response message, then encrypt the signed response message with the SP's public key, and finally send the signed and encrypted response message and the address of the SP's server to the user terminal. The IDP server can also first use the SP's public key to encrypt the response message, then use the IDP's private key to sign the encrypted response message, and then send the encrypted and signed response message and the address of the SP's server to the user terminal. In the embodiment of the present application, the example of signing the response message first and then encrypting it is used for explanation.

[0075] S208: The user terminal forwards the response message to the SP's server.

[0076] After receiving the address of the SP's server and the encrypted and signed response message sent by the IDP server, the user terminal forwards the encrypted response message to the SP's server according to the address of the SP's server.

[0077] S209 . The SP server receives the response message sent by the user terminal, generates a second verification request according to the response message, and sends the second verification request to the user terminal.

[0078] After receiving the signed and encrypted response message forwarded by the user terminal, the SP's server decrypts the encrypted response message using the SP's private key. If decryption is successful, the SP's server uses the IDP identifier in the response message to locate the IDP metafile corresponding to the IDP identifier in the SP's server metafile. It then finds the IDP's public key in the IDP metafile and verifies the signature of the response message using the IDP's public key. If the SP's server successfully decrypts the encrypted response message and the signature verification passes, the SP's server determines that the response message is the unmodified response message sent by the IDP server.

[0079] After confirming that the response message is unmodified, the SP's server sends a second verification request to the user terminal based on the MFA verification method corresponding to the user in the response message. This second verification request includes an MFA page, which instructs the user to perform multi-factor authentication. Specifically, the MFA page includes a verification method and a verification code input box. The verification method can be a user-configured verification method or selected through the verification method options on the MFA page. For example, if the user has only bound one MFA verification method, and the bound MFA verification method is verification by email or mobile phone number, the verification method on the MFA page cannot be selected. The SP's server needs to generate a verification code based on the user's bound MFA verification method and send the verification code to the user's bound email or mobile phone number.

[0080] If the user has bound multiple MFA verification methods, the user needs to select the MFA verification method to be used currently, such as Figure 3 As shown, Figure 3 This is a schematic diagram of an MFA page provided in an embodiment of the present application. The user has set three authentication methods: email verification, mobile phone number verification, and dynamic verification code authentication generated by an MFA device. The user needs to make a selection on the MFA page. After the user selects an MFA verification method, the user terminal sends the user's selection result to the SP's server to notify the SP's server to perform verification according to the MFA verification method indicated by the selection result. For example, if the user chooses email verification, the SP's server generates a verification code and sends the verification code to the user's email.

[0081] S210: The user terminal sends the verification code to the SP's server.

[0082] If the user's MFA authentication method is email or mobile, the verification code is generated by the SP's server and sent to the user's email or mobile number. If the user's MFA authentication method is dynamic verification code generated by an MFA device, the verification code is generated by the user's MFA device. The user's terminal receives the verification code entered by the user in the verification code input box on the MFA page and sends it to the SP's server.

[0083] S211 . The SP server verifies the verification code sent by the user terminal. If the verification is successful, it generates an access credential and sends the access credential to the user terminal.

[0084] After the SP's server receives the verification code sent by the user terminal, the SP's server verifies the verification code. For example, if the user chooses to verify via email, the SP's server determines that the verification code received from the user terminal is the same as the verification code generated by the SP's server and sent to the user's email, which means that the verification is successful. If the verification is successful, the SP's server determines the user's identity information in the SP system, such as the user name, user group, and access rights, based on the user name in the response message, the user group to which the user name belongs, and the identity conversion rules between the IDP user and the SP's user. Based on the user's identity information in the SP system, the server generates an access credential and sends the access credential to the user terminal. The user terminal needs to carry the access credential each time it accesses the SP's server. The user credential includes the user's username in the SP system.

[0085] It is understood that after receiving the access credentials, the user terminal will carry the access credentials each time it accesses the SP's server. After the service provider's server receives the access request sent by the user terminal carrying the access credentials, if the service provider's server determines that the access credentials are legitimate, the service provider's server will send the data accessed by the access request to the user terminal.

[0086] In one possible embodiment, if the MFA verification method bound to the user includes authentication using a dynamic verification code generated by an MFA device, the above-mentioned response message also includes an MFA key. The MFA key is used by the MFA device and the SP's server to generate a verification code based on the MFA key and the TOTP algorithm. When the user uses the verification code generated by the MFA device for authentication, the SP's server generates a verification code based on the MFA key after receiving the verification code sent by the user terminal. The SP's server then compares the verification code generated based on the MFA key with the verification code received from the user terminal. If they are the same, authentication succeeds; if they are different, authentication fails.

[0087] In a possible embodiment, in the above S207, if the authentication credentials sent by the user terminal to the IDP server fail to pass the verification of the IDP server, for example, the user name or user password entered by the user is incorrect, the IDP server generates a feedback message indicating that the user name or user password is incorrect and sends it to the user terminal, and no longer performs the operation of the IDP server after determining that the user is a legitimate user, that is, no response message is generated and the subsequent processes in S208 to S211 are no longer performed.

[0088] In one possible embodiment, in S209 above, if the SP's server cannot decrypt the encrypted response message using the SP's private key, indicating that the message received by the SP's server was not sent by the IDP's server with which the SP has established a trust relationship, the SP's server will not send the second verification request to the user terminal. Alternatively, if the SP's server successfully decrypts the encrypted response message using the SP's private key and verifies the signature of the response message using the IDP's public key, and the SP's server determines that the signature of the response message is incorrect, indicating that the response message has been modified, the SP's server will similarly not send the second verification request to the user terminal.

[0089] The following describes how to initiate federated identity authentication from the IDP side. Figure 4 This is an interactive diagram of a federated identity authentication provided by an embodiment of the present application, such as Figure 4 As shown in the figure, the federated identity authentication process initiated from the IDP side is as follows:

[0090] S401: The user terminal sends a login request to the IDP server.

[0091] When a user needs to access the resources of the target SP, the user can first log in to the IDP server. The user enters the login link of the IDP in the browser, and after receiving the login link entered by the user, the user terminal sends a login request to the IDP server.

[0092] S402: After receiving the login request, the IDP server sends a first verification request to the user terminal.

[0093] After receiving the login request from the user terminal, the IDP server sends a first authentication request to the user terminal. The first authentication request includes the IDP login page, which instructs the user to enter authentication credentials, including a username and password. The IDP login page includes a username input box and a password input box, which instruct the user to enter the username and password.

[0094] S403: The user terminal sends the authentication credentials to the IDP server.

[0095] The user terminal displays the above-mentioned IDP login interface on the browser page, receives the authentication credentials entered by the user, and sends the authentication credentials to the IDP server.

[0096] S404: The IDP server receives the authentication credentials sent by the user terminal, verifies the authentication credentials, and sends service information to the user terminal if the authentication credentials are verified successfully.

[0097] After receiving the above authentication credentials, the IDP server matches the username and password in the authentication credentials with the username and password of the registered user stored by the IDP. If the username and password in the authentication credentials match in the IDP server, the IDP server confirms that the user is a legitimate user.

[0098] After the IDP server confirms that the user is a legitimate user, it sends service information to the user terminal. The service information includes labels or access links of one or more SPs that have established a trust relationship with the IDP.

[0099] S405: After receiving the service information, the user terminal determines the target SP selected by the user and sends the target SP information to the IDP server.

[0100] After receiving the service information, the user terminal displays a page in the browser that includes labels or access links for one or more service providers (SPs). After the user selects a target SP, the user terminal sends the selected SP information to the IDP server. For example, if the browser page includes access links for n SPs, from SP1 to SPn, and the user wants to access SP1, the user clicks the access link for SP1.

[0101] S406: After receiving the target SP information, the IDP server generates a response message according to the authentication credentials, and sends the response message and the server address of the target SP to the user terminal.

[0102] After receiving the target SP information, the IDP server determines the address of the target SP's server based on the target SP information, and generates a response message based on the authentication credentials. The method for the IDP server to generate a response message and sign and encrypt it can refer to the method for generating a response message and signing and encrypting it in S207 above, which will not be repeated here.

[0103] After the IDP server sends the encrypted response message and the address of the target SP server to the user terminal, other processes of initiating federated identity authentication from the IDP side can refer to S208 to S211 above and will not be repeated here.

[0104] By implementing the above method, during federated identity authentication, after the identity provider's server successfully authenticates the user's identity for the first time, the service provider's server needs to authenticate the user's identity a second time. Only after the user passes the second authentication on the service provider's server will the service provider's server allow the user to access the service provider's resources. Authenticating user identities through multi-factor authentication prevents the use of identity credentials from a single system during federated identity authentication, which could pose risks to user data security if the identity credentials of a single system are leaked, thereby improving the security of federated identity authentication.

[0105] In a possible embodiment, in the above S402, the first verification request sent by the IDP to the user terminal also includes a label or access link of a server of one or more SPs that have established a trust relationship with the IDP. After receiving the first verification request, the user terminal displays the IDP login page and the label or access link of the server of the one or more SPs that have established a trust relationship with the IDP on the browser page. The user enters the authentication credentials on the browser page and selects the target SP to be accessed. Then, the user terminal sends the authentication credentials and the target SP information together to the IDP server. After confirming that the user is a legitimate user based on the authentication credentials, the IDP server performs the operation of the IDP server after receiving the target SP information in the above S406, which will not be repeated here.

[0106] In a possible embodiment, the user logs in to the SP's server through a browser using the two methods mentioned above. After obtaining the access credentials, the user terminal accesses the SP's server with the access credentials. After obtaining the access credentials, the SP's server will configure a federated identity credential for the user, and the federated identity credential includes the above-mentioned MFA key. When the user terminal uses the resources provided by the SP, all operation requests sent to the SP's server include the federated identity credential. If the user performs a sensitive operation, the SP's server will require verification of the pending verification code generated by the MFA device. After receiving the pending verification code sent by the user terminal, the SP's server generates an MFA verification code based on the MFA key in the federated identity credential, and matches it with the pending verification code sent by the user terminal to the SP's server. If they are the same, it means that the user can perform the sensitive operation. If they are different, the user's sensitive operation is rejected.

[0107] The aforementioned federated identity authentication initiated from the SP side and the federated identity authentication initiated from the IDP side are both implemented through the user terminal's browser. In one possible implementation, single sign-on access to the SP's server can also be achieved through the user terminal's client program. Specifically, after logging into the client program, the user sends a response message to the SP's server using the SP's server address set in the client program. The information included in this response message can be similar to the information included in the response message for federated identity authentication initiated from the SP side. This response message must include the MFA key, meaning that when the user uses the client program to access the SP's server, they must bind the authentication method to a dynamic verification code generated by an MFA device.

[0108] After the client program passes the authentication of the SP's server using the same method as described above, the SP's server issues a federated identity credential to the client program, which includes an MFA key. After the client program passes the authentication of the SP's server, when it accesses the application programming interface (API) of the SP's server for the first time, the client program includes the federated identity credential in the call request sent to the SP's server. At this time, the SP's server will require verification of the dynamic verification code generated by the MFA device. The SP's server generates an MFA verification code based on the MFA key in the federated identity credential, and matches it with the dynamic verification code generated by the MFA device sent by the client program to the SP's server. If they are the same, it indicates that the client program has permission to access the SP's server API. After determining that the client program has permission to call the API, the SP's server issues an access credential to the client, which includes an MFA authentication tag. The MFA authentication tag indicates that the client program has permission to access the SP's server API. The client program uses the access credential to access the SP's server API.

[0109] Combined with the above Figures 1 to 4 The identity authentication method provided by this application is described in detail. Figures 5 and 6 , describes the relevant devices and equipment for implementing the identity authentication provided by the embodiment of this application. Figure 5 , Figure 5 This is a structural diagram of an identity authentication device provided in an embodiment of the present application, which is deployed on the server of the above-mentioned SP. The identity authentication device 500 includes a receiving unit 510, a sending unit 520 and a processing unit 530.

[0110] The receiving unit 510 is configured to receive a message indicating that the user's identity has been authenticated by the identity provider's server, the message including the verification method information of the user binding. Specifically, the information included in the message can refer to the response message in S207 above, which will not be repeated here.

[0111] The sending unit 520 is configured to send a second verification request to the user terminal according to the verification method information, wherein the second verification request instructs the user terminal to return a verification code. The generation of the second verification request and the information included therein can be referred to the detailed description in S209 above and will not be repeated here.

[0112] The receiving unit 510 is further configured to receive a verification code sent by the user terminal. The verification code sent by the user terminal can be generated by the SP's server and sent to the user's email address or mobile phone number, or can be generated by the user's MFA device, which is not specifically limited in this embodiment of the application.

[0113] Processing unit 530 is configured to verify the verification code sent by the user terminal. If the verification code is successfully verified, it generates an access credential corresponding to the user and sends the access credential to the user terminal. The access credential indicates that the user has permission to access the service provider (SP) server. The verification code verification process by processing unit 530 can be described in detail in the same manner as the verification code verification process by the SP server in S211 above, and will not be further described here.

[0114] In a possible embodiment, the processing unit 530 is further configured to determine a method for the user to receive the verification code based on the verification method information and generate a verification code, wherein the method for the user to receive the verification code includes receiving the verification code via email or receiving the verification code via SMS.

[0115] The sending unit 520 is specifically configured to send a second verification request to the user terminal, and send the verification code to the electronic device used by the user through a determined user receiving verification code method.

[0116] In a possible embodiment, the above-mentioned verification code is generated by the MFA device used by the user, and the message includes the MFA key of the user; the receiving unit 510 is also used to: receive a first verification code generated by the MFA device sent by the user terminal; the processing unit 530 generates a second verification code based on the MFA key, verifies the first verification code based on the second verification code, and determines that the first verification code verification is successful if the first verification code and the second verification code are the same.

[0117] In one possible embodiment, the identity authentication device receives an access request from a user terminal at a message receiving unit 510 sent by an identity provider (IDP) server. The access request includes the IDP identifier of the IDP. A processing unit 530 generates an authentication request based on the access request, the authentication request includes the SP identifier, and determines the address of the IDP server based on the IDP identifier. A sending unit 520 sends the authentication request to the IDP server based on the IDP server address. The authentication request instructs the IDP server to authenticate the user's identity and sends a message to the user terminal based on the authentication result.

[0118] Specifically, the operations of the identity authentication device 500 to implement identity authentication may refer to the operations performed by the SP server in the above method embodiment, and will not be repeated here.

[0119] See also Figure 6 , Figure 6 6 is a schematic diagram of the structure of a server provided in an embodiment of the present application. The server 600 includes a processor 610, a communication interface 620 and a memory 630. Optionally, the processor 610, the communication interface 620 and the memory 630 are interconnected via a bus 640, wherein:

[0120] The processor 610 is used to implement the operations performed by the processing unit 530. The specific implementation of the various operations performed by the processor 610 can refer to the specific operations performed by the SP server in the above method embodiment. Figure 2 The operations of the SP server in S202, S209 and S211 are not described here in detail.

[0121] The processor 610 can have a variety of specific implementation forms. For example, the processor 610 can be a central processing unit (CPU) or a graphics processing unit (GPU). The processor 610 can also be a single-core processor or a multi-core processor. The processor 610 can be a combination of a CPU and a hardware chip. The above-mentioned hardware chip can be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The above-mentioned PLD can be a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof. The processor 610 can also be implemented solely using a logic device with built-in processing logic, such as an FPGA or a digital signal processor (DSP).

[0122] The communication interface 620 may be a wired interface or a wireless interface for communicating with other modules or devices. The wired interface may be an Ethernet interface, a local interconnect network (LIN), etc. The wireless interface may be a cellular network interface or a wireless local area network interface, etc.

[0123] In the embodiment of the present application, the communication interface 620 performs the operations implemented by the aforementioned receiving unit 510 and sending unit 520. For example, it may be used to perform the operations of receiving an access request sent by a user terminal in S201, receiving a response message generated by the IDP server and forwarded by the user terminal, and sending a second verification message to the user terminal in S209. Specifically, the operations performed by the communication interface 620 may refer to the operations received or sent by the SP server in the aforementioned method embodiment, and will not be further described here.

[0124] The memory 630 may be a non-volatile memory, such as a read-only memory (ROM), a programmable ROM (PROM), an erasable programmable ROM (EPROM), an electrically erasable programmable ROM (EEPROM), or a flash memory. The memory 630 may also be a volatile memory, such as a random access memory (RAM), which is used as an external cache.

[0125] The memory 630 can also be used to store instructions and data so that the processor 610 can call the instructions stored in the memory 630 to implement the operations performed by the processing unit 530, such as the operations performed by the server of the SP in the above method embodiment. In addition, the server 600 may include a Figure 6 Show more or fewer components, or configure components differently.

[0126] The bus 640 may be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus. The bus 640 may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 6 Only one thick line is used in the diagram, but this does not mean that there is only one bus or one type of bus.

[0127] Optionally, the server 600 may further include an input / output interface 650 , to which an input / output device is connected for receiving input information and outputting operation results.

[0128] Specifically, the specific implementation of the various operations performed by the coordination server 600 can refer to the specific operations performed by the SP server in the above method embodiment, which will not be repeated here.

[0129] An embodiment of the present application also provides a non-transitory computer-readable storage medium, which stores a computer program. When the computer program runs on a processor, it can implement the method steps performed by the SP server in the above method embodiment. The specific implementation of the processor of the computer storage medium in executing the above method steps can refer to the specific operations of the SP server in the above method embodiment, which will not be repeated here.

[0130] In the above embodiments, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0131] The above embodiments can be implemented in whole or in part through software, hardware, firmware, or any other combination. When implemented using software, the above embodiments can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded or executed on a computer, the processes or functions described in accordance with the embodiments of the present invention are generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server or data center that contains a collection of one or more available media. The available medium can be a magnetic medium (e.g., a floppy disk, hard disk, tape), an optical medium (e.g., a DVD), or a semiconductor medium. The semiconductor medium can be a solid state drive (SSD).

[0132] The steps in the method of the embodiment of the present application can be adjusted in order, combined or deleted according to actual needs; the modules in the device of the embodiment of the present application can be divided, combined or deleted according to actual needs.

[0133] The above is a detailed introduction to the embodiments of the present application. Specific examples are used herein to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method and core idea of ​​the present application. At the same time, for those skilled in the art, according to the idea of ​​the present application, there may be changes in the specific implementation methods and application scope. In summary, the content of this specification should not be understood as a limitation on the present application.

Claims

1. An identity authentication method, characterized in that: A user registers with a cloud service provider as a user of the cloud service provider, and the user applies for cloud service resources from the cloud service provider, the method comprising: When a user of the cloud service provider applies to the cloud service provider for access to the cloud service resources, the cloud service provider establishes a trust relationship with the identity provider; After the user of the cloud service provider passes the identity authentication of the identity provider, the cloud service provider authenticates the user; If the user passes the identity authentication at the identity provider, the cloud service provider provides the cloud service resources to the user; The cloud service provider authenticates the user, including: The cloud service provider generates a verification request based on a response message of the identity provider to the authentication request of the user of the cloud service provider, and sends the verification request to the user terminal of the user, so that the user authenticates his / her identity again based on the verification request. The response message is forwarded to the cloud service provider by the user terminal.

2. The method according to claim 1, characterized in that The cloud service provider authenticates the user, including: The cloud service provider sends a first verification code to the user terminal; The cloud service provider receives a second verification code provided by the user terminal; If the first verification code and the second verification code are the same, the identity verification is passed.

3. The method according to claim 1, characterized in that The cloud service provider authenticates the user, including: The cloud service provider completes identity verification through the user's email address or mobile phone number.

4. The method according to claim 1, wherein The cloud service provider authenticates the user, including: The cloud service provider completes the user's identity authentication through multi-factor authentication (MFA).

5. An identity authentication device, characterized in that: For a cloud service provider, a user is registered as a user of the cloud service provider at the cloud service provider, and the user has applied for cloud service resources at the cloud service provider; The identity authentication device comprises: a trust unit, configured to enable the cloud service provider to establish a trust relationship with the identity provider when a user of the cloud service provider applies to the cloud service provider for access to the cloud service resources; a processing unit, configured to authenticate the user of the cloud service provider after the user passes the identity authentication at the identity provider, and provide cloud service resources to the user if the user passes the identity authentication at the identity provider; In terms of authenticating the user, the processing unit is specifically configured to: A verification request is generated based on a response message of the identity provider to the authentication request of the user of the cloud service provider, and the verification request is sent to the user terminal of the user, so that the user authenticates his / her identity again based on the verification request. The response message is forwarded to the cloud service provider by the user terminal.

6. The device according to claim 5, characterized in that The processing unit is further configured to send a first verification code to the user terminal, receive a second verification code provided by the user terminal, and pass identity authentication if the first verification code and the second verification code are the same.

7. The device according to claim 5, characterized in that The processing unit is specifically used to complete identity authentication through the user's email address or mobile phone number.

8. The device according to claim 5, characterized in that The processing unit is further configured to complete the identity authentication of the user through multi-factor authentication (MFA).

9. A server, characterized in that: The server comprises a processor and a memory; when the processor executes the instructions stored in the memory, the server executes the method according to any one of claims 1 to 4.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, and the computer program is used to implement the method according to any one of claims 1 to 4.

Images