Data processing method and related device

Abstract

The embodiment of the invention provides a data processing method and a related device, and relates to the technical field of communication. The method comprises the following steps: when a service provider registers a service in an authorization center, a public key of the service provider can be sent to the authorization center, and a service requester can acquire the public key of the service provider from the authorization center in advance. When a service requester sends a service request message to a service provider, a public key of the service requester can be transmitted in the message. Thus, the number of times of interaction between the service requester and the service provider is reduced, the cost of bandwidth traffic is reduced, and the processing delay during service interaction between services is also reduced.

Description

Technical Field

[0001] The present application relates to the field of communication technology, and in particular to a data processing method and related devices. Background Art

[0002] Applications in electronic devices can provide users with various services, such as game services, cloud space services, payment services, etc. Among them, when providing services, applications need corresponding servers for business support, so as to realize the processing of application background business data and the interaction between different services.

[0003] However, when business interactions are carried out between the service requester and the service provider, more bandwidth processes are consumed and the business request latency is high. Summary of the invention

[0004] The data processing method and related device provided by the embodiment of the present application can send the public key of the service provider to the authorization center when the service provider registers the service, and the service requester can obtain the public key of the service provider from the authorization center in advance. When the service requester sends a service request message to the service provider, the public key of the service requester can be transmitted in the message. In this way, the public key exchange of the service provider can be completed in advance by the authorization center, and the service requester can complete the public key exchange of the service requester when sending a message to the service provider, thereby reducing the number of interactions between the service requester and the service provider.

[0005] In a first aspect, the data processing method provided by the embodiment of the present application includes:

[0006] Obtaining a first public key from a second service, wherein the first public key is sent by the first service to the second service; sending a first request to the first service; receiving a response to the first request from the first service; and processing the response according to the first public key. In this way, the number of interactions between the service requester and the service provider can be reduced, thereby reducing the cost of bandwidth traffic and the processing delay when the services interact with each other.

[0007] In a possible implementation, before sending the first request to the first service, the method further includes: generating a second public key; sending the first request to the first service includes: sending the first request including the second public key to the first service. In this way, the number of interactions between the service requester and the service provider can be reduced, thereby reducing the processing delay when the service interacts between services.

[0008] In a possible implementation, obtaining the first public key from the second service includes: sending a third request to the second service; receiving a response to the third request from the second service, wherein the response to the third request includes the first public key. In this way, when the service requester obtains the token from the authorization center, the ECC public key of the service provider can be obtained at the same time. In this way, the number of interactions between the service requester and the service provider can be reduced.

[0009] In a possible implementation, before processing the response according to the first public key, the process further includes: generating a second private key; generating a first key based on the second private key and the first public key; and processing the response according to the first public key, including: decrypting the response according to the first key. In this way, the service requester and the service provider encrypt or decrypt the transmitted message based on their locally generated keys, without the need to transfer keys between services, thereby improving the security of service interaction.

[0010] In a possible implementation, the response to the third request also includes the first token, and sending the first request to the first service includes: sending the first request including the first token to the first service. In this way, the service requester sends the first request including the first token, and the service provider can verify the first token, thereby improving the security of the interaction between services and making the identity and access rights of the service requester controllable.

[0011] In a second aspect, the data processing method provided by the embodiment of the present application includes:

[0012] A first request from a third service is received, wherein the first request includes a second public key; and the first request is processed according to the second public key. In this way, the service provider can obtain the ECC public key of the service requester from the request. In this way, the number of interactions between the service requester and the service provider can be reduced, thereby reducing the cost of bandwidth traffic and the processing delay when the service interacts between services.

[0013] In a possible implementation, before processing the first request according to the second public key, the process further includes: generating a first private key; generating a first key based on the first private key and the second public key; and processing the first request according to the second public key, including: decrypting the first request according to the first key. In this way, during the interaction between the service provider and service A, the first key can be used to encrypt the transmitted data to protect the security of the data during transmission.

[0014] In a possible implementation, the first request also includes the first token, and before receiving the first request from the third service, the first token public key is obtained from the second service; after receiving the first request from the third service, the first token is verified using the first token public key. In this way, the concurrent processing capability and efficiency of the service provider are improved, and the processing delay when the service requester and the service provider interact with each other is shortened.

[0015] In a possible implementation, the first token is a token corresponding to the first interface, and the first token is verified using the first token public key, including: generating a first token key of the first interface based on the first token public key and the interface ID of the first interface; and verifying the first token using the first token key. In this way, the uniqueness of the token and the key at the interface level can be achieved, thereby improving the security of accessing the service interface.

[0016] In a possible implementation, obtaining the first token public key from the second service includes: obtaining the first token public key from the second service when sending a registration request to the second service. In this way, the service provider can verify the first token of the service requester locally, thereby realizing localized verification of the token and reducing the delay of business processing.

[0017] In a third aspect, an embodiment of the present application provides a data processing method, which is applied to a service interaction system, wherein the service interaction system includes a first service, a second service, and a third service, and the method includes:

[0018] The first service generates a first private key and a first public key; the first service sends the first public key to the second service; the third service obtains the first public key from the second service; the third service generates a second private key and a second public key, and generates a first key based on the second private key and the first public key; the third service sends a first request to the first service, and the first request includes the second public key and data encrypted by the first key; the first service generates the first key based on the first private key and the second public key, and decrypts the encrypted data in the first request; the first service returns a response to the first request to the third service, and the response includes data encrypted by the first key; the third service decrypts the encrypted data in the response based on the first key. In this way, the number of interactions between the service requester and the service provider is reduced, the cost of bandwidth traffic is reduced, and the processing delay during business interaction between services is also reduced.

[0019] In a possible implementation, before the first service sends the first public key to the second service, it also includes: the first service generates a third private key and a third public key; the first service sends a second request to the second service, the second request includes the third public key; the second service returns a response to the second request to the first service, the response to the second request includes the fourth public key of the second service; the first service generates a second key based on the third private key and the fourth public key; the first service sends the first public key to the second service, including: the first service sends the first public key encrypted by the second key to the second service. In this way, during the interaction between the service provider and the STS service, the second key can be used to encrypt the transmitted data to protect the security of the data during transmission.

[0020] In a possible implementation, after the first service sends the first public key to the second service, the process further includes: the second service saves the mapping relationship between the first public key and the identifier of the third service; the third service obtains the first public key from the second service, including: the third service obtains the first public key from the mapping relationship of the second service. In this way, the service requester and the public key generated by the service provider for the service requester can be matched through the mapping relationship, the service requester can obtain the accurate public key, and perform business interaction with the service provider based on the public key.

[0021] In a possible implementation, the first request also includes the first token. After the first service sends the first public key to the second service, the first service also includes: the first service obtains the first token public key from the second service; the third service obtains the first public key from the second service, including: the third service obtains the first public key and the first token from the second service; after the third service sends the first request to the first service, the first service also includes: the first service verifies the first token using the first token public key. In this way, the service provider does not need to initiate additional requests to the STS service to verify the token, which improves the concurrent processing capability and efficiency of the service provider and shortens the processing delay when the service requester interacts with the service provider.

[0022] In a possible implementation, the first token is a token corresponding to the first interface of the first service, and the first service verifies the first token using the first token public key, including: the first service generates a first token key of the first interface based on the first token public key and the interface ID of the first interface; the first service verifies the first token using the first token key. In this way, the uniqueness of the token and the key at the interface level can be achieved, thereby improving the security of accessing the service interface.

[0023] In a possible implementation, verifying the first token includes any one or more of the following: verifying the validity period of the first token, determining whether the first token is authorized to the first interface, verifying the signature of the first token, verifying the legitimacy of the first token, verifying the issuer of the first token, or verifying the customized parameters of the first token. In this way, the service provider verifies the first token, which can improve the security of the interaction between services and make the identity and access rights of the service requester controllable.

[0024] In a possible implementation, the first service obtains the first token public key from the second service, including: when the first service sends a registration request to the second service, the first service obtains the first token public key from the second service. In this way, the service provider can verify the first token of the service requester locally, realize the localized verification of the token, and reduce the delay of business processing.

[0025] In a possible implementation, the third service obtains the first public key and the first token from the second service, including: when the third service sends a token application request to the second service, the third service obtains the first public key and the first token from the second service. In this way, the third service obtains the first token from the second service, and the first token can be updated to the local of the third service in a timely manner, thereby facilitating business interaction with the third service through the first token.

[0026] In one possible implementation, the second service is configured with the authorization information of the first service, and the authorization information includes one or more of the following: authentication level, validity period of the first token. In this way, the service provider can select different security levels for the service requester based on actual conditions, thereby improving the control flexibility of the token security level.

[0027] In a possible implementation, the authentication level includes one or more of the following: advanced authentication, ordinary authentication, no authentication, and access denied, where advanced authentication corresponds to the token signature algorithm that combines the ECDSAwithSHA256 algorithm and the HmacSHA256 algorithm. In this way, the token signature algorithm is at a higher level and is less likely to be cracked, making the transmitted data more secure.

[0028] In a possible implementation, the second service also regularly updates the first token public key and the first token secret key, so that they are not easily cracked by an untrusted third party, thereby improving the interaction security between the service provider and the service requester.

[0029] In a possible implementation, the method further includes: the first service reconfigures authorization information for the third service in the second service; the second service generates a first token public key and a first token secret key based on the reconfigured authorization information; the first service receives a message from the second service, the message including the regenerated first token public key. In this way, when the configuration authorization information of the service provider in the STS service changes, the STS service can trigger a callback and push the updated secret key information to the service provider, so that the service provider can obtain the latest secret key information in a timely manner, thereby improving the timeliness of the secret key update.

[0030] In a fourth aspect, an embodiment of the present application provides a data processing device, which may be an electronic device, or a chip or chip system in an electronic device. The device may include a processing unit. The processing unit is used to implement any method related to processing, which is executed by the first aspect or any possible implementation of the first aspect, or the second aspect or any possible implementation of the second aspect, or the third aspect or any possible implementation of the third aspect, by the first service, or the third aspect or any possible implementation of the third aspect, or by the third service in the third aspect or any possible implementation of the third aspect. When the device is an electronic device, the processing unit may be a processor. The device may also include a storage unit, which may be a memory. The storage unit is used to store instructions, and the processing unit executes the instructions stored in the storage unit to enable the electronic device to implement the method described in the first aspect or any possible implementation of the first aspect, or the method described in the second aspect or any possible implementation of the second aspect, or the method executed by the first service in the third aspect or any possible implementation of the third aspect, or the method executed by the second service in the third aspect or any possible implementation of the third aspect, or the method executed by the third service in the third aspect or any possible implementation of the third aspect, and any method related to processing. When the device is a chip or chip system in an electronic device, the processing unit may be a processor. The processing unit executes the instructions stored in the storage unit to enable the electronic device to implement the method described in the first aspect or any possible implementation of the first aspect, or the method described in the second aspect or any possible implementation of the second aspect, or the method executed by the first service in the third aspect or any possible implementation of the third aspect, or the method executed by the second service in the third aspect or any possible implementation of the third aspect, or the method executed by the third service in the third aspect or any possible implementation of the third aspect, and any method related to processing. The storage unit may be a storage unit within the chip (eg, a register, a cache, etc.), or a storage unit within the electronic device that is located outside the chip (eg, a read-only memory, a random access memory, etc.).

