CN118337519A - Authentication method, authentication device, server, medium and product - Google Patents

Abstract

The application discloses an authentication method, an authentication device, a server, a medium and a product, and belongs to the technical field of information security. The method comprises the following steps: generating service token information and service verification information according to the application identifier of the service provider corresponding to the login request; wherein the service token information corresponds to the service verification information; sending the service verification information to a service provider, and returning service token information to a user terminal sending a login request; redirecting the login request to the service provider; the user terminal sends an authorization request to the service provider, the service provider analyzes the authorization request, access verification is carried out on the service token information by using the service verification information, and the service provider allows the user terminal to access under the condition that the access verification is passed, and the authorization request is obtained according to the service token information. The application improves the safety of authentication when the user accesses the resource.

Description

Authentication method, authentication device, server, medium and product

Technical Field

The present application relates to the field of information security technologies, and in particular, to an authentication method, a server, a system, a medium, and a product.

Background

In the related art, when a user logs in a service provider such as a website or an application, remote authentication can be performed through an authentication server. After passing the verification, the authentication server returns an access token, whereby the service provider allows the user access.

However, if the user uses the same user name and password and other identity credentials in multiple service providers, once one of the service providers or the remote authentication server reveals data, or the data in the process of data transmission of remote authentication is revealed, an attacker may attempt to construct an access token by attacking the acquired identity credentials of the user, or use the same access token to access other service providers, thereby causing security threat.

Disclosure of Invention

The application mainly aims to provide an authentication method, an authentication device, a server, a medium and a product, and aims to solve the technical problem that the information security of identity verification among a plurality of service providers in the related technology is mutually influenced.

In order to achieve the above object, the present application provides an authentication method, which is applicable to an authentication server, and the method includes:

Generating service token information and service verification information according to the application identifier of the service provider corresponding to the login request; wherein the service token information corresponds to the service verification information;

Sending the service verification information to a service provider, and returning service token information to a user terminal sending a login request;

Redirecting the login request to the service provider; the user terminal sends an authorization request to the service provider, the service provider analyzes the authorization request, access verification is carried out on the service token information by using the service verification information, and the service provider allows the user terminal to access under the condition that the access verification is passed, and the authorization request is obtained according to the service token information.

In a possible embodiment of the present application, generating service token information and service verification information according to the identity information of the user and the application identifier of the service provider corresponding to the login request includes:

And generating service token information and service verification information according to the application identifier of the service provider corresponding to the user identity information and the login request.

In a possible embodiment of the present application, generating service token information and service verification information according to an application identifier of a service provider corresponding to a login request includes:

generating an access salt value according to the application identifier of the service provider corresponding to the login request;

splicing the access salt value with the identity information, and then performing first hash calculation to obtain service verification information;

Taking the access salt value, a first splicing mode of the access salt value and the identity information and a first hash algorithm of first hash calculation as service token information;

The service token information carried in the authorization request is obtained by splicing the identity information and the access salt value by the user terminal according to a first splicing mode and then carrying out hash calculation by using a first hash algorithm.

In a possible embodiment of the present application, in case that the access authentication is passed, the service provider allows the user terminal to access, comprising:

In the case that the time difference between the first receiving time and the second receiving time is smaller than a preset value and the access authentication is passed, allowing the user terminal to access by the service provider; the first receiving time is the time when the service provider receives the service verification information, and the second receiving time is the time when the service provider receives the authorization request.

In a possible embodiment of the present application, generating service token information and service verification information according to an application identifier of a service provider corresponding to a login request includes:

And under the condition that the login request of the user terminal passes the platform identity authentication, executing the application identification of the service provider corresponding to the login request, and generating service token information and service verification information.

In a possible embodiment of the present application, in a case that a login request of a user terminal passes platform identity authentication, before generating service token information and service verification information according to an application identifier of a service provider corresponding to the login request, the method further includes:

under the condition that a user identifier and an access password input during user registration are received, generating a user salt value bound with a user;

Splicing the user salt value with the access password, and then performing second hash calculation to obtain platform verification information;

Transmitting the user salt value, a second splicing mode of the user salt value and the access password and a second hash algorithm of second hash calculation to the user terminal;

Under the condition that a platform verification request of a user terminal is received, verifying an identity credential carried by the platform verification request by utilizing platform verification information; the identity credential is obtained by splicing the user salt value and the access password according to a second splicing mode and carrying out hash calculation by using a second hash algorithm after receiving the user identification and the access password input by the user on the login interface by the user terminal; the login interface is triggered under the condition that a login request of the user terminal is redirected to the authentication server;

And under the condition that the authentication of the identity credentials is passed, determining that the login request of the user terminal passes the platform identity authentication.

In a second aspect, the present application also provides an authentication apparatus configured in an authentication server, the apparatus comprising:

the information generation module is used for generating service token information and service verification information according to the application identifier of the service provider corresponding to the login request; wherein the service token information corresponds to the service verification information;

The information sending module is used for sending the service verification information to the service provider and returning the service token information to the user terminal sending the login request;

A redirection module for redirecting the login request to the service provider; the user terminal sends an authorization request to the service provider, the service provider analyzes the authorization request, and performs access verification on the service token information by using the service verification information, and the service provider allows the user terminal to access when the access verification is passed, wherein the authorization request is obtained according to the service token information

In a third aspect, the present application also provides an authentication server comprising a processor, a memory and a computer program stored in the memory, which when executed by the processor implements the authentication method as in the first aspect.

In a fourth aspect, the present application also provides a computer readable storage medium having stored thereon a computer program which, when executed by a processor, implements the authentication method as in the first aspect.

