Third-party app service provision method and device

Abstract

The embodiments of this specification provide a service provision method and device for a third-party mini-program. In this method, the second-party server generates and saves an application key (AppKey), and sends the AppKey to the first-party client; obtains an open authentication system identifier (OpenID) and generates a session identifier (SessionID); establishes a correspondence between the AppKey, OpenID, and SessionID; receives a business data request from the first-party client; determines whether the SessionID and AppKey carried in the business data request conform to the established correspondence; if so, sends a business resource request carrying the business parameters and the OpenID corresponding to the SessionID carried in the business data request to the third-party server; and sends the response data to the first-party client. The embodiments of this specification can improve the service security of third-party mini-programs.

Description

Technical Field

[0001] One or more embodiments of this specification relate to network communication technology, and more particularly, to a method and apparatus for providing services for third-party applets. Background Art

[0002] With the continuous advancement of software development technology, mini-programs (mini programs) have gradually come into the public eye due to their speed and portability. Mini-programs are applications that can be used without downloading or installing. As third-party software, mini-programs generally run within a host program, which provides the mini-program with a service interface that enables various business functions. For example, there are currently mini-programs for Alipay, 360, and Toutiao.

[0003] When providing services to third-party mini-programs, the following network nodes are usually involved: a third-party client (i.e., an application loaded on a terminal device by a third-party mini-program), a third-party server (i.e., a server providing services to the third-party mini-program), a second-party server, a first-party client (i.e., an application loaded on a terminal device by a host program), and a first-party server (i.e., a server providing services to the host program). The first-party server stores the user's original user ID. To prevent privacy leaks of the original user ID, the second-party server stores the OpenID mapped from the original user ID. When providing services to third-party mini-programs, the original user ID is no longer used. Instead, the OpenID is used as the user's identifier, and the service for the third-party mini-program is completed through processing by the second-party server.

[0004] However, in the prior art, it often happens that the service resources enjoyed by third-party applets are stolen, thereby greatly reducing security. Summary of the Invention

[0005] One or more embodiments of this specification describe a method and apparatus for providing services of a third-party mini-program, which can improve the security of the services of the third-party mini-program.

[0006] According to a first aspect, a method for providing a service for a third-party mini-program is provided, the method comprising:

[0007] Generate and save the application key AppKey;

[0008] Send the AppKey to the first-party client, so that the first-party client can send the AppKey to the third-party client;

[0009] Obtain the open authentication system identifier OpenID and generate a session identifier SessionID;

[0010] Establishing a correspondence between the AppKey, OpenID, and SessionID;

[0011] Receive a service data request from the first-party client, where the service data request carries the SessionID, AppKey, and service parameters;

[0012] Determine whether the SessionID and AppKey carried in the business data request conform to the established correspondence;

[0013] If yes, send a service resource request to the third-party server, where the service resource request carries the service parameters and the OpenID corresponding to the SessionID carried in the service data request;

[0014] The response data returned by the third-party server is sent to the first-party client, so that the first-party client sends the response data to the third-party client.

[0015] According to a second aspect, a method for providing services of a third-party mini-program is provided, the method comprising:

[0016] Receive the AppKey sent by the first-party client;

[0017] Send a third-party login request to the first-party client;

[0018] After receiving a successful login response from the first-party client, sending a service data request to the first-party client, where the service data request carries the AppKey and service parameters;

[0019] Receive response data from the first-party client.

[0020] According to a third aspect, a method for providing a service of a third-party mini-program is provided, the method comprising:

[0021] Receive the AppKey sent by the second-party server;

[0022] Send the AppKey to the third-party client;

[0023] Sending the third-party login request sent by the third-party client to the second-party server;

[0024] Receive the session ID SessionID sent by the second-party server and send a login success response to the third-party client;

[0025] Receive business data requests from third-party clients, which carry AppKey and business parameters;

[0026] Send the business data request carrying SessionID, AppKey and business parameters to the second-party server;

[0027] Receive response data from the second-party server, and send the response data to the third-party client.

[0028] According to a fourth aspect, a service providing device for a third-party applet is provided, the device comprising:

[0029] An application key processing module, configured to generate and save an application key AppKey, and send the AppKey to the first-party client;

[0030] An identification acquisition module configured to obtain an open authentication system identification OpenID and generate a session identification SessionID;

[0031] A corresponding relationship establishing module, configured to establish a corresponding relationship between the AppKey, OpenID and SessionID;

[0032] The service processing module is configured to receive a service data request from a first-party client, the service data request carrying the SessionID, AppKey, and service parameters; and determine whether the SessionID and AppKey carried in the service data request conform to the established correspondence relationship;