[0031] In a fifth aspect, an embodiment of the present application provides an electronic device, comprising a processor and a memory, the memory being used to store code instructions, and the processor being used to run the code instructions to execute the method described in the first aspect or any possible implementation of the first aspect, or the method described in the second aspect or any possible implementation of the second aspect, or the method executed by the first service in the method described in the third aspect or any possible implementation of the third aspect, or the method executed by the second service in the method described in the third aspect or any possible implementation of the third aspect, or the method executed by the third service in the method described in the third aspect or any possible implementation of the third aspect.

[0032] In a sixth aspect, an embodiment of the present application provides a service interaction system, comprising a first electronic device, a second electronic device, and a third electronic device, the first electronic device being used to execute a method executed by the first service in the method described in the third aspect or any possible implementation of the third aspect, the second electronic device being used to execute a method executed by the second service in the method described in the third aspect or any possible implementation of the third aspect, and the third electronic device being used to execute a method executed by the third service in the method described in the third aspect or any possible implementation of the third aspect.

[0033] In the seventh aspect, an embodiment of the present application provides a computer-readable storage medium, in which a computer program or instruction is stored. When the computer program or instruction is run on a computer, the computer executes the method described in the first aspect or any possible implementation of the first aspect, or the method described in the second aspect or any possible implementation of the second aspect, or the method executed by the first service in the method described in the third aspect or any possible implementation of the third aspect, or the method executed by the second service in the method described in the third aspect or any possible implementation of the third aspect, or the method executed by the third service in the method described in the third aspect or any possible implementation of the third aspect.

[0034] In an eighth aspect, an embodiment of the present application provides a computer program product comprising a computer program. When the computer program runs on a computer, it enables the computer to execute the method described in the first aspect or any possible implementation of the first aspect, or the method described in the second aspect or any possible implementation of the second aspect, or the method executed by the first service in the method described in the third aspect or any possible implementation of the third aspect, or the method executed by the second service in the method described in the third aspect or any possible implementation of the third aspect, or the method executed by the third service in the method described in the third aspect or any possible implementation of the third aspect.

[0035] In a ninth aspect, the present application provides a chip or a chip system, the chip or chip system comprising at least one processor and a communication interface, the communication interface and the at least one processor are interconnected by a line, and the at least one processor is used to run a computer program or instruction to execute the method described in the first aspect or any possible implementation of the first aspect. The communication interface in the chip can be an input / output interface, a pin or a circuit, etc.

[0036] In a possible implementation, the chip or chip system described above in the present application further includes at least one memory, in which instructions are stored. The memory may be a storage unit inside the chip, such as a register, a cache, etc., or a storage unit of the chip (e.g., a read-only memory, a random access memory, etc.).

[0037] It should be understood that the fourth to ninth aspects of the present application correspond to the technical solutions of the first, second or third aspects of the present application, and the beneficial effects achieved by each aspect and the corresponding feasible implementation methods are similar and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] Figure 1 A module architecture diagram of an STS service provided in an embodiment of the present application;

[0039] Figure 2 An architecture diagram of an STS.SDK toolkit provided in an embodiment of the present application;

[0040] Figure 3 A schematic diagram of a process of symmetrically encrypting and transmitting data provided in an embodiment of the present application;

[0041] Figure 4 A schematic diagram of a process of sending a key KEY through asymmetric encryption provided in an embodiment of the present application;

[0042] Figure 5 A schematic diagram of a process of HTTPS encrypted data transmission provided in an embodiment of the present application;

[0043] Figure 6 A schematic diagram of an ECDH key agreement algorithm provided in an embodiment of the present application;

[0044] Figure 7 A schematic diagram of a process flow of interaction between service A and service B provided in an embodiment of the present application;

[0045] Figure 8 A schematic diagram of a public key exchange between service A and service B provided in an embodiment of the present application;

[0046] Fig. 9 A schematic diagram of a data processing method provided in an embodiment of the present application;

[0047] Fig.10 A schematic diagram of another data processing method provided in an embodiment of the present application;

[0048] Fig.11 A schematic diagram of another data processing method provided in an embodiment of the present application;

[0049] Fig.12 A schematic diagram of the structure of a chip provided in an embodiment of the present application. DETAILED DESCRIPTION

[0050] In order to clearly describe the technical solutions of the embodiments of the present application, some terms and technologies involved in the embodiments of the present application are briefly introduced below:

[0051] 1. STS: Security token service (STS) is a security service product. STS service can also be understood as an authorization center. STS service can provide cloud service products with a token-based, time-effective, tamper-proof, anti-counterfeit verification and authentication and interface-level authorization and authentication integrated solution, providing configurable, reliable security guarantees and interface-level permission control for access between cloud services.

[0052] Among them, cloud services may include game center services, account services, cloud space services, push services, message center services, video services and payment services, etc., which are not limited in the embodiments of the present application.

[0053] These cloud services can interact with each other, and the service provider can provide an interface to the service requester. The service requester can use the related services provided by the service provider to the service requester by accessing the service provider's interface. The service requester can also be understood as an authorized service object.

[0054] For ease of description, the service requester is referred to as service A and the service provider is referred to as service B. Wherein, service A and service B can be any of the above-mentioned cloud services, and the embodiments of the present application are not limited thereto. In some implementations, service A can also be understood as a client, and service B can also be understood as a server.

[0055] Figure 1 The module architecture diagram of the STS service is shown.

[0056] STS services may include STS-MANAGE configuration services, STS business services, and STS software development kit (STS.SDK), etc.

[0057] Among them, STS-MANAGE configuration services can include key management, service management, token management, and permission management.

[0058] Key management can be used to execute processes such as key generation, key update, and key deletion. For example, in an embodiment of the present application, the STS service can generate a service-level key masterKey and an interface-level key serviceKey for the cloud service.

[0059] Service management can be used to perform processes such as service registration, service configuration, and version management. For example, in the embodiment of the present application, service B can register a service in the STS service and can also perform interface authorization configuration for service A.

[0060] Token management can be used to execute page configuration, real-time token generation, and token lifecycle management. For example, in the embodiment of the present application, service B can configure the validity period of the token for service A in the STS service; the STS service can also generate a token for service A to access the B service interface in real time; when the token is not within the validity period, the STS service can also regenerate the token, etc.

[0061] Permission management can be used to execute permission policies, configuration pages, version control and other processes. For example, in the embodiment of the present application, the STS service can provide a configuration page for the B service, and the B service can configure the authentication level and service version for the A service in the configuration page.

[0062] In addition, the STS-MANAGE configuration service can also save the service provider's configuration data to a database or memory or other place used to store data, thereby achieving persistence of service registration data, persistence of token data, and localization of token keys.

[0063] Among them, service registration data persistence can include STS registration service encryption storage, STS real-time caching registration service and real-time generation of serviceKey, etc. For example, in the embodiment of the present application, the STS service can save the registration data of service A and service B; the STS service can also generate interface-level keys serviceKey for cloud services, etc.

[0064] Token data persistence can include caching tokens on the service side, updating tokens on the service side, and STS generating tokens in real time, etc. For example, in the embodiment of the present application, the STS service can also generate a token for service A to access service B's interface in real time; when the token is not within the validity period, the STS service can also update the token, etc.

[0065] Token key localization can include obtaining certificate keys, masterKey localization, and real-time calculation of serviceKey. For example, in the embodiment of the present application, the STS service can obtain and save the certificate keys of each cloud service, generate and save the service-level key masterKey for the cloud service, etc.

[0066] STS business services can obtain the business data of the service provider from the database and provide business data support for the STS.SDK toolkit. The service provider can obtain the business data of the service provider from the STS business service based on the STS.SDK toolkit to perform business processing.

[0067] Figure 2 Shows the architecture diagram of the STS.SDK toolkit.

[0068] The STS.SDK toolkit can include encryption and decryption modules, signature modules, authentication modules, and certificate chain modules.

[0069] The encryption and decryption module can execute processes such as key negotiation algorithm (elliptic curve diffie-hellman, ECDH) based on elliptic curves cryptography (ECC) negotiation key encryption and decryption, advanced encryption standard (AES) algorithm encryption and decryption, and RSA public and private key encryption and decryption. Among them, ECDH can also be understood as an algorithm for exchanging public keys and generating symmetric keys. The AES algorithm is a symmetric encryption algorithm. For example, in an embodiment of the present application, when services interact with each other, the ECC public key and ECC private key of each service can be generated based on the AES algorithm, and the ECDH negotiation key sessionKey can be generated based on the ECC public key and the ECC private key, and the sessionKey is used to encrypt or decrypt the transmitted data, thereby improving the security of data transmission.

[0070] The signature module can execute processes such as Sha256 hash algorithm, HMAC authentication, signature verification check and certificate private key signature. For example, in the embodiment of the present application, the STS service can use the Sha256 hash algorithm to sign the token, and the B service can use the Sha256 hash algorithm to verify the signature of the token. Among them, signature verification can also be called signature verification.

[0071] The authentication module can perform token signature authentication, serviceKey generation, Jwt token parsing, health detection, authentication downgrade, token validity period verification, access rights verification and other processes. For example, STS.SDK can access the STS service regularly to determine whether the STS service is running normally. If the STS service is down or other abnormalities occur, STS.SDK will downgrade the authentication of the token locally and pass the data transmission by default. This can maintain the availability of business services.

[0072] The certificate chain module can perform processes such as certificate chain conversion, root certificate parsing, certificate chain verification, certificate public key encryption, and certificate private key decryption. The certificate chain can also be called a business certificate or service certificate. The certificate chain can be used to verify whether the identity of the other party is credible when two services interact with each other. For example, in the embodiment of the present application, STS.SDK can also perform certificate chain verification on service A.

[0073] 2. Symmetric encryption: Symmetric encryption can be understood as the client and the server holding the same key and using the same key to encrypt or decrypt the transmitted data.

[0074] Figure 3 The process of data transmission using symmetric encryption is shown.

[0075] The client and the server may hold the same key KEY. When the client transmits data to the server, the client may use the key KEY to encrypt the data. For example, the data may include a user name and a password. The user name may be "Username=HYN" and the password may be "Password=123456". The data encrypted by the symmetric key KEY may be "U2FsdGVkX19hRYvxq9V......".

[0076] After the server obtains the encrypted data, it can use the key KEY to decrypt the data and parse out the username and password.