In a fifth aspect, the application also provides a computer program product comprising a computer program which, when executed by a processor, implements the steps of the authentication method as in the first aspect.

The authentication method provided by the embodiment of the application is suitable for an authentication server, and comprises the following steps: generating service token information and service verification information according to the application identifier of the service provider corresponding to the login request; wherein the service token information corresponds to the service verification information; sending the service verification information to a service provider, and returning service token information to a user terminal sending a login request; redirecting the login request to the service provider; the user terminal sends an authorization request to the service provider, the service provider analyzes the authorization request, access verification is carried out on the service token information by using the service verification information, and the service provider allows the user terminal to access under the condition that the access verification is passed, and the authorization request is obtained according to the service token information.

Therefore, the embodiment of the application introduces the application identifier of the service provider when generating the token required by the access service provider, namely the service token information, so that the isolation and the differentiation processing of the user identity among the service providers are not needed because different service providers use different application identifiers, and the embodiment of the application provides a differentiated authentication mode. Even if an attacker obtains corresponding access credentials and/or token information by attacking one service provider, or the attacker intercepts or monitors the access credentials and/or token information transmitted in the authentication process, other service providers cannot be accessed, and the security and flexibility of authentication when a user accesses resources are improved.

Drawings

FIG. 1 is a schematic diagram of an authentication system according to the present application;

FIG. 2 is a schematic diagram of an authentication server in an authentication system according to the present application;

FIG. 3 is a flowchart of a first embodiment of an authentication method according to the present application;

FIG. 4 is a flowchart of a second embodiment of an authentication method according to the present application;

FIG. 5 is a flowchart of a third embodiment of an authentication method according to the present application;

Fig. 6 is a schematic block diagram of an authentication device according to the present application.

The achievement of the objects, functional features and advantages of the present application will be further described with reference to the accompanying drawings, in conjunction with the embodiments.

Detailed Description

It should be understood that the specific embodiments described herein are for purposes of illustration only and are not intended to limit the scope of the application.

When a user accesses a resource, the provider of the resource, i.e., the service provider, needs to verify the identity of the user, and only after the identity of the user passes the verification, the user is allowed to access the resource. In the related art, a user may perform remote authentication through another authentication server. Such as LDAP (LIGHTWEIGHT DIRECTORY ACCESS PROTOCOL ), RADIUS (Remote Authentication Dial-In User Service), OAuth/OpenID, etc. are installed by the Service provider. In these cases, when a user attempts to access a resource, the service provider will send an authentication request to the authentication server. The authentication server will check the identity credentials of the user and return a verification result, i.e. an access token. The user accesses the service provider by accessing the token.

However, if the user uses the same user name and password and other identity credentials in multiple service providers, once one of the service providers or the remote authentication server reveals data, or the data in the process of data transmission of remote authentication is revealed, an attacker may attempt to construct an access token by attacking the acquired identity credentials of the user, or use the same access token to access other service providers, thereby causing security threat.

When the authentication server is a shared server or a unified authentication server in a single sign-on system, the security threat is more obvious because the authentication server can provide identity authentication services for a plurality of service providers. Taking single sign-on as an example, SAML (Security Assertion Markup Language) -based single sign-on is an identity authentication and authorization protocol that allows a user to access multiple mutually trusted applications or service providers with only one sign-on. SAML enables the exchange of authentication and authorization information across domains by defining a communication mechanism between an identity Provider (Identity Provider, idP) and a Service Provider (SP).

In a SAML single sign-on system, user sign-on mainly involves the following key steps:

Request interception redirection: when a user attempts to access a protected service provider, the service provider checks whether the user has logged in. If the user is not logged in, the application will send an authentication request to the unified authentication server. After receiving the authentication request, the unified authentication server generates a redirection response, and redirects the single sign-on request of the user browser to a login page of the unified authentication server.

User login performs identity verification: the user enters a user name and password (or other authentication means such as biometric identification, token, etc.) on the login page to login. Once the user successfully logs in, the unified authentication server generates a token (e.g., JWT or SAML token) that contains the user's identity information and authorization information.

Access rights granting: the unified authentication server redirects the user browser back to the service provider that originally attempted access, with the generated token. This redirected URL typically contains the token as a parameter or the token is stored in a cookie. Upon receipt of the redirect request, the service provider extracts the token from the URL parameter or cookie and verifies the validity of the token with the SSO platform. Or the service provider may send a SAML request to the user terminal asking for verification of the identity of the user. After receiving the request, the user terminal searches the token existing in the user and sends the corresponding token to the service provider.

If the token is valid, the service provider will allow the user to access the application resource. Thus, the user does not need to repeatedly input a user name and a password in each service provider, and can access all application resources which are mutually trusted only by logging in once.

However, after the authentication of the unified authentication server is successful, the tokens for authentication of all the service providers are consistent, so that once one service provider or application program has data leakage, an attacker can attempt to access other application programs through attacking the acquired tokens of the user, thereby causing security threat.

Therefore, the application provides a solution, by introducing service provider application identifiers when generating tokens, namely service token information, required by access service providers, so that different service providers use different application identifiers, isolation and differentiated processing of user identities among the service providers are not required, and the embodiment of the application provides a differentiated authentication mode. Even if an attacker obtains corresponding access credentials and/or token information by attacking one service provider, or the attacker intercepts or monitors the access credentials and/or token information transmitted in the authentication process, other service providers cannot be accessed, and the security and flexibility of the user when accessing resources are improved.