[0033] a resource acquisition module configured to send a service resource request to a third-party server after the service processing module determines that the corresponding relationship is met, wherein the service resource request carries the service parameters and an OpenID corresponding to the SessionID carried in the service request;

[0034] The response data processing module is configured to send the response data returned by the third-party server to the first-party client, so that the first-party client can send the response data to the third-party client.

[0035] According to a fifth aspect, a service providing device for a third-party mini-program is provided, the device comprising:

[0036] An application key acquisition module configured to receive the AppKey sent by the first-party client;

[0037] a login request module configured to send a third-party login request to the first-party client;

[0038] a resource request module configured to send a service data request to the first-party client after receiving a successful login response from the first-party client, wherein the service data request carries the AppKey and service parameters;

[0039] The resource data receiving module is configured to receive response data sent by the first-party client.

[0040] According to a sixth aspect, a service providing device for a third-party mini-program is provided, the device comprising:

[0041] An AppKey forwarding module is configured to receive the AppKey sent by the second-party server and send the AppKey to the third-party client;

[0042] The login processing module is configured to send a third-party login request sent by the third-party client to the second-party server; receive a session identifier SessionID sent by the second-party server, and send a login success response to the third-party client;

[0043] The service data request forwarding module is configured to receive a service data request from a third-party client, the service data request carrying the AppKey and service parameters; and send the service data request carrying the SessionID, AppKey and service parameters to the second-party server;

[0044] The response data forwarding module is configured to receive the response data sent by the second-party server and send the response data to the third-party client.

[0045] According to a seventh aspect, a computing device is provided, comprising a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the method described in any embodiment of this specification is implemented.

[0046] In order to prevent the service resources enjoyed by third-party mini-programs from being misappropriated, it is necessary to ensure that the third-party client that initially logs in and connects is the same third-party client that subsequently requests resources. Therefore, in the service provision method and device for third-party mini-programs provided in the embodiments of this specification, in the first stage, i.e., the stage when the third-party client initiates the login, the second-party server will send the AppKey to the third-party client through the first-party client, so that the third-party client that initiates the login obtains the AppKey information. After that, in the second stage, when the third-party client requests resource data, the second-party server obtains the AppKey from the current third-party client from the business data request. If the AppKey obtained by the second-party server in the second stage is the same as the AppKey issued by the second-party server in the first stage, it means that the third-party client that initiated the login in the first stage and the third-party client that obtained the resource data in the second stage are the same client, and resource data leakage will not occur. Therefore, the response data will be sent to the third-party client requesting resource data through the first-party client. If the AppKey obtained by the second-party server in the second stage is different from the AppKey issued by the second-party server in the first stage, it means that the third-party client that initiated the login in the first stage and the third-party client that obtained the resource data in the second stage are not the same client. If the response data is provided, resource data leakage will occur. Therefore, the response data will not be sent to the third-party client requesting resource data through the first-party client. It can be seen that the method of the embodiment of this specification completes a more complete verification process for the identity of the third-party client, greatly improving the security of the service provision process of the third-party applet. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] In order to more clearly illustrate the embodiments of this specification or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0048] Figure 1 It is a schematic diagram of a system architecture applied in one embodiment of this specification.

[0049] Figure 2 This is a flowchart of a service provision method of a third-party applet executed in a second-party server in one embodiment of this specification.

[0050] Figure 3 This is a flowchart of a service provision method for a third-party applet executed in a third-party client in one embodiment of this specification.

[0051] Figure 4 This is a flowchart of a service provision method for a third-party mini-program executed in a first-party client in one embodiment of this specification.

[0052] Figure 5 This is a flowchart of a service provision method for a third-party mini-program executed in cooperation among various parties in one embodiment of this specification.

[0053] Figure 6 It is a structural diagram of a service providing device of a third-party applet set in a second-party server in one embodiment of this specification.

[0054] Figure 7 It is a structural diagram of a service providing device of a third-party applet set in a third-party client in one embodiment of this specification.

[0055] Figure 8 It is a structural diagram of a service providing device of a third-party mini-program set in a first-party client in one embodiment of this specification. DETAILED DESCRIPTION

[0056] The solution provided in this specification is described below in conjunction with the accompanying drawings.

[0057] First, it should be noted that the terms used in the embodiments of the present invention are for the purpose of describing specific embodiments only and are not intended to limit the present invention. As used in the embodiments of the present invention and the appended claims, the singular forms "a," "the," and "the" are intended to include the plural forms, unless the context clearly indicates otherwise.