[0077] 3. Asymmetric encryption: Symmetric encryption can be understood as using a public key to encrypt the transmitted data and a private key to decrypt it.

[0078] Figure 4 The process of sending the key KEY using asymmetric encryption is shown.

[0079] 4.1. The client sends a request message to the server.

[0080] 4.2. The server can generate a public key and a private key, wherein the server can save the private key locally on the server and return the public key to the client.

[0081] 4.3. The client generates a key KEY and encrypts the key KEY using the public key.

[0082] 4.4. The client sends the encrypted key KEY to the server, and the server can decrypt the key KEY using the private key stored locally. In this way, the client and the server hold the same key KEY.

[0083] 4.5. The client and server can use the key KEY for symmetric encryption transmission.

[0084] 4. Terminology

[0085] In the embodiments of the present application, words such as "first" and "second" are used to distinguish the same or similar items with substantially the same functions and effects. For example, the first chip and the second chip are only used to distinguish different chips, and their order is not limited. Those skilled in the art can understand that words such as "first" and "second" do not limit the quantity and execution order, and words such as "first" and "second" do not necessarily limit them to be different.

[0086] It should be noted that in the embodiments of the present application, words such as "exemplary" or "for example" are used to indicate examples, illustrations or descriptions. Any embodiment or design described as "exemplary" or "for example" in the present application should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary" or "for example" is intended to present related concepts in a specific way.

[0087] In the embodiments of the present application, "at least one" refers to one or more, and "more than one" refers to two or more. "And / or" describes the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone, where A and B can be singular or plural. The character " / " generally indicates that the previous and next associated objects are in an "or" relationship. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, ab, a--c, bc, or abc, where a, b, c can be single or multiple.

[0088] Applications in electronic devices can provide users with various services, such as game services, cloud space services, payment services, etc. Among them, when providing services, applications need corresponding servers for business support, so as to realize the processing of application background business data and the interaction between different services.

[0089] When service A communicates with service B, the transmitted messages may be accessed by untrusted third parties, who may then obtain the message data and / or modify the message content, leading to the leakage of privacy or security information. Therefore, in order to prevent the messages between service A and service B from being accessed by untrusted third parties, the messages transmitted between service A and service B need to be encrypted.

[0090] In some implementations, the client and the server may use the hypertext transfer protocol secure (HTTPS) to encrypt data transmission.

[0091] Figure 5 The process of HTTPS encrypted data transmission is shown.

[0092] 5.1. The client sends a request message to the server. For example, the link of the request message may be "https: / / www.xxx.com".

[0093] 5.2. The server can generate public key X and private key Y.

[0094] The public key X may be understood as the public key of the server's digital certificate.

[0095] 5.3. The server responds to the client's request message and may return information to the client, wherein the information may include the server's digital certificate, etc., and the digital certificate may include the server's public key X.

[0096] 5.4. The client parses the server's digital certificate and verifies the legitimacy of the certificate.

[0097] After the client obtains the digital certificate from the server, it can verify the legitimacy of the certificate.

[0098] If the certificate is verified to be legitimate, the client can parse the server's public key X from the digital certificate and generate a random code KEY. The client can also use the server's public key X to encrypt the random code KEY.

[0099] 5.5. The client sends the encrypted random code KEY to the server.

[0100] 5.6. The server can use the private key Y to decrypt the random code KEY and use the random code KEY to symmetrically encrypt the transmitted data.

[0101] 5.7. The server transmits the symmetrically encrypted content to the client.

[0102] 5.8. The client uses the previously generated random code KEY to decrypt the data and can also use symmetric encryption to transmit content to the server.

[0103] In other implementations, service A and service B may respectively integrate the STS.SDK tool, so that service A and service B may use STS.SDK and encrypt messages based on ECDH.

[0104] For example, Figure 6 As shown, when service A and service B use the ECDH key agreement algorithm, service A can generate an ECC public key pbkey-A and an ECC private key prikey-A.

[0105] Among them, the private key prikey-A is stored locally in the A service, and the public key pbkey-A is sent to the B service. After receiving the public key pbkey-A of the A service, the B service saves it locally in the B service. The B service can also generate the ECC public key pbkey-B and the ECC private key prikey-B. Among them, the private key prikey-B is stored locally in the B service, and the public key pbkey-B is sent to the A service.

[0106] In this way, service A locally stores the private key prikey-A and the public key pbkey-B of service B, and service B locally stores the private key prikey-B and the public key pbkey-A of service A. Service A can generate the symmetric key aeskey based on prikey-A and pbkey-B after the ECC algorithm, and service B can also generate the symmetric key aeskey based on prikey-B and pbkey-A after the ECC algorithm. In other words, after service A and service B exchange their respective public keys, they can generate the same symmetric key aeskey based on the ECC algorithm. Among them, the symmetric key aeskey can also be called the ECDH negotiation key sessionKey or session key sessionKey.

[0107] After generating the ECDH negotiation key sessionKey, service A and service B can interact with each other based on the same symmetric key aeskey.

[0108] However, in the above-mentioned interaction between the two services, in addition to the business message interaction, service A and service B need to exchange ECC public keys in advance. The ECC public key pbkey-A of service A is sent to service B, and the ECC public key pbkey-B of service B is sent to service A. In this way, one business interaction actually requires multiple interactions between service A and service B, which increases the cost of bandwidth traffic and the processing delay during business interaction between services. At the same time, because the ECDH negotiated key exchange protocol does not verify the identity of the sender of the public key, it is impossible to prevent attacks during the sending of the public key. Once the public key is intercepted, both services are at risk of being replaced and counterfeited.

[0109] In view of this, the data processing method provided in the embodiment of the present application is that when the service provider registers the service at the authorization center, the public key of the service provider can be sent to the authorization center, and the service requester can obtain the public key of the service provider from the authorization center in advance. When the service requester sends a business request message to the service provider, the public key of the service requester can be transmitted in the message. In this way, the public key exchange of the service provider can be completed in advance through the authorization center, and the service requester can complete the public key exchange of the service requester when sending a message to the service provider, thereby reducing the number of interactions between the service requester and the service provider, reducing the cost of bandwidth traffic, and reducing the processing delay during business interaction between services.

[0110] Figure 7 The flow of business interaction between service A and service B in the embodiment of the present application is shown. The interaction flow may include (1) interaction between service B and STS service, (2) interaction between service A and STS service, and (3) interaction between service A and service B.

[0111] (1) Interaction between B service and STS service.

[0112] Service B can configure interface authorization for service A in the STS service, allowing service A to access a certain interface-X interface of service B. The interface-X interface can be any interface provided by service B, for example, the interface-X interface can be a getUserInfo() interface for obtaining user information, a getUserRegist() interface for obtaining user registration information, etc. The specific services provided by the interface-X interface are not limited in the embodiments of the present application.

[0113] When service B configures authorization on the STS service side, the STS-MANAGE security token configuration service of the STS service can provide service B with the ability to support configurable token security level control, such as configuring authentication level authlevel and token validity period.

[0114] The authentication level provided by the STS service may include one or more levels, which are not limited in the embodiments of the present application. The authentication level may include advanced authentication, ordinary authentication, no authentication, access denied, etc.

[0115] Exemplarily, if the authentication level configured by service B for service A is advanced authentication, the signature algorithm level used when services A and B interact is relatively high. If the authentication level configured by service B for service A is ordinary authentication, the signature algorithm level used when services A and B interact is relatively low. If service B configures the authentication level of interface-X to no authentication, all services can be allowed to access interface-X, including service A. If service B configures the authentication level of interface-X to deny access, no service is allowed to access interface-X, including service A. It will be understood that the specific authentication level can be set by service B, and the embodiments of the present application are not limited thereto.

[0116] The validity period of the token can be set by service B. For example, the validity period of the token can be set to 30 minutes. The validity period of the token can also be set to other values. The specific value of the validity period of the token is not limited in the embodiment of the present application.

[0117] (1.1) Pre-registration process for B service.

[0118] It is understandable that the purpose of pre-registration is to exchange ECC public keys between service B and service STS. When service B is pre-registered, service B can generate ECC private key prikey-B1 and ECC public key pbkey-B1 locally, the private key prikey-B1 is stored locally in service B, and the public key pbkey-B1 is sent to service STS, where the public key pbkey-B1 can be used for interaction between service B and service STS.

[0119] When service B starts or obtains tasks from service STS, service B can send a request message of pre-registration service RreRegist to service STS. In this request message, service B's signature, service B's service certificate, and service B's public key pbkey-B1 can be carried. The signature is to prevent the request message sent by service B from being tampered with, and the service certificate is to prove that the identity of service B is credible.

[0120] After the STS service obtains the pre-registration request message from service B, it can perform signature verification and certificate verification on the request message. It can be understood that the signature verification is to determine whether the request message sent by service B has been tampered with, and the certificate verification is to determine whether the identity of service B is credible.

[0121] Exemplarily, the STS service can use the ECDSA public key of service B to verify the signature of the request message of service B. Among them, the ECDSA public key of service B can be the newly generated ECC public key pbkey-B11 of service B, or it can be the certificate public key pbKeyCertB of service B, which is not limited in the embodiments of the present application. Among them, the certificate public key pbKeyCertB of service B can be understood as the certificate public key at the end of B's ​​certificate chain, and can also be called the public key of the root certificate of service B. pbkey-B11 is different from pbkey-B1.

[0122] If the signature verification succeeds, it means that the request message content of service B has not been tampered with during the transmission process; if the signature verification fails, it means that the request message content of service B has been tampered with during the transmission process, and the STS service cannot exchange ECC public keys with service B.

[0123] The STS service can also use the public key pbKeyCertS of the root certificate of the STS service to verify the legitimacy of the certificate in the request message of service B. If the certificate verification of service B passes, the STS service can exchange ECC public keys with service B; if the certificate verification of service B fails, the STS service cannot exchange ECC public keys with service B.

[0124] After verifying the signature and certificate of the B service request message, the STS service can encrypt and persist the information such as the B service's public key pbkey-B1, and generate the STS service's ECC private key prikey-S1 and ECC public key pbkey-S1.

[0125] According to the above description of ECDH, the STS service can generate the ECDH negotiation key sessionKey1 between the B service and the STS service based on the private key prikey-S1 and the public key pbkey-B1 of the B service through the ECC algorithm. In the subsequent interaction between the B service and the STS service, the sessionKey1 can be used to encrypt the transmitted data.

[0126] The STS service can save the private key prikey-S1 locally and return a pre-registration response to service B. The response can carry information such as the signature of the STS service, the service certificate of the STS service, and the public key pbkey-S1 of the STS service.

[0127] Similarly, after obtaining the pre-registration response returned by the STS service, service B can verify the signature and certificate of the response. For example, service B can use the ECDSA public key of the STS service to verify the signature of the response of the STS service. Among them, the ECDSA public key of the STS service can be the newly generated ECC public key pbkey-S11 of the STS service, or it can be the certificate public key pbKeyCertS of the STS service, which is not limited in the embodiments of the present application. pbkey-S11 is different from pbkey-S1. Service B can also use the certificate public key pbKeyCertS of the STS service to verify the legitimacy of the certificate of the response of the STS service party.