The inventive concept of the present application is further illustrated below in conjunction with some specific examples and implementations.

Referring to fig. 1, fig. 1 is a schematic architecture diagram of a login system according to an embodiment of the present application.

Referring to fig. 1, fig. 1 is a schematic architecture diagram of an authentication system according to an exemplary embodiment. As shown in fig. 1, the authentication system includes an authentication server 10, a service provider 20, and a user terminal 30.

And any two of the user terminal 30, the service provider 20 and the authentication server 10 are communicatively connected. Such as via a network connection. The network may include various types of wired or wireless networks. In one embodiment, the network may include a Public Switched telephone network (Public Switched TelephoneNetwork, PSTN) and the Internet.

The authentication server 10 may be a physical server comprising a separate host, or the authentication server 10 may be a virtual server carried by a cluster of hosts. As shown in fig. 2, in one embodiment, the authentication server 10 may include: a processor 1001, such as a CPU, a user interface 1003, a memory 1005, and a communication bus 1002. Wherein the communication bus 1002 is used to enable connected communication between these components. The optional user interface 1003 may also be a Display (Display), an input unit such as a Keyboard (Keyboard), or the like. The memory 1005 may be a high-speed RAM memory or a stable memory (non-volatilememory), such as a disk memory. The memory 1005 may also optionally be a storage device separate from the processor 1001 described above. It will be appreciated that the authentication server 10 may also include a network interface 1004, the network interface 1004 optionally including a standard wired interface, a wireless interface (e.g., WI-FI interface). Optionally, the authentication server 10 may further include an RF (Radio Frequency) circuit, a sensor, an audio circuit, a WiFi module, and the like. It will be appreciated by those skilled in the art that the authentication server 10 structure shown in fig. 2 is not limiting of the authentication server 10 structure and may include more or fewer components than shown, or may combine certain components, or may be a different arrangement of components.

The service provider 20 may also be a physical server comprising a separate host, or the authentication server 10 may be a virtual server carried by a cluster of hosts. During operation, the service provider 20 may run a server-side program of an application to implement the relevant business functions of the application.

The user terminal 30 may comprise electronic devices of the type such as: workstations, smartphones, tablet devices, notebook computers, personal computers (PDAs), etc., to which one or more embodiments of the present disclosure are not limited. In operation, a browser is installed on the user terminal 30 so that the authentication server 10 can be logged in through the browser or the service provider 20 can be accessed.

Based on the above-described structure, but not limited to the above-described structure, a first embodiment of the authentication method of the present application is proposed. Referring to fig. 3, fig. 3 is a flowchart illustrating a first embodiment of an authentication method according to the present application.

It should be noted that although a logical order is depicted in the flowchart, in some cases the steps depicted or described may be performed in a different order than presented herein.

In this embodiment, the authentication method includes:

step S100, the authentication server generates service token information and service verification information according to the application identifier of the service provider corresponding to the login request.

Wherein the service token information corresponds to the service authentication information.

Step 200, the authentication server sends the service verification information to the service provider, and returns the service token information to the user terminal sending the login request.

Specifically, when a user attempts to access the service provider 20 through the user terminal 30, the service provider 20 transmits an authentication request to the authentication server 10. Upon receipt of the authentication request, the authentication server 10 generates a redirect response that redirects the login request of the browser of the user terminal 30 to the login page of the authentication server 10.

At this point, the authentication server 10 reads the application identification of the service provider 20 that the user is attempting to access. The application identification may be an application ID of the service provider 20. Of course, the application identifier may also be the name of the application, a tag, or the LOGO of the application, etc. The following specifically describes an application ID in which an application is identified as the service provider 20 as an example. It will be appreciated that the application identities of the different service providers 20 are different.

After reading the application identifier, the authentication server 10 generates service token information and service verification information according to the application identifier. It will be appreciated that the service token information is an access token, which the authentication server 10 sends to the user terminal 30, by means of which the user terminal 30 proves that it is authenticated by the authentication server 10, so that the resource to be accessed can be accessed accordingly.

Correspondingly, the service verification information is data for verifying whether the service token information is valid or not. Since the application identifier of the service provider 20 is introduced in the process of generating the service token information in this embodiment, the access authentication data of different service providers 20 cannot be used in common, and it is also necessary to generate the service authentication information for verifying whether the service token information is valid or not while generating the service token information. I.e. the service token information corresponds to the service authentication information, the service token information of different service providers 20 cannot be used in common with each other.

Then, the authentication server 10 transmits the service token information to the user terminal 30, and transmits the service verification information to the service provider 20. It will be appreciated that the authentication server 10 may transmit the service token information to the user terminal 30 and the service verification information to the service provider 20 at the same time. Alternatively, the authentication server 10 may transmit the service token information to the user terminal 30 and the service authentication information to the service provider 20 at two adjacent times or within a preset period of time, so as to avoid the service token information and the service authentication information from being invalid. It will be appreciated that the duration of the predetermined period of time is determined by the effective duration of the service token information and the service verification information.

Further, the service token information and the service authentication information may be two data bound to each other, and the service provider 20 may verify whether the service token information and the service authentication information transmitted from the user terminal 30 are a set of data bound in advance in a subsequent authorization step.

Or the service token information may be an original data and a calculation mode of the original data, and the service verification information is a calculation result of the original data according to the calculation mode, so that the service provider 20 can verify whether the calculation result of the original data and the calculation mode of the original data sent by the user terminal 30 for re-calculation is consistent with the service verification information in a subsequent authorization step.

Thus, as a specific embodiment, step S200 may specifically include:

In step S210, the authentication server 10 generates an access salt value according to the application identifier of the service provider 20 corresponding to the login request.

Step S220, the authentication server 10 performs a first hash calculation after splicing the access salt value and the identity information, to obtain service verification information.

In step S230, the authentication server 10 uses the access salt, the first concatenation method of the access salt and the identity information, and the first hash algorithm of the first hash calculation as the service token information.

Illustratively, after the authentication server 10 reads the application identifier, a preset salt value generation algorithm may be invoked to obtain the access salt value. It will be appreciated that the salt value is typically a randomly generated string, the length of which may be dependent on the particular requirements.

The authentication server 10 may first generate a random string using a random string generator and then concatenate the random string with the application ID to obtain the access salt. It should be noted that, the splicing of the random string and the application ID may be that the random string is before, the application ID is after, or the random string is after, the application ID is before, or even the random string is embedded into the application ID, which is not limited in this embodiment.

After obtaining the access salt value, the authentication server 10 splices the access salt value and the identity information of the user according to the first splicing mode and then performs hash calculation, thereby obtaining service verification information. Meanwhile, the unified authentication server 10 uses the access salt value, the first splicing mode of the access salt value and the identity information and the first hash algorithm of the first hash calculation, which are used in the process of calculating the service verification information, as the service token information.

It should be noted that, the first splicing manner used for splicing the access salt value and the identity information may be that the access salt value is before, the identity information is after, or that the access salt value is after, the identity information is before, so that the access salt value may be embedded into the identity information, which is not limited in this embodiment.

Furthermore, it should be noted that the identity information of the user may be any one of a user name, a user identifier, a user ID, an access password, and an authentication password, and of course, the identity information of the user may also be a concatenation result of at least two of the user name, the user identifier, the user ID, the access password, and the authentication password. The user's identity information is further described below as an access password.

Step S300, the authentication server 10 redirects the login request to the service provider 20.

After the service provider 20 acquires the service verification information and the user terminal 30 acquires the service token information, the authentication server 10 redirects the login request of the user terminal 30 to the service provider 20 so that the user terminal 30 establishes a link with the service provider 20.

Step S400, the user terminal 30 sends an authorization request to the service provider 20.

In step S500, the service provider 20 analyzes the authorization request, performs access authentication on the service token information using the service authentication information, and when the access authentication is passed, the service provider 20 allows the user terminal 30 to access.

After the user terminal establishes a connection with the service provider, the user terminal 30 looks up the already existing service token information and sends the corresponding service token information to the service provider 20. The service provider 20 performs access authentication on the service token information using the service authentication information, and in the case where the access authentication passes, the service provider 20 allows the user terminal 30 to access.

It may be appreciated that, when the service token information is the access salt value, the first splicing manner, and the first hash algorithm, as a specific embodiment, the generating process of the authorization request may be: the user terminal 30 invokes the access password (e.g. stored in a cache) input by the user on the login interface, then splices the access salt value and the access password according to the received first splicing mode, and then hashes the splicing result according to the first hash algorithm to obtain a result hash value, thereby reproducing the service verification information calculated before the authentication server 10. And finally, taking the result hash value as data carried in the authorization request.

Or as another specific embodiment, the authorization request may be generated by the user terminal 30 firstly calling the access password (e.g. stored in the cache) input by the user in the login interface, and then packaging the received first splicing mode, access salt value, access password and first hash algorithm, so as to generate the authorization request.

Upon receiving the authorization request, the service provider 20 parses it to extract data related to the service token information. It will be appreciated that the relevant data may be the service token information itself, or may be the result of a calculation of the service token information, such as the result hash value described above. The service provider 20 then verifies the extracted service token information itself, or the resulting hash value, or also the service token information received by the user and the access password associated with the service token information, against the service verification information.

Specifically, when the service token information is obtained by parsing the authorization request, the service provider 20 may request to the authentication server 10 to verify whether the service token information and the service verification information are a set of data satisfying the binding relationship, and if the binding relationship is satisfied, the verification is passed.

Or when resolving the authorization request to obtain a resulting hash value, the service provider 20 may compare whether the resulting hash value is consistent with the service authentication information, and if so, verify. It will be appreciated that in this manner, the data interacted between the user terminal 30, the authentication server 10 and the service provider 20 are hash values or random strings, and the information is kept secret and isolated from each other, so that the security is better. And the service provider 20 only needs to perform the comparison of the hash values, without performing complex cryptographic processing or interacting with the authentication server 10. This can reduce the burden on the service provider 20 and improve the verification efficiency.

In addition, to further provide security of the system, as a specific embodiment, the service provider 20 starts a timer to count when receiving the service authentication information, and stops counting until receiving the authorization information, so as to obtain a time difference between a first time when receiving the service authentication information and a second time when receiving the authorization information. Of course, it is also possible that the service provider 20 records the first time and the second time according to the local clock and then calculates the time difference between the first time and the second time. At this time, step S500 specifically includes: in case the time difference between the first reception time and the second reception time is smaller than a preset value and the access authentication is passed, the service provider 20 allows the user terminal 30 to access.

That is, in the present embodiment, the service token information is time-efficient, and when the time difference is greater than or equal to the preset value, the service token information is disabled, and even if it passes the authentication of the service provider 20, the service provider 20 still denies the access to the user terminal 30. I.e. the final verification result is still a failure.