[0058] It should be understood that the term "and / or" as used herein is merely a description of the relationship between associated objects, indicating that three possible relationships exist. For example, "A and / or B" can represent: A exists alone, A and B exist simultaneously, or B exists alone. Furthermore, the character " / " in this document generally indicates that the associated objects are in an "or" relationship.

[0059] In order to facilitate the understanding of the method provided in this manual, the system architecture involved and applicable to this manual is first described. Figure 1 As shown in , the system architecture mainly includes five types of network nodes: third-party clients (i.e., the application end of the third-party applet loaded on the terminal device), third-party servers (i.e., servers that provide service resources for third-party applet), second-party servers (for security reasons, used to isolate first-party servers from third-party servers), first-party clients (i.e., the application end of the host program loaded on the terminal device), and first-party servers (i.e., servers that provide services for the host program).

[0060] Both third-party clients and first-party clients are installed and run on terminal devices. Terminal devices may include, but are not limited to, smart mobile terminals, smart home devices, network devices, wearable devices, smart medical devices, and PCs (personal computers). Smart mobile devices may include mobile phones, tablets, laptops, PDAs (personal digital assistants), and internet-connected cars. Smart home devices may include smart home appliances such as smart TVs, smart air conditioners, smart water heaters, smart refrigerators, and smart air purifiers. Smart home devices may also include smart door locks, smart sockets, smart lights, and smart cameras. Network devices may include switches, wireless access points, and servers. Wearable devices may include smart watches, smart glasses, smart bracelets, virtual reality devices, augmented reality devices, and mixed reality devices (i.e., devices that support both virtual reality and augmented reality). Smart medical devices may include smart thermometers, smart blood pressure monitors, and smart blood glucose meters.

[0061] It should be understood that Figure 1 The number of various network nodes in the embodiment is only for illustration purposes and any number may be selected and deployed as required.

[0062] The methods of the embodiments of this specification mainly involve the processing of the second-party server, the processing of the third-party client, and the processing of the first-party client, which are described below through different embodiments.

[0063] First, the processing in the second-party server will be described. Figure 2 This is a flow chart of a method for providing a service for a third-party applet executed on a second-party server in one embodiment of this specification. The execution subject of this method is a service providing device for a third-party applet. This device may be located on the second-party server. It is understood that this method may also be executed by any device, equipment, platform, or device cluster with computing and processing capabilities. Figure 2 , the method comprising:

[0064] Step 201: The second-party server generates and saves an application key (AppKey);

[0065] Step 203: The second-party server sends the AppKey to the first-party client, so that the first-party client sends the AppKey to the third-party client;

[0066] Step 205: The second-party server obtains the open authentication system identifier (OpenID) and generates a session identifier (SessionID);

[0067] Step 207: The second-party server establishes a correspondence between the AppKey, OpenID, and SessionID;

[0068] Step 209: The second-party server receives the service data request sent by the first-party client, where the service data request carries the SessionID, AppKey, and service parameters.

[0069] Step 211: The second-party server determines whether the SessionID and AppKey carried in the service data request conform to the established correspondence; if so, execute step 215; otherwise, execute step 213.

[0070] Step 213: Refuse to provide services to the current third-party client, and end the current process.

[0071] Step 215: The second-party server sends a service resource request to the third-party server. The service resource request carries the service parameters and the OpenID corresponding to the SessionID carried in the service data request.

[0072] Step 217: The second-party server sends the response data returned by the third-party server to the first-party client, so that the first-party client sends the response data to the third-party client.

[0073] above Figure 2 The process shown in the figure describes the processing in the second party server. Figure 2 The processing of the second-party server shown, the third-party client and the first-party client also need to cooperate to complete the corresponding processing.

[0074] The following description corresponds to Figure 2 The processing of the second-party server is shown, and the corresponding processing is performed in the third-party client. Figure 3 This is a flowchart of a service provision method for a third-party applet executed in a third-party client in one embodiment of this specification. The execution subject of this method is a service provision device for a third-party applet. This device can be located in the third-party client. It is understood that this method can also be executed by any device, equipment, platform, or device cluster with computing and processing capabilities. Figure 3 , the method comprising:

[0075] Step 301: The third-party client receives the AppKey sent by the first-party client;

[0076] Step 303: The third-party client sends a third-party login request to the first-party client;

[0077] Step 305: After receiving the successful login response from the first-party client, the third-party client sends a service data request to the first-party client. The service data request carries the AppKey and service parameters.

[0078] Step 307: The third-party client receives the response data sent by the first-party client.

