Token authentication method and related device

Abstract

The embodiment of the invention provides a token authentication method and a related device, and relates to the technical field of communication. The method comprises the steps that a service provider can obtain a public key of a token from STS service in advance, and after the service provider receives a service request of a service requester, the service provider can locally use the public key of the token to verify the token. Thus, the service provider does not need to initiate an additional request to the STS service to verify the token, the concurrent processing capability and efficiency of the service provider are improved, and the processing time delay during service interaction between the service requester and the service provider is shortened.

Description

Technical Field

[0001] The present application relates to the field of communication technology, and in particular to a token authentication 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 interaction is performed between a service requester and a service provider, the concurrent processing capability and efficiency of the service provider are low, and the business request latency of the service requester is high. Summary of the invention

[0004] In the token authentication method and related device provided in the embodiment of the present application, the service provider can obtain the public key of the token from the STS service in advance. When the service provider receives the service 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 an additional request to the STS service to verify the token.

[0005] In a first aspect, the token authentication method provided by the embodiment of the present application comprises:

[0006] A first request from a first service is received, the first request including a first token; and the first token is verified using a first token public key, wherein the first token public key is obtained in advance from a second service request. 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 perform business interaction is shortened.

[0007] 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.

[0008] 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 security of the interaction between services is improved, and the identity and access rights of the service requester can be controlled.

[0009] In a possible implementation, before receiving the first request from the first service, the method further includes: sending a second request to the second service; receiving a response to the second request from the second service, wherein the response to the second request includes the first token public key. 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.

[0010] In a possible implementation, before sending the second request to the second service, the method further includes: generating a first private key and a first public key; sending a third request to the second service, the third request including the first public key; receiving a response to the third request from the second service, the response to the third request including the second public key of the second service; generating a first key based on the first private key and the second public key; sending the second request to the second service, including: sending the second request encrypted by the first key to the second service. In this way, during the interaction between the service provider and the STS service, the first key can be used to encrypt the transmitted data to protect the security of the data during transmission.

[0011] 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.

[0012] 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 can be made at a higher level and less likely to be cracked, thereby making the transmitted data more secure.

[0013] 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.

[0014] In a possible implementation, the method further includes: reconfiguring authorization information for the first service in the second service, so as to regenerate the first token public key and the first token secret key for the second service. In this way, the STS service can provide the service provider with the ability to remove the authorization key and reissue a new key, and support the configuration and update capability of the first token public key at the service level and the first token secret key at the interface level, thereby improving the security of the token.

[0015] In a possible implementation, after reconfiguring the authorization information for the first service in the second service, the method further includes: receiving a message from the second service, wherein the message includes the regenerated first token public key. In this way, the service provider can obtain the latest key information in a timely manner, thereby improving the timeliness of key updates.

[0016] In a second aspect, a token authentication method provided in an embodiment of the present application 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:

[0017] The third service obtains the first token public key from the second service; the third service receives the first request from the first service, wherein the first request includes the first token, which is obtained by the first service from the second service request in advance; the third service verifies the first token using the first token public key. In this way, the third service no longer needs to verify the first token with the STS service as the center, thus achieving the decentralization of token verification and reducing the pressure of concurrent processing of the STS service; the third service can verify the token locally, thus achieving the localization of token verification and reducing the delay of business processing.

[0018] In a possible implementation, the first token is a token corresponding to the first interface of the third service, and the third service verifies the first token using the first token public key, including: the third service generates the first token key of the first interface based on the first token public key and the interface ID of the first interface; the third 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.

[0019] In a possible implementation, the third service obtains the first token public key from the second service, including: when the third service sends a registration request to the second service, the third service obtains the first token public key from the second service. In this way, the service provider obtains the first token public key from the STS service, and the first token public key can be synchronized between the service provider and the STS service. Therefore, 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.

[0020] In a possible implementation, the first token is a token generated by the second service. Before the third service receives the first request from the first service, it also includes: the first service determines whether there is a cached and valid first token; if the first service determines that there is a cached first token and the first token is within the validity period, the first service sends the first request to the third service; if the first service determines that there is a cached first token, but the first token is not within the validity period, or the first service determines that there is no cached first token, the first service obtains the first token from the second service. In this way, when the first service accesses the third service, the identity of the first service is credible and the access rights are controllable, so that business interaction with the third service is effective.

[0021] In a possible implementation, the first service obtains the first token from the second service, including: the first service sends a fourth request to the second service; the second 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, wherein the interface ID of the first interface is obtained by the second service from the registration request sent by the third service; the second service generates the first token based on the first token key; the first service receives a response to the fourth request from the second service, wherein the response to the fourth request includes the first token. In this way, the first token is updated to the local of the first service in a timely manner, thereby facilitating business interaction with the third service through the first token.

[0022] 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.

[0023] 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.

[0024] 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.

[0025] In a possible implementation, the method further includes: the third service reconfiguring authorization information for the first service in the second service; the second service generating a first token public key and a first token secret key based on the reconfigured authorization information; and the third service receiving a message from the second service, the message including the regenerated first token public key. In this way, the service provider can obtain the latest key information in a timely manner, thereby improving the timeliness of key updates.

[0026] In a third aspect, an embodiment of the present application provides a token authentication 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 performed 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 second aspect or any possible implementation of the second aspect, or the second service in the second aspect or any possible implementation of the second aspect, or the third service in the second aspect or any possible implementation of the second 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 performed by the first service described in the second aspect or any possible implementation of the second aspect, or the method performed by the second service described in the second aspect or any possible implementation of the second aspect, or the method performed by the third service described in the second aspect or any possible implementation of the second aspect. 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 executed by the first service described in the second aspect or any possible implementation of the second aspect, or the method executed by the second service described in the second aspect or any possible implementation of the second aspect, or the method executed by the third service described in the second aspect or any possible implementation of the second aspect. The storage unit may be a storage unit within the chip (e.g., a register, a cache, etc.), or a storage unit within the electronic device that is located outside the chip (e.g., a read-only memory, a random access memory, etc.).