It can be seen that the service provider application identifier is introduced when the token required by the service provider is generated, namely the service token information, so that different service providers use different application identifiers, isolation and differentiation processing of user identities among the service providers are not required, and the embodiment of the application provides a differentiated authentication mode. Even if an attacker obtains corresponding access credentials and/or token information by attacking one service provider, or the attacker intercepts or monitors the access credentials and/or token information transmitted in the authentication process, other service providers cannot be accessed, and the security and flexibility of a user in remote authentication and resource access are improved.

In addition, in the present embodiment, the data interacted among the user terminal 30, the authentication server 10 and the service provider 20 are all hash values or random strings, and plaintext information such as an access password is not interacted, and the information is kept secret and isolated from each other, so that the security is better.

It should be noted that, in the single sign-on system, the authentication procedure provided in the foregoing embodiment may be a secondary authentication procedure in the single sign-on system. Specifically, referring to fig. 4, a second embodiment of the authentication method according to the present application is described below.

In this embodiment, the authentication method includes:

step S10, when the login request of the user terminal passes the platform identity authentication, the authentication server generates service token information and service verification information according to the application identifier of the service provider corresponding to the login request.

Step S20, the authentication server sends the service verification information to the service provider, and returns the service token information to the user terminal sending the login request.

Step S30, the authentication server 10 redirects the login request to the service provider 20.

Step S40, the user terminal 30 sends an authorization request to the service provider 20.

In step S50, the service provider 20 analyzes the authorization request, performs access authentication on the service token information using the service authentication information, and when the access authentication is passed, the service provider 20 allows the user terminal 30 to access.

Specifically, in the present embodiment, the authentication server 10 may be a unified authentication server in a single sign-on system. Of course, when a user attempts to access one of the service providers 20 in the single sign-on system through the user terminal 30, the service provider 20 checks whether the user has logged in. If the user is not logged in, the service provider 20 sends an authentication request to the authentication server 10. Upon receipt of the authentication request, the authentication server 10 generates a redirect response that redirects the login request of the browser of the user terminal 30 to the login page of the authentication server 10. The user enters a user identification (user name, nickname or mailbox address, etc.) and a password (or other identity credential, such as a fingerprint, iris, face, etc.) on the login page to login. In the single sign-on system, once the user successfully logs in, it is explained that the single sign-on request of the user terminal 30 passes the platform identity authentication.

In this case, the authentication server 10 will read the application identification of the service provider 20 that the user is attempting to access. It will be appreciated that in the authentication server 10, each service provider 20 that is trusted is configured with a globally unique label, i.e. each service provider 20 has an application identity corresponding thereto, and that the application identities of the different service providers 20 are different.

After reading the application identifier, the authentication server 10 generates service token information and service verification information according to the application identifier. Then, the authentication server 10 transmits the service token information to the user terminal 30, and transmits the service verification information to the service provider 20.

It should be noted that in a SAML-based single sign-on system, after the platform identity verification is passed, the unified authentication server needs to generate a SAML token, which contains the identity information of the user. That is, the service provider 20 needs to determine whether it is a platform-authenticated user through the identity information of the user. Thus, as an alternative to this embodiment, the authentication server 10 may be configured to send a SAML token containing the identity information of the user, and during the login process, the authentication server 10 may also send a generated service token information. That is, the service provider 20 needs to verify both the service token information and the SAML token, and in the case that both are verified, the user terminal 30 is allowed to access the service provider 20.

Or as an alternative to this embodiment, step S200 may be: the authentication server 10 generates service token information and service verification information according to the application identifier of the service provider 20 corresponding to the single sign-on request and the identity information of the user.

Specifically, during the login process, the authentication server 10 does not generate the SAML token and the service token information respectively, but includes the identity information of the user in the service token information, so that the service token information includes the identity information of the user and the application identifier of the service provider 20, thereby simplifying the login process and improving the user experience and convenience.

The authentication server 10 redirects the login request to the service provider 20, and after receiving the redirect request, the service provider 20 sends a request to the user terminal 30, requesting to verify the token information of the user, and after receiving the request, the user terminal 30 sends an authorization request carrying the service token information to the service provider 20. Of course, it is also possible that the user terminal 30 actively sends an authorization request carrying service token information to the service provider 20. The user terminal 30 then looks up the already existing service token information and sends the corresponding service token information to the service provider 20. The service provider 20 performs access authentication on the service token information using the service authentication information, and in the case where the access authentication passes, the service provider 20 allows the user terminal 30 to access.

It will be appreciated that referring to the first embodiment of the authentication method, access to salt values is also involved in the generation of service token information and service verification information. It is easy to understand that, since in the single sign-on system, the authentication of the service provider 20 that integrates a plurality of channels, part of the service provider 20 belongs to a cloud application or a third party application, which has a certain independence. For these service providers 20, single sign-on systems cannot achieve 100% security control. Therefore, the design of the access salt value corresponds to different applications, so that information isolation is formed between the different applications, and the safety is improved. Therefore, the threat to the safety of the application system caused by hard cracking modes such as a database collision after the illegal application system obtains the salt value of the user in the prior art can be avoided.

It can be seen that, in this embodiment, by introducing the application identifier of the service provider 20 when the platform identity verification passes the generation of the service token information, since different service providers 20 use different application identifiers, that is, access to different application tokens is different, isolation and differentiation processing of user identities between the service providers 20 are not required, and even if an attacker obtains corresponding authorization information by attacking one of the service providers 20 in the single sign-on system, the attacker cannot access other service providers 20, so that the security and flexibility of the user during single sign-on are improved.

Furthermore, in the single sign-on system, in order to protect identity information such as an access password of the user when the user performs platform identity verification, a third embodiment of the authentication method of the present application is provided on the basis of the above-mentioned method embodiment.