[0079] The following description corresponds to Figure 2 The processing of the second-party server is shown, and the corresponding processing is performed in the first-party client. Figure 4 This is a flow chart of a method for providing a service for a third-party applet executed in a first-party client in one embodiment of this specification. The execution subject of this method is a service providing device for a third-party applet. This device can be located in the first-party client. It is understood that this method can also be executed by any device, equipment, platform, or device cluster with computing and processing capabilities. Figure 4 , the method comprising:

[0080] Step 401: The first-party client receives the AppKey sent by the second-party server;

[0081] Step 403: The first-party client sends the AppKey to the third-party client;

[0082] Step 405: The first-party client sends the third-party login request sent by the third-party client to the second-party server;

[0083] Step 407: The first-party client receives the session identifier SessionID sent by the second-party server and sends a login success response to the third-party client;

[0084] Step 409: The first-party client receives the service data request sent by the third-party client, where the service data request carries the AppKey and service parameters.

[0085] Step 411: The first-party client sends a service data request carrying SessionID, AppKey, and service parameters to the second-party server;

[0086] Step 413: The first-party client receives the response data sent by the second-party server, and sends the response data to the third-party client.

[0087] As mentioned above, in the prior art, it often happens that the service resources enjoyed by third-party applets are misappropriated, thus greatly reducing security. For example, on a host program platform, there are multiple third-party applet clients (i.e., multiple third-party clients), and these multiple third-party applet clients all obtain the service resources they need through the same host program (i.e., the same first-party client). Therefore, it is very likely that third-party client A obtains the SessionID of a session that originally belonged to third-party client B, thereby allowing third-party client A to obtain the service resources that should have been provided to third-party client B. For another example, an attacker can also obtain the service resources that should have been provided to third-party client B by launching an attack. Therefore, the security of the prior art needs to be improved.

[0088] In the embodiment of this specification, in order to avoid the situation where the service resources enjoyed by the third-party applet are misappropriated, it is necessary to ensure that the third-party client that logs in and connects initially and the third-party client that subsequently requests resources are the same client. Figure 2 、 Figure 3 and Figure 4 In the process shown in the embodiment of the present specification, in the first phase, i.e., when the third-party client initiates login, the second-party server sends the AppKey to the third-party client via the first-party client, so that the third-party client that initiated login obtains the AppKey information. Thereafter, in the second phase, i.e., when the third-party client requests resource data, the second-party server obtains the AppKey from the current third-party client in the service data request. If the AppKey obtained by the second-party server in the second phase is the same as the AppKey issued by the second-party server in the first phase, it indicates that the third-party client that initiated login in the first phase and the third-party client that obtained resource data in the second phase are the same client, and resource data leakage will not occur. Therefore, the response data will be sent to the third-party client requesting resource data via the first-party client. If the AppKey obtained by the second-party server in the second phase is different from the AppKey issued by the second-party server in the first phase, it indicates that the third-party client that initiated login in the first phase and the third-party client that obtained resource data in the second phase are different clients. If the response data is provided, resource data leakage will occur. Therefore, the response data will not be sent to the third-party client requesting resource data via the first-party client. It can be seen that the method of the embodiment of this specification completes a more complete verification process for the identity of the third-party client, greatly improving the security of the service provision process of the third-party mini-program.

[0089] In the above Figure 2 、 Figure 3 and Figure 4In the process shown, the third-party client obtains the AppKey issued by the second-party server in the first stage. Specifically,

[0090] In the third-party client, the above step before step 301 includes: in the first stage of the third-party client requesting to log in, the third-party client sends the initialization key pre-agreed with the second-party server to the first-party client;

[0091] Accordingly, in the first-party client, the above step before step 401 further includes: the first-party client sending the initialization key sent by the third-party client to the second-party server;

[0092] Accordingly, in the second-party server, the above step 201 further includes: the second-party server receives the initialization key pre-agreed with the third-party client and forwarded by the first-party client; verifies the initialization key; if the verification is successful, executes the generation and storage of AppKey in step 201.

[0093] In the above Figure 2 、 Figure 3 and Figure 4 In the process shown, the SessionID can be further encrypted, so that the encrypted SessionID is transmitted among the parties, further preventing other parties from stealing the SessionID of the third-party client in the session and thus stealing the service resources of the third-party client in the session. Specifically,

[0094] In the second-party server, after generating the SessionID in step 205 and before receiving the service data request sent by the first-party client in step 209, the second-party server further includes: encrypting the SessionID using the AppKey and sending the encrypted SessionID to the first-party client;

[0095] Accordingly, the first-party client sends the encrypted SessionID to the third-party client;