[0128] After the signature and certificate verification of the pre-registration response of the STS service, according to the above description of ECDH, the B service can generate the ECDH negotiation key sessionKey1 between the B service and the STS service based on the private key prikey-B1 and the public key pbkey-S1 of the STS service through the ECC algorithm. In the subsequent interaction between the B service and the STS service, the sessionKey1 can be used to encrypt the transmitted data.

[0129] (1.2) Registration process for B service.

[0130] After the B service and the STS service exchange the ECC public key, the B service can send a request message of the registration service RegistServer to the STS service to obtain the authorization information of the interface-X interface, which includes the authorization of the A service. In the request message, the signature of the B service, the service certificate of the B service, the public key pbkey-B2 of the B service required for the interaction between the B service and the A service, and the registration service data data encrypted by the ECDH negotiation key sessionKey1 can be carried. The data can include information such as the token validity period, the B service ID appid, the interface-X interface ID intfid, the authentication level authlevel and / or the salt value saltvalue.

[0131] Among them, intfid can be understood as a unique identifier of the service interface level. In some implementations, intfid can also be represented by interfaceName.

[0132] It can be understood that service B can obtain interface-X interface authorization information from service STS when it is started, and can also obtain interface-X interface authorization information from service STS periodically, or, when the interface-X interface authorization information in service STS is updated, the updated interface-X interface authorization information can be sent to service B in real time. The specific timing and method for service B to obtain interface-X interface authorization information are not limited in the embodiments of the present application.

[0133] After receiving the registration request message from service B, the STS service can verify the signature and certificate of the request message. The specific verification of the signature and certificate of service B by the STS service can refer to the relevant description in the pre-registration process of service B above (1.1), which will not be repeated here.

[0134] After verifying the signature and certificate of the B service request message, the STS service can save the public key pbkey-B2 and other information of the B service required for the interaction between the B service and the A service. It is understandable that the B service sends the ECC public key pbkey-B2 of the B service to the STS service in advance and saves it in the STS service. When the A service obtains the token from the STS service, it can also obtain the ECC public key of the B service. In this way, the A service can obtain the ECC public key of the B service in advance, which can reduce the number of interactions between the A service and the B service, and reduce the processing delay when the business interacts between the services.

[0135] The STS service can generate a public key masterKey1 for the token for the B service. The masterKey1 can also be called the master key of the token or the root key of the token. It is understandable that the STS service can generate different public keys for different tokens for different services. For example, the public key generated by the STS service for the B service can be masterKey1, and the public key generated by the STS service for the A service can be masterKey2. MasterKey1 and masterKey2 are different. MasterKey1 and masterKey2 can also be understood as the master keys of the service-level token.

[0136] After the STS service generates the public key masterKey1 of the token for the B service, it can return the registration service response to the B service, which may include the STS service certificate chain, the STS service signature, the STS service public key pbkey-S1, and the registration response data encrypted by the ECDH negotiation key sessionKey1, etc. Among them, the data may include the certificate serial number serialNum of the B service, the public key masterKey1 of the token, the token signature key tokenSignPbKey, the challenge value challenge, and the version number version, etc.

[0137] Service B can verify the signature and certificate of the registration service response of the STS service. The specific verification of the signature and certificate of the STS service by service B can refer to the relevant description in the pre-registration process of service B above (1.1), which will not be repeated here.

[0138] After performing signature verification and certificate verification on the response of the STS service, service B can cache the public key masterKey1 and other information of the obtained token locally on service B.

[0139] It should be noted that after generating masterKey1, the STS service can also derive the interface-X interface-level token key serviceKey based on masterKey1, the service ID appid of service B, the interface-level ID inifid of service B, and the challenge value challenge through the HmasSHA256 algorithm. The serviceKey can also be called the token signature key. The serviceKey can be used to generate the interface-X interface token and can also be used to verify the token.

[0140] It is understandable that since the challenge value challenge generated each time is random, the serviceKey corresponding to each interface of service B is also different. In other words, one interface corresponds to one key serviceKey, and different interfaces correspond to different keys serviceKey. The key of interface-X1 cannot be parsed for interface-X2. In this way, the uniqueness of the token and the key at the interface level can be achieved, which improves the security of interface access.

[0141] Based on the pre-registration and registration process, service B can send the ECC public key to the STS service in advance, so that service A can obtain the ECC public key of service B while obtaining the token. This reduces the number of interactions between service A and service B, reduces the cost of bandwidth traffic, and reduces the processing delay when the business interacts between services.

[0142] (2) Interaction between A service and STS service.

[0143] (2.1) Service A requests a token from the STS service.

[0144] When service A accesses interface-X of service B, service A can first determine whether there is a valid token corresponding to accessing interface-X of service B cached in the memory.

[0145] If service A has a locally cached token for interface-X and the token is within its validity period, it means that the token is valid and service A can initiate a business request message to service B, and the request message will carry the token.

[0146] If service A does not have a locally cached token for interface-X, or the token is not valid, it means that there is no token or the token is invalid. Service A can send a request message to the STS service to apply for access to the token for interface-X of service B.

[0147] It is understandable that before service A applies for a token from the STS service, for example, when service A is started, service A can perform a pre-registration and registration process with the STS service. The specific pre-registration and registration process can refer to the relevant description of the pre-registration and registration process in the interaction between service B and STS service (1) above, which will not be repeated here.

[0148] It should be noted that after service A and service STS perform the pre-registration and registration process, service A can locally save information such as service A's ECC private key prikey-A1, STS service's ECC public key pbkey-S2, and the public key masterKey2 of the token generated by STS service for service A.

[0149] Service A can generate the ECDH negotiation key sessionKey2 between service A and service STS based on private key prikey-A1 and public key pbkey-S2 through the ECC algorithm. Similarly, service STS can locally save the ECC private key prikey-S2 of service STS and the ECC public key pbkey-A1 of service A, and generate the ECDH negotiation key sessionKey2 between service A and service STS based on private key prikey-S2 and public key pbkey-A1 through the ECC algorithm. In the subsequent interaction between service A and service STS, the sessionKey2 can be used to encrypt the transmitted data.

[0150] The request message from service A to the STS service for a token can carry the signature of service A, the certificate chain of service A, and the request data encrypted by masterKey2, etc. The data can include information such as timestamp, service ID appid of service B, and interface ID intfid of interface-X.

[0151] (2.2) The STS service returns information such as token.

[0152] After the STS service obtains the request message for the token application from service A, it can verify the signature and certificate of the request message from service A. The specific verification of the signature and certificate by the STS service on service A can refer to the description of the verification of the signature and certificate by the STS service on service B in the pre-registration process of service B (1.1) above, which will not be repeated here.

[0153] After verifying the signature and certificate of the request message of service A, the STS service can query whether the interface-X of service B is authorized to service A.

[0154] If interface-X does not allow service A to access, the STS service will not generate and return a token corresponding to interface-X for service A.

[0155] If the interface-X interface allows service A to access, the STS service can generate a corresponding token for the interface-X interface. Exemplarily, the STS service can generate a token based on the serviceKey of the interface-X interface. The validity period of the token can be counted from the time of generation. The token can include relevant information such as the service ID appid of service B, relevant information such as the service ID appid of service A, relevant information such as the interface ID intfid of interface-X, the validity period of the token and the challenge value challenge.

[0156] The STS service can use masterKey2 to encrypt the information returned to A, and the returned information may include information such as the token of interface-X, the certificate serial number of service B serialnum, and the public key of service B pbkey-B2. The token may include information such as the validperiod of the token and the service ID appid of service B.

[0157] After service A obtains the decrypted token of interface-X, it can cache the token locally. It is understandable that if service A determines that the token is valid, it does not need to apply for a new token from STS when requesting interface-X of service B, and can reuse the token in the cache.

[0158] Service A can also generate an ECDH negotiation key sessionKey3 between service A and service B based on the private key prikey-A2 of service A and the public key pbkey-B2 of service B through the ECC algorithm. The sessionKey3 can be used to encrypt sensitive information in the request message sent to service B.

[0159] (3) Interaction between service A and service B.

[0160] (3.1) Service A sends a service request message to service B.

[0161] When service A initiates a request message for interface-X related services to service B, the request message may carry information such as the signature of service A, the certificate chain of service A, and the token of interface-X.

[0162] In a possible implementation, service A can use double-layer encryption to send a request message to service B. The request message may include the certificate chain of service A, the hash summary signed by the private key certificate of service A, the ECDSA public key of service A, and the request data data, etc. Among them, the ECDSA public key of service A can be the newly generated ECC public key pbkey-A11 of service A, or it can be the certificate public key pbKeyCertA of service A, which is not limited in the embodiment of the present application. pbkey-A11 is different from pbkey-A1. The data data may include token, public key pbkey-A2 of service A, salt value saltvalue, and encrypted data EncryptData encrypted by ECDH negotiated key sessionKey3.

[0163] It is understandable that when service A and service B use the HTTPS protocol to transmit data, the HTTPS protocol itself can encrypt the transmitted data, which is called the first layer of encryption. Based on the encryption based on the HTTPS protocol, the embodiment of the present application can also encrypt the transmitted data again based on sessionKey3 to obtain the encrypted data EncryptData, which is called the second layer of encryption. In this way, for scenarios with high requirements for the security of the transmitted content, the use of double-layer encryption can make the interaction between services more secure.

[0164] In an embodiment of the present application, when service A sends a message to service B, it can complete the exchange of service A's public key pbkey-A2, thereby reducing the number of interactions between service A and service B, reducing the cost of bandwidth traffic, and reducing the processing delay during business interactions between services.

[0165] (3.2) Service B verifies the request message of service A.

[0166] Service B can integrate the STS.SDK toolkit, which can intercept the request message of service A. After intercepting the request message, STS.SDK can parse the request message and verify the signature and certificate chain of the request message.

[0167] For example, STS.SDK can verify the signature of service A based on A's certificate public key pbKeyCertA. If the verification is successful, it means that the request message content of service A has not been tampered with during transmission; if the verification fails, it means that the request message content of service A has been tampered with during transmission, and service B returns an exception.

[0168] STS.SDK can also verify the certificate chain of service A. For example, STS.SDK can use the local root certificate rootCA of service B to verify the legitimacy of the certificate chain of service A. If the certificate chain of service A is legal, it means that the certificate chain verification has passed, and the verification of information such as tokens can continue; if the certificate chain of service A is illegal, it means that the certificate chain verification has failed, and service B returns an exception.

[0169] STS.SDK can also obtain the token in the request message and verify the token.

