Application systems, clients, servers, storage media and program products

Abstract

The application relates to the mobile development technical field and provides an application program system, a client, a server, a storage medium and a program product, which can improve authentication security. Under the triggering of a third-party business webpage, an application program client sends a first request parameter to an application program server; the application program server carries out one-stage identity authentication based on a first type token, obtains third-party configuration data of the third-party business webpage based on a domain name identifier of the third-party business webpage after passing the one-stage identity authentication, generates a second type token, carries out two-stage identity authentication with a third-party business server based on the second type token, and feeds back a third type token and an asymmetric encryption public key to the third-party business webpage after passing the two-stage identity authentication; and the third-party business webpage carries out identity authentication based on the third type token and carries out double-key hybrid encryption based on the asymmetric encryption public key and a symmetric encryption key in the interaction process with the third-party business server.

Description

Technical Field

[0001] This application relates to the field of mobile development technology, and in particular to an application system, client, server, storage medium, and computer program product. Background Technology

[0002] In the rapid development cycle of mobile applications, integrating third-party business pages (such as H5 pages) into the application has become a common practice. In this architecture, the application acts as the basic framework, providing core functionality, while the third-party business pages carry the specific business logic, achieving cross-platform flexibility.

[0003] However, when applications need to integrate external content, such as third-party business systems, ensuring secure authentication and subsequent service interactions becomes a critical challenge. One such challenge is interaction security, as direct interaction between third-party business pages and servers may lead to data leakage during transmission. Although data can be protected by implementing encryption within the third-party business pages, the keys stored in this way may themselves be subject to security risks. Summary of the Invention

[0004] Therefore, it is necessary to provide an application system, client, server, storage medium, and computer program product to address the aforementioned technical problems.

[0005] This application provides an application system, which includes an application client and an application server:

[0006] When triggered by a third-party business webpage embedded in the application client, the application client sends the first request parameters to the application server;

[0007] The application server performs one-stage authentication based on the first type of token carried by the first request parameter. After the one-stage authentication is successful, it obtains the third-party configuration data corresponding to the third-party business webpage based on the domain name identifier of the third-party business webpage carried by the first request parameter, so as to generate the second type of token.

[0008] The application server performs two-phase authentication with the third-party business server based on the second type of token; the third-party business server is used to return a third type of token and an asymmetric encryption public key to the third-party business webpage after the two-phase authentication is successful; the third-party business webpage is used to perform authentication based on the third type of token and perform hybrid encryption based on the asymmetric encryption public key and the symmetric encryption key during the interaction with the third-party business server.

[0009] In one embodiment, triggered by a third-party business webpage embedded in the application client, the application client sends a first request parameter to the application server, specifically including:

[0010] When the native method interface of the application client is called by a third-party business webpage embedded in the application client, the native method interface generates a first request parameter based on the first type of token and the domain name identifier of the third-party business webpage, and calls the third-party user authentication information interface of the application server so that the first request parameter is transmitted to the third-party user authentication information interface; the third-party user authentication information interface is used to perform two-phase authentication, obtain third-party configuration data, and generate a second type of token.

[0011] In one embodiment, the application server performs two-phase authentication with a third-party business server based on the second type of token, specifically including:

[0012] The third-party user authentication information interface calls the corresponding user authentication interface on the third-party business server according to the third-party user authentication address in the third-party configuration data, and sends a second request parameter to the user authentication interface; the user authentication interface is used to generate a third request parameter according to the second type of token carried by the second request parameter and the third-party identifier stored in itself, and send the third request parameter to the third-party dedicated user token authentication interface of the application server.

[0013] The third-party dedicated user token authentication interface performs two-stage identity verification based on the second type of token and the third-party identifier carried in the third request parameter.

[0014] In one embodiment, after the two-phase authentication is successful, the third-party dedicated user token authentication interface sends a user identifier back to the user authentication and authorization interface; the user authentication and authorization interface is used to determine whether there is an associated account in the business system to which the third-party business server belongs based on the user identifier, and if so, to generate a third type of token based on the associated account.

[0015] In one embodiment, a second type of token is generated based on third-party configuration data corresponding to a third-party business webpage, including:

[0016] Retrieve the third-party identifier from the third-party configuration data corresponding to the third-party business webpage;

[0017] A second type of token is generated based on the third-party identifier and the user identifier.

[0018] In one embodiment, hybrid encryption based on the asymmetric encryption public key and the symmetric encryption key includes:

[0019] Based on a symmetric encryption key, the content to be interacted with is encrypted to obtain the encrypted content to be interacted with and used as the request body.

[0020] The symmetric encryption key is encrypted using an asymmetric encryption public key and used as a request header; the request body and the request header are transmitted to a third-party business server.

[0021] This application provides an application client, which is an application client included in the application system described in the above embodiments.

[0022] This application provides an application server, which is the application server included in the application system described in the above embodiments.

[0023] This application provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the steps involved in the application system described in the above embodiments.

[0024] This application provides a computer-readable storage medium having a computer program stored thereon, the computer program being executed by a processor of the steps involved in the application system described in the above embodiments.

[0025] This application provides a computer program product having a computer program stored thereon, wherein the computer program is executed by a processor through the steps involved in the application system described in the above embodiments.