[0096] Correspondingly, the third-party client uses the AppKey to decrypt the SessionID and sends the SessionID to the first-party client, which caches the SessionID.

[0097] In the embodiments of this specification, it is also possible to further implement encrypted transmission of service parameters to further improve security. Specific implementations include:

[0098] In the second-party server, after generating the SessionID in step 205 and before receiving the service data request sent by the first-party client in step 209, the process further includes: generating a session key, the session key having the same lifecycle as the SessionID; sending the session key and the SessionID to the first-party client;

[0099] Afterwards, the first-party client receives the session key sent by the second-party server and saves the session key. In step 411, before sending the service data request to the second-party server, the first-party client further encrypts the service parameters in the service data request sent to the second-party server using the saved session key. In other words, the service data request sent by the first-party client to the second-party server carries the service parameters encrypted using the session key.

[0100] Afterwards, in the second-party server, after determining in step 211 that the SessionID and AppKey carried in the business data request meet the established correspondence, the second-party server uses the session key to decrypt the encrypted business parameters in the business data request before sending the business resource request to the third-party server to obtain the business parameters, so that the business parameters can be carried in the business resource request in step 215.

[0101] Below through Figure 1 The cooperation of all parties in the system is used to illustrate the flow chart of the service provision method of the third-party applet in the embodiment of this specification. Figure 5 , the method comprising:

[0102] Step 501: When a business service corresponding to a third-party client is needed, the third-party client sends an initialization key agreed in advance with the second-party server to the first-party client.

[0103] Step 503: The first-party client sends the initialization key to the second-party server.

[0104] Step 505: The second-party server verifies the received initialization key and generates an AppKey after successful verification.

[0105] Step 507: The second-party server sends the AppKey to the first-party client, and the first-party client sends the AppKey to the third-party client.

[0106] Step 509: The third-party client sends a third-party login request to the first-party client. The third-party login request is used to request to establish a session connection for the third-party client, and the third-party login request carries the AppKey and the identity information of the third-party client.

[0107] For example, a third-party client corresponds to a third-party mini-program on the Alipay platform that processes user electricity bills. A first-party client corresponds to the host program on the Alipay platform. When a user needs to check their electricity bill balance, they can click on the third-party mini-program, which then sends a third-party login request to the first-party client through the corresponding third-party client.

[0108] Step 511: The first-party client sends the received third-party login request to the second-party server.

[0109] Step 513: The second-party server obtains the AppKey from the third-party login request and verifies the AppKey, that is, determines whether the AppKey carried in the third-party login request is the same as the previously generated AppKey. If they are the same, execute step 515; otherwise, refuse to provide services to the current third-party client and end the current process.

[0110] Step 515: The second-party server sends the identity information of the third-party client and a session update request in a one-party login state to the first-party server.

[0111] Step 517: The first-party server returns a token corresponding to this session to the second-party server, and saves the consistency relationship between the token and the received login state.

[0112] Step 519: The second-party server uses the token and the login status of one party to request OpenID from the first-party server.

[0113] Step 521: The first-party server verifies whether the token used when requesting the OpenID and the login state of one party have the above consistency relationship. If so, it returns the OpenID corresponding to this session to the second-party server.

[0114] Step 523: The second-party server generates a SessionID and a session key based on the received OpenID, encrypts the SessionID and the session key using the AppKey, and establishes a correspondence between the obtained AppKey, OpenID, and SessionID.

[0115] Step 525: The second-party server sends the encrypted SessionID and session key to the first-party client.

[0116] Step 527: The first-party client sends the encrypted SessionID and session key to the third-party client.

[0117] Step 529: The third-party client uses the AppKey to decrypt the encrypted SessionID and session key to obtain the SessionID and session key.

[0118] Step 531: The third-party client sends the decrypted SessionID and session key to the first-party client.

[0119] Step 533: The first-party client saves the SessionID and session key, and sends a login success response to the third-party client.

[0120] Step 535: After receiving the successful login response from the first-party client, the third-party client sends a service data request to the first-party client. The service data request carries the AppKey and service parameters.

[0121] Step 537: The first-party client encrypts the service parameters using the session key, and sends a service data request carrying the SessionID, AppKey, and the encrypted service parameters to the second-party server.

[0122] Step 539: The second-party server verifies the AppKey, that is, determines whether the SessionID and AppKey carried in the business data request conform to the established correspondence. If so, execute step 541; otherwise, refuse to provide services to the current third-party client.

[0123] Step 541: The second-party server decrypts the encrypted service parameters using the session key, and then sends a service resource request to the third-party server. The service resource request carries the service parameters and the OpenID corresponding to the SessionID in the service data request.

