Token authentication methods and related devices

Abstract

The token authentication method and related apparatus provided in this application relate to the field of communication technology. The method includes: a service provider can pre-obtain the public key of a token from an STS service; when the service provider receives a business request from a service requester, it can locally verify the token using the public key. This eliminates the need for the service provider to initiate an additional request to the STS service for token verification, improving the service provider's concurrent processing capabilities and efficiency, and shortening the processing latency during business interactions between the service requester and the service provider.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to token authentication methods and related devices. Background Technology

[0002] Applications in electronic devices can provide users with various services, such as game services, cloud storage services, and payment services. When providing services, applications require corresponding servers to support business operations, thereby enabling the processing of application backend business data and the interaction between different services.

[0003] However, when business interactions occur between the service requester and the service provider, the service provider has low concurrency processing capabilities and efficiency, while the service requester experiences high latency in its business requests. Summary of the Invention

[0004] The token authentication method and related apparatus provided in this application allow the service provider to obtain the public key of the token in advance from the STS service. When the service provider receives a business request from the service requester, it can verify the token locally using the public key. This eliminates the need for the service provider to initiate an additional request to the STS service for token verification.

[0005] Firstly, the token authentication method provided in the embodiments of this application includes:

[0006] The system receives a first request from a first service, the first request including a first token; it then verifies the first token using the first token's public key, which is obtained beforehand from a second service request. This improves the service provider's concurrent processing capabilities and efficiency, and reduces processing latency during business interactions between the service requester and the service provider.

[0007] In one possible implementation, the first token is the token corresponding to the first interface. Verification of the first token is performed using the first token's public key, including: generating a first token key for the first interface based on the first token's public key and the interface ID of the first interface; and verifying the first token using the first token key. This ensures the uniqueness of both the token and the key at the interface level, improving the security of accessing the service interface.

[0008] In one 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 legality of the first token, verifying the issuer of the first token, or verifying the custom parameters of the first token. This enhances the security of inter-service interactions, making the identity and access permissions of the service requester controllable.

[0009] In one possible implementation, before receiving the first request from the first service, the process further includes: sending a second request to the second service; and receiving a response from the second service to the second request, wherein the response to the second request includes the first token public key. This allows the service provider to locally verify the first token of the service requester, achieving localized token verification and reducing latency in business processing.

[0010] In one possible implementation, before sending the second request to the second service, the process 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 including the second public key of the second service; generating a first key based on the first private key and the second public key; and sending the second request to the second service, including sending a second request encrypted with the first key. 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, protecting 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. This authorization information includes one or more of the following: authentication level and the validity period of the first token. This allows the service provider to select different security levels for service requesters based on actual circumstances, enhancing the flexibility of token security level control.

[0012] In one possible implementation, the authentication levels include one or more of the following: advanced authentication, normal authentication, no authentication, and access denied. Advanced authentication corresponds to using a token signature algorithm that combines the ECDSAwithSHA256 and HmacSHA256 algorithms. This allows for a higher level of token signature, reducing the likelihood of it being cracked and thus making the transmitted data more secure.

[0013] In one possible implementation, the second service also periodically updates the first token's public key and private key. This makes them less susceptible to cracking by untrusted third parties, thereby enhancing the security of the interaction between the service provider and the service requester.

[0014] In one possible implementation, the method further includes: reconfiguring the authorization information for the first service in the second service, so that the second service can regenerate the first token public key and the first token private key. In this way, the STS service can provide service providers with the ability to remove authorized keys and reissue new keys, supporting the configuration update capabilities of the service-level first token public key and the interface-level first token private key, thereby improving token security.

[0015] In one possible implementation, after reconfiguring the authorization information for the first service in the second service, the process also includes receiving a message from the second service containing the regenerated first token public key. This allows the service provider to obtain the latest key information promptly, improving the timeliness of key updates.

[0016] Secondly, the token authentication method provided in this application is applied to a service interaction system, which includes a first service, a second service, and a third service. The method includes:

[0017] The third service obtains the first token public key from the second service; the third service receives a first request from the first service, wherein the first request includes the first token, which the first service has previously requested from the second service; the third service uses the first token public key to verify the first token. In this way, the third service no longer needs to rely on the STS service for first token verification, achieving decentralized token verification and reducing the pressure on the STS service's concurrent processing; the third service can perform token verification locally, achieving localized token verification and reducing business processing latency.

[0018] In one possible implementation, the first token is the token corresponding to the first interface of the third service. The third service verifies the first token using the first token's public key, including: the third service generating a first token key for the first interface based on the first token's public key and the interface ID of the first interface; and the third service verifying the first token using the first token key. This ensures the uniqueness of both the token and the key at the interface level, improving the security of accessing the service interface.

[0019] In one 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 obtaining the first token public key from the STS service enables synchronization of the first token public key between the service provider and the STS service. Therefore, the service provider can locally verify the first token of the service requester, achieving localized token verification and reducing business processing latency.

[0020] In one 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, the process includes: the first service determining whether it has a cached and valid first token; if the first service determines that it has a cached first token and that the first token is valid, the first service sends the first request to the third service; if the first service determines that it has a cached first token but that the first token is not valid, or if the first service determines that it does not have a 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, its identity is trustworthy and its access permissions are controllable, thus enabling effective business interaction with the third service.

[0021] In one possible implementation, the first service obtains a first token from the second service, including: the first service sending a fourth request to the second service; the second service generating a 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 a registration request sent by the third service; the second service generating a first token based on the first token key; and the first service receiving a response from the second service to the fourth request, the response to the fourth request including the first token. This ensures that the first token is updated locally on the first service in a timely manner, facilitating business interactions with the third service via the first token.

[0022] In one possible implementation, the second service is configured with the authorization information of the first service. This authorization information includes one or more of the following: authentication level and the validity period of the first token. This allows the service provider to select different security levels for service requesters based on actual circumstances, enhancing the flexibility of token security level control.

[0023] In one possible implementation, the authentication levels include one or more of the following: advanced authentication, normal authentication, no authentication, and access denied. Advanced authentication corresponds to using a token signature algorithm that combines the ECDSAwithSHA256 and HmacSHA256 algorithms. This makes the token's signature algorithm more secure and less likely to be cracked, thus enhancing the security of the transmitted data.

[0024] In one possible implementation, the second service also periodically updates the first token's public key and private key. This makes them less susceptible to cracking by untrusted third parties, thereby enhancing the security of the interaction between the service provider and the service requester.

[0025] In one possible implementation, the method further includes: a third service reconfiguring the authorization information for the first service within the second service; the second service generating a first token public key and a first token private key based on the reconfigured authorization information; and the third service receiving a message from the second service, which includes the regenerated first token public key. This allows the service provider to obtain the latest key information in a timely manner, improving the timeliness of key updates.

[0026] Thirdly, embodiments of this application provide a token authentication apparatus, which may be a server, a chip within a server, or a chip system. The apparatus may include a processing unit. The processing unit is used to implement any method related to processing, executed by the first aspect or any possible implementation of the first aspect, or executed by the first service, or executed by the second service, or executed by the third service, in any possible implementation of the second aspect. When the apparatus is a server, the processing unit may be a processor. The apparatus may further 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 cause the server 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, or the method executed by the second service, or the method executed by the third service, in any possible implementation of the second aspect. When the apparatus is a chip within a server, the processing unit may be a processor. The processing unit executes the instructions stored in the storage unit to cause the server 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, cache, etc.) or a storage unit located outside the chip within the server (e.g., read-only memory, random access memory, etc.).

[0027] Fourthly, embodiments of this application provide a server, including a processor and a memory. The memory is used to store code instructions, and the processor is used to execute the code instructions to perform the method described in the first aspect or any possible implementation of the first aspect, or the method performed by a first service in the method described in the second aspect or any possible implementation of the second aspect, or the method performed by a second service in the method described in the second aspect or any possible implementation of the second aspect, or the method performed by a third service in the method described in the second aspect or any possible implementation of the second aspect.