[0170] The token verification includes the token validity period verification, whether the token is authorized to interface-X, the token signature verification, the token subject legitimacy verification, the token issuer verification, and the token custom parameter verification. Among them, the token signature verification can also be called token verification.

[0171] For example, STS.SDK can derive the interface-X interface-level token key serviceKey based on the public key masterKey1 of the token provided by the STS service, the service ID appid of the B service, the interface-level ID inifid of the B service, and the challenge value challenge. STS.SDK can verify the token based on the serviceKey.

[0172] STS.SDK's token validity check may include checking the uniform resource locator (URL) of the interface.

[0173] After the token verification is passed, STS.SDK can record the timestamp, verify the validity period of the token, and confirm whether service A is authorized to access interface-X of service B.

[0174] In a possible implementation, when registering, service B can obtain the authorization object of each interface from the STS service, including the authorization object service A of the interface-X interface of service B. When service A requests the interface-X interface of service B, the token in the request message of service A can carry the interface information to be accessed. Service B can determine whether the interface information in the token of the request message of service A is consistent with the URL interface information to be accessed, and whether the authorization object of the interface-X interface cached by service B includes service A, and then determine whether the interface-X interface authorizes service A to access the interface-X interface of service B.

[0175] If it is confirmed that service A is not authorized to access interface-X of service B, service B returns an exception.

[0176] If it is confirmed that service A is authorized to access interface-X of service B, service B can have normal business interaction with service A. For example, service B can obtain key sessionKey3 through ECDH negotiation based on private key prikey-B2 of service B and public key pbkey-A2 of service A. Then, service B can use sessionKey3 to decrypt the encrypted data EncryptData sent by service A, and return the response of the business request message to service A.

[0177] It is understandable that the embodiments of the present application can be applied to message interactions between multiple services. For example, when each service registers a service with the STS service, it can send the public key information between each service to the STS service. When other services obtain tokens, they can obtain the other party's public key, so that interaction between services can be achieved based on the public key. In this way, the number of interactions between services can be reduced, the cost of bandwidth traffic can be reduced, and the processing delay during business interaction between services can be reduced.

[0178] Figure 8 A schematic diagram showing the exchange of public keys between service A and service B provided in an embodiment of the present application is shown.

[0179] 8.1. Service B sends a pre-registration message to service STS.

[0180] The B service can generate the ECC private key prikey-B1 and the ECC public key pbkey-B1 locally. The private key prikey-B1 is stored locally in the B service, and the public key pbkey-B1 is sent to the STS service through the pre-registration message.

[0181] After the STS service obtains the pre-registration message of the B service, the STS service can generate the ECC private key prikey-S1 and the ECC public key pbkey-S1. The private key prikey-S1 is stored locally in the STS service, and the public key pbkey-S1 is returned to the B service. In addition, the STS service can also return to the B service the service list of all the authorized objects of the B service. For example, the authorized objects can include multiple services such as A service, C service, and D service.

[0182] According to the above description of ECDH, service B can generate the ECDH negotiation key sessionKey1 between service B and service STS based on the private key prikey-B1 and the public key pbkey-S1 of service STS through the ECC algorithm. Service STS can also generate the key sessionKey1 based on the private key prikey-S1 and the public key pbkey-B1 of service B. In the subsequent interaction between service B and service STS, the key sessionKey1 can be used to encrypt the transmitted data.

[0183] The specific pre-registration process for service B can refer to the above Figure 7 The relevant description in the pre-registration process of the corresponding embodiment (1.1) B service will not be repeated here.

[0184] 8.2. Service B transmits the registration message to service STS in encrypted form.

[0185] Service B can generate ECC private keys and ECC public keys for interacting with each service locally. For example, if service B interacts with 50 services, service B can generate 50 ECC private keys and 50 ECC public keys, which may include ECC private key prikey-B2 and ECC public key pbkey-B2 for interaction between service B and service A. Service B can save the ECC private keys for interacting with each service locally in service B, and encrypt the ECC public keys for interacting with each service through registration messages and send them to STS service, which will save these ECC public keys.

[0186] In a possible implementation, the B service can use a collection, list, database, etc. to store the ECC private key, and the STS service can use a collection, list, database, etc. to store the ECC public key. The specific method of storing the ECC private key and the ECC public key is not limited in the embodiment of this application. For the convenience of description, the following example is used to illustrate that the B service uses a Map collection to store the ECC private key and the STS service can use a Map collection to store the ECC public key.

[0187] Service B can put the ECC private key for interacting with each service in the ECC private key Map collection. The key of the ECC private key Map collection can be the service name clientname of each service, and the value of the ECC private key Map collection can be the ECC private key prikey for Service B to interact with each service. For example, the ECC private key Map collection can be Map<clientname,prikey> The ECC public key Map set may include the ECC private key prikey-B2 of the B service that interacts with the A service.

[0188] Among them, clientname can also be understood as the unique identifier of each service. In some implementations, clientname can also be represented by appid, serviceId or serviceName.

[0189] The STS service can put the ECC public key for interacting with each service in the ECC public key Map collection. The key of the ECC public key Map collection can be the service name clientname of each service, and the value of the ECC public key Map collection can be the ECC public key pubkey for the B service to interact with each service. For example, the ECC public key Map collection can be Map<clientname,pubkey> The ECC public key Map set may include the ECC public key pbkey-B2 of the B service that interacts with the A service.

[0190] The registration process for the specific B service can refer to the above Figure 7 The relevant description in the registration process of the corresponding embodiment (1.2) B service will not be repeated here.

[0191] 8.3. Service A applies to STS for a token to access interface-X of service B.

[0192] The message for applying for a token can include the service name clientname of service A. In this way, the STS service can easily find the corresponding public key pbkey-B2 of service B in the ECC public key Map set according to the clientname of service A. Thus, the STS service can return a message containing the public key pbkey-B2 of service B to service A.

[0193] The specific process of service A applying for a token from the STS service can refer to the above Figure 7 The relevant description in the corresponding embodiment (2.1) A service requests a token from the STS service will not be repeated here.

[0194] 8.4. Service A generates ECDH negotiation key sessionKey3.

[0195] Service A can generate ECC private key prikey-A2 and ECC public key pbkey-A2 for interaction with service B. Private key prikey-A2 is stored locally in service A, and public key pbkey-A2 is sent to service B via request message.

[0196] According to the above description of ECDH, service A can generate the ECDH negotiation key sessionKey3 between service A and service B based on the private key prikey-A2 and the public key pbkey-B2 of service B through the ECC algorithm. In the subsequent interaction between service A and service B, the key sessionKey3 can be used to encrypt the transmitted data.

[0197] Among them, the data encrypted using the key sessionKey3 may not include the public key pbkey-A2 of service A. In this way, service B can obtain the public key pbkey-A2 of service A and generate the key sessionKey3 based on the private key prikey-B2 of service B and the public key pbkey-A2 of service A, thereby using the key sessionKey3 to parse the encrypted data.

[0198] The specific process of service A generating key sessionKey3 can refer to the above Figure 7 The relevant description in the corresponding embodiment (2.2) STS service returns token and other information, which will not be repeated here.

[0199] 8.5. Service A sends a request message to service B.

[0200] The request message sent by service A to service B may include service A's certificate, service A's signature, data encrypted by key sessionKey3, and service A's public key pbkey-A2.

[0201] Service B can verify the certificate chain of service A.

[0202] Service B can also generate key sessionKey3 based on private key prikey-B2 and public key pbkey-A2 of service A, and decrypt the message based on sessionKey3. Service B can also obtain the public key pbKeyCertA of service A's certificate in the decrypted message, and verify the signature of service A through pbKeyCertA, thereby verifying whether the message of service A has been tampered with.

[0203] The specific process of service A sending a request message to service B and service B verifying the message of service A can refer to the above Figure 7The relevant description of the interaction between service A and service B in the corresponding embodiment (3) will not be repeated here.

[0204] 8.6. Service B returns a message to service A.

[0205] The message returned by service B to service A may include service B's certificate, service B's signature, return data encrypted by key sessionKey3, etc. Similarly, service A can verify the certificate chain of service B.

[0206] Service A can also decrypt the message based on the key sessionKey3 and obtain the certificate public key pbKeyCertB of service B in the decrypted message. Service A can verify the signature of service B through pbKeyCertB to verify whether the message of service B has been tampered with.

[0207] The specific process of service A verifying the message of service B is similar to the process of service B verifying the message of service A in step 8.5 above, and will not be repeated here.

[0208] In the embodiment of the present application, through the process of pre-registration and registration of each service, some ECC public key exchanges can be completed in advance, and the number of ECC public key interactions can be reduced when services interact with each other, thereby saving network interaction traffic and bandwidth, and reducing the latency cost of interaction between services. At the same time, each service can verify the signature through STS.SDK to prevent the message from being intercepted and tampered, and improve the security of interaction between services.

[0209] Optionally, in addition to being applied to the interaction between two services, the data processing method of the embodiment of the present application can also be applied to the interaction scenario between the server and the client, for example, the server is a game center server and the client is a game center application. The data processing method of the server can refer to the data processing method of the above-mentioned B service, and the data processing method of the client can refer to the data processing method of the above-mentioned A service, which will not be repeated. The specific server and client are not limited in the embodiment of the present application. The game center application can be an application on electronic devices such as mobile phones, tablets, and computers, and the type of specific electronic equipment is not limited in the embodiment of the present application.

[0210] The following specific embodiments are used to describe the method of the present application in detail. The following embodiments may be combined with each other or implemented independently, and the same or similar concepts or processes may not be described in detail in some embodiments.

[0211] Fig. 9 The data processing method of the embodiment of the present application is shown. The method is applied to a service interaction system, the service interaction system includes a first service, a second service and a third service, and the method includes:

[0212] S901. The first service generates a first private key and a first public key.

[0213] In the embodiment of the present application, the first service can be understood as a service provider. For example, the first service can be the above-mentioned Figure 7 Corresponding to service B in the embodiment.

[0214] The first private key and the first public key can be understood as the private key and the public key generated by the service provider, and the first private key and the first public key can be used to interact with the service requester. Figure 7 Corresponding to the ECC private key prikey-B2 of service B in the embodiment, the first public key can be the above Figure 7 This corresponds to the ECC public key pbkey-B2 of service B in the embodiment.

[0215] S902: The first service sends a first public key to the second service.

[0216] In the embodiment of the present application, the second service can be understood as a service for receiving the first public key of the service provider. For example, the second service can be the above Figure 7 Corresponding to the authorization center or STS service in the embodiment.

[0217] The specific process of the first service sending the first public key to the second service can refer to the above Figure 7 The corresponding description of the registration process of service B in (1.2) of the embodiment, and the above Figure 8 The relevant description of step 8.2 in the corresponding embodiment is not repeated here.

[0218] S903: The third service obtains the first public key from the second service.