[0124] Step 543: The second-party server sends the response data returned by the third-party server to the first-party client.

[0125] Step 545: The first-party client sends the response data to the third-party client.

[0126] In one embodiment of the present specification, a service providing device for a third-party applet is provided, and the device is set in a second-party server. Figure 6 , the device comprises:

[0127] An application key processing module 601 is configured to generate and save an application key AppKey, and send the AppKey to the first-party client;

[0128] The identification acquisition module 602 is configured to obtain the open authentication system identification OpenID and generate a session identification SessionID;

[0129] A correspondence establishing module 603 is configured to establish a correspondence between the AppKey, OpenID and SessionID;

[0130] The service processing module 604 is configured to receive a service data request from a first-party client, the service data request carrying the SessionID, AppKey, and service parameters; and determine whether the SessionID and AppKey carried in the service data request conform to the established correspondence relationship.

[0131] The resource acquisition module 605 is configured to send a service resource request to the third-party server after the service processing module determines that the corresponding relationship is met, where the service resource request carries the service parameters and the OpenID corresponding to the SessionID carried in the service request;

[0132] The response data processing module 606 is configured to send the response data returned by the third-party server to the first-party client, so that the first-party client can send the response data to the third-party client.

[0133] exist Figure 6 In one embodiment of the device shown in this specification, the application key processing module 601 is further configured to: before generating and saving the application key AppKey, receive the initialization key pre-agreed with the third-party client forwarded by the first-party client; verify the initialization key; if the verification is successful, execute the generation and saving of AppKey.

[0134] exist Figure 6 In one embodiment of the device shown in this specification, the above-mentioned business processing module 604 is further configured to: after generating the SessionID and before receiving the business data request sent by the first-party client, further use the AppKey to encrypt the SessionID, and send the encrypted SessionID to the first-party client, so that the first-party client interacts with the third-party client so that the first-party client obtains the decrypted SessionID.

[0135] exist Figure 6In one embodiment of the device shown in this specification, the above-mentioned business processing module 604 is further configured to: after generating the SessionID and before receiving the business data request sent by the first-party client, further generate a session key, and the session key has the same life cycle as the SessionID; send the session key and the SessionID to the first-party client; in the business data request sent by the first-party client, the business parameters are encrypted by the first-party client using the session key; after determining that the SessionID and AppKey carried in the business data request meet the established correspondence, and before sending the business resource request to the third-party server, further use the session key to decrypt the encrypted business parameters in the business data request to obtain the business parameters.

[0136] In one embodiment of the present specification, a service providing device for a third-party applet is provided, and the device is set in a third-party client. Figure 7 , the device comprises:

[0137] Application key acquisition module 701, configured to receive the AppKey sent by the first-party client;

[0138] A login request module 702 is configured to send a third-party login request to the first-party client;

[0139] The resource request module 703 is configured to send a service data request to the first-party client after receiving a successful login response from the first-party client, wherein the service data request carries the AppKey and service parameters;

[0140] The resource data receiving module 704 is configured to receive response data sent by the first-party client.

[0141] exist Figure 7 In the embodiment of the apparatus shown in this specification, the application key acquisition module 701 is further configured to execute: before receiving the AppKey sent by the first-party client, send the initialization key pre-agreed with the second-party server to the first-party client.

[0142] exist Figure 7 In the embodiment of the device shown in this specification, the login request module 702 is further configured to execute: receiving the encrypted SessionID and session key sent by the first-party client; using the AppKey to decrypt the encrypted SessionID and session key to obtain the SessionID and session key; and sending the decrypted SessionID and session key to the first-party client.

[0143] In one embodiment of the present specification, a service providing device for a third-party applet is provided, and the device is set in a first-party client. Figure 8 , the device comprises:

[0144] AppKey forwarding module 801 is configured to receive the AppKey sent by the second-party server and send the AppKey to the third-party client;

[0145] The login processing module 802 is configured to send the third-party login request sent by the third-party client to the second-party server; receive the session identifier SessionID sent by the second-party server, and send a login success response to the third-party client;

[0146] The service data request forwarding module 803 is configured to receive a service data request from a third-party client, the service data request carrying the AppKey and service parameters; and send the service data request carrying the SessionID, AppKey and service parameters to the second-party server;

[0147] The response data forwarding module 804 is configured to receive the response data sent by the second-party server and send the response data to the third-party client.

[0148] exist Figure 8 In the embodiment of the apparatus shown in this specification, the AppKey forwarding module 801 is further configured to execute: before receiving the AppKey sent by the second-party server, send the initialization key sent by the third-party client to the second-party server.