[0028] Fifthly, embodiments of this application provide a service interaction system, including a first server, a second server, and a third server. The first server is used to execute the method executed by the first service in the method described in the second aspect or any possible implementation of the second aspect. The second server is used to execute the method executed by the second service in the method described in the second aspect or any possible implementation of the second aspect. The third server is used to execute the method executed by the third service in the method described in the second aspect or any possible implementation of the second aspect.

[0029] Sixthly, embodiments of this application provide a computer-readable storage medium storing a computer program or instructions that, when executed on a server, cause the server to perform the method described in the first aspect or any possible implementation of the first aspect, or the method performed by a first service in the method described in the second aspect or any possible implementation of the second aspect, or the method performed by a second service in the method described in the second aspect or any possible implementation of the second aspect, or the method performed by a third service in the method described in the second aspect or any possible implementation of the second aspect.

[0030] In a seventh aspect, embodiments of this application provide a computer program product including a computer program, which, when run on a server, causes the server 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] Eighthly, this application provides a chip or chip system including at least one processor and a communication interface, the communication interface and the at least one processor being interconnected via a circuit, the at least one processor being used to run computer programs or instructions to perform the methods described in the first aspect or any possible implementation thereof. The communication interface in the chip may be an input / output interface, pins, or circuits, etc.

[0032] In one possible implementation, the chip or chip system described above in this application further includes at least one memory storing instructions. The memory can be an internal storage unit of the chip, such as a register or cache, or it can be a storage unit of the chip itself (e.g., read-only memory, random access memory, etc.).

[0033] It should be understood that the third to eighth aspects of this application correspond to the technical solutions of the first or second aspects of this application, and the beneficial effects achieved by each aspect and the corresponding feasible implementation are similar, and will not be repeated here. Attached Figure Description

[0034] Figure 1 A schematic diagram of an ECDH key negotiation algorithm provided in an embodiment of this application;

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

[0036] Figure 3 An architecture diagram of an STS.SDK toolkit provided for embodiments of this application;

[0037] Figure 4 This application provides an authentication and authorization process for Service A and Service B as an embodiment of the present application.

[0038] Figure 5 A business interaction diagram of service A, service B, and STS service is provided for an embodiment of this application;

[0039] Figure 6 An interaction diagram of service A requesting a token from service STS provided in an embodiment of this application;

[0040] Figure 7 A schematic diagram illustrating the verification of tokens between service A and service B, provided as an embodiment of this application;

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

[0042] Figure 9A schematic diagram illustrating a gateway authentication scenario provided in an embodiment of this application;

[0043] Figure 10 This application provides a schematic diagram of gateway authentication for integrating STS.SDK into a microservice cluster.

[0044] Figure 11 This application provides a schematic diagram of gateway authentication integrating STS.SDK.

[0045] Figure 12 A schematic diagram illustrating a token authentication method provided in an embodiment of this application;

[0046] Figure 13 A schematic diagram illustrating another token authentication method provided in an embodiment of this application;

[0047] Figure 14 This is a schematic diagram of the structure of a chip provided in an embodiment of this application. Detailed Implementation

[0048] To facilitate a clear description of the technical solutions in the embodiments of this application, some terms and technologies involved in the embodiments of this application will be briefly introduced below:

[0049] 1. ECC: Elliptic Curve Cryptography (ECC).

[0050] ECDH: Elliptic Curve Difficult-Hellman (ECDH) is a key exchange algorithm based on ECC. ECDH can also be understood as an algorithm for exchanging public keys and generating symmetric keys.

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

[0052] In this setup, the private key `prikey-X` is stored locally on service X, and the public key `pbkey-X` is sent to service Y. Service Y receives the public key `pbkey-X` from service X and stores it locally. Service Y can also generate an ECC public key `pbkey-Y` and an ECC private key `prikey-Y`. The private key `prikey-Y` is stored locally on service Y, and the public key `pbkey-Y` is sent to service X.

[0053] In this way, service X locally stores its private key prikey-X and service Y's public key pbkey-Y, while service Y locally stores its private key prikey-Y and service X's public key pbkey-X. Service X can generate a symmetric key aeskey based on prikey-X and pbkey-Y using the ECC algorithm, and service Y can also generate a symmetric key aeskey based on prikey-Y and pbkey-X using the ECC algorithm. That is, after service X and service Y exchange their public keys, they can generate the same symmetric key aeskey using the ECC algorithm. This symmetric key aeskey can also be called the ECDH negotiation key sessionKey or session key.

[0054] After generating the ECDH negotiation key (sessionKey), services X and Y can interact based on the same symmetric key (aeskey). This eliminates the need for ECDH to transmit the aeskey, reducing the possibility of key interception during transmission and thus improving the security of business interactions between services X and Y.

[0055] 2. STS: Security Token Service (STS) is a security service product. STS can also be understood as an authorization center. STS provides cloud service products with an integrated solution for time-sensitive, tamper-proof, and anti-spoofing verification and authentication, as well as interface-level authorization and authorization, based on tokens. It provides configurable and reliable security guarantees and interface-level permission control for access between cloud services.

[0056] The cloud services may include game center services, account services, cloud space services, push services, message center services, video services, and payment services, etc., and this application embodiment does not limit them.

[0057] These cloud services can interact with each other. Service providers can provide interfaces to service requesters, who can then access these interfaces to use the relevant services offered by the service provider. The service requester can also be understood as an authorized service object.

[0058] For ease of description, the service requester will be referred to as Service A, and the service provider as Service B. Service A and Service B can be any of the cloud services mentioned above, and this embodiment of the application does not limit the scope of the service requester.

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

[0060] STS services can include STS-MANAGE configuration services, STS business services, and STS software development kits (STS.SDK).

[0061] The STS-MANAGE configuration service can include services such as key management, service management, token management, and permission management.

[0062] Key management can be used to perform processes such as key generation, key updating, and key deletion. For example, in this embodiment of the application, the STS service can generate service-level keys (masterKey) and interface-level keys (serviceKey) for cloud services.

[0063] Service management can be used to perform processes such as service registration, service configuration, and version management. For example, in this embodiment, service B can register in the STS service and configure interface authorization for service A.

[0064] Token management can be used to perform processes such as page configuration, real-time token generation, and token lifecycle management. For example, in this embodiment, service B can configure the expiration date of the token for service A in the STS service; the STS service can also generate a token for service A to access the interface of service B in real time; and the STS service can regenerate the token when it expires.

[0065] Access control can be used to execute access policies, configure pages, and implement version control. For example, in this embodiment, the STS service can provide a configuration page for service B, where service B can configure authentication levels and service versions for service A.

[0066] In addition, the STS-MANAGE configuration service can also save the service provider's configuration data to a database or memory, enabling persistent service registration data, persistent token data, and localized token keys.

[0067] The persistence of service registration data can include encrypted storage of the STS registration service on disk, real-time caching of the STS registration service, and real-time generation of serviceKeys. For example, in this embodiment, the STS service can store the registration data of services A and B; the STS service can also generate interface-level keys (serviceKeys) for cloud services.

[0068] Token data persistence can include server-side caching of tokens, server-side updating of tokens, and STS real-time generation of tokens. For example, in this embodiment, the STS service can also generate a token for service A to access the interface of service B in real time; when the token expires, the STS service can also update the token, etc.

[0069] Token key localization can include obtaining certificate keys, localizing the masterKey, and calculating the serviceKey in real time. For example, in this embodiment, the STS service can obtain and save the certificate keys of various cloud services, and can generate and save service-level keys such as masterKeys for cloud services.

[0070] The STS business service can retrieve business data from the database, providing business data support for the STS.SDK toolkit. Service providers can then use the STS.SDK toolkit to retrieve their own business data from the STS business service for business processing.

[0071] Figure 3 The architecture diagram of the STS.SDK toolkit is shown.