[0027] In a fourth 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 executed by the first service in the method described in the second aspect or any possible implementation of the second aspect, or the method executed by the second service in the method described in the second aspect or any possible implementation of the second aspect, or the method executed by the third service in the method described in the second aspect or any possible implementation of the second aspect.

[0028] In a fifth 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 second aspect or any possible implementation of the second aspect, the second electronic device being used to execute a method executed by the second service in the method described in the second aspect or any possible implementation of the second aspect, and the third electronic device being used to execute a method executed by the third service in the method described in the second aspect or any possible implementation of the second aspect.

[0029] In a sixth 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 executed by the first service in the method described in the second aspect or any possible implementation of the second aspect, or the method executed by the second service in the method described in the second aspect or any possible implementation of the second aspect, or the method executed by the third service in the method described in the second aspect or any possible implementation of the second aspect.

[0030] In the seventh aspect, an embodiment of the present application provides a computer program product including 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 executed by the first service in the method described in the second aspect or any possible implementation of the second aspect, or the method executed by the second service in the method described in the second aspect or any possible implementation of the second aspect, or the method executed by the third service in the method described in the second aspect or any possible implementation of the second aspect.

[0031] In an eighth 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.

[0032] 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.).

[0033] It should be understood that the third to eighth aspects of the present application correspond to the technical solutions of the first or second aspect 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

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

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

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

[0037] Figure 4 An authentication process for service A and service B provided in an embodiment of the present application;

[0038] Figure 5 A business interaction diagram of service A, service B and STS provided in an embodiment of the present application;

[0039] Figure 6 An interaction diagram of an A service applying for a token from an STS service provided in an embodiment of the present application;

[0040] Figure 7 A schematic diagram of a token verification between service A and service B provided in an embodiment of the present application;

[0041] Figure 8 A schematic diagram of a client login authentication scenario provided in an embodiment of the present application;

[0042] Fig. 9A schematic diagram of a gateway authentication scenario provided in an embodiment of the present application;

[0043] Fig.10 A schematic diagram of gateway authentication for a microservice cluster integrated with STS.SDK provided in an embodiment of the present application;

[0044] Fig.11 A schematic diagram of gateway authentication of a gateway integrated with STS.SDK provided in an embodiment of the present application;

[0045] Fig.12 A schematic diagram of a token authentication method provided in an embodiment of the present application;

[0046] Fig.13 A schematic diagram of another token authentication method provided in an embodiment of the present application;

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

[0048] 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:

[0049] 1. ECC: elliptic curves cryptography (ECC).

[0050] ECDH: ECC-based key agreement algorithm (elliptic curve diffie-hellman, ECDH). ECDH can also be understood as an algorithm for exchanging public keys and generating symmetric keys.

[0051] For example, Figure 1 As shown, when service X and service Y use the ECDH key agreement algorithm, service X can generate an ECC public key pbkey-X and an ECC private key prikey-X.

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

[0053] In this way, the X service locally stores the private key prikey-X and the public key pbkey-Y of the Y service, and the Y service locally stores the private key prikey-Y and the public key pbkey-X of the X service. The X service can generate the symmetric key aeskey based on prikey-X and pbkey-Y after the ECC algorithm, and the Y service can also generate the symmetric key aeskey based on prikey-Y and pbkey-X after the ECC algorithm. In other words, after the X service and the Y service 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.

[0054] After generating the ECDH negotiation key sessionKey, service X and service Y can interact with each other based on the same symmetric key aeskey. In this way, ECDH does not need to transmit the symmetric key aeskey, reducing the possibility of the key being intercepted during transmission, thereby improving the security of service interaction between service X and service Y.

[0055] 2. 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.

[0056] 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.

[0057] 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.

[0058] For ease of description, the service requester is referred to as service A and the service provider is referred to as service B. Service A and service B can be any of the above cloud services, which is not limited in the embodiments of the present application.

[0059] Figure 2 The module architecture diagram of the STS service is shown.

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

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

[0062] 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.

[0063] 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.

[0064] 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.

[0065] 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.

[0066] 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.

[0067] 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.

[0068] 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.

[0069] 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.

[0070] 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.

[0071] Figure 3 Shows the architecture diagram of the STS.SDK toolkit.

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

[0073] The encryption and decryption module can perform ECDH negotiation key encryption and decryption, advanced encryption standard (AES) algorithm encryption and decryption, and RSA public and private key encryption and decryption processes. Among them, 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 ECC private key, and the sessionKey is used to encrypt or decrypt the transmitted data, thereby improving the security of data transmission.

