Application authentication method, system, device and storage medium

Abstract

The present invention relates to the field of WEB development, and provides an application authentication method for a client, including: registering with an authentication center to obtain a service identifier; logging in with the service identifier, and obtaining a user identifier on a client backend; the client backend submits the user identifier and the name of the application to be accessed to the authentication center, and if approved, generates an access identifier and an access key and returns them to the client backend; the client backend confuses the access key to generate a first obfuscated message; the client backend submits request information, the access identifier and the first obfuscated message to the application backend to be accessed; the application backend submits the access identifier and the application name to the authentication center to obtain the access key; the application backend confuses the access key to generate a second obfuscated message and compares it with the first obfuscated message, and if they are consistent, provides services to the client. The solution of the present invention shortens the interaction process, simplifies the system complexity, and improves security.

Description

Technical Field

[0001] The present invention relates to the field of WEB development, and more specifically, to an application authentication method, system, device and storage medium. Background Art

[0002] In the field of WEB development, when multiple application systems are presented in the form of WEB pages, the integration system integrates the WEB pages and provides unified external services. However, the integration system needs to consider the issue of unified page authentication to avoid repeated logins and login security issues when the integrated system accesses different WEB pages.

[0003] The integrated system also needs to consider the authentication issues of interface interactions between different application systems. The application system saves the authentication information of the authentication center. The requesting application system carries the authentication information when initiating the request. The receiving application system judges the authentication information through the central authentication system. If the authentication information is credible, the service is provided to the requesting application system.

[0004] The commonly used authentication methods and systems in the field of WEB development are mainly through session-cookie authentication or token authentication. However, the commonly used authentication methods and system page specifications and interface specifications are not unified, which is not conducive to development and use. The interaction process is redundant and complex, and security cannot be well taken into account. Summary of the invention

[0005] The present invention aims to overcome at least one defect of the above-mentioned prior art and provide an application authentication method, system, device and storage medium, so that the page specification and interface specification are provided by the same authentication system, the logic is unrelated to each other, and useful trusted information can still be obtained in the interaction process, shortening the interaction process, simplifying the system complexity, and improving security. The authentication method of the present invention does not incorporate business logic, thereby ensuring the independence of the business application access process. The authentication method of the present invention does not proxy interface traffic, but provides necessary signature verification parameters to the application, and the applications interact directly, reducing the pressure on the interface of the authentication center.

[0006] The technical solution adopted by the present invention is to register with an authentication center to obtain a service identifier; use the service identifier to log in, and the client backend obtains a user identifier; the client backend submits the user identifier and the name of the application to be accessed to the authentication center, and if passed, generates an access identifier and an access key and returns them to the client backend; the client backend obfuscates the access key to generate a first obfuscated message; the client backend submits request information, the access identifier and the first obfuscated message to the application backend to be accessed; the application backend submits the access identifier and the application name to the authentication center to obtain the access key; the application backend obfuscates the access key to generate a second obfuscated message and compares it with the first obfuscated message, and if they are consistent, provides services to the client.

[0007] The service identifier is the ID of the service provided by the authentication center. After the user logs in to the authentication center through the client, it is redirected back to the client. The client can then obtain relevant authentication information based on the service identifier. The access identifier is the identifier used by the client to access other applications. The access key is the key used by the client to access other applications for obfuscation.

[0008] The solution of the present invention builds the relationship between the authentication center, the client and the application end through the increment of the effective authentication information of the WEB page, so that the authentication center has the function of the authentication gateway. The authentication center serves as the authentication hub and completes the process authentication of the page and the interface.

[0009] A set of interaction specifications can be established through the design of logic such as central authentication, web verification and use, inter-system call application and API verification and use to constitute the authentication method of the present invention.

[0010] The client identifies the service identifier and calls the client backend to complete a set of authentication, namely login and registration actions. The whole set of authentication actions is packaged as an API call of the authentication center to improve the integration of the system. After the authentication center verifies the legitimacy of the service identifier, it returns the user identifier, and the client backend provides services for the client.

[0011] The authentication center has registered the names of several applications. The client submits the application name and user ID to be accessed to the authentication center, and then applies for access to the application. The authentication center generates an access ID and access key for access and submits them to the client backend.