[0072] The STS.SDK toolkit may include encryption / decryption modules, signing modules, authentication modules, and certificate chain modules.

[0073] The encryption / decryption module can perform ECDH negotiated key encryption / decryption, Advanced Encryption Standard (AES) algorithm encryption / decryption, and RSA public / private key encryption / decryption processes. AES is a symmetric encryption algorithm. For example, in this embodiment, when services interact, each service's ECC public and private keys can be generated based on the AES algorithm, and an ECDH negotiated key (sessionKey) can be generated based on these keys. The sessionKey is then used to encrypt or decrypt transmitted data, thereby improving data transmission security.

[0074] The signature module can perform processes such as Sha256 hash algorithm, hash-based message authentication code (HMAC) authentication, signature verification, and certificate private key signing. For example, in this embodiment, the STS service can use the Sha256 hash algorithm to sign the token, and the B service can use the Sha256 hash algorithm to verify the signature of the token. Signature verification can also be called signature checking.

[0075] The authentication module can perform processes such as token signing authentication, serviceKey generation, JWT token parsing, health checks, authentication degradation, token validity verification, and access permission checks. For example, STS.SDK can periodically access the STS service to determine if it is running normally. If the STS service experiences an outage or other abnormality, STS.SDK will locally degrade the token authentication, defaulting to successful token authentication. This maintains the availability of business services.

[0076] The certificate chain module can perform processes such as certificate chain conversion, root certificate parsing, certificate chain verification, public key encryption, and private key decryption. A certificate chain, also known as a business certificate or service certificate, can be used to authenticate the trustworthiness of another service during business interactions. For example, in this embodiment, STS.SDK can also perform certificate chain verification for service A.

[0077] 3. Terminology

[0078] In the embodiments of this application, terms such as "first" and "second" are used to distinguish identical or similar items with substantially the same function and purpose. For example, "first chip" and "second chip" are used only to distinguish different chips and do not limit their order of execution. Those skilled in the art will understand that terms such as "first" and "second" do not limit the quantity or execution order, and that "first" and "second" do not necessarily imply that they are different.

[0079] It should be noted that, in the embodiments of this application, the terms "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design scheme described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0080] In this application embodiment, "at least one" refers to one or more, and "more than one" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer 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, and c can be single or multiple.

[0081] Applications in electronic devices can provide users with various services, such as game services, cloud storage services, and payment services. When providing services, applications require corresponding servers to support business operations, thereby enabling the processing of application backend business data and the interaction between different services.

[0082] If the services provided by service B to service A are accessed by an untrusted third party, the third party may obtain service data and / or modify service content, leading to information leakage. Therefore, to prevent untrusted third parties from accessing the services provided by service B to service A, an authentication and authorization strategy is needed between service B and service A. Service B can perform identity authentication and access permission verification for service A, thereby ensuring that the identity and access permissions of service A are controllable.

[0083] The following example, using Service A as the game center service and Service B as the account service, illustrates the authentication and authorization process between Service A and Service B in some implementations.

[0084] like Figure 4 As shown, when a user wants to log in to their account in 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 log in to the user's account.

[0085] Understandably, before the Game Center service interacts with the Account service, the Account service needs to authorize the Game Center service on the STS service side. 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 Game Center service's permission to access the Account service. The Game Center service stores the token locally.

[0086] When logging into an account through the Game Center service, the Game Center service can send a business request to the Account service, carrying a token. Upon receiving the request from the Game Center service, the Account service first needs to initiate a Hypertext Transfer Protocol (HTTP) or Secure Hypertext Transfer Protocol (HTTPS) request to the STS service, which then verifies the token. The STS service's token verification may include checking the issuer, the correctness of the accessed interface, the token's validity period, and whether the signature algorithm has been tampered with.

[0087] After the STS service successfully verifies the token, it can return a successful token verification message to the account service. The account service can then interact with the game center service.

[0088] However, for service B, when processing business requests, it needs to first send an additional HTTP or HTTPS request to the STS service for token verification, reducing its concurrent processing capacity and efficiency. For service A, the overall latency of its business requests includes the latency of the HTTP or HTTPS request from service B to the STS service, thus lengthening the processing latency of service A's business requests. For the STS service, when multiple services need to perform token verification or multiple business interfaces of a single service need to perform token verification, it puts significant pressure on the STS service's concurrent processing capabilities.

[0089] In view of this, the token authentication method provided in this application allows the service provider to obtain the public key of the token from the STS service in advance. When the service provider receives a business request from the service requester, it can verify the token locally using the public key of the token. This eliminates the need for the service provider to initiate an additional request to the STS service for token verification, improving the service provider's concurrent processing capabilities and efficiency, and shortening the processing latency during business interactions between the service requester and the service provider.

[0090] Figure 5 The present application illustrates the process of business interaction between service A and service B in an embodiment of this application. The interaction process may include (1) interaction between service B and STS service, (2) interaction between service A and STS service, and (3) interaction between service A and service B.