Referring to fig. 5, in this embodiment, before step S10, the method further includes:

In step S01, the authentication server 10 generates a user salt value bound to the user when receiving the user identifier and the access password input at the time of user registration.

Step S02, the authentication server 10 performs second hash calculation after splicing the user salt value and the access password to obtain platform verification information.

Specifically, when the user registers on the authentication server 10, the browser of the user terminal 30 displays a registration interface. The user needs to input a user identification and an access password through the registration interface. It will be appreciated that the user identification may be a user name, a user nickname, or a mailbox name, among others.

The authentication server 10 generates a random string for each registered user, which is defined as a user salt. And then, splicing the user salt value with the access password, and performing hash calculation to obtain platform verification information. It should be noted that, the splicing manner of the user salt value and the access password may be that the user salt value is before, the access password is after, or that the user salt value is after, the access password is before, or that the user salt value is embedded in the access password, which is not limited in this embodiment.

It can be seen that, because the salt value is a random and unique character string, the platform verification information of each user can be unique by combining the user salt value with the access password of the user and then performing hash processing. Even if the passwords of two users are the same, the hash value, i.e. the platform authentication information, will be different due to the difference of the user salt values. By the aid of the method, common attack means such as a rainbow table can be prevented from being used, and the security of the password is improved.

In step 03, the authentication server 10 sends the user salt value, the second splicing manner of the user salt value and the access password, and the second hash algorithm of the second hash calculation to the user terminal 30.

The authentication server 10 sends the user salt value, the second splicing mode of the user salt value and the access password, and the second hash algorithm of the second hash calculation to the user terminal 30, and stores the user salt value, the access password, and the platform verification information in a database or other persistent storage, and forms a mapping relationship with the user identifier for later use in platform verification.

It is appreciated that the first hash function and the second hash function may be hash functions such as bcrypt, PBKDF2, scrypt, and the like. In addition, the second splicing mode, the first hash algorithm and the second hash algorithm can be the same, so that the computing resources are saved.

In step S04, when receiving the platform verification request from the user terminal 30, the authentication server 10 verifies the identity credential carried by the platform verification request by using the platform verification information.

The identity credential is obtained by splicing the user salt value and the access password according to a second splicing mode and performing hash calculation by using a second hash algorithm after the user terminal 30 receives the user identifier and the access password input by the user on the login interface; wherein the login interface is triggered by the single sign-on request of the user terminal 30 being redirected to the authentication server.

In step S05, if the authentication of the identity credential is passed, the unified authentication server 10 determines that the single sign-on request of the user terminal 30 passes the platform identity authentication.

When a user attempts to access a service provider 20 in a single sign-on system, a single sign-on request is sent and the user single sign-on request is redirected to the unified authentication server 10. At this time, the user's browser will display a login page. The user inputs a user identification and an access password (or other authentication modes such as fingerprint, face and the like) on the login page to log in. And the user terminal 30 will call the stored user salt value corresponding to the user identifier after receiving the user identifier and the access password input by the user. And then splicing the user salt value and the access password according to a second splicing mode, and performing hash calculation according to a second hash algorithm to obtain a login hash value, namely an identity credential. The user terminal 30 then sends the identity credential to the authentication server 10. The authentication server 10 invokes the platform verification information mapped by the user identifier, then compares the identity credential with the pre-stored platform verification information, and if the identity credential is consistent with the pre-stored platform verification information, the platform identity authentication passes.

It can be seen that, in this embodiment, the access password of the user may be stored in the database after being encrypted by using the salt value and performing hash processing on the salt value, and neither the user terminal 30 nor the authentication server 10 directly stores the plaintext password, thereby protecting the privacy of the user.

Thus, the present embodiment provides a secure and reliable authentication server 10, which protects the identity and password information of the user, and prevents password disclosure and identity falsification. By using random user salt value and hash function to carry out password processing, generating security measures such as access salt value and the like, the security of the user password is enhanced, common password attack means such as rainbow table attack, violent password cracking and the like are effectively prevented, and the identity and credentials of the user are safer in the transmission and storage processes.

In addition, in a specific embodiment, when the authentication server 10 generates the access salt according to the application identifier of the service provider 20 corresponding to the login request, instead of generating a random string by using a random string generator, the random string is spliced with the application identifier, and the user salt is spliced with the application identifier by using the user salt.

Therefore, in this embodiment, the design of the access salt value corresponds to different applications, and is based on the unified user salt value and encryption elements generated by different application systems, so that information isolation is formed between different applications, and security is improved.

To facilitate an understanding of the single sign-on procedure described above, an example is shown below:

there is a single sign-on system with a service provider a named "AppA". The following is a detailed description of the overall process:

1. User registration: the user Alice registers an account in the unified authentication server, and inputs a user name "Alice" and a password "pa$w0rd".

2. Generating a user salt value: the unified authentication server generates a random user salt for Alice: "3a5f9c8b21e7".

3. Salt adding treatment of the password: the unified authentication server combines the user salt value "3a5f9c8b21e7" and the password "pa$w0rd": "3a5f9c8b21e7pa $$ w0 rd).

4. And (3) password hash processing: the unified authentication server uses the SHA-256 hash function to hash the combined password to obtain a hash value: "67f4d5ab8e12e41f9d8b1eef a8edca e78e71a50b89ac42a06a655b9c79b1e".

5. Storing user information: the unified authentication server stores the password "pa$ w0rd", the initial salt value "3a5f9c8b21e7", and the hash value "67f4d5ab8e12e41f9d8b1eef a8edca69e78e71a50b89ac42a06a655b9c79b1e" in a database in association with the user's account.