[0012] Before calling an external interface, the client needs to mix the access key into the request parameters, perform encryption to generate the first obfuscated message, and request access to other applications. The application to be accessed obtains the access key corresponding to the access identifier through the authentication center, and re-mixes the access key into the request parameters to generate the second obfuscated message. The first obfuscated message and the second obfuscated message are compared to ensure that the request content has not been tampered with and the identity of the accessing client user is credible. Then services are provided to the client, which improves the security of access between applications.

[0013] Since the front-end jump is not eavesdropped, the authentication center jumps to the client's page. The service ID carried can collude with page authentication and interface authentication. When the authentication center receives the verification request of the service ID, it pre-traverses the service ID's IP whitelist, domain name whitelist, and service ID verification maximum time interval filter, and destroys the service ID after the verification is completed to prevent unknown callers from using the service ID to replay the system attack.

[0014] Further, the login is:

[0015] Submit the service ID to the client backend;

[0016] The client backend submits the service ID to the authentication center for verification, and returns a user ID if it passes.

[0017] The client backend completes the client login based on the user ID.

[0018] The user ID is the unique ID of the current user recognized by the authentication center and the client. Through the user ID, the authentication center can provide corresponding permissions according to the preset and whitelist, and then obtain corresponding services.

[0019] Further, the registration is:

[0020] Access the client backend through the access interface;

[0021] The client backend determines whether the user is logged in. If not, it redirects the user to the authentication center via 302.

[0022] The authentication center logs in and returns the service identifier to the client.

[0023] By using 302 redirection to access the authentication center, the non-eavesdropping nature of the front-end jump is utilized to ensure the security of the process of accessing the authentication center.

[0024] Further, the generating of the access identifier is specifically:

[0025] Generate a time number based on the access time;

[0026] Generate source machine code based on the client's machine code;

[0027] Generate target machine code according to the machine code of the application end to be accessed;

[0028] The time number, source machine code and target machine code are combined into an access identifier.

[0029] The present invention provides a scheme for generating access identifiers. Since the access identifier uniquely indicates the connection between servers, the connection should be considered to expire within the same day. Therefore, when the access identifier is used for timeliness log query, there is no need to pay attention to the cross-month log. When the concurrency exceeds the established design, the temporary additionally allocated identifier can be added with a preparation number. The source machine code represents the unique identifier of the client, which is managed and uniformly allocated by the authentication center. The target machine code represents the unique identifier of the application end that receives the request, which is managed and uniformly allocated by the authentication center.

[0030] When there are frequent calls or the same-origin machine requests for application access, the preparation number can be used as a time number extension to distinguish possible requests at the same millisecond level by means of random codes.

[0031] For the access identifier generation method of the present invention, a log archiving and query solution is also provided, specifically: log archiving is performed every day, and the year and month time bits are expanded upward during archiving to facilitate the basic self-increment strategy and retrieval requirements of the access identifier. When querying currently, if there is an unfinished archiving task, the current log is a mixture of the previous day's and the current day's logs, and the date can still be judged by the highest bit of the time number to clarify whether the log occurred on the previous day or the current day.

[0032] Further, the confusion is:

[0033] Generate a request message according to the source message and the sequence number;

[0034] After the request message is transcoded, the access key is randomly inserted to generate an obfuscated message.

[0035] The source message and serial number are data information of the client or application. The request message is generated and transcoded based on the source message and serial number, and the access key is randomly inserted. The obfuscated message generated in this way has unique identification to ensure security.

[0036] Furthermore, the transcoding is base64 transcoding.

[0037] Base64 encoding is an encoding method that splits a string into four 6-bit byte subsequences (6-bit valid bytes, the two leftmost bytes are always 0, which are actually 8-bit bytes) at a rate of 3 8-bit byte subsequences each, and then searches the base64 encoding index table for the obtained subsequences to get the corresponding characters and concatenate them into a new string.

[0038] Because the original message is embedded with a serial number, the obfuscated message body of each request is different. Assuming that the attacker does not understand the message obfuscation scheme, the attacker will not be able to tamper with the message because each request message is different. The original message replay attack will also be rejected by the target server because the restored serial number is the same.