[0149] exist Figure 8 In the embodiment of the device shown in this specification, the SessionID sent by the second-party server received by the login processing module 802 is an encrypted SessionID, which is further sent to the third-party client; and the decrypted SessionID is received from the third-party client.

[0150] exist Figure 8 In the embodiment of the apparatus of this specification shown, the login processing module 802 receives the encrypted SessionID and session key sent by the second-party server, sends the encrypted SessionID and session key to the third-party client; receives the decrypted SessionID and session key sent by the third-party client;

[0151] The service data request sent by the service data request forwarding module 803 to the second-party server carries the service parameters encrypted using the session key.

[0152] One embodiment of the present specification provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed in a computer, the computer is caused to execute the method in any one of the embodiments of the present specification.

[0153] An embodiment of the present specification provides a computing device including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the method of any embodiment of the present specification is implemented.

[0154] It should be understood that the structures illustrated in the embodiments of this specification do not constitute specific limitations on the devices of the embodiments of this specification. In other embodiments of the specification, the above-mentioned devices may include more or fewer components than shown in the figure, or combine or separate certain components, or arrange the components differently. The components shown in the figure may be implemented in hardware, software, or a combination of software and hardware.

[0155] The various embodiments in this specification are described in a progressive manner. Similar parts between the various embodiments can be referred to in conjunction with each other. Each embodiment focuses on the differences from other embodiments. In particular, the device embodiments are generally similar to the method embodiments, so the description is relatively simple. For relevant parts, refer to the description of the method embodiments.

[0156] Those skilled in the art will appreciate that in one or more of the above examples, the functions described in the present invention may be implemented using hardware, software, widgets, or any combination thereof. When implemented using software, these functions may be stored in a computer-readable medium or transmitted as one or more instructions or codes on a computer-readable medium.

[0157] The specific implementation methods described above further illustrate the objectives, technical solutions and beneficial effects of the present invention in detail. It should be understood that the above description is only a specific implementation method of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent replacements, improvements, etc. made on the basis of the technical solution of the present invention should be included in the scope of protection of the present invention.

Claims

1. The service provision method of the third-party mini program is applied to the second-party server; The method includes: Generate and save the application key AppKey; Send the AppKey to the first-party client, so that the first-party client can send the AppKey to the third-party client; Obtain the open authentication system identifier OpenID and generate a session identifier SessionID; Establishing a correspondence between the AppKey, OpenID, and SessionID; Receive a service data request from the first-party client, where the service data request carries the SessionID, AppKey, and service parameters; Determine whether the SessionID and AppKey carried in the business data request conform to the established correspondence; If yes, send a service resource request to the third-party server, where the service resource request carries the service parameters and the OpenID corresponding to the SessionID carried in the service data request; The response data returned by the third-party server is sent to the first-party client, so that the first-party client sends the response data to the third-party client.

2. The method according to claim 1, wherein Before generating and saving the application key AppKey, the method further includes: Receive the initialization key pre-agreed with the third-party client and forwarded by the first-party client; Verifying the initialization key; If the verification is successful, the AppKey is generated and saved.

3. The method according to claim 1, wherein After generating the SessionID and before receiving the service data request from the first-party client, the method further includes: The SessionID is encrypted using the AppKey, and the encrypted SessionID is sent to the first-party client, so that the first-party client interacts with the third-party client and obtains the decrypted SessionID.

4. The method according to claim 1, wherein After generating the SessionID and before receiving the service data request from the first-party client, the method further includes: generating a session key, the session key having the same life cycle as the SessionID; and sending the session key and the SessionID to the first-party client; In the service data request sent by the first-party client, the service parameter is encrypted by the first-party client using a session key; After determining that the SessionID and AppKey carried in the business data request conform to the established correspondence, and before sending the business resource request to the third-party server, it further includes: using the session key to decrypt the encrypted business parameters in the business data request to obtain the business parameters.

5. The service provision method of the third-party mini program is applied to the third-party client; The method includes: Receive the AppKey sent by the first-party client; Send a third-party login request to the first-party client; After receiving a successful login response from the first-party client, the second-party server sends a service data request to the first-party client, where the service data request carries the AppKey and service parameters, so that the second-party server determines whether the SessionID and the AppKey carried in the service data request conform to a pre-established correspondence based on the service data request from the first-party client; After the second-party server determines that the SessionID and AppKey carried in the business data request conform to the pre-established correspondence, it receives the response data sent by the first-party client.

6. The method according to claim 5, wherein: Before the AppKey sent by the first-party client is received, the third-party client sends an initialization key pre-agreed with the second-party server to the first-party client.