[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 of Service B. The interface-X can be any interface provided by Service B, such as the getUserInfo() interface for retrieving user information or the getUserRegist() interface for retrieving user registration information. This application embodiment does not limit the specific service provided by the interface-X.

[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 control the security level of the configurable token, such as configuring the authentication level authlevel and the token validity period.

[0094] The authentication levels provided by the STS service may include one or more levels, which are not limited in this embodiment. For example, authentication levels may include advanced authentication, normal authentication, no authentication, and access denied.

[0095] For example, if service B configures the authentication level for service A to be high-level authentication, the signature algorithm level used when service A and service B interact is relatively high. If service B configures the authentication level for service A to be normal authentication, the signature algorithm level used when service A and service B interact is relatively low. If service B configures the authentication level of the interface-X interface to no authentication, all services, including service A, can access the interface-X interface. If service B configures the authentication level of the interface-X interface to deny access, no service, including service A, is allowed to access the interface-X interface. It is understood that the specific authentication level can be set by service B, and this embodiment does not limit it.

[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, or it can be set to other values. The specific value of the token validity period is not limited in this application embodiment.

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

[0098] Understandably, the purpose of pre-registration is to facilitate the exchange of ECC public keys between Service B and the STS service. During pre-registration, Service B can locally generate an ECC private key prikey-B1 and an ECC public key pbkey-B1. The private key prikey-B1 is stored locally on Service B, while the public key pbkey-B1 is sent to the STS service. This public key pbkey-B1 can be used for interaction between Service B and the STS service.

[0099] When Service B starts up or retrieves a task from Service STS, Service B can send a request to Service STS for the pre-registration service RreRegist. This request can include Service B's signature, service certificate, and public key pbkey-B1. The signature is to prevent the request from Service B from being tampered with, and the service certificate is to prove that Service B's identity is trustworthy.

[0100] After receiving the pre-registration request from Service B, the STS service can perform signature verification and certificate verification on the request. It's understandable that signature verification is to determine if the request sent by Service B has been tampered with, and certificate verification is to determine if Service B's identity is trustworthy.

[0101] For example, the STS service can use the elliptic curve digital signature algorithm (ECDSA) public key of service B to verify the signature of service B's request. The ECDSA public key of service B can be either the newly generated ECC public key pbkey-B11 of service B, or the certificate public key pbKeyCertB of service B; this embodiment of the application does not limit the choice. The certificate public key pbKeyCertB of service B can be understood as the last certificate public key in B's certificate chain, and pbkey-B11 is different from pbkey-B1.

[0102] If the signature verification is successful, it means that the request content of Service B has not been tampered with during transmission; if the signature verification fails, it means that the request content of Service B has been tampered with during transmission, 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 STS service's root certificate to verify the validity of the certificate requested by service B. If service B's certificate verification passes, the STS service can exchange ECC public keys with service B; if service B's certificate verification 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 persistently store information such as the public key pbkey-B1 of the B service, and generate the ECC private key prikey-S1 and the ECC public key pbkey-S1 of the STS service.

[0105] Based on the above description of ECDH, the STS service can generate an ECDH negotiation key, sessionKey1, between service B and the STS service using the ECC algorithm based on the private key prikey-S1 and the public key pbkey-B1 of service B. Subsequently, during the interaction between service B and the STS service, sessionKey1 can be used to encrypt transmitted data.

[0106] The STS service can store the private key prikey-S1 locally and return a pre-registration response to service B. This response can include the STS service's signature, service certificate, and public key pbkey-S1.

[0107] Similarly, after receiving the pre-registration response from the STS service, Service B can verify the signature and certificate of the response. For example, Service B can use the STS service's ECDSA public key to verify the signature of the STS service's response. The STS service's ECDSA public key can be either the newly generated ECC public key pbkey-S11 or the STS service's certificate public key pbKeyCertS; this embodiment does not limit the specific key. pbkey-S11 is different from pbkey-S1. Service B can also use the STS service's certificate public key pbKeyCertS to verify the certificate validity of the STS service's response.

[0108] After verifying the signature and certificate of the pre-registration response to the STS service, as described above regarding ECDH, service B can generate an ECDH negotiation key, sessionKey1, between service B and the STS service using the ECC algorithm based on the private key prikey-B1 and the public key pbkey-S1 of the STS service. Subsequently, during interactions between service B and the STS service, sessionKey1 can be used to encrypt transmitted data.

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

[0110] After Service B and STS exchange their ECC public keys, Service B can send a RegistServer request to STS to obtain authorization information for the Interface-X interface, including authorization for Service A. This request may include Service B's signature, Service B's service certificate, Service B's public key pbkey-B2 required for interaction between Service B and Service A, and registration service data encrypted with the ECDH negotiated key sessionKey1. This data may contain information such as the token validity period, Service B's ID appid, Interface-X ID intfid, authentication level authlevel, and / or saltvalue.

[0111] Here, appid can be understood as a unique identifier for a 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 is understood that Service B can obtain interface-X interface authorization information from the STS service at startup, or periodically obtain interface-X interface authorization information from the STS service. Alternatively, when the interface-X interface authorization information in the STS service is updated, the updated interface-X interface authorization information can be sent to Service B in real time. The specific timing and method by which Service B obtains interface-X interface authorization information are not limited in this embodiment.

[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 signature and certificate of Service B by the STS service can be found in the relevant description in the pre-registration process of Service B in (1.1) above, and will not be repeated here.

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

[0116] The STS service can generate a public key, masterKey1, for a token for service B. This masterKey1 can also be called the token's master key or root key. It's understood that the STS service can generate different public keys for different services. For example, the public key generated for service B might be masterKey1, while the public key generated for service A might be masterKey2. masterKey1 and masterKey2 are different and can also be understood as the service-level master keys for the tokens.

[0117] After generating the public key masterKey1 for the token for service B, the STS service can return a registration response to service B. This response may include the STS service's certificate chain, the STS service's signature, the STS service's public key pbkey-S1, and registration response data (data) encrypted with the ECDH negotiation key sessionKey1. This data may contain information such as service B's certificate serial number serialNum, the token's public key masterKey1, the token's signing key tokenSignPbKey, the challenge value challenge, and the version number version.

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

[0119] After performing signature and certificate verification on the response from 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 further derive the serviceKey (serviceKey) for the interface-X interface-level token using the HmasSHA256 algorithm, based on masterKey1, the service ID (appid) of service B, the interface-level ID (inifid) of service B, and the challenge value (challenge). This serviceKey can also be referred to as the token signing key. This serviceKey can be used to generate the interface-X interface token and to verify the token.

[0121] Understandably, since the generated challenge value is random each time, the serviceKey corresponding to each interface of service B is also different. That is, one interface corresponds to one serviceKey, and different interfaces correspond to different serviceKeys; the key for interface-X1 cannot resolve the key for interface-X2. This ensures the uniqueness of both the token and the key at the interface level, improving 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 using 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 using the HmacSHA256 signature algorithm; the STS service can also sign the token a second time based on the token signing key tokenSignPbKey using the ECDSAwithSHA256 signature algorithm.

[0124] Understandably, using only the HmacSHA256 signature algorithm can be called a single-layer signature algorithm or a standard signature algorithm. A signature algorithm combining ECDSAwithSHA256 and HmacSHA256 can be called a two-layer signature algorithm or an advanced signature algorithm. Using a two-layer signature algorithm increases the security of the token's signature, making it less susceptible to cracking and thus enhancing the security of transmitted data.

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

[0126] Firstly, the STS service can reconfigure the authorization data according to the requirements of Service B, triggering an update of the token's key serviceKey1. Service B can obtain the latest authorization information and the latest serviceKey from the STS service, thereby enabling Service B to control the removal of authorization keys and the reissue of new keys, thus improving the security of the token.

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

[0128] Thirdly, the STS service can employ a key expiration and rotation strategy. For example, the STS service can periodically update masterKey1 and serviceKey, etc., for already registered and authorized configuration data. The update cycle can be set by the STS service or Service B, for example, it can be 1 day or 1 week, etc., and this application embodiment does not limit this. Service B can obtain the latest service authorization information and key information, etc., to synchronously update the newly generated masterKey1 and serviceKey, etc., thereby improving the security of the token key.

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

[0130] Understandably, based on the pre-registration and registration process, Service B can synchronize masterKey1 and serviceKey, enabling Service B to obtain and automatically update the token key upon startup.

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

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

[0133] When service A accesses service B's interface-X interface, service A can first determine whether there is a valid token cached in memory for accessing service B's interface-X interface.

[0134] If service A has a cached interface-X token locally, and the token is within its validity period, then the token is valid. Service A can send a business request to service B, and the request will include the token.

[0135] If Service A does not have a cached token for the Interface-X interface locally, or if 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 to request access to the token for Service B's Interface-X interface.

[0136] It is understandable that before Service A requests a token from the STS service, such as when Service A starts up, Service A can also perform a pre-registration and registration process with the STS service. The specific pre-registration and registration process can be referred to the relevant description of the pre-registration and registration process in the interaction between Service B and the STS service in (1) above, and will not be repeated here.

[0137] It should be noted that after Service A and STS Service perform the pre-registration and registration process, Service A can locally store information such as the public key masterKey2 of the token generated by STS Service for Service A.

[0138] In the request from service A to the STS service for a token, service A's signature, certificate chain, and request data encrypted with masterKey2 can be included. This data may contain a timestamp, service B's service ID (appid), and the interface ID (intfid) of the interface-X interface. (2.2) The STS service returns the token and other information.

[0139] After receiving the request for the application token from Service A, the STS service can verify the signature and certificate of Service A's request. The specific verification of the signature and certificate of Service A by the STS service can be found in the description of the verification of the signature and certificate of Service B in the pre-registration process of Service B (1.1) above, and will not be repeated here.

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

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

[0142] If the interface-X allows service A to access it, the STS service can generate a corresponding token for the interface-X. For example, the STS service can generate a token based on the serviceKey of the interface-X. The token's validity period can be calculated from the time of generation. The token may include information such as the service ID (appid) of service B, the service ID (appid) of service A, the interface ID (intfid) of the interface-X, the token's validity period, and a challenge value.

[0143] The STS service can encrypt the information returned to A using masterKey2. This returned information may include the interface-X token, the certificate serial number (serialnum) of service B, and the public key (pbkey-B2) of service B. The token may contain information such as the token validity period (validperiod) and the service ID (appid) of service B.

[0144] After obtaining the decrypted interface-X token, service A can cache the token locally. Understandably, if service A subsequently determines that the token is valid, it will not need to request a new token from the STS service when requesting service B's interface-X interface; it can reuse the cached token.

[0145] Service A can also generate an ECDH negotiation key sessionKey3 between Service A and Service B using the ECC algorithm based on Service A's private key prikey-A2 and Service B's public key pbkey-B2. This sessionKey3 can be used to encrypt sensitive information in requests sent to Service B.

[0146] Figure 6 This diagram illustrates a detailed process where service A requests a token from the STS service to access service B.

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

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

[0149] After receiving the request from service A to apply for a token, the STS service can perform cyclic verification of the certificate chain, public key parsing, and signature authentication on service A based on the local root certificate rootCA, thereby obtaining service A's certificate public key pbKeyCertA.

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

[0151] The STS service can also determine whether service A is registered by checking its service ID (appid) in the STS service registration cache; similarly, it can determine whether service B is registered by checking its service ID (appid) in the STS service registration cache. If the STS service determines that service A and / or service B are not registered, service A will be unable to obtain the interface-X token, and the STS service will return 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 failed, service B does not allow service A to access it, and 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 the whitelist verification is successful and Service B allows Service A to access it. In this case, the STS service can encrypt and return the interface-X token to Service A. The specific process of the STS service generating and returning the token can be found in the relevant description in (2.2) above, where the STS service returns the token and other information. It will not be repeated here.

[0155] It is understood that the STS service can store configuration switches indicating whether a request to service B can be made without a token. For example, this configuration switch could be named sts.service.enable. The data type of this configuration switch can include integer, boolean, string, etc. For example, when the configuration switch is set to true, it means that a token is required to request service B; when the configuration switch is set to false, it means that a request to service B can be made without a token using HTTP or HTTPS. This configuration switch can be set by service B, and the specific naming and value of the configuration switch are not limited in this embodiment.

[0156] (3) The 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 to service B for business related to the interface-X interface, the request can carry information such as service A's signature, service A's certificate chain, and the interface-X interface token.

[0159] In a possible implementation, service A can send a request to service B using double-layer encryption. This request may include service A's certificate chain, a hash digest of service A's private key certificate signature, service A's ECDSA public key, and request data (data). Service A's ECDSA public key can be either a newly generated ECC public key (pbkey-A11) or service A's certificate public key (pbKeyCertA), which is not limited in this embodiment. pbkey-A11 is different from pbkey-A1. The data may include a token, service A's public key (pbkey-A2), a salt value, and encrypted data (EncryptData) encrypted using the ECDH negotiated key (sessionKey3).

[0160] It is understandable that when services A and B transmit data using the HTTPS protocol, the HTTPS protocol itself can encrypt the transmitted data, which is called the first layer of encryption. Based on the HTTPS encryption, this embodiment of the application can further encrypt the transmitted data using sessionKey3 to obtain encrypted data EncryptData, which is called the second layer of encryption. Thus, for scenarios with high security requirements for transmitted content, using double encryption can enhance the security of interactions between services.

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

[0162] Service B can integrate the STS.SDK toolkit, which can intercept requests from Service A. After intercepting a request, STS.SDK can parse the request and perform signature verification and certificate chain validation.

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

[0164] STS.SDK can also perform certificate chain verification on service A. For example, STS.SDK can use the root certificate (rootCA) of service B to verify the validity of service A's certificate chain. If service A's certificate chain is valid, the certificate chain verification passes, and the verification of information such as the token can continue. If service A's certificate chain is invalid, the certificate chain verification fails, and service B returns an exception.

[0165] STS.SDK can also retrieve the token from the request and verify the token.

[0166] Token verification includes verifying the token's validity period, whether the token has been authorized to the Interface-X interface, the token's signature, the validity of the token's subject, the issuer's identity, and custom parameters. The token's signature verification can also be referred to as token signature verification.

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

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

[0169] In a possible implementation, STS.SDK can use the serviceKey to verify the HmacSHA256 signature algorithm, performing a first signature verification on the token, known as primary signature verification. STS.SDK can also use the token signing key tokenSignPbKey to verify the ECDSAwithSHA256 signature algorithm, performing a second signature verification on the token, known as secondary signature verification.

[0170] STS.SDK's token validity verification can include validating the interface's Uniform Resource Locator (URL).

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

[0172] In a possible implementation, service B can obtain the authorization object for each interface from the STS service during registration, including the authorization object for service A of service B's interface-X interface. When service A requests service B's interface-X interface, the token in service A's request can carry the interface information to be accessed. Service B can determine whether the interface information in service A's requested token matches the URL interface information to be accessed, and whether service B's cached authorization object for the interface-X interface includes service A. Therefore, service B can determine whether the interface-X interface authorizes service A to access service B's interface-X interface.

[0173] If it is confirmed that service A is not authorized to access service B's interface-X interface, service B will return an exception.

[0174] If service A is authorized to access service B's interface-X, service B can then engage in normal business interactions with service A. For example, service B can use its private key prikey-B2 and service A's public key pbkey-A2 to negotiate and obtain the key sessionKey3. Then, service B can use sessionKey3 to decrypt the encrypted data EncryptData sent by service A and return a response to its business request to service A.

[0175] Figure 7 This diagram illustrates the process of verifying tokens between service A and service B.

[0176] In a possible implementation, service A and service B can pre-agree on the base for generating the ECC public and private keys for ECDH, as well as a shared parameter p. The base can be obtained from service B's service ID (appid) and certificate serial number (serialNum). Alternatively, service A and service B can use the generated random number as a parameter for generating the ECC public and private keys; this embodiment of the application does not impose such limitations.

[0177] After service A generates an ECC private key prikey-A2 and an ECC public key pbkey-A2, and service B generates an ECC private key prikey-B2 and an ECC public key pbkey-B2, and they exchange their public keys, service A can generate an 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. Similarly, service B can generate an 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 if it has a local cached token for accessing service B's interface-X interface. The specific process of service A querying and updating the token can be found in the description of service A requesting the token from the STS service in section (2.1) above, and 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 description of Service A initiating a business request to Service B in section (3.1) above; further details 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 verification of signature and certificate chain can be referred to the relevant description of Service B's request to verify Service A in (3.2) above, and will not be repeated here.

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

[0182] It is understandable that during the process of service B validating a request from service A, service B may return an exception to service A. These exception scenarios may include the following:

[0183] (a) If the signature verification or certificate chain verification of Service A fails, an exception will be returned.

[0184] (b) When parsing the requested data, if no token is available, 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 the key for the token locally, it will retrieve the key from the STS service. If STS.SDK detects that Service B has not yet registered, it will return an exception and trigger the registration process for Service B. It should be noted that if STS.SDK detects that the STS service does not exist, it will perform authentication verification downgrade on Service A and return normal.

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

[0187] In this embodiment of the 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. This allows Service B to act as the verification center for the token, thereby implementing token verification locally on Service B. This reduces the latency of business requests while maintaining interaction security and implementing verification functions.

[0188] It is understood that the embodiments of this application can be applied to token verification between multiple services. For example, when each service starts up, it can obtain authorization information between services, as well as token keys and other related information, from the STS service. After obtaining the token keys and other related information, each service can perform token verification locally. In this way, each service no longer needs to rely on the STS service for token verification, achieving decentralized token verification and reducing the pressure on the STS service's concurrent processing; each service can perform token verification locally, achieving localized token verification and reducing business processing latency.

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

[0190] For example, Figure 8 This illustrates the interaction between the Authorization Center of the server and the client in a client login authentication scenario.

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

[0192] For example, when logging into an account, a client can send a login request to the server's authorization center, such as the login() function. The client can then pass the username (name) and password (pwd) in the login() function.

[0193] The authorization center can log in and authenticate digital signatures to verify client signatures. After successful verification, the authorization center can generate and return a token and a refresh token to the client. When the token expires, the client can use the refresh token to request a new token from the server.

[0194] The client can store the acquired token and refresh token locally. The client can also use the token to request server resources.

[0195] If the server verifies the token, it can return the resource to the client.

[0196] If the authorization center determines that the token has expired or the signature verification fails, it will return a verification failure message to the client. The client can then request server resources by sending a refresh_token.

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

[0198] If the authorization center fails to verify the refresh_token, it will return a verification failure message to the client and require the client to log in to the account again.

[0199] The server's authorization center can integrate STS.SDK to verify tokens locally on the server. This allows the server to act as a token verification center, enabling local token verification. This improves the server's concurrent processing capabilities and efficiency while maintaining interactive security and implementing verification functions, and also reduces the latency of client login authentication.

[0200] Optionally, the token authentication method of this application embodiment can also be applied to gateway authentication scenarios. The gateway may include a Zuul gateway, etc.

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

[0202] When a client sends a user request to the gateway, it can include a token. The gateway can then send the token to a server in the microservice cluster, such as server A. It's understood that server A could include services like account management.

[0203] Server A can send a token to the authorization center, which can remotely authenticate the client's token. After successful authentication, the authorization center can return the user's authorization request information to server A. Subsequently, the gateway can obtain server A's service list through the registry center, thereby enabling business interactions with the client.

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

[0205] Figure 10 This illustrates a gateway authentication scenario when integrating STS.SDK into a microservice cluster.

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

[0207] When a client sends a user request to the gateway, it can include a token. The gateway can then send the token to a server in the microservice cluster, such as server A. Server A can perform local authentication of the client's token using the STS.SDK. After successful authentication, the registry can return the service list of server A to the gateway, enabling business interactions between the gateway and the client.

[0208] By integrating STS.SDK into 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 perform local verification of the token.

[0210] Figure 11 This illustrates a gateway authentication scenario when the gateway is integrated with the STS.SDK.

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

[0212] When a client sends a service request to the gateway to access server A, it can include a token. The gateway can then perform local authentication of the client's token using the STS.SDK. After successful authentication, the registry can return the service list of server A to the gateway, enabling business interactions between the gateway and the client.

[0213] By integrating STS.SDK into the gateway, the gateway can be given interface-level token authentication capabilities.

[0214] The methods of this application will be described in detail below through specific embodiments. The following embodiments can be combined with each other or implemented independently, and the same or similar concepts or processes may not be described again in some embodiments.

[0215] Figure 12This application illustrates a token authentication method according to an embodiment of the present application. The method includes:

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

[0217] In this embodiment of the application, the first service can be understood as the service requester, for example, the first service can be the one described above. Figure 5 Service A in the corresponding 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 described as described above. Figure 5 In the corresponding embodiment, service A initiates a business request to service B.

[0219] The first token can be understood as the token required by the service requester to access a certain interface of the service provider. For example, the first token can be one of the above. Figure 5 The token used by service A to access the interface-X interface of service B in the corresponding embodiment.

[0220] The service provider may receive a first request from the first service, wherein the service provider may be the aforementioned Figure 5 The corresponding example is Service B in this embodiment. Specifically, the first service sending the first request to the second service can be referred to the above. Figure 5 The relevant description of Service A initiating a business request to Service B in the corresponding embodiment (3.1) will not be repeated here.

[0221] S1202. Verify the first token using the first token public key, wherein the first token public key is obtained in advance from the second service request.

[0222] In this embodiment, 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 or root key of the token. For example, the first token public key can be as described above. Figure 5 In the corresponding embodiment, the STS service generates a public key masterKey1 for the token of service B, and service B can verify the token sent by service A based on masterKey1.

[0223] The second service can be understood as the service that generates the public key for the first token. For example, the second service could be as described above. Figure 5 The corresponding embodiment refers to the authorization center or STS service.

[0224] Verifying the first token using the first token's public key can be done as described above. Figure 5The relevant description of the request for service A to verify service B in the corresponding embodiment (3.2) will not be repeated here.

[0225] Service providers can obtain the public key of the token in advance from the STS service. When a service provider receives a business request from a service requester, it can verify the token locally using the public key. This eliminates the need for the service provider to send an additional request to the STS service for token verification, improving its concurrent processing capabilities and efficiency, and reducing processing latency during business interactions between the service requester and the service provider.

[0226] Optional, in Figure 12 Based on the corresponding embodiment, the first token is the token corresponding to the first interface. Verifying the first token using the first token public key may include: generating a first token key for 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 this embodiment, the first interface can be understood as any interface of the service provider accessed by the service requester; this embodiment is not limited thereto. For example, the first interface can be as described above. Figure 5 The corresponding embodiment uses the interface-X interface of service B.

[0228] The interface ID of the first interface can be used to identify the first interface, or it can be understood as a unique identifier for the first interface. The specific unique identifier for the first interface is not limited in this embodiment. For example, the interface ID of the first interface can be as described above. Figure 5 The corresponding example uses intfid or interfaceName.

[0229] The first token key can be understood as the signing key for the first token. The first token key can be used to generate the token for the first interface, and also to verify the token for the first interface. For example, the first token key can be as described above. Figure 5 The corresponding token signing key is serviceKey in this embodiment. The specific process for generating the first token key can be referred to the above. Figure 5 The relevant descriptions of generating the serviceKey in the corresponding embodiments will not be repeated here.

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

[0231] Each interface of the service provider can have a different initial token key. A token key for one interface cannot be used to parse and verify another interface, thus ensuring the uniqueness of both the token and the key at the interface level, improving the security of accessing the service interface.

[0232] Optional, in Figure 12 Based on the corresponding embodiments, the verification of the first token may include 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 legality of the first token, verifying the issuer of the first token, or verifying the customized parameters of the first token.

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

[0234] The service provider's verification of the first token can improve the security of inter-service interactions and make the identity and access permissions of the service requester controllable.

[0235] Optional, in Figure 12 Based on the corresponding embodiment, before receiving the first request from the first service, it may further include: sending a second request to the second service; receiving a response from the second service to the second request, wherein the response to the second request includes the first token public key.

[0236] In this embodiment of the 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 In the corresponding embodiment, service B sends a registration service request to service STS. The specific second request sent is not limited in this embodiment.

[0237] The specific process by which the service provider sends a second request to the STS service and obtains the first token public key can be referred to the above. Figure 5 The relevant description of the registration process of service (1.2)B in the corresponding embodiment will not be repeated here.

[0238] The service provider obtains the first token public key from the STS service, enabling synchronization of the first token public key between the service provider and the STS service. This allows the service provider to locally verify the first token from the service requester, achieving localized token verification and reducing business processing latency.

[0239] Optional, in Figure 12Based on the corresponding embodiment, before sending the second request to the second service, the method may further 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 from the second service to the third request, 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; and sending the second request to the second service, which may include: sending a second request encrypted with the first key to the second service.

[0240] In this embodiment, the first private key and the first public key can be understood as the private key and public key generated by the service provider, which can be used to interact with the STS service. For example, the first private key can be as described above. Figure 5 In the corresponding embodiment, the ECC private key prikey-B1 for service B, the first public key can be the one described above. Figure 5 In the corresponding embodiment, the ECC private key pbkey-B1 for service B.

[0241] The third request can be understood as a request from the service provider to transmit the first public key to the STS service. For example, the third request can be as described above. Figure 5 In the corresponding embodiment, service B sends a pre-registration request to the STS service. The specific process of service B sending a pre-registration request to the STS service can be referred to the above. Figure 5 The relevant description of the pre-registration process of service (1.1) in the corresponding embodiment will not be repeated.

[0242] The second public key can be understood as the public key generated by the STS service, which can be used to interact with the service provider. For example, the second public key can be as described above. Figure 5 In the corresponding embodiment, the ECC private key pbkey-S1 of the STS service.

[0243] The first key can be understood as the key used to encrypt or decrypt transmitted data during the interaction between the service provider and the STS service. For example, the first key can be as described above. Figure 5 In the corresponding embodiment, the ECDH negotiation key between service B and service STS is sessionKey1.

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

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

[0246] In this embodiment of the application, the authentication level may include one or more levels, and this embodiment of the application does not limit it. For example, the authentication level may be as described above. Figure 5 The corresponding authentication levels in the embodiments can be found in the above description. Figure 5 The descriptions of the authentication levels in the corresponding embodiments will not be repeated here.

[0247] STS service supports configurable token security level control, which allows service providers to select different security levels for service requesters based on actual needs, improving the flexibility of token security level control.

[0248] Optional, in Figure 12 Based on the corresponding implementation, the authentication levels include one or more of the following: advanced authentication, normal authentication, no authentication, and access denied. Among them, advanced authentication corresponds to the use of a token signature algorithm that combines the ECDSAwithSHA256 algorithm and the HmacSHA256 algorithm.

[0249] In this embodiment of the application, the specific authentication level can be referred to the above. Figure 5 The descriptions of the authentication levels in the corresponding embodiments will not be repeated here.

[0250] Using a two-layer signature algorithm that combines ECDSAwithSHA256 and HmacSHA256 algorithms can make the token's signature algorithm more secure and less likely to be cracked, thus making the transmitted data more secure.

[0251] Optional, in Figure 12 Based on the corresponding implementation, the second service also periodically updates the first token public key and the first token private key.

[0252] In this embodiment of the application, the STS service periodically updates the first token public key and the first token private key, which can improve the security of the token private key, making it less likely to be cracked by untrusted third parties, thereby improving the security of the interaction between the service provider and the service requester.

[0253] Optional, in Figure 12 Based on the corresponding embodiments, 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 private key in the second service.

[0254] In this embodiment, the STS service can provide the service provider with the ability to remove authorized keys and reissue new keys, and supports 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 Figure 12 Based on the corresponding embodiment, after reconfiguring the authorization information for the first service in the second service, it may further include: receiving a message from the second service, the message including the regenerated first token public key.

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

[0257] Figure 13 Another token authentication method according to an embodiment of this application is illustrated. The method includes:

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

[0259] In this embodiment of the application, the third service can be understood as a service provider, for example, the third service can be the one described above. Figure 5 Service B in the corresponding embodiment.

[0260] The second service can be referred to the above. Figure 12 The description of the second service in step S1202 of the corresponding embodiment will not be repeated here.

[0261] The first token public key can be referenced as described above. Figure 12 The description of the first token public key in step S1202 of the corresponding embodiment will not be repeated here.

[0262] The process by which the third service obtains the first token public key from the second service can be referred to the above. Figure 12 The relevant descriptions of obtaining the first token public key in the corresponding embodiments will not be repeated here.

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

[0264] In this embodiment of the application, the first service can refer to the above. Figure 12 The description of the first service in step S1201 of the corresponding embodiment will not be repeated here.

[0265] The first request can refer to the above. Figure 12 The description of the first request in step S1201 of the corresponding embodiment will not be repeated here.

[0266] The first token can be referred to as described above. Figure 12 The description of the first token in step S1201 of the corresponding embodiment will not be repeated here.

[0267] The specific method for the third service to receive the first request from the first service can be referred to the above. Figure 5 The relevant description of Service A initiating a business request to Service B in the corresponding embodiment (3.1) will not be repeated here.

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

[0269] In this embodiment, the third service verifies the first token using the first token's public key, as described above. Figure 5 The relevant description of the request for service A to verify service B in the corresponding embodiment (3.2) will not be repeated here.

[0270] After obtaining the public key of the first token, the third service can perform the first token verification locally. In this way, the third service no longer needs to rely on the STS service for the first token verification, thus achieving decentralized token verification and reducing the pressure on the STS service for concurrent processing; the third service can also perform token verification locally, achieving localized token verification and reducing the latency of business processing.

[0271] Optional, in Figure 13 Based on the corresponding embodiment, the first token is the token corresponding to the first interface of the third service. The third service uses the first token public key to verify the first token, which may include: the third service generating a first token key for the first interface based on the first token public key and the interface ID of the first interface; and the third service using the first token key to verify the first token.

[0272] In this embodiment of the application, the first interface can refer to the above. Figure 12 The interface ID of the first interface can be referred to in the above description of the corresponding embodiment. Figure 12 The description of the interface ID of the first interface in the corresponding embodiment will not be repeated.

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

[0274] Each interface of the service provider can have a different initial token key. A token key for one interface cannot be used to parse and verify another interface, thus ensuring the uniqueness of both the token and the key at the interface level, improving the security of accessing the service interface.

[0275] Optional, in Figure 13Based on the corresponding embodiments, the third service obtaining the first token public key from the second service 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 this embodiment, the service provider obtains the first token public key from the STS service, enabling synchronization of the first token public key between the service provider and the STS service. This allows the service provider to locally verify the first token of the service requester, achieving localized token verification and reducing business processing latency.

[0277] Optional, in Figure 13 Based on 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 further include: the first service determining 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 its 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 its validity period, or if the first service determines that there is no cached first token, the first service obtains the first token from the second service.

[0278] In this embodiment of the application, the first service determines whether there is a cached and valid first token, which enables the first service to have a trustworthy identity and controllable access permissions when accessing the third service, thereby effectively interacting with the third service.

[0279] Optional, in Figure 13 Based on the corresponding embodiment, the first service obtaining the first token from the second service may include: the first service sending a fourth request to the second service; the second service generating a 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 a registration request sent by the third service; and the second service generating the first token based on the first token key. The first service receives a response from the second service to the fourth request, the response to the fourth request including the first token.

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

[0281] The process by which the second service generates the first token based on the first token key, and the process by which the first service receives the response from the second service to the fourth request, can be referred to the above. Figure 5The relevant descriptions in (2.2) of the STS service returning tokens and other information in the corresponding embodiment will not be repeated here.

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

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

[0284] In this embodiment of the application, the authentication level can be referred to the above. Figure 12 The descriptions of authentication levels in the corresponding embodiments will not be repeated here.

[0285] STS service supports configurable token security level control, which allows service providers to select different security levels for service requesters based on actual needs, improving the flexibility of token security level control.

[0286] Optional, in Figure 13 Based on the corresponding implementation, the authentication levels include one or more of the following: advanced authentication, normal authentication, no authentication, and access denied. Among them, advanced authentication corresponds to the use of a token signature algorithm that combines the ECDSAwithSHA256 algorithm and the HmacSHA256 algorithm.

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

[0288] Optional, in Figure 13 Based on the corresponding implementation, the second service also periodically updates the first token public key and the first token private key.

[0289] In this embodiment of the application, the STS service periodically updates the first token public key and the first token private key, which can improve the security of the token private key, making it less likely to be cracked by untrusted third parties, thereby improving the security of the interaction between the service provider and the service requester.

[0290] Optional, in Figure 13 Based on the corresponding embodiment, the method may further include: a 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 private 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.

[0291] In this embodiment of the application, the STS service can support the configuration update capability of the first token public key at the service level and the first token 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 to push the updated key information to the service provider, so that the service provider can obtain the latest key information in a timely manner and improve the timeliness of key updates.

[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, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0293] The foregoing primarily describes the solutions provided by the embodiments of this application from a methodological perspective. To achieve the aforementioned functions, it includes corresponding hardware structures and / or software modules for executing each function. Those skilled in the art should readily recognize that, based on the method steps of the examples described in conjunction with the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0294] This application embodiment can divide the apparatus for implementing the method into functional modules based on the above method examples. For example, each function can be divided into its own functional modules, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module. It should be noted that the module division in this application embodiment is illustrative and only represents one logical functional division; other division methods may be used in actual implementation.

[0295] like Figure 14 The diagram shows a chip structure according to an embodiment of this application. The chip 1400 includes one or more processors 1401, communication lines 1402, communication interfaces 1403, and memory 1404.

[0296] In some implementations, memory 1404 stores elements such as executable modules or data structures, or subsets thereof, or extended sets thereof.

[0297] The methods described in the embodiments of this application can be applied to, or implemented by, processor 1401. Processor 1401 may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above methods can be completed by integrated logic circuits in the hardware of processor 1401 or by instructions in software form. Processor 1401 may be a general-purpose processor (e.g., a microprocessor or conventional processor), a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gates, transistor logic devices, or discrete hardware components. Processor 1401 can implement or execute the various processing-related methods, steps, and logic block diagrams disclosed in the embodiments of this application.

[0298] The steps of the method disclosed in the embodiments of this application can be directly implemented by a hardware decoding processor, or implemented by a combination of hardware and software modules in the decoding processor. The software modules can be located in mature storage media in the art, such as random access memory, read-only memory, programmable read-only memory, or electrically erasable programmable read-only memory (EEPROM). This storage medium is located in memory 1404, and processor 1401 reads information from memory 1404 and, in conjunction with its hardware, completes the steps of the above method.

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

[0300] In the above embodiments, the instructions stored in the memory for execution by the processor can be implemented in the form of a computer program product. This computer program product can be pre-written into the memory, or it can be downloaded and installed into the memory as software.

[0301] This application also provides a computer program product comprising one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the flow or function according to the embodiments of this application is generated. 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. For example, computer instructions may be transmitted from a website site, computer, server, or data center to another website site, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. 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 integrates one or more available media. For example, available media may include magnetic media (e.g., floppy disk, hard disk, or magnetic tape), optical media (e.g., digital versatile disc (DVD)), or semiconductor media (e.g., solid-state disk (SSD)).

[0302] This 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. The computer-readable medium may include computer storage media and communication media, and may also include any medium capable of transferring a computer program from one place to another. The storage medium can be any target medium accessible by a computer.

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

[0304] This application describes embodiments with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processing unit of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processing unit of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

Claims

1. A token authentication method, characterized by, The method is applied to a third service, the third service being a service provider, and the method comprises: receiving a first request from a first service, the first request comprising a first token; the first service being a service requester; the first token being obtained in advance by the first service from a second service; locally verifying the first token using a first token public key, wherein the first token public key is obtained in advance from the second service; the second service being configured with an authentication level of an interface of the third service, the authentication level being any one of high-level authentication, normal authentication, no authentication, and access prohibition; the first token being a token corresponding to a first interface, and the locally verifying the first token using the first token public key comprising: generating a first token secret key of the first interface based on the first token public key, an interface ID of the first interface, and a challenge value; locally verifying the first token using the first token secret key; before the receiving the first request from the first service, the third service receiving a third public key from the second service, the third public key being saved in the second service by the first service when the first service registers with the second service; the third service generating a second secret key based on the third public key and a second private key of the third service, so that the third service and the first service perform data interaction based on the second secret key.

2. The method of claim 1, wherein, The verifying the first token comprises any one or more of the following: verifying a validity period of the first token, determining whether the first token is authorized for the first interface, verifying a signature of the first token, verifying legality of the first token, verifying an issuer of the first token, or verifying a customized parameter of the first token.

3. The method according to claim 1 or 2, characterized in that, Before the receiving the first request from the first service, the method further comprises: sending a second request to the second service; receiving a response to the second request from the second service, the response to the second request comprising the first token public key.

4. The method of claim 3, wherein, Before the sending the second request to the second service, the method further comprises: generating a first private key and a first public key; sending a third request to the second service, the third request comprising the first public key; receiving a response to the third request from the second service, the response to the third request comprising a second public key of the second service; generating a first secret key based on the first private key and the second public key; sending the second request to the second service, comprising: sending the second request encrypted by the first secret key to the second service.

5. The method according to any one of claims 1 to 4, characterized in that, The second service is configured with authorization information of the first service, the authorization information comprising one or more of the following: the authentication level, and a validity period of the first token.

6. The method of claim 5, wherein, The authentication level comprises one or more of the following: high-level authentication, normal authentication, no authentication, and access prohibition, wherein the high-level authentication corresponds to a token signature algorithm using a combination of an ECDSA with SHA256 algorithm and an HmacSHA256 algorithm.

7. The method according to any one of claims 1 to 6, characterized in that, The second service further periodically updates the first token public key and the first token secret key.

8. The method according to any one of claims 1 to 6, characterized in that, The method further comprises: reconfiguring authorization information of the first service in the second service, for the second service to regenerate a first token public key and a first token secret key.

9. The method of claim 8, wherein, After reconfiguring the authorization information of the first service in the second service, the method further comprises: receiving a message from the second service, the message comprising the regenerated first token public key.

10. A token authentication method, characterized by, The method is applied to a service interaction system, the service interaction system comprising a first service, a second service and a third service, the first service being a service requester, and the third service being a service provider; The method comprises: 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 comprises a first token, the first token being obtained by the first service from the second service in advance; the second service is configured with an authentication level of an interface of the third service, the authentication level being any one of high-level authentication, normal authentication, no authentication and access prohibition; The third service verifies the first token locally using the first token public key; The first token is a token corresponding to a first interface of the third service, and the third service verifies the first token locally using the first token public key, comprising: The third service generates a first token secret key of the first interface based on the first token public key, an interface ID of the first interface and a challenge value; The third service verifies the first token locally using the first token secret key; Before the third service receives the first request from the first service, The third service receives a third public key from the second service, the third public key being saved in the second service by the first service when registering with the second service; The third service generates a second secret key based on the third public key and a second private key of the third service; The first service receives a fourth public key from the second service, the fourth public key being saved in the second service by the third service when registering with the second service; The first service generates the second secret key based on the fourth public key and a second private key of the first service; The third service and the first service perform data interaction based on the second secret key.

11. The method of claim 10, wherein, The third service obtains a first token public key from the second service, comprising: The third service obtains the first token public key from the second service when sending a registration request to the second service.

12. The method according to claim 10 or 11, characterized in that, The first token is a token generated by the second service, and before the third service receives the first request from the first service, the method further comprises: 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 a valid period, the first service sends the first request to the third service; If the first service determines that the first token is cached, but the first token is not within a valid period, or the first service determines that the first token is not cached, the first service acquires the first token from the second service.

13. The method of claim 12, wherein, The first service acquires the first token from the second service, comprising: The first service sends a fourth request to the second service; The second 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, wherein the interface ID of the first interface is acquired 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 first token is included in the response to the fourth request.

14. The method according to any one of claims 10 to 13, 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, valid period of the first token.

15. The method of claim 14, wherein, The authentication level includes one or more of the following: high-level authentication, ordinary authentication, no authentication, and access prohibited, wherein the high-level authentication corresponds to a token signature algorithm using a combination of ECDSA with SHA256 algorithm and HmacSHA256 algorithm.

16. The method according to any one of claims 10-15, characterized in that, The second service also periodically updates the first token public key and the first token key.

17. The method according to any one of claims 10-16, characterized in that, The method further comprises: The third service reconfigures the authorization information of the first service in the second service; The second service generates the first token public key and the first token key based on the reconfigured authorization information; The third service receives a message from the second service, and the message includes the first token public key regenerated.

18. A server, comprising: Comprise: a memory for storing a computer program, and a processor for executing the computer program to perform the method of any one of claims 1-9, or the method performed by the first service in the method of any one of claims 10-17, or the method performed by the second service in the method of any one of claims 10-17, or the method performed by the third service in the method of any one of claims 10-17.

19. A service interaction system, characterized by Comprise: a first server for performing the method performed by the first service in the method of any one of claims 10-17, a second server for performing the method performed by the second service in the method of any one of claims 10-17, and a third server for performing the method performed by the third service in the method of any one of claims 10-17.

20. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions that, when executed, cause the server to perform the method of any of claims 1-9, or the method performed by the first service of any of claims 10-17, or the method performed by the second service of any of claims 10-17, or the method performed by the third service of any of claims 10-17.

21. A computer program product, characterised in that, The computer program, when run, causes the server to perform the method of any of claims 1-9, or the method performed by the first service of any of claims 10-17, or the method performed by the second service of any of claims 10-17, or the method performed by the third service of any of claims 10-17.

Images