[0219] In the embodiment of the present application, the third service can be understood as a service requester. For example, the first service can be the above-mentioned Figure 7 Corresponding to service A in the embodiment.

[0220] The process of the third service obtaining the first public key from the second service can refer to the above Figure 7 In the corresponding embodiment (2.2) the STS service returns the token and other information, as well as the above Figure 8 The relevant description of step 8.3 in the corresponding embodiment is not repeated here.

[0221] S904: The third service generates a second private key and a second public key, and generates a first key based on the second private key and the first public key.

[0222] In the embodiment of the present application, the second private key and the second public key can be understood as the private key and the public key generated by the service requester, and the second private key and the second public key can be used to interact with the service provider. Figure 7 Corresponding to the ECC private key prikey-A2 of service A in the embodiment, the second public key can be the above Figure 7 This corresponds to the ECC public key pbkey-A2 of service A in the embodiment.

[0223] The first key can be understood as a key for encrypting or decrypting transmitted data during the interaction between the service provider and the service requester. Figure 7 This corresponds to the ECDH negotiated key sessionKey3 between service B and service A in the embodiment.

[0224] The process of the third service generating the first key can refer to the above Figure 8 The relevant description of step 8.4 in the corresponding embodiment is not repeated here.

[0225] S905: The third service sends a first request to the first service, where the first request includes the second public key and data encrypted by the first key.

[0226] In the embodiment of the present application, the first request can be understood as a business request sent by the service requester to the service provider. For example, the first request can be Figure 7 The service A in this embodiment initiates a business request to the service B. The specific third service sending the first request to the first service can refer to the above Figure 7 The description of the service A initiating a business request to the service B in the corresponding embodiment (3.1), and the above Figure 8 The relevant description of step 8.5 in the corresponding embodiment is not repeated here.

[0227] S906: The first service generates a first key based on the first private key and the second public key, and decrypts the encrypted data in the first request.

[0228] In the embodiment of the present application, the process of the first service decrypting the encrypted data in the first request can refer to the above Figure 8 The relevant description of step 8.5 in the corresponding embodiment is not repeated here.

[0229] S907: The first service returns a response to the first request to the third service, where the response includes data encrypted by the first key.

[0230] In the embodiment of the present application, the process of the first service returning the response to the first request to the third service can refer to the above Figure 8 The relevant description of step 8.6 in the corresponding embodiment is not repeated here.

[0231] S908: The third service decrypts the encrypted data in the response based on the first key.

[0232] In the embodiment of the present application, the process of the third service decrypting the encrypted data in the response based on the first key can refer to the above Figure 8 The relevant description of step 8.6 in the corresponding embodiment is not repeated here.

[0233] In an embodiment of the present application, when the service provider registers the service with the authorization center, the service provider's ECC public key exchange can be completed in advance, and when the service requester sends a message to the service provider, the service requester's ECC public key exchange can be completed, thereby reducing the number of interactions between the service requester and the service provider, reducing the cost of bandwidth traffic, and reducing the processing delay during business interaction between services.

[0234] Optional, in Fig. 9 On the basis of the corresponding embodiment, before the first service sends the first public key to the second service, it can also include: the first service generates a third private key and a third public key; the first service sends a second request to the second service, and the second request includes the third public key; the second service returns a response to the second request to the first service, and the response to the second request includes the fourth public key of the second service; the first service generates a second key based on the third private key and the fourth public key; the first service sends the first public key to the second service, including: the first service sends the first public key encrypted by the second key to the second service.

[0235] In the embodiment of the present application, the third private key and the third public key can be understood as the private key and the public key generated by the service provider, and the third private key and the third public key can be used to interact with the STS service. Figure 7 Corresponding to the ECC private key prikey-B1 of service B in the embodiment, the third public key can be the above Figure 7 This corresponds to the ECC public key pbkey-B1 of service B in the embodiment.

[0236] The second request can be understood as a request from the service provider to transfer the third public key to the STS service. For example, the second request can be the above Figure 7 In the corresponding embodiment, the B service sends a pre-registration request to the STS service. The specific process of the B service sending the pre-registration request to the STS service can refer to the above Figure 7 The description of the pre-registration process of service B in the corresponding embodiment (1.1) and the above Figure 8 The relevant description of step 8.1 in the corresponding embodiment is not repeated here.

[0237] The fourth public key can be understood as a public key generated by the STS service, and the fourth public key can be used to interact with the service provider. Figure 7 The ECC private key pbkey-S1 of the STS service in the corresponding embodiment. The specific process of the second service returning the response to the second request to the first service can refer to the above Figure 7 The description of the pre-registration process of service B in the corresponding embodiment (1.1) and the above Figure 8 The relevant description of step 8.1 in the corresponding embodiment is not repeated here.

[0238] The second key can be understood as a key for encrypting or decrypting transmitted data during the interaction between the service provider and the STS service. Figure 7 This corresponds to the ECDH negotiated key sessionKey1 between the B service and the STS service in the embodiment.

[0239] After the service provider and the STS service exchange each other's public keys, they can generate a second key based on their own private key and the other party's service public key. Therefore, during the interaction between the service provider and the STS service, the second key can be used to encrypt the transmitted data to protect the security of the data during transmission.

[0240] Optional, in Fig. 9 On the basis of the corresponding embodiment, after the first service sends the first public key to the second service, it can also include: the second service saves the mapping relationship between the first public key and the identifier of the third service; the third service obtains the first public key from the second service, which can include: the third service obtains the first public key from the mapping relationship of the second service.

[0241] In the embodiment of the present application, the mapping relationship between the first public key and the identifier of the third service can refer to the above Figure 8 The relevant description of step 8.2 in the corresponding embodiment is not repeated here.

[0242] The service requester and the public key generated by the service provider for the service requester can be matched through the mapping relationship, so that the service requester can obtain the accurate public key and perform business interaction with the service provider based on the public key.

[0243] Optional, in Fig. 9 On the basis of the corresponding embodiment, the first request also includes a first token. After the first service sends the first public key to the second service, it also includes: the first service obtains the first token public key from the second service; the third service obtains the first public key from the second service, including: the third service obtains the first public key and the first token from the second service; after the third service sends the first request to the first service, it also includes: the first service verifies the first token using the first token public key.

[0244] In the embodiment of the present application, the first token can be understood as a token required by the service requester to access a certain interface of the service provider. For example, the first token can be the above Figure 7 This corresponds to the token used when service A accesses interface-X of service B in the embodiment.

[0245] The first token public key can be understood as the public key corresponding to the token when the service provider verifies the token of the service requester. The first token public key can also be understood as the master key of the token or the root key of the token. For example, the first token public key can be the above Figure 7 In the corresponding embodiment, the STS service generates a public key masterKey1 of a token for the B service, and the B service can verify the token sent by the A service based on the masterKey1.

[0246] The process of verifying the first token using the first token public key can refer to the above Figure 7 The description of the request for B service to verify A service in the corresponding embodiment (3.2) will not be repeated here.

[0247] The service provider can obtain the public key of the token from the STS service in advance. When the service provider receives the business request from the service requester, the service provider can verify the token locally using the public key of the token. In this way, the service provider does not need to initiate additional requests to the STS service to verify the token, which improves the concurrent processing capability and efficiency of the service provider and shortens the processing delay when the service requester interacts with the service provider.

[0248] Optional, in Fig. 9 Based on the corresponding embodiment, the first token is the token corresponding to the first interface of the first service, and the first service uses the first token public key to verify the first token, which can include: the first service generates a first token key of the first interface based on the first token public key and the interface ID of the first interface; the first service uses the first token key to verify the first token.

[0249] In the embodiment of the present application, the first interface can be understood as any interface of the service requester to access the service provider, and the embodiment of the present application is not limited. Figure 7 This corresponds to the interface-X of service B in the embodiment.

[0250] The interface ID of the first interface can be used to identify the first interface, and can also be understood as a unique identifier of the first interface. The specific unique identifier of the first interface is not limited in the embodiment of the present application. For example, the interface ID of the first interface can be the above Figure 7 Corresponding to intfid or interfaceName in the embodiment.

[0251] The first token key can be understood as the signature key of the first token. The first token key can be used to generate the token of the first interface, and can also be used to verify the token of the first interface. For example, the first token key can be the above Figure 7 The corresponding embodiment of the token token signature key serviceKey. The specific process of generating the first token key can refer to the above Figure 7 The description of generating serviceKey in the corresponding embodiment will not be repeated here.

[0252] Using the first token key to verify the first token can refer to the above Figure 7 The description of the request for B service to verify A service in the corresponding embodiment (3.2) will not be repeated here.

[0253] The first token key corresponding to each interface of the service provider can be different. The token key of one interface cannot parse and verify another interface, so that the uniqueness of the token and the key at the interface level can be achieved, improving the security of accessing the service interface.

[0254] Optional, in Fig. 9 Based on the corresponding embodiments, the verification of the first token may include any one or more of the following: verification of the validity period of the first token, determination of whether the first token is authorized to the first interface, verification of the signature of the first token, verification of the legitimacy of the first token, verification of the issuer of the first token, or verification of the custom parameters of the first token.

[0255] In the embodiment of the present application, the verification of the first token can refer to the above Figure 7 The description of the request for B service to verify A service in the corresponding embodiment (3.2) will not be repeated here.

[0256] The service provider verifies the first token, which can improve the security of interaction between services and make the identity and access rights of the service requester controllable.

[0257] Optional, in Fig. 9 On the basis of the corresponding embodiment, the first service obtains the first token public key from the second service, which may include: when the first service sends a registration request to the second service, the first service obtains the first token public key from the second service.

[0258] In the embodiment of the present application, the service provider obtains the first token public key from the STS service during registration, and the first token public key can be synchronized between the service provider and the STS service. Thus, the service provider can verify the first token of the service requester locally, realizing the localized verification of the token and reducing the delay of business processing.

[0259] Optional, in Fig. 9 On the basis of the corresponding embodiment, the third service obtains the first public key and the first token from the second service, which may include: when the third service sends a token application request to the second service, the third service obtains the first public key and the first token from the second service.

[0260] In the embodiment of the present application, the third service obtains the first token from the second service and can timely update the first token to the local of the third service, thereby facilitating business interaction with the third service through the first token.

[0261] Optional, in Fig. 9 On the basis of the corresponding embodiment, the second service is configured with the authorization information of the first service, and the authorization information may include one or more of the following: the authentication level, and the validity period of the first token.

[0262] In the embodiment of the present application, the authentication level may include one or more levels, which are not limited in the embodiment of the present application. Figure 7 For the authentication level in the corresponding embodiment, the specific authentication level can refer to the above Figure 7 The relevant description of the authentication level in the corresponding embodiment is not repeated here.

[0263] The STS service supports configurable token security level control, so that the service provider can select different security levels for the service requester based on actual conditions, thereby improving the control flexibility of the token security level.