6. Alice accesses AppA: alice now wants to access AppA and the browser is redirected to the unified authentication server for authentication.

7. Inputting the evidence: on the login page of the unified authentication server, alice enters her username "Alice" and password "pa$w0rd".

8. Alice client combines the entered password "pa$$ w0rd" with the initial salt value "3a5f9c8b21e7" as: "3a5f9c8b21e7pa $$ w0rd", and then performing SHA-256 hash processing to obtain a new hash value: "67f4d5ab8e12e41f9d8b1eef a8edca e78e71a50b89ac42a06a655b9c79b1e".

9. The unified authentication server receives a new hash value provided by Alice: "67f4d5ab8e12e41f9d8b1eef a8edca e78e71a50b89ac42a06a655b9c79b1e", obtain Alice's hash value from the database: "67f4d5ab8e12e41f9d8b1eef a8edca e78e71a50b89ac42a06a655b9c79b1e". The unified authentication server compares the newly generated hash value with the hash value stored in the database, and judges that the authentication is successful.

10. Generating access salt value: the unified authentication server generates a secondary salt value corresponding to the application A according to the ID "AppA123" of the application A and the user salt value "3a5f9c8b21e7" of the user Alice: "AppA1233a5f9c8b21e7" is sent to user Alice.

11. Generating a hash value: the unified authentication server will password "pa$w0rd" and access the salt value: the combination of the 'AppA 1233a5f9c8b21e 7' results in 'AppA 1233a5f9c8b21e7pa $$ w0 rd', and then SHA-256 hash processing is performed to obtain a new hash value, namely service verification information, which is sent to the AppA.

12. The user client generates a hash value: alice's client combines the entered password "pa$$ w0rd" with the access salt value "AppA1233a5f9c8b21e7" as: "AppA1233a5f9c8b21e7pa $$ w0rd", and then SHA-256 hash processing is performed to obtain a new hash value.

13. Judging a verification result: and the AppA compares the service verification information provided by the unified authentication server with the hash value provided by the Alice, and if the comparison is successful, the AppA confirms that the identity of the user Alice is effective, and allows the Alice to access the related resources of the AppA.

As can be easily understood, in the related art, if a user uses the same user name and password on a plurality of websites or applications, once one of the websites or applications has data leakage, an attacker can obtain the user's password and attempt to log in on other websites or applications, thereby causing a greater security threat. And in conventional user name and password authentication, the password is typically sent to the server in plain text for authentication. Thus, the password of the user can be intercepted by man-in-the-middle attack in the transmission process, and the password of the user is revealed.

In the above example, single sign-on and multi-application sharing are realized, and a user can access a plurality of applications only by registering an account in a unified authentication server, so that the login process of the user is simplified, and the user experience and convenience are improved. And by using random user salt value, proper hash function and access salt value generation, the scheme enhances the security of user passwords, and effectively prevents common password attack means such as rainbow table attack, violent password cracking and the like. The passwords and the sensitive information of the user are not directly transmitted to each service provider, and verification is carried out through the unified authentication server, so that the privacy protection of the user is improved, and the risk of sensitive information leakage is reduced. Further, by introducing the ID of the service provider when the access salt value is generated, differentiated SAML processing is realized. Each service provider uses different secondary salt values, so that isolation and differentiation of user identities among different applications are ensured, and flexibility and expandability of the system are improved.

In addition, referring to fig. 6, an embodiment of the present application further provides an authentication device configured in an authentication server, where the device includes:

the information generation module is used for generating service token information and service verification information according to the application identifier of the service provider corresponding to the login request; wherein the service token information corresponds to the service verification information;

the information sending module is used for sending the service verification information to the service provider and returning the service token information to the user terminal sending the login request;

A redirection module for redirecting the login request to the service provider; the user terminal sends an authorization request to the service provider, the service provider analyzes the authorization request, access verification is carried out on the service token information by using the service verification information, and the service provider allows the user terminal to access under the condition that the access verification is passed, and the authorization request is obtained according to the service token information.

It should be noted that, in this embodiment, each implementation manner of the authentication device and the technical effects achieved by the implementation manner may refer to various implementation manners of the authentication method in the foregoing embodiment, and are not described herein again.

In addition, the embodiment of the application also provides a computer storage medium, and a computer program is stored on the storage medium, and when the computer program is executed by a processor, the steps of the authentication method are realized. Therefore, a detailed description will not be given here. In addition, the description of the beneficial effects of the same method is omitted. For technical details not disclosed in the embodiments of the computer-readable storage medium according to the present application, please refer to the description of the method embodiments of the present application. As an example, the program instructions may be deployed to be executed on one computing device or on multiple computing devices at one site or distributed across multiple sites and interconnected by a communication network.

Furthermore, the embodiment of the application also provides a computer program product, wherein the computer program product stores a computer program, and the computer program realizes the steps of the authentication method when being executed by a processor.

Those skilled in the art will appreciate that implementing all or part of the above-described methods may be accomplished by way of computer programs, which may be stored on a computer-readable storage medium, and which, when executed, may comprise the steps of the embodiments of the methods described above. The storage medium may be a magnetic disk, an optical disc, a Read-only memory (ROM), a Random access memory (Random AccessMemory, RAM), or the like.