[0074] The signature module can execute processes such as Sha256 hash algorithm, hash-based message authentication code (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 Sha256hash algorithm to verify the signature of the token. Among them, signature verification can also be called signature verification.

[0075] 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 token authentication locally, and the token authentication will pass by default. This can maintain the availability of business services.

[0076] 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.

[0077] 3. Terminology

[0078] 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.

[0079] 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.

[0080] 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.

[0081] 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.

[0082] If the service provided by service B to service A is accessed by an untrusted third party, the third party may obtain service data and / or modify service content, resulting in information leakage. Therefore, in order to prevent the service provided by service B to service A from being accessed by an untrusted third party, an authentication and authorization strategy is required between service B and service A. Service B can authenticate the identity and access rights of service A, thereby ensuring that the identity and access rights of service A are controllable.

[0083] The following takes service A as a game center service and service B as an account service as an example to illustrate the authentication process between service A and service B in some implementations.

[0084] like Figure 4 As shown, when a user wants to log in to the account of the game center application, the game center application needs to interact with the account service through the game center service in the cloud server to realize the login of the user account.

[0085] It is understandable that before the game center service interacts with the account service, on the STS service side, the account service needs to first authorize the game center service. After allowing the game center service to access the account service, the STS service can provide the game center service with a token, which includes the permission for the game center service to access the account service. The game center service saves the token locally.

[0086] When logging into an account through the Game Center service, the Game Center service can carry a token to initiate a business request to the Account Service. After the Account Service receives the request from the Game Center service, it needs to first initiate a Hypertext Transfer Protocol (HTTP) or Hypertext Transfer Protocol Secure (HTTPS) request to the STS service, and verify the token through the STS service. The STS service's verification of the token may include verification of the issuer, whether the access interface is correct, verification of the token validity period, and whether the signature algorithm has been tampered with.

[0087] After the STS service successfully verifies the token, it can return the token verification success message to the account service. Then, the account service can interact with the game center service.

[0088] However, for service B, when processing business requests, service B needs to first initiate an additional HTTP or HTTPS request to the STS service to verify the token, which reduces the concurrent processing capability and efficiency of service B. For service A, the overall latency of service A's business request includes the link time of the HTTP or HTTPS request initiated by service B to the STS service, thereby lengthening the processing latency of service A's business request. For STS services, when multiple services need to verify tokens or multiple business interfaces of a service need to verify tokens, it puts a lot of pressure on the concurrent processing of STS services.

[0089] In view of this, in the token authentication method provided in the embodiment of the present application, 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 an additional request 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.

[0090] Figure 5 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 service STS, (2) interaction between service A and service STS, and (3) interaction between service A and service B.

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

[0092] 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.

[0093] 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.

[0094] 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. For example, the authentication level may include advanced authentication, ordinary authentication, no authentication, access prohibited, etc.

[0095] 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.

[0096] 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.

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

[0098] 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.

[0099] When service B starts or obtains tasks from service STS, service B can send a request for pre-registration service RreRegist to service STS. In this request, 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 sent by service B from being tampered with, and the service certificate is to prove that the identity of service B is credible.

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

[0101] Exemplarily, the STS service can use the elliptic curve digital signature algorithm (ECDSA) public key of service B to verify the request 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 pbkey-B11 is different from pbkey-B1.

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

[0103] 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 requested by 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.

[0104] After verifying the signature and certificate of the B service request, 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.

[0105] 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.

[0106] 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.

[0107] 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.

[0108] 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.

[0109] (1.2) Registration process for Service B.

[0110] After the B service and the STS service exchange ECC public keys, the B service can send a request for the registration service RegistServer to the STS service to obtain the authorization information of the interface-X interface, which includes the authorization for the A service. In the request, 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.

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

[0112] intfid can be understood as a unique identifier at the service interface level. In some implementations, intfid can also be represented by interfaceName.

[0113] 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.

[0114] After receiving the registration request from service B, the STS service can verify the signature and certificate of the request. 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 (1.1) above, which will not be repeated here.

[0115] After verifying the signature and certificate of the B service request, the STS service can save information such as the B service's public key pbkey-B2 required for the B service to interact with the A service.

[0116] 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.

[0117] 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.

[0118] 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.

[0119] 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.

[0120] 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.

[0121] 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 token and key at the interface level can be achieved, which improves the security of interface access.

[0122] In a possible implementation, if the authentication level configured for service B is normal authentication, the STS service can sign the token once based on the serviceKey and use the HmacSHA256 signature algorithm.

[0123] If the authentication level configured for service B is advanced authentication, the STS service can sign the token once based on the serviceKey and use the HmacSHA256 signature algorithm; the STS service can also sign the token twice based on the token signature key tokenSignPbKey and use the ECDSAwithSHA256 signature algorithm.

[0124] It is understandable that using only the HmacSHA256 signature algorithm can be called a one-layer signature algorithm or a common signature algorithm. The signature algorithm that uses the ECDSAwithSHA256 signature algorithm and the HmacSHA256 signature algorithm can be called a two-layer signature algorithm or an advanced signature algorithm. The use of a two-layer signature algorithm can make the token signature algorithm higher in level and less likely to be cracked, thereby making the transmitted data more secure.

[0125] In addition, the STS-MANAGE security token configuration service of the STS service can also support the update of the public key masterKey1 of the service-level token and the key serviceKey of the interface-level token, for example, including the following aspects:

[0126] First, the STS service can reconfigure the authorization data according to the requirements of the B service, triggering the update of the token key serviceKey1. The B service can obtain the latest authorization information and the latest serviceKey from the STS service, thereby supporting the B service's ability to control the removal of the authorization key and reissue a new key, improving the security of the token.

[0127] Secondly, the STS service can delete the B service registration data according to the requirements of the B service and trigger the cleanup of the token's public key masterKey1. After the B service re-registers the service, the STS service can generate a new token's public key masterKey1 and generate a new key serviceKey based on masterKey1.

[0128] Thirdly, the STS service can adopt a key expiration rotation strategy. For example, the STS service can regularly update masterKey1 and serviceKey for the registered and authorized configuration data. The update cycle can be set by the STS service or the B service. For example, the update cycle can be 1 day or 1 week, etc., which is not limited in the embodiments of this application. The B service can obtain the latest service authorization information and key information, etc., and synchronize the latest generated masterKey1 and serviceKey information to improve the security of the token key.

[0129] Fourthly, when the masterKey1 and / or serviceKey of service B in the STS service changes, the STS service can trigger a callback and push the updated key information to service B, so that service B can obtain the latest key information in a timely manner, thereby improving the timeliness of key updates.

[0130] It is understandable that based on the pre-registration and registration process, service B can synchronize masterKey1 and serviceKey, and realize the ability of service B to start obtaining and automatically update the token key.

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

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

[0133] 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.

[0134] 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 to service B, and the request will carry the token.

[0135] 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 to the STS service for a token to access service B's interface-X.

[0136] 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 also 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.

[0137] 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 the public key masterKey2 of the token generated by service STS for service A.

[0138] In the request from service A to the STS service for a token, the signature of service A, the certificate chain of service A, and the request data encrypted by masterKey2 can be carried. The data can include information such as timestamp, service ID appid of service B, and interface ID intfid of interface-X. (2.2) The STS service returns information such as a token.

[0139] After the STS service obtains the request for a token from service A, it can verify the signature and certificate of 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.

[0140] After passing the signature and certificate verification for the request to service A, the STS service can query whether the interface-X of service B is authorized to service A.

[0141] 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.

[0142] 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.

[0143] 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.

[0144] 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.

[0145] 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 sent to service B.

[0146] Figure 6 The figure shows a detailed diagram of service A applying for a token from service STS to access service B.

[0147] When service A accesses interface-X of service B, service A can first determine whether there is a valid token corresponding to interface-X cached in the memory. The specific determination method may refer to the above (2.1) description of service A requesting a token from the STS service, which will not be repeated here.

[0148] If service A does not have a valid token for interface-X locally, service A can send a request to the STS service to apply for a token for accessing interface-X. The specific data carried in the request can refer to the description of service A requesting a token from the STS service above (2.1), which will not be repeated here.

[0149] After the STS service obtains the request for a token from service A, it can perform a circular check of the certificate chain, public key resolution, and signature authentication on service A based on the local root certificate rootCA, thereby obtaining the certificate public key pbKeyCertA of service A.

[0150] The STS service can use pbKeyCertA to verify the signature of service A. If the signature verification succeeds, it means that the request content of service A has not been tampered with during the transmission process; if the signature verification fails, it means that the request content of service A has been tampered with during the transmission process, and the STS service returns an exception.

[0151] The STS service can also determine whether service A is registered from the STS service cache registration cache based on the service ID appid of service A; it can also determine whether service B is registered from the STS service cache registration cache based on the service ID appid of service B. If the STS service determines that service A and / or service B are not registered, service A cannot obtain the token of the interface-X interface, and the STS service returns an exception to service A.

[0152] The STS service can also determine whether service A is in the whitelist of accessible services registered by service B.

[0153] If service A is not in the whitelist of accessible services registered by service B, it means that the whitelist verification fails and service B does not allow service A to access it. Then the STS service returns an exception to service A.

[0154] If service A is in the whitelist of accessible services registered by service B, it means that the whitelist verification has passed and service B allows service A to access. Then the STS service can encrypt and return the token of interface-X to service A. The specific process of STS service generating token and returning token can refer to the relevant description in the above (2.2) STS service side returns token and other information, which will not be repeated here.

[0155] It is understandable that the STS service may store a configuration item switch for indicating whether service B can be requested without carrying a token. For example, the configuration item switch may be named sts.service.enable. The data type of the configuration item switch may include integer, Boolean, string, and other types. For example, when the configuration item switch value is true, it indicates that service B needs to be requested with a token; when the configuration item switch value is false, it indicates that service B can be requested without carrying a token and using HTTP or HTTPS. The configuration item switch can be set by service B. The naming and value of the specific configuration item switch are not limited in the embodiments of the present application.

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

[0157] (3.1) Service A initiates a business request to service B.

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

[0159] In a possible implementation, service A can use double-layer encryption to send a request to service B. The request 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.

[0160] 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.

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

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

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

[0164] 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.

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

[0166] 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.

[0167] 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.

[0168] For the double-encrypted request sent by service A, STS.SDK can verify the token twice based on serviceKey and token signature key tokenSignPbKey. The two verifications can also be called double verification or advanced authentication.

[0169] In possible implementations, STS.SDK can use serviceKey to verify the HmacSHA256 signature algorithm and perform the first signature verification on the token, which is called one-time signature verification. STS.SDK can also use the token signature key tokenSignPbKey to verify the ECDSAwithSHA256 signature algorithm and perform the second signature verification on the token, which is called two-time signature verification.

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

[0171] 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.

[0172] 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 of service A can carry the interface information to be accessed. Service B can determine whether the interface information in the token requested by 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 interface-X interface authorizes service A to access the interface-X interface of service B.

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

[0174] 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 to service A.

[0175] Figure 7 The figure shows the process flow of token verification between service A and service B.

[0176] In a possible implementation, service A and service B can agree in advance on the base for generating the ECC public key and ECC private key of ECDH, as well as the shared parameter p, where the base can be obtained from the service ID appid of service B and the certificate serial number serialNum of service B. Alternatively, service A and service B can also use the generated random number as a parameter for generating the ECC public key and ECC private key, which is not limited in the embodiments of the present application.

[0177] After service A generates ECC private key prikey-A2 and ECC public key pbkey-A2, service B generates ECC private key prikey-B2 and ECC public key pbkey-B2, and they exchange their public keys, service A can generate ECDH negotiation key sessionKey3 between service A and service B based on service A's ECC private key prikey-A2 and service B's public key pbkey-B2. Service B can generate ECDH negotiation key sessionKey3 between service A and service B based on service B's ECC private key prikey-B2 and service A's public key pbkey-A2.

[0178] Before service A interacts with service B, service A needs to check whether there is a token cached locally for accessing interface-X of service B. The specific process of service A querying and updating the token can refer to the above description of (2.1) service A requesting the token from the STS service, which will not be repeated here.

[0179] Service A can use double encryption to send request data to service B. For details, please refer to the above (3.1) description of service A initiating a business request to service B, which will not be repeated here.

[0180] Service B can verify the signature and certificate chain of Service A based on STS.SDK. The specific process of verifying the signature and certificate chain can refer to the above (3.2) description of Service B verifying Service A's request, which will not be repeated here.

[0181] After STS.SDK verifies the request of service A, service B can decrypt the encrypted data EncryptData of the request based on sessionKey3, obtain the decrypted request data data, and then perform business processing.

[0182] It is understandable that during the process of service B verifying the request of service A, service B may return an exception to service A. Among them, the abnormal scenarios may include the following situations:

[0183] (a) The signature verification or certificate chain verification of service A fails and an exception is returned.

[0184] (b) When parsing the request data, if there is no token, the access authentication level of service A is determined. If the access authentication level of service A is not satisfied, an exception is returned.

[0185] (c) If STS.SDK detects that service B does not have a local token key, it will go to the STS service to obtain the token key; if STS.SDK detects that service B has not been registered, it will return an exception and trigger the registration process for service B. It should be noted that if STS.SDK detects that service STS does not exist, it will perform authentication verification on service A and downgrade it to normal.

[0186] (d) STS.SDK fails to verify the token and returns an exception.

[0187] In an embodiment of the present application, service B can obtain key information related to the token through the pre-registration and registration process, and perform local verification of the token through the integrated STS.SDK, so that service B can serve as a verification center for the token, thereby implementing verification of the token locally in service B, thereby reducing the latency of business requests while maintaining interaction security and implementing verification functions.

[0188] It is understandable that the embodiments of the present application can be applied to token verification between multiple services. For example, when each service is started, it can go to the STS service to obtain the authorization information between the services, as well as related information such as the token key. After each service obtains the token key and other related information, each service can perform token verification locally. In this way, each service no longer needs to perform token verification centered on the STS service, which realizes the decentralization of token verification and reduces the pressure of concurrent processing of the STS service; each service can perform token verification locally, realizes localized token verification, and reduces the delay of business processing.

[0189] Optionally, the token authentication method of the embodiment of the present application can also be applied to the interaction scenario between the server Server and the client Client. For example, the interaction scenario may include a client login authentication scenario.

[0190] For example, Figure 8 It shows the interaction between the authorization center of the server and the client in the client login authentication scenario.

[0191] Both the server and the client can integrate the STS.SDK toolkit. The server can include business services and authorization centers. Business services can interact with clients, and the authorization center can verify the client's token based on STS.SDK.

[0192] Exemplarily, when logging into an account, the client may send a login interface to the authorization center of the server, for example, the login interface may be login(). The client may pass the user name name and password pwd in the login interface login().

[0193] The authorization center can log in to authenticate the digital signature and verify the signature of the client. After the signature is verified, the authorization center can generate and return a token and refresh_token for the client. Among them, when the token expires, the client can use the refresh_token to request a new token from the server.

[0194] The client can save the obtained token and refresh_token locally. The client can also carry the token to request server resources.

[0195] If the server passes the token verification, the resource can be returned to the client.

[0196] If the authorization center determines that the token has expired or the signature verification fails, it will return a prompt message indicating that the verification failed to the client. Then, the client can carry the refresh_token to request server resources.

[0197] If the authorization center passes the refresh_token refresh token verification, the authorization center can generate a new token token and a new refresh_token refresh token, and return the new token token and the new refresh_token refresh token to the client. The client can discard the previously saved token token and refresh_token refresh token, and save the new token token and the new refresh_token refresh token. The client can use the new token token to request resources from the server.

[0198] If the authorization center fails to verify the refresh_token refresh token, a prompt message indicating that the verification failed will be returned to the client, and the client will be required to log in to the account again.

[0199] The authorization center of the server can verify the token locally on the server by integrating STS.SDK, so that the server can serve as the verification center of the token, thereby realizing local token verification on the server. While maintaining the interaction security and realizing the verification function, it improves the server's concurrent processing capacity and efficiency, and shortens the delay of client login authentication.

[0200] Optionally, the token authentication method of the embodiment of the present application can also be applied to a gateway authentication scenario, where the gateway can include a Zuul gateway or the like.

[0201] In some implementations, such as Fig. 9 As shown, the client can first apply for a token from the authorization center AuthorizationCenter through the gateway. After successful authorization, the authorization center can return the token to the gateway, and then the gateway can return the token to the client.

[0202] When the client sends a user request to the gateway, it can carry a token, and the gateway can send the token to a server in the microservice cluster, such as server A. It is understandable that server A can include the above-mentioned account service, etc.

[0203] Server A can send the token to the authorization center, and the authorization center can remotely authenticate the client's token. After the authentication is passed, the authorization center can return the user's request authorization information to server A. Then, the gateway can obtain the service list of server A through the registration center, so as to interact with the client.

[0204] In one possible implementation, STS.SDK can be integrated into the microservice cluster to implement local verification of tokens.

[0205] Fig.10 It shows the gateway authentication scenario when STS.SDK is integrated in the microservice cluster.

[0206] The client can first apply for a token from the authorization center through the gateway. After successful authorization, the authorization center can return the token to the gateway, and then the gateway can return the token to the client.

[0207] When the client sends a user request to the gateway, it can carry a token, and the gateway can send the token to a server in the microservice cluster, such as server A. Server A can perform local authentication on the client's token based on STS.SDK. After the authentication is passed, the registration center can return the service list of server A to the gateway, and then the gateway and the client can interact with each other.

[0208] In this way, by integrating STS.SDK in the microservice cluster, the microservice cluster can have interface-level token authentication capabilities.

[0209] In another possible implementation, the gateway can integrate STS.SDK to implement local verification of the token.

[0210] Fig.11 It shows the gateway authentication scenario when the gateway integrates STS.SDK.

[0211] The client can first apply for a token from the authorization center through the gateway. After successful authorization, the authorization center can return the token to the gateway, and then the gateway can return the token to the client.

[0212] When the client initiates a service request to the gateway to access server A, it can carry a token, and the gateway can perform local authentication on the client's token based on STS.SDK. After the authentication is passed, the registration center can return the service list of server A to the gateway, and then the gateway and the client can interact with each other.

[0213] In this way, by integrating STS.SDK in the gateway, the gateway can have interface-level token authentication capabilities.

[0214] 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.

[0215] Fig.12The token authentication method of the embodiment of the present application is shown. The method includes:

[0216] S1201. Receive a first request from a first service, where the first request includes a first token.

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

[0218] 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 5 This corresponds to the business request initiated by service A to service B in the embodiment.

[0219] 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 5 This corresponds to the token used when service A accesses interface-X of service B in the embodiment.

[0220] The service provider may receive a first request from a first service, wherein the service provider may be the above Figure 5 The corresponding embodiment of the B service. The specific first service sends the first request to the second service can refer to the above Figure 5 The description of (3.1) service A initiating a business request to service B in the corresponding embodiment will not be repeated here.

[0221] S1202: Use the first token public key to verify the first token, where the first token public key is obtained in advance from the second service request.

[0222] In the embodiment of the present application, 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 5 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.

[0223] The second service can be understood as a service for generating the first token public key. For example, the second service can be the above Figure 5 Corresponding to the authorization center or STS service in the embodiment.

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

[0225] 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.

[0226] Optional, in Fig.12 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.

[0227] 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 5 This corresponds to the interface-X of service B in the embodiment.

[0228] 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 5 Corresponding to intfid or interfaceName in the embodiment.

[0229] 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 5 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 5 The description of generating serviceKey in the corresponding embodiment will not be repeated here.

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

[0231] 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.

[0232] Optional, in Fig.12 Based on the corresponding embodiments, the verification of the first token may include 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.

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

[0234] 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.

[0235] Optional, in Fig.12 On the basis of the corresponding embodiment, before receiving the first request from the first service, it may also include: sending a second request to the second service; receiving a response to the second request from the second service, wherein the response to the second request includes the first token public key.

[0236] In the embodiment of the present application, the second request can be understood as any request sent by the service provider to the STS service. Through the second request, the service provider can obtain the first token public key from the STS service. For example, the second request can be understood as the above Figure 5 The corresponding embodiment is a registration service request sent by the B service to the STS service. The specific second request sent is not limited in the embodiment of the present application.

[0237] The specific process of the service provider sending the second request to the STS service and the service provider obtaining the first token public key can refer to the above Figure 5 The description of the registration process of service B in the corresponding embodiment (1.2) is not repeated here.

[0238] The service provider obtains the first token public key from the STS service, and can synchronize the first token public key between the service provider and the STS service. Thus, 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.

[0239] Optional, in Fig.12On the basis of the corresponding embodiment, before sending the second request to the second service, it may also include: generating a first private key and a first public key; sending a third request to the second service, the third request including the first public key; receiving a response to the third request from the second service, the response to the third request including the second public key of the second service; generating a first key based on the first private key and the second public key; sending the second request to the second service may include: sending the second request encrypted by the first key to the second service.

[0240] In the embodiment of the present application, 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 STS service. Figure 5 Corresponding to the ECC private key prikey-B1 of service B in the embodiment, the first public key can be the above Figure 5 This corresponds to the ECC private key pbkey-B1 of service B in the embodiment.

[0241] The third request can be understood as a request from the service provider to transfer the first public key to the STS service. Figure 5 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 5 The description of the pre-registration process of service B in the corresponding embodiment (1.1) is not repeated here.

[0242] The second public key can be understood as a public key generated by the STS service, and the second public key can be used to interact with the service provider. Figure 5 This corresponds to the ECC private key pbkey-S1 of the STS service in the embodiment.

[0243] The first 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 5 This corresponds to the ECDH negotiated key sessionKey1 between the B service and the STS service in the embodiment.

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

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

[0246] 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 5 For the authentication level in the corresponding embodiment, the specific authentication level can refer to the above Figure 5 The relevant description of the authentication level in the corresponding embodiment is not repeated here.

[0247] 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.

[0248] Optional, in Fig.12 Based on the corresponding embodiments, the authentication level includes 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.

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

[0250] 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.

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

[0252] 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.

[0253] Optional, in Fig.12 Based on the corresponding embodiment, the method may further include: reconfiguring authorization information for the first service in the second service, so as to regenerate the first token public key and the first token secret key for the second service.

[0254] In an embodiment of the present application, the STS service can provide the service provider with the ability to remove authorization keys and reissue new keys, support the configuration update capability of the first token public key at the service level and the first token key at the interface level, thereby improving the security of the token.

[0255] Optional, in Fig.12 On the basis of the corresponding embodiment, after reconfiguring the authorization information for the first service in the second service, the method may further include: receiving a message from the second service, wherein the message includes the regenerated first token public key.

[0256] 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.

[0257] Fig.13 Another token authentication method of an embodiment of the present application is shown. The method includes:

[0258] S1301. The third service obtains the first token public key from the second service.

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

[0260] The second service can refer to the above Fig.12 The relevant description of the second service in step S1202 of the corresponding embodiment is not repeated here.

[0261] The first token public key can refer to the above Fig.12 The relevant description of the first token public key in step S1202 of the corresponding embodiment is not repeated here.

[0262] The process of the third service obtaining the first token public key from the second service can refer to the above Fig.12 The relevant description of obtaining the first token public key in the corresponding embodiment will not be repeated here.

[0263] S1302: The third service receives a first request from the first service, where the first request includes a first token, wherein the first token is obtained in advance by the first service from the second service request.

[0264] In the embodiment of the present application, the first service can refer to the above Fig.12 The relevant description of the first service in step S1201 of the corresponding embodiment is not repeated here.

[0265] The first request can refer to the above Fig.12 The relevant description of the first request in step S1201 of the corresponding embodiment is not repeated here.

[0266] The first token can refer to the above Fig.12 The relevant description of the first token in step S1201 of the corresponding embodiment is not repeated here.

[0267] For details about how the third service receives the first request from the first service, please refer to the above Figure 5 The description of (3.1) service A initiating a business request to service B in the corresponding embodiment will not be repeated here.

[0268] S1303: The third service uses the first token public key to verify the first token.

[0269] In the embodiment of the present application, the third service uses the first token public key to verify the first token. Figure 5 The description of the request for B service to verify A service in the corresponding embodiment (3.2) will not be repeated here.

[0270] After obtaining the first token public key, the third service can perform the first token verification locally. In this way, the third service no longer needs to perform the first token verification centered on the STS service, which realizes the decentralization of token verification and reduces the pressure of concurrent processing of the STS service; the third service can perform token verification locally, realizes the localization of token verification, and reduces the delay of business processing.

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

[0272] In the embodiment of the present application, the first interface can refer to the above Fig.12 The interface ID of the first interface can refer to the above description of the first interface in the corresponding embodiment. Fig.12 The relevant description of the interface ID of the first interface in the corresponding embodiment is not repeated here.

[0273] The first token key can refer to the above Fig.12 The relevant description of the first token key in the corresponding embodiment will not be repeated. The first token can be verified by using the first token key, as described above. Figure 5 The description of the request for B service to verify A service in the corresponding embodiment (3.2) will not be repeated here.

[0274] 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.

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

[0276] In the embodiment of the present application, the service provider obtains the first token public key from the STS service, 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, realize the localized verification of the token, and reduce the delay of business processing.

[0277] Optional, in Fig.13 On the basis of the corresponding embodiment, the first token is a token generated by the second service. Before the third service receives the first request from the first service, it may also include: the first service determines whether there is a cached and valid first token; if the first service determines that there is a cached first token and the first token is within the validity period, the first service sends the first request to the third service; if the first service determines that there is a cached first token, but the first token is not within the validity period, or the first service determines that there is no cached first token, the first service obtains the first token from the second service.

[0278] In the embodiment of the present application, the first service determines whether there is a cached and valid first token, so that when the first service accesses the third service, the identity of the first service is trustworthy and the access rights are controllable, thereby effectively interacting with the third service.

[0279] Optional, in Fig.13 On the basis of the corresponding embodiment, the first service obtains the first token from the second service, which may include: the first service sends a fourth request to the second service; the second 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, wherein the interface ID of the first interface is obtained by the second service from the registration request sent by the third service; the second service generates the first token based on the first token key. The first service receives a response from the second service to the fourth request, and the response to the fourth request includes the first token.

[0280] In the embodiment of the present application, the fourth request can be understood as a request for applying for the first token sent by the service request direction to the STS service. For example, the fourth request can refer to the above Figure 5 The relevant description in (2.1) Service A requests a token from the STS service in the corresponding embodiment will not be repeated here.

[0281] The process in which the second service generates the first token based on the first token key and the first service receives the response to the fourth request from the second service can refer to the above Figure 5The relevant description of the information such as the token returned by the STS service in the corresponding embodiment (2.2) will not be repeated here.

[0282] The first service obtains the first token from the second service and can timely update the first token to the local of the first service, thereby facilitating business interaction with the third service through the first token.

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

[0284] In the embodiment of the present application, the authentication level can refer to the above Fig.12 The relevant description of the authentication level in the corresponding embodiment will not be repeated here.

[0285] 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.

[0286] Optional, in Fig.13 Based on the corresponding embodiments, the authentication level includes 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.

[0287] In the embodiment of the present application, a two-layer signature algorithm combining the ECDSAwithSHA256 algorithm and the HmacSHA256 algorithm is used to make the signature algorithm of the token higher in level and less likely to be cracked, thereby making the transmitted data more secure.

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

[0289] 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.

[0290] Optional, in Fig.13 Based on the corresponding embodiment, the method may further include: the third service reconfigures the authorization information for the first service in the second service; the second service generates the first token public key and the first token secret key based on the reconfigured authorization information. The third service receives a message from the second service, the message including the regenerated first token public key.

[0291] In an embodiment of the present application, the STS service can support the configuration update capability of the first token public key at the service level and the first token secret key at the interface level. 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 the key update.

[0292] 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.

[0293] 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.

[0294] 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.

[0295] like Fig.14 FIG. 14 is a schematic diagram of a chip structure provided by an embodiment of the present application. The chip 1400 includes one or more (including two) processors 1401 , a communication line 1402 , a communication interface 1403 and a memory 1404 .

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

[0297] The method described in the above embodiment of the present application can be applied to the processor 1401, or implemented by the processor 1401. The processor 1401 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 or software instructions in the processor 1401. The above processor 1401 can be a general 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 1401 can implement or execute the methods, steps and logic block diagrams related to each processing disclosed in the embodiment of the present application.

[0298] 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 being 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 1404, and the processor 1401 reads the information in the memory 1404 and completes the steps of the above method in combination with its hardware.

[0299] The processor 1401 , the memory 1404 , and the communication interface 1403 may communicate with each other via the communication line 1402 .

[0300] 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.

[0301] 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.

[0302] 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.

[0303] 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.

[0304] 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 token authentication method, characterized in that, the method includes: receiving a first request from a first service, the first request including a first token; using a first token public key to verify the first token, wherein the first token public key is obtained in advance by requesting from a second service.

2. The method according to claim 1, characterized in that, the first token is a token corresponding to a first interface, and the using the first token public key to verify the first token includes: generating a first token key for the first interface based on the first token public key and the interface ID of the first interface; using the first token key to verify the first token.

3. The method according to claim 1 or 2, characterized in that, 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 for the first interface, verifying the signature of the first token, verifying the legality of the first token, verifying the issuer of the first token, or verifying the custom parameters of the first token.

4. The method according to any one of claims 1-3, characterized in that, before receiving the first request from the first service, further includes: sending a second request to the second service; receiving a response from the second service to the second request, the response to the second request including the first token public key.

5. The method according to claim 4, characterized in that, before sending the second request to the second service, further includes: generating a first private key and a first public key; sending a third request to the second service, the third request including the first public key; receiving a response from the second service to the third request, the response to the third request including a second public key of the second service; generating a first key based on the first private key and the second public key; sending the second request to the second service includes: sending the second request encrypted by the first key to the second service.

6. The method according to any one of claims 1-5, 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, validity period of the first token.

7. The method according to claim 6, characterized in that, the authentication level includes one or more of the following: high-level authentication, ordinary authentication, no authentication, prohibited access, wherein the high-level authentication corresponds to a token signature algorithm combining the ECDSAwithSHA256 algorithm and the HmacSHA256 algorithm.

8. The method according to any one of claims 2-7, characterized in that, the second service also regularly updates the first token public key and the first token key.

9. The method according to any one of claims 2-8, characterized in that, the method further includes: reconfiguring authorization information for the first service in the second service for the second service to regenerate the first token public key and the first token key.

10. The method according to claim 9, wherein, after reconfiguring the authorization information for the first service in the second service, further comprising: receiving a message from the second service, the message including the regenerated first token public key.

11. A token authentication method, wherein, the method is applied to a service interaction system, the service interaction system including a first service, a second service, and a third service, the method comprising: the third service obtains a first token public key from the second service; the third service receives a first request from the first service, wherein the first request includes a first token, and the first token is previously requested by the first service from the second service; the third service uses the first token public key to verify the first token.

12. The method according to claim 11, wherein, the first token is a token corresponding to a first interface of the third service, and the third service uses the first token public key to verify the first token, including: the third 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 third service uses the first token key to verify the first token.

13. The method according to claim 11 or 12, wherein, the third service obtains the first token public key from the second service, including: when the third service sends a registration request to the second service, the third service obtains the first token public key from the second service.

14. The method according to any one of claims 11-13, wherein, the first token is a token generated by the second service, and before the third service receives the first request from the first service, further comprising: the first service determines whether there is a cached and valid first token; if the first service determines that there is a cached first token and the first token is within the validity period, the first service sends the first request to the third service; if the first service determines that there is a cached first token but the first token is not within the validity period, or the first service determines that there is no cached first token, the first service obtains the first token from the second service.

15. The method according to claim 14, wherein, the first service obtains the first token from the second service, including: the first service sends a fourth request to the second service; the second service generates the first token key for the first interface based on the first token public key and the interface ID of the first interface, wherein the interface ID of the first interface is obtained by the second service from the registration request sent by the third service; the second service generates the first token based on the first token key; the first service receives a response to the fourth request from the second service, and the response to the fourth request includes the first token.

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

17. The method according to claim 16, It is characterized in that the authentication level includes one or more of the following: high-level authentication, normal authentication, no authentication, prohibited access, wherein the high-level authentication corresponds to the token signature algorithm that combines the ECDSAwithSHA256 algorithm and the HmacSHA256 algorithm.

18. The method according to any one of claims 12-17, It is characterized in that the second service also regularly updates the first token public key and the first token secret key.

19. The method according to any one of claims 12-18, It is characterized in that the method further includes: the third service reconfigures the authorization information for the first service in the second service; the second service generates the first token public key and the first token secret key based on the reconfigured authorization information; the third service receives a message from the second service, and the message includes the regenerated first token public key.

20. An electronic device, It is characterized in that including: a memory and a processor, the memory is used to store a computer program, and the processor is used to execute the computer program to execute the method according to any one of claims 1-10, or the method executed by the first service in the method according to any one of claims 11-19, or the method executed by the second service in the method according to any one of claims 11-19, or the method executed by the third service in the method according to any one of claims 11-19.

21. A service interaction system, It is characterized in that including: a first electronic device, a second electronic device and a third electronic device, the first electronic device is used to execute the method executed by the first service in the method according to any one of claims 11-19, the second electronic device is used to execute the method executed by the second service in the method according to any one of claims 11-19, and the third electronic device is used to execute the method executed by the third service in the method according to any one of claims 11-19.

22. A computer-readable storage medium, It is characterized in that the computer-readable storage medium stores instructions, and when the instructions are executed, the computer is caused to execute the method according to any one of claims 1-10, or the method executed by the first service in the method according to any one of claims 11-19, or the method executed by the second service in the method according to any one of claims 11-19, or the method executed by the third service in the method according to any one of claims 11-19.

23. A computer program product, It is characterized in that Comprising a computer program which, when run, causes an electronic device to execute the method according to any one of claims 1-10, or the method executed by the first service in the method according to any one of claims 11-19, or the method executed by the second service in the method according to any one of claims 11-19, or the method executed by the third service in the method according to any one of claims 11-19.

Images