[0264] Optional, in Fig. 9 Based on the corresponding embodiments, the authentication level may include one or more of the following: advanced authentication, ordinary authentication, no authentication, and access prohibited, wherein advanced authentication corresponds to a token signature algorithm that uses a combination of the ECDSAwithSHA256 algorithm and the HmacSHA256 algorithm.

[0265] In the embodiment of the present application, the specific authentication level can refer to the above Figure 7 The relevant description of the authentication level in the corresponding embodiment is not repeated here.

[0266] Using a two-layer signature algorithm that combines the ECDSAwithSHA256 algorithm and the HmacSHA256 algorithm can make the token signature algorithm level higher and less likely to be cracked, making the transmitted data more secure.

[0267] Optional, in Fig. 9 Based on the corresponding embodiment, the second service also periodically updates the first token public key and the first token secret key.

[0268] In an embodiment of the present application, the STS service regularly updates the first token public key and the first token secret key to improve the security of the token secret key, which is not easily cracked by an untrusted third party, thereby improving the interaction security between the service provider and the service requester.

[0269] Optional, in Fig. 9 Based on the corresponding embodiments, the method may also include: the first service reconfigures authorization information for the third service in the second service; the second service generates a first token public key and a first token secret key based on the reconfigured authorization information, and the first service receives a message from the second service, wherein the message includes the regenerated first token public key.

[0270] In an embodiment of the present application, when the configuration authorization information of the service provider in the STS service changes, the STS service can trigger a callback and push the updated key information to the service provider, so that the service provider can obtain the latest key information in a timely manner, thereby improving the timeliness of key updates.

[0271] Fig.10 The data processing method of the embodiment of the present application is shown. The method includes:

[0272] S1001. Obtain a first public key from a second service, where the first public key is sent by the first service to the second service.

[0273] In the embodiment of the present application, the first service can refer to the above Fig. 9 The relevant description of the first service in step S901 of the corresponding embodiment, the second service can refer to the above Fig. 9 The first public key can refer to the description of the second service in step S902 of the corresponding embodiment. Fig. 9 The relevant description of the first public key in step S901 of the corresponding embodiment is not repeated here.

[0274] The process of obtaining the first public key from the second service can refer to the above Figure 7 In the corresponding embodiment (2.2) the STS service returns the token and other information, as well as the above Figure 8 The relevant description of step 8.3 in the corresponding embodiment is not repeated here.

[0275] S1002. Send a first request to a first service.

[0276] In the embodiment of the present application, the first request can refer to the above Fig. 9 The description of the first request in step S905 of the corresponding embodiment is not repeated here. The process of sending the first request to the first service can refer to the above Figure 7 The description of the service A initiating a business request to the service B in the corresponding embodiment (3.1), and the above Figure 8The relevant description of step 8.5 in the corresponding embodiment is not repeated here.

[0277] S1003. Receive a response to the first request from the first service.

[0278] In the embodiment of the present application, the process of receiving the response from the first service to the first request can refer to the above Figure 8 The relevant description of step 8.6 in the corresponding embodiment is not repeated here.

[0279] S1004. Process a response according to the first public key.

[0280] In the embodiment of the present application, the process of processing the response according to the first public key can refer to the above Figure 8 The relevant description of step 8.6 in the corresponding embodiment is not repeated here.

[0281] The service requester can obtain the ECC public key of the service provider from the authorization center. In this way, the number of interactions between the service requester and the service provider can be reduced, thereby reducing the cost of bandwidth traffic and the processing delay when the business interacts between services.

[0282] Optional, in Fig.10 On the basis of the corresponding embodiment, before sending the first request to the first service, it may also include: generating a second public key; sending the first request to the first service includes: sending the first request including the second public key to the first service.

[0283] In the embodiment of the present application, the second public key can be understood as a public key generated by the service requester, and the second public key can be used to interact with the service provider. Figure 7 This corresponds to the ECC public key pbkey-A2 of service A in the embodiment.

[0284] When the service requester sends a service request message to the service provider, the service requester's ECC public key can be transmitted in the message. In this way, the number of interactions between the service requester and the service provider can be reduced, thereby reducing the processing delay when the service interacts between services.

[0285] Optional, in Fig.10 Based on the corresponding embodiment, obtaining the first public key from the second service may include: sending a third request to the second service; receiving a response to the third request from the second service, wherein the response to the third request includes the first public key.

[0286] In the embodiment of the present application, the third request can be understood as a request sent by the service requester to the STS service to obtain the first public key. For example, the third request can be the above Figure 7 This corresponds to the request of service A to the STS service for a token in the embodiment.

[0287] When the service requester obtains a token from the authorization center, it can also obtain the ECC public key of the service provider. This can reduce the number of interactions between the service requester and the service provider, thereby reducing the cost of bandwidth traffic and the processing delay when services interact with each other.

[0288] Optional, in Fig.10 On the basis of the corresponding embodiment, before processing the response according to the first public key, it can also include: generating a second private key; generating a first key based on the second private key and the first public key; processing the response according to the first public key, including: decrypting the response according to the first key.

[0289] In the embodiment of the present application, the second private key can be understood as a private key generated by the service requester, and the second private key can be used to interact with the service provider. Figure 7 This corresponds to the ECC private key pbkey-A2 of service A in the embodiment.

[0290] The first key can refer to the above Fig. 9 The description of the first key in step S904 of the corresponding embodiment is not repeated here. The process of decrypting the response according to the first key can refer to the above Figure 8 The relevant description of step 8.6 in the corresponding embodiment is not repeated here.

[0291] The service requester and service provider encrypt or decrypt the transmitted messages based on their locally generated keys, eliminating the need to transfer keys between services, thereby improving the security of service interaction.

[0292] Optional, in Fig.10 Based on the corresponding embodiment, the response to the third request also includes the first token, and sending the first request to the first service may include: sending the first request including the first token to the first service.

[0293] In the embodiment of the present application, the first token can refer to the above Fig. 9 The relevant description of the first token in the corresponding embodiment will not be repeated here.

[0294] The service requester sends a first request including a first token, and the service provider can then verify the first token, thereby improving the security of interaction between services and making the identity and access rights of the service requester controllable.

[0295] Fig.11 The data processing method of the embodiment of the present application is shown. The method includes:

[0296] S1101. Receive a first request from a third service, wherein the first request includes a second public key.

[0297] In the embodiment of the present application, the third service can refer to the above Fig. 9 The description of the third service in step S903 of the corresponding embodiment, the first request can refer to the above Fig. 9 The second public key may refer to the description of the first request in step S905 of the corresponding embodiment. Fig. 9 The relevant description of the second public key in step S904 of the corresponding embodiment is not repeated here.

[0298] S1102. Process the first request according to the second public key.

[0299] In the embodiment of the present application, the process of processing the first request according to the second public key can refer to the above Figure 7 Corresponding to the description of the request for B service to verify A service in (3.2) of the embodiment, and the above Figure 8 The relevant description of step 8.5 in the corresponding embodiment is not repeated here.

[0300] The service provider can obtain the ECC public key of the service requester from the request. This can reduce the number of interactions between the service requester and the service provider, thereby reducing the cost of bandwidth traffic and the processing delay when the service interacts with each other.

[0301] Optional, in Fig.11 On the basis of the corresponding embodiment, before processing the first request according to the second public key, it can also include: generating a first private key; generating a first key based on the first private key and the second public key; processing the first request according to the second public key can include: decrypting the first request according to the first key.

[0302] In the embodiment of the present application, the first private key can refer to the above Fig. 9 The description of the first private key in step S901 of the corresponding embodiment, the first key can refer to the above Fig. 9 The description of the first key in step S904 of the corresponding embodiment is not repeated here. The process of decrypting the first request according to the first key can refer to the above Figure 7 Corresponding to the description of the request for B service to verify A service in (3.2) of the embodiment, and the above Figure 8 The relevant description of step 8.5 in the corresponding embodiment is not repeated here.

[0303] After the service provider and service A exchange each other's public keys, they can both generate a first key based on their own private key and the public key of the other service. Therefore, during the interaction between the service provider and service A, the first key can be used to encrypt the transmitted data to protect the security of the data during transmission.

[0304] Optional, in Fig.11Based on the corresponding embodiment, the first request may also include a first token. Before receiving the first request from the third service, it may also include: obtaining the first token public key from the second service; after receiving the first request from the third service, it may also include: verifying the first token using the first token public key.

[0305] In the embodiment of the present application, the first token can refer to the above Fig. 9 The first token public key can refer to the above description of the first token in the corresponding embodiment. Fig. 9 The relevant description of the first token public key in the corresponding embodiment will not be repeated here.

[0306] The process of verifying the first token using the first token public key can refer to the above Figure 7 The description of the request for B service to verify A service in the corresponding embodiment (3.2) will not be repeated here.

[0307] The service provider can obtain the public key of the token from the STS service in advance. When the service provider receives the business request from the service requester, the service provider can verify the token locally using the public key of the token. In this way, the service provider does not need to initiate additional requests to the STS service to verify the token, which improves the concurrent processing capability and efficiency of the service provider and shortens the processing delay when the service requester interacts with the service provider.

[0308] Optional, in Fig.11 Based on the corresponding embodiment, the first token is the token corresponding to the first interface, and the first token is verified using the first token public key, which can include: generating the first token key of the first interface based on the first token public key and the interface ID of the first interface; and verifying the first token using the first token key.

[0309] In the embodiment of the present application, the first interface can refer to the above Fig. 9 The interface ID of the first interface can refer to the above description of the first interface in the corresponding embodiment. Fig. 9 The first token key can refer to the above description of the interface ID of the first interface in the corresponding embodiment. Fig. 9 The relevant description of the first token key in the corresponding embodiment will not be repeated here.

[0310] The process of verifying the first token using the first token key can refer to the above Figure 7 The description of the request for B service to verify A service in the corresponding embodiment (3.2) will not be repeated here.

[0311] The first token key corresponding to each interface of the service provider can be different. The token key of one interface cannot parse and verify another interface, so that the uniqueness of the token and the key at the interface level can be achieved, improving the security of accessing the service interface.

[0312] Optional, in Fig.11 On the basis of the corresponding embodiment, obtaining the first token public key from the second service may include: when sending a registration request to the second service, obtaining the first token public key from the second service.

[0313] In the embodiment of the present application, the service provider obtains the first token public key from the STS service during registration, and the first token public key can be synchronized between the service provider and the STS service. Thus, the service provider can verify the first token of the service requester locally, realizing the localized verification of the token and reducing the delay of business processing.

[0314] 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, stored data, displayed data, 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 relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and provide corresponding operation entrances for users to choose to authorize or refuse.

[0315] The above mainly introduces the solution provided by the embodiment of the present application from the perspective of the method. In order to achieve the above functions, it includes hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art should easily appreciate that, in combination with the method steps of each example described in the embodiment disclosed herein, the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in the form of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present application.