It should be further noted that the above-described apparatus embodiments are merely illustrative, where elements described as separate elements may or may not be physically separate, and elements shown as elements may or may not be physical elements, may be located in one place, or may be distributed over a plurality of network elements. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment. In addition, in the drawings of the embodiment of the device provided by the application, the connection relation between the modules represents that the modules have communication connection, and can be specifically implemented as one or more communication buses or signal lines. Those of ordinary skill in the art will understand and implement the present application without undue burden.

From the above description of the embodiments, it will be apparent to those skilled in the art that the present application may be implemented by means of software plus necessary general purpose hardware, or of course by means of special purpose hardware including application specific integrated circuits, special purpose CPUs, special purpose memories, special purpose components, etc. Generally, functions performed by computer programs can be easily implemented by corresponding hardware, and specific hardware structures for implementing the same functions can be varied, such as analog circuits, digital circuits, or dedicated circuits. But a software program implementation is a preferred embodiment for many more of the cases of the present application. Based on such understanding, the technical solution of the present application may be embodied essentially or in a part contributing to the prior art in the form of a software product stored in a readable storage medium, such as a floppy disk, a usb disk, a removable hard disk, a Read-only memory (ROM), a random-access memory (RAM, randomAccessMemory), a magnetic disk or an optical disk of a computer, etc., including several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the method of the embodiments of the present application.

The foregoing description is only of the preferred embodiments of the present application, and is not intended to limit the scope of the application, but rather is intended to cover any equivalents of the structures or equivalent processes disclosed herein or in the alternative, which may be employed directly or indirectly in other related arts.

Claims (10)

1. An authentication method, adapted for use with an authentication server, the method comprising:

Generating service token information and service verification information according to the application identifier of the service provider corresponding to the login request; wherein the service token information corresponds to the service verification information;

the service verification information is sent to the service provider, and the service token information is returned to the user terminal which sends the login request;

Redirecting the login request to the service provider; the user terminal sends an authorization request to the service provider, the service provider analyzes the authorization request, the service token information is subjected to access verification by using the service verification information, the service provider allows the user terminal to access under the condition that the access verification is passed, and the authorization request is obtained according to the service token information.

2. The authentication method according to claim 1, wherein the generating service token information and service verification information according to the application identifier of the service provider corresponding to the login request includes:

And generating the service token information and the service verification information according to the application identifier of the service provider corresponding to the login request and the identity information of the user.

3. The authentication method according to claim 2, wherein the generating the service token information and the service verification information according to the application identifier of the service provider corresponding to the login request by the identity information of the user includes:

generating an access salt value according to the application identifier of the service provider corresponding to the login request;

the access salt value and the identity information are spliced and then subjected to first hash calculation, so that the service verification information is obtained;

Taking the access salt value, a first splicing mode of the access salt value and the identity information and a first hash algorithm of the first hash calculation as the service token information;

And the authorization request is obtained by splicing the identity information and the access salt value by the user terminal according to the first splicing mode and then carrying out hash calculation by using the first hash algorithm.

4. The authentication method according to claim 1, wherein the service provider allows the user terminal to access in case of passing of access authentication, comprising:

in the case that the time difference between the first receiving time and the second receiving time is smaller than a preset value and the access authentication is passed, the service provider allows the user terminal to access; the first receiving time is the time when the service provider receives the service verification information, and the second receiving time is the time when the service provider receives the authorization request.

5. The authentication method according to claim 1, wherein the generating service token information and service verification information according to the application identifier of the service provider corresponding to the login request includes:

And under the condition that the login request of the user terminal passes the platform identity authentication, executing the application identifier of the service provider corresponding to the login request, and generating service token information and service verification information.

6. The authentication method according to claim 5, wherein in the case that the login request of the user terminal passes the platform identity authentication, before generating the service token information and the service verification information according to the application identifier of the service provider corresponding to the login request, the method further comprises:

under the condition that a user identifier and an access password input during user registration are received, generating a user salt value bound with the user;

Splicing the user salt value with the access password, and then performing second hash calculation to obtain platform verification information;

Transmitting the user salt value, a second splicing mode of the user salt value and the access password and a second hash algorithm of the second hash calculation to the user terminal;

Under the condition that a platform verification request of the user terminal is received, verifying an identity credential carried by the platform verification request by utilizing the platform verification information; the identity credential is obtained by splicing the user salt value and the access password according to the second splicing mode and performing hash calculation by using the second hash algorithm after the user terminal receives the user identifier and the access password which are input by the user on a login interface; wherein the login interface is triggered by the user terminal when a login request is redirected to the authentication server;

and under the condition that the authentication of the identity credential is passed, determining that the login request of the user terminal passes the platform identity authentication.

7. An authentication apparatus, configured in an authentication server, comprising:

the information generation module is used for generating service token information and service verification information according to the application identifier of the service provider corresponding to the login request; wherein the service token information corresponds to the service verification information;

The information sending module is used for sending the service verification information to the service provider and returning the service token information to the user terminal sending the login request;

A redirection module for redirecting the login request to the service provider; the user terminal sends an authorization request to the service provider, the service provider analyzes the authorization request, the service token information is subjected to access verification by using the service verification information, the service provider allows the user terminal to access under the condition that the access verification is passed, and the authorization request is obtained according to the service token information.

8. An authentication server comprising a processor, a memory and a computer program stored in the memory, which when executed by the processor, implements the authentication method according to any one of claims 1 to 6.

9. A computer readable storage medium, characterized in that the computer readable storage medium has stored thereon a computer program which, when executed by a processor, implements the authentication method according to any of claims 1 to 6.

10. A computer program product, characterized in that the computer program product comprises a computer program which, when executed by a processor, implements the steps of the authentication method according to any one of claims 1 to 6.