[0039] The message obfuscation scheme does not use symmetric encryption. Before the attacker learns the access key, even if the obfuscation scheme is leaked, the attacker cannot restore the message. Therefore, the calculation scheme for message restoration is efficient and safe, meeting the security and performance requirements of inter-system requests. By combining base64 encoding with the obfuscation method of the present invention, the complexity is low, the development is easy, and the security of authentication is guaranteed.

[0040] Furthermore, after the application backend obtains the access key, the authentication center destroys the access identifier and the access key.

[0041] The access token and access key are issued once and verified once. Assuming that when application B uses the access token to obtain the access key normally, the authentication center will destroy the access token and access key stored in the center. In this way, only application A and application B know the backend key, which is used for application A to access application B in a one-way manner. Through the design of key validity, the access token can be prevented from being stolen to impersonate application A to initiate a new backend session with application B.

[0042] The present invention also provides an application authentication system, comprising:

[0043] Client: Customers register, log in, and access the application to obtain services through the client;

[0044] The client backend is used to obtain the user identifier, generate the first obfuscated message, and submit the user identifier, the name of the application to be accessed, the request information, the access identifier, and the first obfuscated message;

[0045] The authentication center is used to register clients and generate service identifiers, access identifiers, and access keys;

[0046] The application-side backend is used to submit the access identifier and the application name, obfuscate the access key to generate a second obfuscated message and compare it with the first obfuscated message, and provide services to the client.

[0047] The present invention also provides a computer device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor implements the application authentication method of the present invention when executing the computer program.

[0048] The present invention also provides a computer-readable storage medium on which a computer program is stored, characterized in that the application authentication method of the present invention is implemented when the computer program is executed by a processor.

[0049] The application authentication system, computer device, and computer-readable storage medium of the present invention are based on the same inventive concept as the application authentication method of the present invention, and will not be described in detail herein.

[0050] Compared with the prior art, the present invention has the following beneficial effects:

[0051] 1. Shorten the interaction process and simplify the system complexity.

[0052] 2. Improved the security of access between applications.

[0053] 3. The authentication method does not proxy the interface traffic, but provides the necessary signature verification parameters to the application, allowing direct interaction between applications, reducing the pressure on the interface of the authentication center.

[0054] 4. Prevent unknown callers from using service identifiers to replay attacks on the system.

[0055] 5. The un-eavesdropping nature of the front-end jump is utilized to ensure the security of the process of accessing the authentication center. BRIEF DESCRIPTION OF THE DRAWINGS

[0056] Figure 1 This is a flow chart of the method of Example 1 of the present invention.

[0057] Figure 2 This is a schematic diagram of the structure of the central authentication system of Example 2 of the present invention.

[0058] Figure 3 This is a schematic diagram of the central authentication system and client structure of Example 2 of the present invention. DETAILED DESCRIPTION

[0059] The drawings of the present invention are only for illustrative purposes and should not be construed as limiting the present invention. In order to better illustrate the following embodiments, some parts of the drawings may be omitted, enlarged or reduced, and do not represent the size of the actual product; it is understandable to those skilled in the art that some well-known structures and their descriptions in the drawings may be omitted.

[0060] Example 1

[0061] like Figure 1 As shown, this embodiment provides an application authentication method, which specifically includes:

[0062] S1. Register with the authentication center to obtain a service identifier;

[0063] S2. Log in using the service ID, and the client backend obtains the user ID;

[0064] S3: The client backend submits the user ID and the name of the application to be accessed to the authentication center. If approved, an access ID and access key are generated and returned to the client backend.

[0065] S4. The client backend obfuscates the access key to generate a first obfuscated message;

[0066] S5. The client backend submits the request information, the access identifier and the first obfuscated message to the application backend to be accessed;

[0067] S6. The application backend submits the access identifier and the application name to the authentication center to obtain an access key;

[0068] S7. The application backend obfuscates the access key to generate a second obfuscated message and compares it with the first obfuscated message. If they are consistent, the application backend provides services to the client.

[0069] The service identifier is the ID of the service provided by the authentication center. After the user logs in to the authentication center through the client, it is redirected back to the client. The client can then obtain relevant authentication information based on the service identifier. The access identifier is the identifier used by the client to access other applications. The access key is the key used by the client to access other applications for obfuscation.