[0316] The embodiment of the present application can divide the functional modules of the device implementing the method according to the above method example. For example, each functional module can be divided according to each function, or two or more functions can be integrated into one processing module. The integrated module can be implemented in the form of hardware or in the form of software functional modules. It should be noted that the division of modules in the embodiment of the present application is schematic and is only a logical function division. There may be other division methods in actual implementation.

[0317] like Fig.12FIG. 1 is a schematic diagram of a chip structure provided by an embodiment of the present application. The chip 1200 includes one or more (including two) processors 1201 , a communication line 1202 , a communication interface 1203 and a memory 1204 .

[0318] In some implementations, the memory 1204 stores the following elements: executable modules or data structures, or a subset thereof, or an extended set thereof.

[0319] The method described in the above embodiment of the present application can be applied to the processor 1201, or implemented by the processor 1201. The processor 1201 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by an integrated logic circuit of hardware in the processor 1201 or an instruction in the form of software. The above processor 1201 can be a general-purpose processor (for example, a microprocessor or a conventional processor), a digital signal processor (digital signal processing, DSP), an application specific integrated circuit (application specific integrated circuit, ASIC), a field-programmable gate array (field-programmable gate array, FPGA) or other programmable logic devices, discrete gates, transistor logic devices or discrete hardware components. The processor 1201 can implement or execute the methods, steps and logic block diagrams related to each processing disclosed in the embodiment of the present application.

[0320] The steps of the method disclosed in the embodiment of the present application can be directly embodied as being executed by a hardware decoding processor, or can be executed by a combination of hardware and software modules in the decoding processor. Among them, the software module can be located in a mature storage medium in the field such as a random access memory, a read-only memory, a programmable read-only memory, or an electrically erasable programmable read only memory (EEPROM). The storage medium is located in the memory 1204, and the processor 1201 reads the information in the memory 1204 and completes the steps of the above method in combination with its hardware.

[0321] The processor 1201 , the memory 1204 , and the communication interface 1203 may communicate with each other via the communication line 1202 .

[0322] In the above embodiments, the instructions stored in the memory for execution by the processor may be implemented in the form of a computer program product, wherein the computer program product may be pre-written in the memory, or may be downloaded and installed in the memory in the form of software.

[0323] The embodiment of the present application also provides a computer program product including one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function according to the embodiment of the present application is generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network or other programmable device. The computer instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions may be transmitted from a website site, computer, server or data center to another website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a server or data center that includes one or more available media integrated. For example, the available medium may include a magnetic medium (e.g., a floppy disk, a hard disk or a tape), an optical medium (e.g., a digital versatile disc (DVD)), or a semiconductor medium (e.g., a solid state disk (SSD)), etc.

[0324] The present application also provides a computer-readable storage medium. The methods described in the above embodiments can be implemented in whole or in part by software, hardware, firmware, or any combination thereof. Computer-readable media may include computer storage media and communication media, and may also include any medium that can transfer a computer program from one place to another. The storage medium may be any target medium that can be accessed by a computer.

[0325] As a possible design, the computer readable medium may include a compact disc read-only memory (CD-ROM), RAM, ROM, EEPROM or other optical disc storage; the computer readable medium may include a magnetic disk storage or other magnetic disk storage device. Moreover, any connection line may also be appropriately referred to as a computer readable medium. For example, if the software is transmitted from a website, server or other remote source using a coaxial cable, fiber optic cable, twisted pair, DSL or wireless technology (such as infrared, radio and microwave), the coaxial cable, fiber optic cable, twisted pair, DSL or wireless technology such as infrared, radio and microwave are included in the definition of medium. Disk and disc as used herein include compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and Blu-ray disc, where disks usually reproduce data magnetically, while optical discs reproduce data optically using lasers.

[0326] The embodiments of the present application are described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processing unit of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, so that the instructions executed by the processing unit of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

Claims

1. A data processing method, It is characterized in that The method comprises: Obtain a first public key from a second service, wherein the first public key is sent by the first service to the second service; Sending a first request to the first service; receiving a response from the first service to the first request; The response is processed according to the first public key.

2. The method according to claim 1, It is characterized in that Before sending the first request to the first service, the method further includes: Generate a second public key; Sending a first request to the first service includes: The first request including the second public key is sent to the first service.

3. The method according to claim 1 or 2, It is characterized in that The obtaining the first public key from the second service includes: sending a third request to the second service; A response to the third request is received from the second service, the response to the third request including the first public key.

4. The method according to any one of claims 1 to 3, It is characterized in that Before processing the response according to the first public key, the method further includes: Generate a second private key; generating a first key based on the second private key and the first public key; Processing the response according to the first public key includes: decrypting the response according to the first secret key.

5. The method according to claim 3 or 4, It is characterized in that The response to the third request also includes a first token, and sending the first request to the first service includes: The first request including the first token is sent to the first service.

6. A data processing method, It is characterized in that The method comprises: Receiving a first request from a third service, wherein the first request includes a second public key; The first request is processed according to the second public key.

7. The method according to claim 6, It is characterized in that Before processing the first request according to the second public key, the method further includes: Generate a first private key; Generate a first key based on the first private key and the second public key; The processing of the first request according to the second public key includes: decrypting the first request according to the first key.

8. The method according to claim 6 or 7, It is characterized in that The first request also includes a first token. Before receiving the first request from the third service, the method further includes: obtaining a first token public key from the second service; After receiving the first request from the third service, the method further includes: verifying the first token using the first token public key.

9. The method according to claim 8, It is characterized in that The first token is a token corresponding to the first interface, and the verifying the first token by using the first token public key includes: Generate a first token key for the first interface based on the first token public key and the interface ID of the first interface; The first token is verified using the first token key.

10. The method according to claim 8 or 9, It is characterized in that Obtaining the first token public key from the second service includes: When sending a registration request to the second service, the first token public key is obtained from the second service.

11. A data processing method, the method being applied to a service interaction system, the service interaction system comprising a first service, a second service and a third service, It is characterized in that The method comprises: The first service generates a first private key and a first public key; The first service sends the first public key to the second service; The third service obtains the first public key from the second service; The third service generates a second private key and a second public key, and generates a first key based on the second private key and the first public key; The third service sends a first request to the first service, where the first request includes the second public key and data encrypted by the first key; The first service generates the first key based on the first private key and the second public key, and decrypts the encrypted data in the first request; The first service returns a response to the first request to the third service, wherein the response includes data encrypted by the first key; The third service decrypts the encrypted data in the response based on the first key.

12. The method according to claim 11, It is characterized in that Before the first service sends the first public key to the second service, the method further includes: The first service generates a third private key and a third public key; The first service sends a second request to the second service, the second request including the third public key; The second service returns a response to the second request to the first service, where the response to the second request includes a fourth public key of the second service; The first service generates a second key based on the third private key and the fourth public key; The first service sending the first public key to the second service includes: The first service sends the first public key encrypted by the second key to the second service.

13. The method according to claim 11 or 12, It is characterized in that After the first service sends the first public key to the second service, the method further includes: The second service stores a mapping relationship between the first public key and the identifier of the third service; The third service obtains the first public key from the second service, including: The third service obtains the first public key from the mapping relationship of the second service.

14. The method according to any one of claims 11 to 13, It is characterized in that The first request also includes a first token, After the first service sends the first public key to the second service, the method further includes: the first service obtains a first token public key from the second service; The third service obtains the first public key from the second service, comprising: the third service obtains the first public key and the first token from the second service; After the third service sends the first request to the first service, the method further includes: the first service verifies the first token using the first token public key.

15. The method according to claim 14, It is characterized in that The first token is a token corresponding to the first interface of the first service, and the first service verifies the first token using the first token public key, including: The first service generates a first token key for the first interface based on the first token public key and the interface ID of the first interface; The first service verifies the first token using the first token key.

16. The method according to claim 14 or 15, It is characterized in that Verification of the first token includes any one or more of the following: verification of the validity period of the first token, determination of whether the first token is authorized to the first interface, verification of the signature of the first token, verification of the legitimacy of the first token, verification of the issuer of the first token, or verification of customized parameters of the first token.

17. The method according to any one of claims 14 to 16, It is characterized in that The first service obtains a first token public key from the second service, including: When the first service sends a registration request to the second service, the first service obtains the first token public key from the second service.

18. The method according to any one of claims 14 to 17, It is characterized in that The third service obtains the first public key and the first token from the second service, including: When the third service sends a token application request to the second service, the third service obtains the first public key and the first token from the second service.

19. The method according to any one of claims 11 to 18, It is characterized in that The second service is configured with authorization information of the first service, and the authorization information includes one or more of the following: authentication level, and validity period of the first token.

20. The method according to claim 19, It is characterized in that The authentication level includes one or more of the following: advanced authentication, ordinary authentication, no authentication, and access prohibited, wherein the advanced authentication corresponds to a token signature algorithm that uses a combination of the ECDSAwithSHA256 algorithm and the HmacSHA256 algorithm.

21. The method according to any one of claims 15 to 20, It is characterized in that The second service also periodically updates the first token public key and the first token secret key.

22. The method according to any one of claims 15 to 21, It is characterized in that The method further comprises: The first service reconfigures authorization information for the third service in the second service; The second service generates a first token public key and a first token secret key based on the reconfiguration authorization information; The first service receives a message from the second service, wherein the message includes the regenerated first token public key.

23. An electronic device, It is characterized in that include: A memory and a processor, the memory being used to store a computer program, the processor being used to execute the computer program to perform the method as described in any one of claims 1 to 5, or the method as described in any one of claims 6 to 10, or the method performed by the first service in the method as described in any one of claims 11 to 22, or the method performed by the second service in the method as described in any one of claims 11 to 22, or the method performed by the third service in the method as described in any one of claims 11 to 22.

24. A service interaction system, It is characterized in that include: A first electronic device, a second electronic device and a third electronic device, the first electronic device is used for the method executed by the first service in the method as described in any one of claims 11-22, the second electronic device is used for the method executed by the second service in the method as described in any one of claims 11-22, and the third electronic device is used to execute the method executed by the third service in the method as described in any one of claims 11-22.

25. A computer-readable storage medium, It is characterized in that The computer-readable storage medium stores instructions, which, when executed, cause the computer to execute the method as described in any one of claims 1-5, or the method as described in any one of claims 6-10, or the method executed by the first service in the method as described in any one of claims 11-22, or the method executed by the second service in the method as described in any one of claims 11-22, or the method executed by the third service in the method as described in any one of claims 11-22.

26. A computer program product, It is characterized in that It comprises a computer program, which, when executed, enables the electronic device to execute the method as described in any one of claims 1 to 5, or the method as described in any one of claims 6 to 10, or the method executed by the first service in the method as described in any one of claims 11 to 22, or the method executed by the second service in the method as described in any one of claims 11 to 22, or the method executed by the third service in the method as described in any one of claims 11 to 22.

Images