7. The method according to claim 5, wherein: After sending the third-party login request to the first-party client and before sending the service data request to the first-party client, further comprising: receiving the encrypted SessionID and session key sent by the first-party client; decrypting the encrypted SessionID and session key using the AppKey to obtain the SessionID and session key; Correspondingly, after obtaining the SessionID and the session key, the method further includes: sending the decrypted SessionID and session key to the first-party client.

8. The service provision method of the third-party mini program is applied to the first-party client; The method includes: Receive the AppKey sent by the second-party server; Send the AppKey to the third-party client; Send the third-party login request sent by the third-party client to the second-party server; Receive the session ID SessionID sent by the second-party server and send a login success response to the third-party client; Receive business data requests from third-party clients, which carry AppKey and business parameters; Sending a service data request carrying SessionID, AppKey, and service parameters to the second-party server, so that the second-party server can determine whether the SessionID and AppKey carried in the service data request conform to the pre-established correspondence; After the second-party server determines that the SessionID and AppKey carried in the business data request conform to the pre-established correspondence, it receives response data from the second-party server and sends the response data to the third-party client.

9. The method according to claim 8, wherein Before receiving the AppKey sent by the second-party server, the method further includes: the first-party client sending the initialization key sent by the third-party client to the second-party server.

10. The method according to claim 8, wherein The SessionID sent by the second-party server is an encrypted SessionID, and the encrypted SessionID is sent to the third-party client; After sending the encrypted SessionID to the third-party client and before receiving the service data request sent by the third-party client, the method further includes: receiving the decrypted SessionID sent by the third-party client.

11. The method according to claim 8, wherein The receiving of the session identifier SessionID sent by the second-party server includes: the first-party client receiving the encrypted SessionID and session key sent by the second-party server, and sending the encrypted SessionID and session key to the third-party client; After sending the encrypted SessionID and session key to the third-party client and before receiving the service data request from the third-party client, the method further includes: the first-party client receiving the decrypted SessionID and session key sent by the third-party client; Then, the service data request sent by the first-party client to the second-party server carries the service parameters encrypted using the session key.

12. A third-party applet service provider, used on a second-party server; The device includes: An application key processing module, configured to generate and save an application key AppKey, and send the AppKey to the first-party client; An identification acquisition module configured to obtain an open authentication system identification OpenID and generate a session identification SessionID; A corresponding relationship establishing module, configured to establish a corresponding relationship between the AppKey, OpenID and SessionID; The service processing module is configured to receive a service data request from a first-party client, the service data request carrying the SessionID, AppKey, and service parameters; and determine whether the SessionID and AppKey carried in the service data request conform to the established correspondence relationship; a resource acquisition module configured to send a service resource request to a third-party server after the service processing module determines that the corresponding relationship is met, wherein the service resource request carries the service parameters and an OpenID corresponding to the SessionID carried in the service request; The response data processing module is configured to send the response data returned by the third-party server to the first-party client, so that the first-party client can send the response data to the third-party client.

13. A service provider for third-party applets, used on third-party clients; The device includes: An application key acquisition module configured to receive the AppKey sent by the first-party client; a login request module configured to send a third-party login request to the first-party client; a resource request module configured to, after receiving a successful login response from the first-party client, send a service data request to the first-party client, the service data request carrying the AppKey and service parameters, so that the second-party server determines, based on the service data request from the first-party client, whether the SessionID and the AppKey carried in the service data request conform to a pre-established correspondence; The resource data receiving module is configured to receive response data sent by the first-party client after the second-party server determines that the SessionID and AppKey carried in the business data request meet the pre-established correspondence.

14. A third-party mini-program service provider, used in first-party clients; The device includes: An AppKey forwarding module is configured to receive the AppKey sent by the second-party server and send the AppKey to the third-party client; The login processing module is configured to send a third-party login request sent by the third-party client to the second-party server; receive a session identifier SessionID sent by the second-party server, and send a login success response to the third-party client; The service data request forwarding module is configured to receive a service data request from a third-party client, the service data request carrying an AppKey and service parameters; and send the service data request carrying a SessionID, AppKey, and service parameters to a second-party server, so that the second-party server determines whether the SessionID and AppKey carried in the service data request conform to a pre-established correspondence. The response data forwarding module is configured to receive the response data sent by the second-party server after the second-party server determines that the SessionID and AppKey carried in the business data request meet the pre-established correspondence, and send the response data to the third-party client.

15. A computing device comprising a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the method according to any one of claims 1 to 11 is implemented.

Images