[0026] The application system provided in this application includes an application client and an application server: Upon triggering by a third-party business webpage embedded in the application client, the application client sends a first request parameter to the application server; the application server performs a first-stage authentication based on a first-type token carried by the first request parameter; after successful first-stage authentication, it obtains third-party configuration data corresponding to the third-party business webpage based on the domain name identifier of the third-party business webpage carried by the first request parameter, to generate a second-type token; the application server performs a second-stage authentication with the third-party business server based on the second-type token; the third-party business server, after successful second-stage authentication, feeds back a third-type token and an asymmetric encryption public key to the third-party business webpage; the third-party business webpage, during interaction with the third-party business server, performs authentication based on the third-type token and performs hybrid encryption using the asymmetric encryption public key and the symmetric encryption key. In the solution provided in this application, the third-party business webpage embedded in the application client does not directly interact with the server, and authentication is jointly completed by the application server and the third-party business server, avoiding the risk of direct interaction between the third-party business webpage and the server, and improving authentication security and user operation convenience. Attached Figure Description

[0027] To more clearly illustrate the technical solutions in the embodiments or related technologies of this application, the accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0028] Figure 1 This is a flowchart illustrating the application system in one embodiment;

[0029] Figure 2 This is a schematic diagram of the relevant process of the native method interface in one embodiment;

[0030] Figure 3 This is a schematic diagram illustrating the relevant process of a third-party user authentication information interface in one embodiment.

[0031] Figure 4 This is a schematic diagram illustrating the relevant process of a third-party dedicated user token authentication interface in one embodiment;

[0032] Figure 5 This is a schematic diagram of the relevant process of the user authentication and authorization interface in one embodiment;

[0033] Figure 6This is a schematic diagram of the interaction process between the application and a third party in one embodiment;

[0034] Figure 7 This is a schematic diagram of the internal structure of an application server in one embodiment. Detailed Implementation

[0035] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0036] The application system provided in this application includes an application client and an application server. Business web pages not controlled by the application's owner are called third-party business web pages, and each third-party business web page has its corresponding business server, which can be called a third-party business server.

[0037] The application client can embed third-party business web pages. In this scenario, when the third-party business web page wants to interact with the third-party business server, it can do so through the solution provided in this application. The process steps involved in the solution provided in this application are as follows: Figure 1 As shown.

[0038] In step S101, triggered by a third-party business webpage embedded in the application client, the application client sends the first request parameter to the application server.

[0039] Users can utilize services provided by third-party business web pages. When providing services to users, these third-party business web pages need to interact with the corresponding third-party business servers. In this scenario, the third-party business web page can trigger the application client by calling the application client's raw method interface. Upon triggering by the third-party business web page, the application client can obtain the app user token (application user token) and the domain identifier corresponding to the third-party business web page. Based on the app user token and the domain identifier, it generates request parameters (which can be called the first request parameters) and sends them to the application server. For distinction, the app user token can be referred to as the first type of token. "App" is an abbreviation for "Application."

[0040] In step S102, the application server performs one-stage authentication based on the first type of token carried in the first request parameter. After the one-stage authentication is successful, it obtains the third-party configuration data corresponding to the third-party business webpage based on the domain name identifier of the third-party business webpage carried in the first request parameter, so as to generate the second type of token.

[0041] After receiving the first request parameters, the application server can parse them to obtain a first-type token and the domain identifier corresponding to the third-party business webpage. The application server can use the first-type token for app user authentication, which is a one-phase authentication. After successful app user authentication (i.e., after successful one-phase authentication), the application server can check the third-party authentication configuration data to see if there is third-party configuration data corresponding to the third-party business webpage, based on the parsed domain identifier. If it does not exist, it means that the third-party business webpage is not authorized to access. If it exists, the application server can obtain a third-party exclusive app user token based on the third-party configuration data corresponding to the third-party business webpage. For distinction, this third-party exclusive app user token can be called a second-type token.

[0042] In step S103, the application server performs two-phase authentication with the third-party business server based on the second type of token.

[0043] The third-party business server is used to return a third-type token and an asymmetric encryption public key to the third-party business webpage after the two-phase authentication is successful. The third-party business webpage is used to perform authentication based on the third-type token and perform hybrid encryption based on the asymmetric encryption public key and the symmetric encryption key during the interaction with the third-party business server.

[0044] After obtaining the second-type token, the application can use it to perform server-level authentication with the third-party business server. Server-level authentication is a type of two-phase authentication.

[0045] After successful two-phase authentication, the third-party business server can generate a business system user token, which can be referred to as a third-type token for distinction. The third-party business server sends the third-type token application and asymmetric encryption public key back to the application server; the application server sends the third-type token application and asymmetric encryption public key back to the application client; and the application client sends the third-type token application and asymmetric encryption public key back to the third-party business webpage.

[0046] During the interaction between the third-party webpage and the third-party business server, authentication is performed based on a third-type token, and hybrid encryption is performed using asymmetric encryption public key and symmetric encryption key.

[0047] In the solution provided in this application, the third-party business webpage embedded in the application client does not interact directly with the server. Instead, the authentication is jointly completed by the application server and the third-party business server, which avoids the risk of the third-party business webpage interacting directly with the server and improves authentication security and user operation convenience.