[0070] The solution of the present invention builds the relationship between the authentication center, the client and the application end through the increment of the effective authentication information of the WEB page, so that the authentication center has the function of the authentication gateway. The authentication center serves as the authentication hub and completes the process authentication of the page and the interface.

[0071] A set of interaction specifications can be established through the design of logic such as central authentication, web verification and use, inter-system call application and API verification and use to constitute the authentication method of the present invention.

[0072] The client identifies the service identifier and calls the client backend to complete a set of authentication, namely login and registration actions. The whole set of authentication actions is packaged as an API call of the authentication center to improve the integration of the system. After the authentication center verifies the legitimacy of the service identifier, it returns the user identifier, and the client backend provides services for the client.

[0073] The authentication center has registered the names of several applications. The client submits the application name and user ID to be accessed to the authentication center, and then applies for access to the application. The authentication center generates an access ID and access key for access and submits them to the client backend.

[0074] Before calling an external interface, the client needs to mix the access key into the request parameters, perform encryption to generate the first obfuscated message, and request access to other applications. The application to be accessed obtains the access key corresponding to the access identifier through the authentication center, and re-mixes the access key into the request parameters to generate the second obfuscated message. The first obfuscated message and the second obfuscated message are compared to ensure that the request content has not been tampered with and the identity of the accessing client user is credible. Then services are provided to the client, which improves the security of access between applications.

[0075] Since the front-end jump is not eavesdropped, the authentication center jumps to the client's page. The service ID carried can collude with page authentication and interface authentication. When the authentication center receives the verification request of the service ID, it pre-traverses the service ID's IP whitelist, domain name whitelist, and service ID verification maximum time interval filter, and destroys the service ID after the verification is completed to prevent unknown callers from using the service ID to replay the system attack.

[0076] Preferably, the login is:

[0077] Submit the service ID to the client backend;

[0078] The client backend submits the service ID to the authentication center for verification, and returns a user ID if it passes.

[0079] The client backend completes the client login based on the user ID.

[0080] The user ID is the unique ID of the current user recognized by the authentication center and the client. Through the user ID, the authentication center can provide corresponding permissions according to the preset and whitelist, and then obtain corresponding services.

[0081] Preferably, the registration is:

[0082] Access the client backend through the access interface;

[0083] The client backend determines whether the user is logged in. If not, it redirects the user to the authentication center via 302.

[0084] The authentication center logs in and returns the service identifier to the client.

[0085] By using 302 redirection to access the authentication center, the non-eavesdropping nature of the front-end jump is utilized to ensure the security of the process of accessing the authentication center.

[0086] Preferably, the generating of the access identifier is specifically:

[0087] Generate a time number based on the access time;

[0088] Generate source machine code based on the client's machine code;

[0089] Generate target machine code according to the machine code of the application end to be accessed;

[0090] The time number, source machine code and target machine code are combined into an access identifier.

[0091] The present invention provides a scheme for generating access identifiers. Since the access identifier uniquely indicates the connection between servers, the connection should be considered to expire within the same day. Therefore, when the access identifier is used for timeliness log query, there is no need to pay attention to the cross-month log. When the concurrency exceeds the established design, the temporary additionally allocated identifier can be added with a preparation number. The source machine code represents the unique identifier of the client, which is managed and uniformly allocated by the authentication center. The target machine code represents the unique identifier of the application end that receives the request, which is managed and uniformly allocated by the authentication center.

[0092] When there are frequent calls or the same-origin machine requests for application access, the preparation number can be used as a time number extension to distinguish possible requests at the same millisecond level by means of random codes.

[0093] For the access identifier generation method of the present invention, a log archiving and query solution is also provided, specifically: log archiving is performed every day, and the year and month time bits are expanded upward during archiving to facilitate the basic self-increment strategy and retrieval requirements of the access identifier. When querying currently, if there is an unfinished archiving task, the current log is a mixture of the previous day's and the current day's logs, and the date can still be judged by the highest bit of the time number to clarify whether the log occurred on the previous day or the current day.

[0094] Preferably, the obfuscation is:

[0095] Generate a request message according to the source message and the sequence number;

[0096] After the request message is transcoded, the access key is randomly inserted to generate an obfuscated message.

[0097] The source message and serial number are data information of the client or application. The request message is generated and transcoded based on the source message and serial number, and the access key is randomly inserted. The obfuscated message generated in this way has unique identification to ensure security.

[0098] Preferably, the transcoding is base64 transcoding.

[0099] Base64 encoding is an encoding method that splits a string into four 6-bit byte subsequences (6-bit valid bytes, the two leftmost bytes are always 0, which are actually 8-bit bytes) at a rate of 3 8-bit byte subsequences each, and then searches the base64 encoding index table for the obtained subsequences to get the corresponding characters and concatenate them into a new string.

[0100] Because the original message is embedded with a serial number, the obfuscated message body of each request is different. Assuming that the attacker does not understand the message obfuscation scheme, the attacker will not be able to tamper with the message because each request message is different. The original message replay attack will also be rejected by the target server because the restored serial number is the same.

[0101] The message obfuscation scheme does not use symmetric encryption. Before the attacker learns the access key, even if the obfuscation scheme is leaked, the attacker cannot restore the message. Therefore, the calculation scheme for message restoration is efficient and safe, meeting the security and performance requirements of inter-system requests. By combining base64 encoding with the obfuscation method of the present invention, the complexity is low, the development is easy, and the security of authentication is guaranteed.

[0102] Preferably, after the application backend obtains the access key, the authentication center destroys the access identifier and the access key.

[0103] The access token and access key are issued once and verified once. Assuming that when application B uses the access token to obtain the access key normally, the authentication center will destroy the access token and access key stored in the center. In this way, only application A and application B know the backend key, which is used for application A to access application B in a one-way manner. Through the design of key validity, the access token can be prevented from being stolen to impersonate application A to initiate a new backend session with application B.

[0104] Example 2

[0105] This embodiment provides an application authentication system, including:

[0106] Client: Customers register, log in, and access the application to obtain services through the client;

[0107] The client backend is used to obtain the user identifier, generate the first obfuscated message, and submit the user identifier, the name of the application to be accessed, the request information, the access identifier, and the first obfuscated message;

[0108] Central authentication system, used to register clients and generate service identifiers, access identifiers, and access keys;

[0109] The application-side backend is used to submit the access identifier and the application name, obfuscate the access key to generate a second obfuscated message and compare it with the first obfuscated message, and provide services to the client.

[0110] like Figure 2 As shown, the central authentication system includes API, policy layer, cache area and user module. Among them, API is used to provide access interface, policy layer is used to save authentication policy and provide session maintenance function, cache is used to cache data, and user module includes: user model, client model and session model.

[0111] like Figure 3 As shown, the central authentication system provides web interaction specifications, page authentication, API interaction specifications and interface authentication functions to the client.

[0112] The persistence layer of the central authentication system includes a user model that stores basic information such as account numbers and passwords, a client model that stores client IP whitelists and business attributes, and a session model that stores key information about the actual session process, such as service identification front-end session process key information, user identification back-end session process key information, access identification, access keys, and the name of the application to be accessed. A cache module with an expiration mechanism is built to accelerate access to high-frequency access content (such as user identification, access keys, and IP whitelists), and the underlying model is open to the outside world in API mode through authentication strategies and session retention strategies.

[0113] The interaction specifications include a single sign-on system based on web authentication, and include API interaction specifications for service identity authentication, access application, and access identity authentication.

[0114] The central authentication system is designed by incrementing the effective authentication information of the web page, so that the central authentication system has the function of authentication gateway, and as the hub of the integrated system, completes the process authentication of pages and interfaces. The solution includes the central authentication system and a set of interaction specifications.

[0115] Interaction specifications include central authentication, web verification and use, inter-system call application, and API verification and use.

[0116] Central authentication: The application follows the central authentication scheme page interaction specification. If the current page is not logged in, it will redirect to the central authentication system with 302. The central authentication system will complete the login action and redirect to the client with the service identifier.

[0117] Web verification and use: The client identifies the service ID and calls the client backend service to complete the authentication action. The authentication action is an API call to the central authentication system. If the central authentication system passes the legitimacy check of the service ID, it returns the user ID. After the client completes the customized login action and user authentication, it provides normal services to the front end.