[0048] In one embodiment, triggered by a third-party business webpage embedded in the application client, the application client sends a first request parameter to the application server, specifically including:

[0049] When the native method interface of the application client is called by a third-party business webpage embedded in the application client, the native method interface generates the first request parameter based on the first type of token and the domain name identifier of the third-party business webpage, and calls the third-party user authentication information interface of the application server so that the first request parameter is transmitted to the third-party user authentication information interface; the third-party user authentication information interface is used to perform two-phase authentication, obtain third-party configuration data, and generate the second type of token.

[0050] The application client can have native method interfaces and third-party user authentication information interfaces.

[0051] The native method interface can specify that it is called by JS in UrlScheme. The native method interface can obtain the app user token and the domain identifier (which can be denoted as UrlHost) corresponding to the third-party business page. The native method interface can also call the third-party user authentication information interface.

[0052] The third-party user authentication information interface can obtain the first request parameters sent by the native method interface, parse the first request parameters, obtain the first type of token, and perform one-phase authentication. The third-party user authentication information interface can also parse the first request parameters to obtain the domain identifier corresponding to the third-party business webpage, and check whether there is third-party configuration data corresponding to the third-party business webpage in the third-party authentication configuration data. If it does not exist, it means that the third-party business webpage is not authorized to access it. If it exists, a third-party exclusive app user token (i.e., the second type of token) can be obtained based on the third-party configuration data corresponding to the third-party business webpage. The third-party user authentication information interface can then perform two-phase authentication with the third-party business server based on the second type of token.

[0053] In other words, the third-party user authentication information interface is used for two-phase authentication, obtaining third-party configuration data, and generating a second type of token.

[0054] In the above embodiments, the third-party business webpage communicates with the server (application server and third-party business server) by calling the native method interface of the application client, and the application server and third-party business server jointly complete the authentication, avoiding the risk of the third-party business webpage interacting directly with the server, and improving authentication security and user operation convenience.

[0055] In one embodiment, the application server performs two-phase authentication with a third-party business server based on a second type of token, specifically including:

[0056] The third-party user authentication information interface calls the corresponding user authentication interface on the third-party business server based on the third-party user authentication address in the third-party configuration data, and sends a second request parameter to the user authentication interface. The user authentication interface generates a third request parameter based on the second type of token carried in the second request parameter and the third-party identifier stored in itself, and sends the third request parameter to the third-party dedicated user token authentication interface on the application server. The third-party dedicated user token authentication interface performs two-phase authentication based on the second type of token carried in the third request parameter and the third-party identifier.

[0057] The application server can also have a dedicated third-party user token authentication interface. Third-party business servers can have user authentication and authorization interfaces.

[0058] The third-party user authentication information interface can also call the user authentication and authorization interface of the third-party business server.

[0059] The user authentication and authorization interface can obtain the request parameters (which can be called the second request parameters) of the third-party user authentication information interface, parse the second request parameters to obtain the third-party exclusive app user authentication token (i.e., the second type of token), and use its own stored third-party identifier to call back the third-party exclusive user token authentication interface for two-phase authentication.

[0060] The third-party dedicated user token authentication interface can obtain the request parameters (which can be called the third request parameters) in the callback authentication process of the user authentication and authorization interface. It can parse the third request parameters to obtain the third-party identifier and the third-party dedicated app user authentication token (i.e., the second type of token), verify the existence, consistency and validity of the two, and return the two-stage authentication result and the user identifier (such as the user's mobile phone number).

[0061] Third-party authentication configuration data may include the third-party identifier, the domain name identifier corresponding to the third-party business webpage, and the third-party user authentication address, as shown in Table 1.

[0062] Table 1

[0063]

[0064] Within this data set, data within the same row belongs to a single third-party configuration. The domain identifier corresponding to the third-party business webpage is used to restrict the domain identifier from which the third-party business webpage calls native method interfaces via JSBridge, thereby increasing call security. The third-party identifier is used to generate a third-party exclusive app user token (i.e., a second type of token) and for authentication during interactions between the application server and the third-party business server. The third-party user authentication address is used for interface scheduling, calling different user authentication interfaces based on different third-party business webpages.

[0065] The third-party user authentication information interface can obtain the first request parameters sent by the native method interface, parse the first request parameters, obtain the first type of token, and perform one-phase authentication. After the one-phase authentication is successful, the third-party user authentication information interface can also parse the first request parameters to obtain the domain name identifier corresponding to the third-party business webpage. It then checks whether there is third-party configuration data corresponding to the third-party business webpage in the third-party authentication configuration data. If it does not exist, it means that the third-party business webpage is not authorized to access it. If it does exist, it can obtain the third-party exclusive app user token (i.e., the second type of token) based on the third-party configuration data corresponding to the third-party business webpage, and generate request parameters (which can be called the second request parameters) based on the second type of token.

[0066] After the third-party user authentication information interface finds the third-party configuration data corresponding to the third-party business webpage in the third-party authentication configuration data, it can obtain the third-party user authentication address in the third-party configuration data. The third-party user authentication address corresponds one-to-one with the user authentication interface. Therefore, based on the third-party user authentication address, the corresponding user authentication interface can be called, and a second request parameter can be sent to the user authentication interface.

[0067] The user authentication and authorization interface can parse the second request parameter to obtain the second type of token. It can also retrieve the third-party identifier stored on the third-party business server, generate a third request parameter based on the third-party identifier and the second type of token, and send the third request parameter to the application server's third-party dedicated user token authentication interface.

[0068] The third-party dedicated user token authentication interface parses the third request parameters to obtain the second type of token and third-party identifier sent by the application server (which can be referred to as the received information). The third-party dedicated user token authentication interface can also obtain the third-party identifier stored by the application server itself and the second type of token generated by the application server's third-party user authentication information interface. It uses these two pieces of information as its own stored information and then compares the information stored by itself with the received information to perform two-phase authentication.

[0069] The application server can pre-assign an identifier to each third-party service, which can be called a third-party identifier, and send the third-party identifier to the corresponding third-party service server for storage.

[0070] In this embodiment, corresponding interfaces are set up on the application server and the third-party business server. The relevant process steps of two-phase authentication are implemented through the interfaces. The functions are clearly divided, which can support the interaction between various third-party business web pages and their third-party business servers without additional development, thus reducing technical costs and complexity.

[0071] In one embodiment, after the two-phase authentication is successful, the third-party dedicated user token authentication interface returns the user identifier to the user authentication and authorization interface; the user authentication and authorization interface is used to determine whether there is an associated account in the business system to which the third-party business server belongs based on the user identifier, and if so, to generate a third type of token based on the associated account.

[0072] After the third-party dedicated user token authentication interface confirms that the two-stage identity verification is successful, it can generate a verification result and send the verification result and user identifier (such as the user's mobile phone number) to the user authentication and authorization interface.

[0073] The user authentication and authorization interface can obtain user identifiers (such as user mobile phone numbers) and determine whether an associated account exists in the business system to which the third-party business server belongs. If not, a new account can be registered, and a business system token (which can be called a third-type token) can be generated based on the new account. If an associated account exists, a business system token (which can be called a third-type token) can be generated based on the associated account. After generating the third-type token, the user authentication and authorization interface can send the third-type token and a dynamically generated asymmetric encryption public key back to the third-party user authentication information interface.

[0074] The third-party user authentication information interface returns the third-type token and asymmetric encryption public key to the native method interface. The native method interface then returns the third-type token and asymmetric encryption public key to the third-party business webpage.

[0075] In this embodiment, after the two-phase authentication is passed, the third-party dedicated user token authentication interface feeds back the user identifier to the user authentication and authorization interface to avoid the leakage of information such as the user identifier; moreover, when the user authentication and authorization interface determines that there is an associated account based on the user identifier, it generates a third type of token based on the associated account to ensure the uniqueness of the third type of token.

[0076] In one embodiment, a second type of token is generated based on third-party configuration data corresponding to a third-party business webpage, including:

[0077] Obtain the third-party identifier from the third-party configuration data corresponding to the third-party business webpage; generate a second type of token based on the third-party identifier and the user identifier.

[0078] The third-party user authentication information interface can obtain the first request parameters sent by the native method interface, parse the first request parameters, obtain the first type of token, and perform one-stage authentication. The third-party user authentication information interface can also parse the first request parameters to obtain the domain identifier corresponding to the third-party business webpage, and check whether third-party configuration data corresponding to the third-party business webpage exists in the third-party authentication configuration data. If it does not exist, it means that the third-party business webpage is not authorized to access it. If it exists, it can obtain the third-party exclusive app user token (i.e., the second type of token) based on the third-party configuration data corresponding to the third-party business webpage, and generate request parameters (which can be called the second request parameters) based on the second type of token.

[0079] Specifically, the third-party configuration data includes a third-party identifier, which can be used to generate a third-party exclusive app user token (i.e., the second type of token) based on the third-party identifier and the user identifier (such as the user's mobile phone number).

[0080] In this embodiment, a second type of token is generated based on two unique types of information: third-party identifier and user identifier, which can enhance the uniqueness of the second type of token.

[0081] In one embodiment, hybrid encryption based on an asymmetric encryption public key and a symmetric encryption key includes:

[0082] Based on a symmetric encryption key, the content to be interacted with is encrypted to obtain the encrypted content to be interacted with, which is used as the request body; based on an asymmetric encryption public key, the symmetric encryption key is encrypted and used as the request header; the request body and request header are transmitted to a third-party business server.

[0083] During interaction with a third-party business server, a third-party webpage can authenticate itself using a third-party token. Upon successful authentication, a dynamically generated symmetric encryption key is randomly generated. The third-party webpage can then use this symmetric encryption key to encrypt the content to be interacted with, obtaining the encrypted content as the request body. Alternatively, the third-party webpage can use an asymmetric encryption public key to encrypt the symmetric encryption key and use this as the request header. Based on the request body and header, the third-party webpage can generate a request and send it to the third-party business server.

[0084] After receiving the request, the third-party business server obtains the request header and request body based on the request; it decrypts the request header using the private key corresponding to the asymmetric encryption public key to obtain the symmetric encryption key, and uses the symmetric encryption key to decrypt the request body to obtain the content to be interacted with, and generates the corresponding response content; it then encrypts the response content using the symmetric encryption key to obtain the encrypted response content and sends it back to the third-party business webpage.

[0085] Third-party business web pages decrypt the encrypted response content using a symmetric encryption key to obtain the response content, thereby providing the corresponding services to users.

[0086] In this embodiment, the third-party business webpage and the third-party business server use a hybrid encryption of asymmetric encryption public key and symmetric encryption key to ensure the security of business processing.

[0087] To better understand the above method, the following provides a detailed application example of the application system provided in this application.

[0088] Symmetric encryption is an encryption method in which the same key is used for both encryption and decryption. This means that if you use a symmetric encryption key to encrypt data, you also need to use the same symmetric encryption key to decrypt the data. The main characteristic of symmetric encryption is its fast encryption and decryption speed, making it suitable for encrypting large amounts of data.

[0089] Asymmetric encryption is a encryption method that uses a pair of keys: a public key (also known as an asymmetric encryption public key) and a private key. The public and private keys are different; the public key can be shared publicly, while the private key must be kept secret. The main characteristic of asymmetric encryption is the use of a pair of keys for encryption and decryption. The public key is used to encrypt data or verify signatures, while the private key is used to decrypt data or create signatures.

[0090] When applications need to integrate external content, such as third-party business systems, ensuring secure authentication and subsequent service interactions becomes a critical challenge. Currently, traditional authentication and interaction technologies have some limitations, specifically:

[0091] 1. Interaction Security: Direct interaction between third-party business pages and servers may lead to data leakage during transmission; although data can be protected by implementing encryption in the third-party business pages, the stored keys themselves may also be subject to security risks.

[0092] 2. Authentication experience: Although using a login page from a third-party business page can improve security, this authentication process with multiple redirects may affect the user experience, especially when switching between multiple third-party business systems frequently. Repeated login processes may lead to user churn.

[0093] 3. System integration: When integrating multiple third-party business systems, each additional third-party business system often means that an additional authentication mechanism needs to be integrated, which increases the complexity and cost of technical implementation.

[0094] The solution provided in this application example integrates third-party business pages within the application client, optimizes the identity authentication process, and employs encryption technology to improve the security of data interaction while maintaining a consistent and smooth user experience.

[0095] This application example provides a secure access and interaction solution for third-party business pages embedded in the application client, covering third-party data configuration, application native methods, application server, and collaborative work of third-party business server.

[0096] The solution provided in this application example mainly includes two parts:

[0097] First, the third-party business pages embedded in the application communicate with the application server and the third-party business server by calling the native method interface of the application client in order to obtain the third-type token and the dynamically generated asymmetric encryption public key.

[0098] Secondly, in subsequent interactions between the third-party business page and the third-party business server, a third-type token is used for authentication. The transmitted parameters (i.e., the content to be interacted with) are encrypted using a hybrid dual dynamic key by combining the asymmetric encryption public key and the newly generated symmetric encryption key, ensuring the security of data exchange.

[0099] The solutions provided in this application example include those from application developers and third parties. The following section introduces the functions of the relevant interfaces from both perspectives.

[0100] 1. Application side:

[0101] 1.1 Application Management Terminal: Primarily used to configure third-party authentication data, forming the third-party authentication configuration data as shown in Table 1. The domain identifier corresponding to the third-party business webpage is used to restrict the domain identifier of the third-party business webpage from calling native method interfaces via JSBridge, increasing call security. The third-party identifier is used to generate a third-party exclusive app user token (i.e., the second type of token) and for authentication in the interaction between the application server and the third-party business server. The third-party user authentication address is used for interface scheduling, calling different user authentication interfaces based on different third-party business webpages.

[0102] 1.2 Native Method Interfaces of Application Clients: such as Figure 2 As shown, the native method interface can be specified to be called by the JS of UrlScheme. The native method interface can obtain the first type of token and the domain identifier (which can be denoted as UrlHost) corresponding to the third-party business page. The native method interface can also call the third-party user authentication information interface, as well as receive the third type of token and the asymmetric encryption public key.

[0103] 1.3 Third-party user authentication information interface of the application server: such as Figure 3 As shown, the third-party user authentication information interface can obtain the first request parameters sent by the native method interface, parse the first request parameters, obtain the first type of token, and perform one-stage authentication. The third-party user authentication information interface can also parse the first request parameters to obtain the domain identifier corresponding to the third-party business webpage, and check whether there is third-party configuration data corresponding to the third-party business webpage in the third-party authentication configuration data. If it does not exist, it means that the third-party business webpage is not authorized to access. If it exists, the third-party identifier can be obtained based on the third-party configuration data corresponding to the third-party business webpage. Based on the third-party identifier and the user identifier (such as the user's mobile phone number), the third-party exclusive app user token (i.e., the second type of token) can be obtained. The third-party user authentication information interface can also call the user authentication and authorization interface of the third-party business server, and receive the third type of token and the asymmetric encryption public key.

[0104] 1.4 Third-party dedicated user token authentication interface for application servers: such as Figure 4 As shown, the third-party exclusive user token authentication interface can obtain the request parameters (which can be called the third request parameters) of the user authentication and authorization interface in the callback authentication process. The third request parameters are parsed to obtain the third-party identifier and the third-party exclusive app user authentication token (i.e., the second type of token). The existence, consistency and validity of the two are verified, and the two-stage authentication result and user identifier (such as the user's mobile phone number) are returned.

[0105] 2. Third party:

[0106] 2.1 User authentication and authorization interface of third-party business servers: such as Figure 5 As shown, the user authentication interface can obtain request parameters (referred to as the second request parameters) from the third-party user authentication information interface. It then parses these parameters to obtain a third-party exclusive app user authentication token (i.e., the second type of token), and uses its stored third-party identifier to call back the third-party exclusive user token authentication interface for two-phase authentication. The user authentication interface can also obtain a user identifier (such as a user's mobile phone number) and determine whether an associated account exists in the business system to which the third-party business server belongs. If not, a new account can be registered, and a business system token (referred to as the third type of token) can be generated based on the new account. If an associated account exists, a business system token (referred to as the third type of token) can be generated based on the associated account. After generating the third type of token, the user authentication interface can send the third type of token and a dynamically generated asymmetric encryption public key back to the third-party user authentication information interface.

[0107] 2.2 Third-party business webpage: When the third-party business webpage loads, it calls the native method interface of the application client through JSBridge to obtain the third-type token and asymmetric encryption public key. Subsequently, each time it interacts with the third-party business server, it generates a dynamic symmetric encryption key, uses the symmetric encryption key to encrypt the content to be interacted with to form the request body, and uses the asymmetric encryption public key to encrypt the symmetric encryption key and use it as the request header, forming a hybrid encryption interaction method with dual dynamic keys.

[0108] Among them, the asymmetric encryption algorithm can be the RSA (Rivest-Shamir-Adleman) algorithm, and the corresponding asymmetric encryption public key can be called the RSA public key, and the private key can be called the RSA private key.

[0109] The symmetric encryption algorithm can be the AES algorithm (AES stands for Advanced Encryption Standard), and the corresponding symmetric encryption public key can be called the AES key.

[0110] In the solution provided in this application example, the interaction between the third-party business webpage, the application client, the application server, and the third-party business server is as follows: Figure 6 As shown.

[0111] Third-party business web pages embedded in the application client can call the application client's native method interfaces.

[0112] The native method interface generates the first request parameters based on the first type of token and the domain name identifier of the third-party business webpage, and calls the third-party user authentication information interface of the application server so that the first request parameters are transmitted to the third-party user authentication information interface.

[0113] The third-party user authentication information interface can obtain the first request parameters sent by the native method interface, parse the first request parameters, obtain the first type of token, and perform one-phase authentication. After the one-phase authentication is successful, the third-party user authentication information interface can also parse the first request parameters to obtain the domain name identifier corresponding to the third-party business webpage. It then checks whether there is third-party configuration data corresponding to the third-party business webpage in the third-party authentication configuration data. If it does not exist, it means that the third-party business webpage is not authorized to access it. If it does exist, it can obtain the third-party exclusive app user token (i.e., the second type of token) based on the third-party configuration data corresponding to the third-party business webpage, and generate request parameters (which can be called the second request parameters) based on the second type of token.

[0114] After the third-party user authentication information interface finds the third-party configuration data corresponding to the third-party business webpage in the third-party authentication configuration data, it can obtain the third-party user authentication address in the third-party configuration data. The third-party user authentication address corresponds one-to-one with the user authentication interface. Therefore, based on the third-party user authentication address, the corresponding user authentication interface can be called, and a second request parameter can be sent to the user authentication interface.

[0115] The user authentication and authorization interface can parse the second request parameter to obtain the second type of token. It can also retrieve the third-party identifier stored on the third-party business server, generate a third request parameter based on the third-party identifier and the second type of token, and send the third request parameter to the application server's third-party dedicated user token authentication interface.

[0116] The third-party dedicated user token authentication interface obtains the request parameters (which can be called the third request parameters) in the callback authentication process of the user authentication and authorization interface. The third request parameters are parsed to obtain the third-party identifier and the third-party dedicated app user authentication token (i.e., the second type of token). The existence, consistency and validity of the two are verified to perform two-phase authentication.

[0117] After the third-party dedicated user token authentication interface confirms that the two-stage identity verification is successful, it can generate a verification result and send the verification result and user identifier (such as the user's mobile phone number) to the user authentication and authorization interface.

[0118] The user authentication and authorization interface can obtain user identifiers (such as user mobile phone numbers) and determine whether an associated account exists in the business system to which the third-party business server belongs. If not, a new account can be registered, and a business system token (which can be called a third-type token) can be generated based on the new account. If an associated account exists, a business system token (which can be called a third-type token) can be generated based on the associated account. After generating the third-type token, the user authentication and authorization interface can send the third-type token and a dynamically generated asymmetric encryption public key back to the third-party user authentication information interface.

[0119] The third-party user authentication information interface returns the third-type token and asymmetric encryption public key to the native method interface. The native method interface then returns the third-type token and asymmetric encryption public key to the third-party business webpage.

[0120] During interaction with a third-party business server, a third-party webpage can authenticate itself using a third-party token. Upon successful authentication, a dynamically generated symmetric encryption key is randomly generated. The third-party webpage can then use this symmetric encryption key to encrypt the content to be interacted with, obtaining the encrypted content as the request body. Alternatively, the third-party webpage can use an asymmetric encryption public key to encrypt the symmetric encryption key and use this as the request header. Based on the request body and header, the third-party webpage can generate a request and send it to the third-party business server.

[0121] After receiving the request, the third-party business server obtains the request header and request body based on the request; it decrypts the request header using the private key corresponding to the asymmetric encryption public key to obtain the symmetric encryption key, and uses the symmetric encryption key to decrypt the request body to obtain the content to be interacted with, and generates the corresponding response content; it then encrypts the response content using the symmetric encryption key to obtain the encrypted response content and sends it back to the third-party business webpage.

[0122] Third-party business web pages decrypt the encrypted response content using a symmetric encryption key to obtain the response content, thereby providing the corresponding services to users.

[0123] The specific steps of hybrid encrypted interaction include:

[0124] (1) Preparation stage:

[0125] ① Obtain the asymmetric encryption public key:

[0126] The third-party business page obtains the asymmetric encryption public key through the native method interface of the application client (for each request, the third-party business server regenerates the user-level asymmetric encryption key pair, sends the asymmetric encryption public key to the third-party business page, and stores the corresponding private key in the third-party business server itself). The asymmetric encryption public key is used to encrypt the symmetric encryption key.

[0127] ② Generate a symmetric encryption key:

[0128] Before each request is made, the third-party business page randomly generates a symmetric encryption key (such as an AES key). The symmetric encryption key is used to encrypt the interactive content that is the request body.

[0129] The length of a symmetric encryption key can be 128 bits, 192 bits, or 256 bits, with the specific length chosen based on security requirements and performance balance.

[0130] (2) Encryption process:

[0131] ③ Symmetric encryption request body:

[0132] The third-party business page uses a symmetric encryption key to encrypt the content to be interacted with, forming a request body. For example, it uses the AES encryption algorithm and adopts ECB (Electronic Codebook Mode), CBC (Cipher BlockChaining), or GCM (Galois / Counter Mode).

[0133] ④ Asymmetric encryption symmetric key:

[0134] The third-party business page uses the asymmetric encryption public key obtained from the third-party business server to encrypt the symmetric encryption key, obtaining the encrypted symmetric encryption key. For example, a custom header field, such as X-Encrypted-Key, can be defined, and the encrypted symmetric encryption key can be used as the value of this field.

[0135] ⑤ Generate request headers:

[0136] Place the encrypted symmetric encryption key into the request header (such as the HTTP request header), and optionally add other necessary header information, such as content type, authentication information, etc.

[0137] (3) Send a request:

[0138] ⑥ Send encryption request:

[0139] The third-party business page obtains the request based on the request body and request headers and then initiates the request to the third-party business server.

[0140] For example, an HTTP request looks like this:

[0141] POST / api / test HTTP / 1.1

[0142] Host: test.com

[0143] X-Encrypted-Key: [Encrypted symmetric encryption key]

[0144] Content-Type: application / octet-stream

[0145] Content-Length: [Length of the encrypted request body]

[0146] [Request Body]

[0147] (4) Processing of third-party business servers:

[0148] ⑦ Decrypt the symmetric key:

[0149] After receiving the request, the third-party business server extracts the encrypted symmetric encryption key from the request header, decrypts it using its own stored private key, and recovers the original symmetric encryption key.

[0150] ⑧ Decryption request body:

[0151] The request body is decrypted using the decrypted symmetric encryption key to recover the original content to be interacted with, and business logic is then processed based on this content.

[0152] (5) Response processing:

[0153] ⑨ Response from the third-party business server:

[0154] After the third-party business server processes the request, it generates a response content, encrypts the response content using the symmetric encryption key obtained in this request, and sends the encrypted response content back to the third-party business page.

[0155] ⑩ Front-end decryption response:

[0156] The third-party business page uses the randomly generated symmetric encryption key in this request to decrypt the encrypted response content and obtain the original response content.

[0157] This application example provides a more convenient and secure authentication and interaction mechanism for third-party business pages. Compared to traditional methods such as credential decryption (low security), native app methods (requiring extensive business logic integration and difficult to directly interface with third-party systems), and authorization callbacks (poor user experience), this application example offers the following advantages:

[0158] 1. Security Authentication and Key Management: Authentication is performed using the app's common native method interface. Upon successful authentication, a third-type token and a dynamically generated asymmetric encryption public key are distributed to the third-party business page. The third-party business page generates a new symmetric encryption key before each interface call, eliminating the need to store keys on the third-party business page. This dual-key encryption mechanism enhances the security of data interaction. Furthermore, the interaction between the third-party business page and the server is achieved through the app's common native method interface, with authentication jointly completed by the application server and the third-party business server. This avoids the risk of direct interaction between the third-party business page and the server, improving authentication security and user convenience.

[0159] 2. Key Management Optimization: During the authentication process, the third-party business system distributes dynamically generated asymmetric encryption public keys, while the third-party business page creates a new dynamic symmetric encryption key before each request. This method avoids storing keys on the third-party business page, thereby reducing the risk of key leakage and enhancing the security of interactions between the third-party business server and the third-party business page.

[0160] 3. Efficient Integration and Flexible Application: This application example simplifies the integration process between third-party business pages and third-party business servers, achieving seamless connectivity through a single authentication interface. Integration with multiple third-party business systems can be accomplished through simple system configuration, requiring no additional development and reducing technical costs and complexity. Furthermore, third-party business pages can trigger identity authentication at any time, ensuring availability across all scenarios.

[0161] 4. Simplified System Integration: By configuring third-party authentication data in the application management interface, a mapping relationship is established between the URLHost and the third-party user authentication address. This allows the server to perform authentication scheduling based on the URL (Uniform Resource Locator) information provided by the application client. When connecting to multiple third-party systems, only configuration changes are needed on the application server, eliminating the need for additional development work and effectively reducing integration complexity and costs.

[0162] This application example not only enhances the security of interactions between the application and third parties, but also improves the system's flexibility and scalability through simplified configuration management, providing users with a smoother and more secure experience.

[0163] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0164] In one embodiment, an application client is provided, which is an application client included in the application system described in the above embodiments.

[0165] In one embodiment, an application server is provided, which is an application server included in the application system described in the above embodiments.

[0166] The internal structure diagram of the application server can be as follows: Figure 7 As shown. This application server includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor of this application server provides computing and control capabilities. The memory of this application server includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database of this application server stores the data involved in the aforementioned methods. The I / O interfaces of this application server are used for exchanging information between the processor and external devices. The communication interface of this application server is used for communicating with external terminals via a network connection. When the computer program is executed by the processor, it implements the steps performed by the application server.

[0167] Those skilled in the art will understand that Figure 7 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the application server to which the present application is applied. A specific application server may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0168] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program being executed by a processor of the steps involved in the application system described in the above embodiments.

[0169] In one embodiment, a computer program product is provided having a computer program stored thereon, the computer program being executed by a processor of the steps involved in the application system described in the above embodiments.

[0170] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0171] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0172] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0173] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. An application system, characterized in that, The application system includes an application client and an application server: When triggered by a third-party business webpage embedded in the application client, the application client sends the first request parameters to the application server; The application server performs one-stage authentication based on the first type of token carried in the first request parameter. After the one-stage authentication is successful, it obtains the third-party configuration data corresponding to the third-party business webpage based on the domain name identifier of the third-party business webpage carried in the first request parameter. Based on the third-party identifier and user identifier in the third-party configuration data corresponding to the third-party business webpage, it generates a second type of token. The first type of token belongs to the app user token. The second type of token belongs to the third-party exclusive app user token; The application server performs two-phase authentication with the third-party business server based on the second type of token, including: the application server's third-party user authentication information interface calls the corresponding user authentication interface on the third-party business server according to the third-party user authentication address in the third-party configuration data, and sends a second request parameter to the user authentication interface; the user authentication interface is used to generate a third request parameter based on the second type of token carried in the second request parameter and the third-party identifier stored in itself, and sends the third request parameter to the application server's third-party dedicated user token authentication interface; the third-party dedicated user token authentication interface performs two-phase authentication based on the second type of token carried in the third request parameter and the third-party identifier; After the second-phase authentication is passed, the third-party dedicated user token authentication interface sends a user identifier back to the user authentication and authorization interface. The user authentication and authorization interface is used to determine whether there is an associated account in the business system to which the third-party business server belongs based on the user identifier. If there is, a third type of token is generated based on the associated account. The third type of token is a business system user token. The third-party business server is used to return a third-type token and an asymmetric encryption public key to the third-party business webpage after the two-phase authentication is successful; the third-party business webpage is used to perform authentication based on the third-type token and perform hybrid encryption based on the asymmetric encryption public key and the symmetric encryption key during the interaction with the third-party business server.

2. The system according to claim 1, characterized in that, When triggered by a third-party business webpage embedded in the application client, the application client sends the first request parameters to the application server, which specifically include: When the native method interface of the application client is called by a third-party business webpage embedded in the application client, the native method interface generates a first request parameter based on the first type of token and the domain name identifier of the third-party business webpage, and calls the third-party user authentication information interface of the application server so that the first request parameter is transmitted to the third-party user authentication information interface; the third-party user authentication information interface is used to perform two-phase authentication, obtain third-party configuration data, and generate a second type of token.

3. The system according to claim 1, characterized in that, Hybrid encryption using the aforementioned asymmetric encryption public key and symmetric encryption key includes: Based on a symmetric encryption key, the content to be interacted with is encrypted to obtain the encrypted content to be interacted with and used as the request body. The symmetric encryption key is encrypted using an asymmetric encryption public key and used as a request header; the request body and the request header are transmitted to a third-party business server.

4. The system according to claim 1, characterized in that, Based on the domain name identifier of the third-party business webpage carried in the first request parameter, the third-party configuration data corresponding to the third-party business webpage is obtained, including: Based on the domain name identifier corresponding to the third-party business webpage, query the third-party authentication configuration data to see if there is third-party configuration data corresponding to the third-party business webpage; If it exists, the retrieved third-party configuration data will be used as the third-party configuration data corresponding to the third-party business webpage.

5. The system according to claim 4, characterized in that, The application server is also used for: If the query determines that no third-party configuration data corresponding to the third-party business webpage exists in the third-party authentication configuration data, then it is determined that the third-party business webpage is not authorized for access.

6. The system according to claim 1, characterized in that, The user identifier includes the user's mobile phone number.

7. An application client, characterized in that, The application client is the application client included in the application system as described in any one of claims 1 to 6.

8. An application server, characterized in that, The application server is the application server included in the application system as described in any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps involved in the application system according to any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps involved in the application system according to any one of claims 1 to 6.

Images