[0118] Inter-system call application: The authentication system registers the names of multiple applications. Application A submits the name of the application to be accessed, the name of the application to be accessed (i.e., application B), and the current application's unique identifier, the user ID, to the authentication system to apply for inter-application system access. The authentication system generates an access identifier and access key for access and returns them to the backend of application A.

[0119] API verification and usage: Before calling the external interface, application A needs to mix the access key into the request parameters and perform md5 encryption to form a signature. Application A carries the request parameters, signature, and access identifier to request the interface of application B. Application B obtains the access key corresponding to the access identifier through the central authentication system, mixes the access key into the request parameters again, and performs md5 encryption to form a signature. If the signature is consistent, it is considered that the request content has not been tampered with, the user identity is credible, and application B returns the normal request content.

[0120] The page specifications and interface specifications of this embodiment are both provided by the same central authentication system. The logics are unrelated to each other, but useful and trusted information can still be obtained during the interaction process, shortening the interaction process, simplifying the system complexity, and improving security. The authentication system of this embodiment does not incorporate business logic, ensuring the independence of the business application access process. The authentication system of this embodiment does not proxy interface traffic, but provides necessary signature verification parameters to the application, allowing direct interaction between applications, reducing the pressure on the API of the central authentication system.

[0121] Obviously, the above embodiments of the present invention are merely examples for clearly illustrating the technical solution of the present invention, and are not intended to limit the specific implementation methods of the present invention. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the claims of the present invention shall be included in the protection scope of the claims of the present invention.

Claims

1. An application authentication method, used for a client, characterized in that: include: Register with the authentication center to obtain a service ID; Log in using the service ID, and the client backend obtains the user ID; The login is: Submit the service ID to the client backend; The client backend submits the service ID to the authentication center for verification, and returns a user ID if it passes. The client backend completes the client login based on the user ID; The client backend submits the user ID and the name of the application to be accessed to the authentication center. If approved, an access ID and access key are generated and returned to the client backend; The client backend obfuscates the access key to generate a first obfuscated message; The client backend submits the request information, the access identifier and the first obfuscated message to the application backend to be accessed; The application backend submits the access identifier and the application name to the authentication center to obtain an access key; The application backend obfuscates the access key to generate a second obfuscated message and compares it with the first obfuscated message. If they are consistent, the application backend provides services to the client.

2. The application authentication method according to claim 1, characterized in that: The registration is: Access the client backend through the access interface; The client backend determines whether the user is logged in. If not, it redirects the user to the authentication center via 302. The authentication center logs in and returns the service identifier to the client.

3. The application authentication method according to claim 1, characterized in that: The specific steps of generating the access identifier are: Generate a time number based on the access time; Generate source machine code based on the client's machine code; Generate target machine code according to the machine code of the application end to be accessed; The time number, source machine code and target machine code are combined into an access identifier.

4. The application authentication method according to claim 1, characterized in that: The confusion is: Generate a request message according to the source message and the sequence number; After the request message is transcoded, the access key is randomly inserted to generate an obfuscated message.

5. The application authentication method according to claim 4, characterized in that: The transcoding is base64 transcoding.

6. The application authentication method according to claim 1, characterized in that: After the application backend obtains the access key, the authentication center destroys the access identifier and the access key.

7. An application authentication system, characterized in that: include: Client: Customers register, log in and access the application to obtain services through the client; The client backend is used to obtain the user identifier, generate the first obfuscated message, and submit the user identifier, the name of the application to be accessed, the request information, the access identifier, and the first obfuscated message; The login is: Submit the service ID to the client backend; The client backend submits the service ID to the authentication center for verification, and returns a user ID if it passes. The client backend completes the client login based on the user ID; The authentication center is used to register clients and generate service identifiers, access identifiers, and access keys; The application-side backend is used to submit the access identifier and the application name, obfuscate the access key to generate a second obfuscated message and compare it with the first obfuscated message, and provide services to the client.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the application authentication method according to any one of claims 1 to 6 is implemented.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the application authentication method according to any one of claims 1 to 6 is implemented.

Images