Micro-service authentication method and related device

Abstract

The embodiment of the invention provides a micro-service authentication method and a related device, the method is applied to a micro-service architecture in a heterogeneous language environment, and the micro-service architecture comprises an authentication service, a gateway and micro-services constructed by different programming languages. The authentication service is used for generating an authentication identifier serving as an authentication basis; the gateway is used for authenticating the request for calling the micro service according to the authentication identifier; the method comprises the following steps: carrying out authentication check on a user request through an interceptor configured in a micro-service; and under the condition that the interceptor intercepts a user request which is not authenticated by the gateway, calling the authentication service to authenticate an authentication identifier in the user request. The implementation difficulty of authentication logic can be reduced.

Description

Technical Field

[0001] The embodiments described in this application relate to the field of microservices technology, and in particular to a microservices authentication method and related apparatus. Background Technology

[0002] Different business scenarios may have different requirements for the technology stack, and in order to efficiently integrate a system to meet user needs, a heterogeneous microservice architecture is usually built. In this architecture, each microservice is built using different programming languages, runtime platforms, and development frameworks.

[0003] The approach to heterogeneous microservice authentication using related technologies involves developing separate authentication logic for each microservice, based on its corresponding programming language and runtime environment. However, implementing this authentication logic is quite challenging. Summary of the Invention

[0004] In view of this, multiple embodiments of this application aim to provide a microservice authentication method and related apparatus, which can reduce the difficulty of implementing authentication logic.

[0005] One embodiment of this application provides a microservice authentication method. The method is applied to a microservice architecture in a heterogeneous language environment. The microservice architecture includes an authentication service, a gateway, and microservices built using different programming languages. The authentication service generates an authentication identifier used as the basis for authentication. The gateway authenticates requests calling microservices based on the authentication identifier. The method includes: performing authentication checks on user requests through interceptors configured in the microservices; and, if the interceptor intercepts a user request that has not been authenticated by the gateway, invoking the authentication service to authenticate the authentication identifier in the user request.

[0006] Optionally, the method further includes: constructing interceptors corresponding to each microservice based on the programming language of each microservice; and configuring the interceptors in the corresponding microservices.

[0007] Optionally, the step of performing authentication checks on user requests through interceptors configured in the microservice includes: sequentially checking user requests through multiple interceptors configured in the microservice; wherein, there is a logical execution order among the multiple interceptors, and a later interceptor is triggered if the previous interceptor fails to intercept successfully, and the first interceptor in the logical execution order is used to perform authentication checks.

[0008] Optionally, the method further includes: upon receiving a signal from the authentication service indicating successful authentication, executing response logic corresponding to the user request.

[0009] Optionally, the method further includes: if the user request does not contain a specific identifier, determining that the user request has not been authenticated by the gateway; wherein the specific identifier is used to associate with the gateway.

[0010] Optionally, the method further includes: upon receiving a target request sent via the gateway, executing response logic corresponding to the target request; wherein the target request is a request that has been authenticated and authorized by the gateway, and the target request includes user information added by the gateway to indicate the source of the target request.

[0011] One embodiment of this application also provides a microservice authentication device, which is applied in a microservice architecture with a heterogeneous language environment. The microservice architecture includes an authentication service, a gateway, and microservices built in different programming languages. The authentication service is used to generate an authentication identifier as the basis for authentication. The gateway is used to authenticate requests calling each microservice based on the authentication identifier. The device includes: a configuration module, used to perform authentication checks on user requests through interceptors configured in the microservices; and an authentication module, used to call the authentication service to authenticate the authentication identifier in the user request when the interceptor intercepts a user request that has not been authenticated by the gateway.

[0012] One embodiment of this application provides a computer device, the computer device including a memory and a processor, the memory storing at least one computer program, the at least one computer program being loaded and executed by the processor to implement the microservice authentication method as described above.

[0013] One embodiment of this application provides a computer-readable storage medium storing at least one computer program that, when executed by a processor, can implement the microservice authentication method described above.

[0014] One embodiment of this application provides a computer program product for implementing the microservice authentication method as described above.

[0015] In several embodiments provided in this application, the microservice authentication method is applied to a microservice architecture in a heterogeneous language environment. The microservice architecture includes an authentication service, a gateway, and microservices built in different programming languages. The authentication service is used to generate an authentication identifier used as the basis for authentication. The gateway is used to authenticate requests calling microservices based on the authentication identifier. Specifically, the microservice authentication method can perform authentication checks on user requests through interceptors configured in the microservices. When the interceptor intercepts a user request that has not been authenticated by the gateway, it calls the authentication service to authenticate the authentication identifier in the user request. This eliminates the need to repeatedly develop authentication logic for each heterogeneous microservice, thereby reducing the difficulty of implementing authentication logic for heterogeneous microservices. Attached Figure Description

[0016] Figure 1 A schematic diagram of the system architecture of an application microservice authentication method provided in one embodiment of this application.

[0017] Figure 2 A flowchart of a microservice authentication method provided for one embodiment of this application.

[0018] Figure 3 This is a schematic diagram of an interceptor configuration provided for one embodiment of this application.

[0019] Figure 4 A schematic diagram of a microservice authentication device provided in one embodiment of this application.

[0020] Figure 5 A schematic diagram of a computer device provided for one embodiment of this application. Detailed Implementation

[0021] The information to be retrieved in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0022] In the description of the embodiments of this application, it should be understood that the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Therefore, features defined with "first" and "second" may explicitly or implicitly include one or more of the stated features. In the description of the embodiments of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0023] Microservices are small, independently deployable service units derived from a monolithic application. In a microservice architecture, each microservice is built around a specific business capability (e.g., recommendation, payment, logistics tracking), has an independent runtime environment, and can collaborate with other services through lightweight communication mechanisms (e.g., HTTP / REST, gRPC, message queues). Because microservices are independent of each other, they offer advantages such as ease of maintenance and scalability.

[0024] In microservice architecture, there are homogeneous and heterogeneous microservice architectures, distinguished by the consistency of the implementation language and runtime environment of the microservices. In a homogeneous microservice architecture, all microservices are built using the same programming language, framework, and runtime environment, and generally follow a unified development standard and technology stack. In a heterogeneous microservice architecture, microservices are built using multiple programming languages ​​and runtime platforms, such as Java, Python, Go, Node.js, and Rust, with each microservice running in a different container or virtual machine environment.

[0025] In the security design of a microservice architecture, microservice calls require authentication to ensure secure invocation. Due to the heterogeneity among microservices in a heterogeneous microservice architecture, implementing authentication typically requires implementing authentication logic separately for each microservice, based on its programming language and runtime environment. For example, if microservices are built using Java, Python, Go, and Node.js, then a separate authentication logic needs to be developed and configured for each microservice.

[0026] This process typically requires developers to master the encryption library calling methods of multiple languages, and also to ensure logical consistency and security, making development quite difficult. Furthermore, since each programming language requires separate coding, debugging, and testing, there is a problem of wasted development resources due to redundant development. In addition, due to the differences in logical implementation between multiple programming languages, implementing the above authentication logic scheme also poses certain security risks. Moreover, maintaining the authentication logic in each microservice is also quite difficult; multi-point maintenance mechanisms can easily lead to version inconsistencies and other problems, affecting the system stability of the microservice architecture.

[0027] Therefore, it is necessary to provide a microservice authentication method applicable to microservice architectures in heterogeneous language environments. This microservice architecture includes an authentication service, a gateway, and microservices built in different programming languages. The authentication service generates authentication identifiers used for authentication, and the gateway authenticates requests calling microservices based on these identifiers. Specifically, the microservice authentication method can use interceptors configured within microservices to perform authentication checks on user requests. If an interceptor intercepts a user request that has not been authenticated by the gateway, it calls the authentication service to authenticate the identifier in the user request. This eliminates the need to repeatedly develop authentication logic for each heterogeneous microservice, reducing the complexity of implementing authentication logic for heterogeneous microservices.

[0028] Please see Figure 1 In several embodiments provided in this application, the microservice authentication method can be applied to a microservice authentication device. The microservice authentication device can be an electronic device with certain computing power and network access capabilities. This electronic device can be a desktop computer, laptop computer, tablet computer, or server. The server can be a distributed server, including multiple processors, memory, network communication modules, etc., working together to achieve various functions. Alternatively, the server can also be a server cluster formed by several servers, possessing higher computing and data processing capabilities. With the development of science and technology, the server can also be implemented using new technological means, such as a new type of "server" based on quantum computing. Of course, in some embodiments, the microservice authentication device can also be a program module running in an electronic device.

[0029] In this embodiment, the microservice authentication device runs multiple microservices in heterogeneous languages. Each microservice is configured with an interceptor adapted to its operating environment and programming language. When an interceptor intercepts a user request that has not been authenticated by the gateway, it remotely calls an authentication service deployed on an external device to authenticate the authentication identifier in the user request. The authentication service on the external device generates an authentication identifier used as the basis for authentication and executes authentication logic. The gateway runs on the external device and authenticates requests to call microservices based on the authentication identifier.

[0030] The architecture comprises microservices using multiple heterogeneous languages, an authentication service, and a gateway. Within this architecture, the authentication service generates an authentication identifier for each user request, serving as the basis for identity verification. When a user requests a microservice through the gateway, the gateway authenticates the user based on the authentication identifier in the request. When a user requests a microservice directly, an interceptor configured within the microservice intercepts the request and invokes the authentication service to perform authentication. The authentication service is responsible for providing unified authentication for all microservice call requests.

[0031] In some implementations, a microservice authentication device runs multiple microservices, authentication services, and gateways in heterogeneous languages. Alternatively, the multiple microservices, authentication services, and gateways in heterogeneous languages ​​each run on independent hardware devices, and the hardware device running the multiple microservices in heterogeneous languages ​​is called a microservice authentication device. Further optionally, the multiple microservices in heterogeneous languages ​​each run on an independent microservice authentication device, and each microservice authentication device establishes communication with the hardware device running the authentication service to invoke the authentication service to execute user request authentication.

[0032] Please see Figure 2 One embodiment of this application provides a microservice authentication method. The microservice authentication method is applied to a microservice architecture in a heterogeneous language environment. The microservice architecture includes an authentication service, a gateway, and microservices built in different programming languages. The authentication service generates an authentication identifier used as the basis for authentication. The gateway authenticates requests to call microservices based on the authentication identifier. Specifically, the microservice authentication method can be applied to a microservice authentication device in a microservice architecture located in a heterogeneous language environment. The microservice authentication method may include the following steps.

[0033] Step S110: Perform authentication checks on user requests using interceptors configured in the microservice.

[0034] Step S120: If the interceptor intercepts a user request that has not been authenticated by the gateway, the authentication service is invoked to authenticate the authentication identifier in the user request.

[0035] In this implementation, an authentication service is provided within a microservice architecture with a heterogeneous language environment, where each microservice is written in a different programming language. The authentication service generates an authentication identifier to represent the user's identity after the user logs into the system. This identifier can be used as the basis for legitimate microservice calls and legitimate resource read / write operations. The authentication service can also perform registration and authorization logic. For example, it can be a remote verification service based on a REST API.

[0036] In this implementation, the authentication identifier can be represented in any of the following forms: JSON-based Lightweight Token (JWT), Session ID, API key, Digital Certificate / Client Certificate, or Temporary Authorization Code.

[0037] In one implementation, the authentication identifier is represented as a JWT that does not rely on server session storage. The JWT contains a declaration of the token type and signing algorithm, user-related declaration information (e.g., user ID, user permissions), a key signature for the declaration information, and a signature validity period. The JWT has a standard format, supports cross-language parsing, and using JWT as the authentication identifier allows microservices using various heterogeneous languages ​​to parse it. Furthermore, the JWT can carry user information, facilitating the extraction of user context added by the gateway from the microservice. Additionally, the JWT is represented as a string, making it easy to pass via HTTP headers or URL parameters. Using JWT as the authentication identifier enables efficient and accurate authentication in heterogeneous microservice architectures.

[0038] Furthermore, after the username and password are submitted to the authentication service, the service generates a JWT, signs the JWT, and returns it to the client. When the client calls the microservice, it can generate a request containing the JWT. Generally, the JWT is written into the request header, such as Authorization: Bearer. <token>The client then sends the request to the gateway, which verifies the JWT in the request and authenticates the username based on the microservice / resource invoked by the request. If both JWT verification and authentication are successful, the gateway forwards the request to the corresponding microservice. Since this microservice is authenticated by the gateway, it can be securely invoked. Specifically, the microservice executes the response logic corresponding to the request without needing to authenticate it.

[0039] In some implementations, to enhance system security, the microservice may call the authentication service to perform secondary authentication of the request, or perform other forms of multi-factor authentication; this application does not limit this.

[0040] In this embodiment, the gateway acts as the request entry point for clients, handling request routing, load balancing, rate limiting, and authentication. In some embodiments, the gateway performs request authentication by: locally verifying the authentication identifier in the client's request using a key identical to that held by the authentication service, ensuring the identifier is not forged, expired, or tampered with. If authentication is successful, the gateway adds user context information to the request and passes it to the corresponding microservice. In other embodiments, the gateway performs request authentication by: sending the authentication identifier in the request as a parameter to the authentication service's verification interface, allowing the verification result to remotely verify the identifier, ensuring it is not forged, expired, or tampered with. When the gateway receives a verification result from the authentication service indicating successful authentication, it adds user context information to the request and passes it to the corresponding microservice.

[0041] In some implementations, the gateway and authentication service are built on Java and Spring Cloud, while the microservices are built on Java, Python, Go, and Node.js, respectively. Different programming languages ​​may be suitable for different functionalities; for example, Python is suitable for developing recommendation functions, while Go is suitable for developing high-concurrency services. Using the appropriate language to develop the corresponding functions / systems can ensure optimal performance. For example, the microservices are used to handle products, orders, users, and inventory, respectively. For instance, microservice 1 provides order-related functions such as placing and canceling orders, microservice 2 provides product-related functions such as product information query and inventory query, and microservice 3 provides payment-related functions such as payment and refund.

[0042] In this implementation, user requests can be sent to the gateway to trigger request authentication, or they can bypass the gateway and be sent directly to the microservice to trigger the microservice's interceptor to intercept and remotely call the authentication service for request authentication. For example, in cases of frequent calls between microservices (e.g., the order service calling the inventory service or product service), authenticating requests through the gateway would increase network latency. In such cases, sending requests directly to the microservice can improve service call efficiency. Furthermore, for high-traffic or long-connection services such as file uploads / downloads, request authentication through the gateway would place a significant load on the gateway and could potentially lead to performance bottlenecks. In these situations, sending requests directly to the microservice, bypassing the gateway, can distribute the gateway's load.

[0043] In this embodiment, because the microservices use different programming languages, interceptors adapted to their respective programming languages ​​are configured in each microservice to ensure smooth operation within the microservice's runtime environment. Interceptors with the same execution goal may have different implementation logic in different microservices. Interceptors are componentized mechanisms used to implement request preprocessing and response postprocessing. In this application, the interceptor executes one or more cross-cutting logic operations, such as authentication checks, logging, performance monitoring, and parameter validation, before the microservice executes its business logic (e.g., order placement logic).

[0044] In this implementation, the microservice is configured with at least one interceptor for executing unauthenticated request interception logic. When a user request received by the microservice is not authenticated by the gateway, the interceptor intercepts the authentication request, preventing the authentication request from being responded to without authentication. Furthermore, the microservice can call the verification interface provided by the authentication service to verify whether the authentication identifier in the authentication request is not forged, expired, or tampered with. After receiving the verification result returned by the verification interface, the microservice can respond to the user request. The specific response logic depends on the actual content of the user request. For example, if the user request is to query product XXX, the user request is sent to the microservice responsible for product information management and, after authentication, the microservice executes the query logic to read information related to product XXX from the database and returns this information as the response result to the user.

[0045] In this embodiment, the microservice authentication method is applied to a microservice architecture in a heterogeneous language environment. The microservice architecture includes an authentication service, a gateway, and microservices built in different programming languages. The authentication service generates an authentication identifier used as the basis for authentication, and the gateway authenticates requests calling microservices based on the authentication identifier. Specifically, the microservice authentication method can perform authentication checks on user requests through interceptors configured in the microservices. When the interceptor intercepts a user request that has not been authenticated by the gateway, it calls the authentication service to authenticate the authentication identifier in the user request. This eliminates the need to repeatedly develop authentication logic for each heterogeneous microservice, reducing the difficulty of implementing authentication logic for heterogeneous microservices.

[0046] In some implementations, the microservice authentication device can construct interceptors corresponding to each microservice based on the programming language of each microservice; and configure the interceptors in the corresponding microservices.

[0047] In this implementation, different microservices can be built using the same programming language or different programming languages. It is understood that in a heterogeneous microservice architecture, at least two microservices are built using different programming languages. Interceptors in different microservices differ in one or more of the following aspects: interface mechanism, registration method, lifecycle control method, exception handling mechanism, optimization method, and observation method.

[0048] In this implementation, interceptors are built based on the programming language of each microservice, which can ensure the consistency of security policies for microservices in different languages, improve the independence and maintainability of microservices, reduce dependence on central components, and improve development efficiency and architectural compatibility.

[0049] In some implementations, the microservice authentication device can sequentially check user requests using multiple interceptors configured in the microservice; wherein, there is a logical execution order among the multiple interceptors, and a later interceptor is triggered if the previous interceptor fails to intercept it, and the first interceptor in the logical execution order is used to perform authentication checks.

[0050] In this implementation, to ensure that a request meets a series of custom conditions before reaching the backend business logic (e.g., reading data, returning a webpage), these custom conditions are configured in the microservice as an interceptor chain. For details, please refer to [link to relevant documentation]. Figure 3 .like Figure 3 As shown, after a microservice receives a user request, it triggers interceptors to check the request sequentially. If the previous interceptor passes the check, the next interceptor is triggered to perform subsequent checks. Once the last interceptor in the interceptor chain passes the check, the user request reaches the backend business logic. If any interceptor fails the check, the process terminates and returns a failure signal (e.g., 401 Unauthorized) and the reason for the failure (e.g., Token expired, IP restricted).

[0051] In this embodiment, the number of interceptors configured in different microservices can be the same or different, and the interception logic of the interceptors configured in different microservices can also be different. This application does not limit this.

[0052] For example, different interceptor chains are configured for different microservice programming languages, namely: JavaServlet interceptor chain, Golang Middleware interceptor chain, and ASP.NET Core ActionFilter interceptor chain.

[0053] Taking a Java Servlet interceptor chain as an example, the specific approach is as follows: Define a Filter class that implements the interface "javax.servlet.Filter". The interface "javax.servlet.Filter" is implemented through the methods "init()", "doFilter()", and "destroy()". The "doFilter()" function includes logic to validate the JWT before the request. If the validation is successful, "chain.doFilter(request, response)" is executed, allowing the request to proceed to the next interceptor. Furthermore, configuration is done in web.xml. <filter>and <filter-mapping>Declare the interceptor or annotate it with `@WebFilter` in your Java class to ensure it is correctly recognized. For multiple interceptors, the execution order is defined by configuration or alphabetical order.

[0054] In some implementations, the microservice authentication device can execute response logic corresponding to the user request upon receiving a signal from the authentication service indicating successful authentication.

[0055] In this implementation, a signal indicating successful authentication is received when a standard HTTP response status and a valid authentication identifier are detected, or when a boolean identifier (e.g., true) is received from the authentication service, or when the authentication service returns a structured object carrying user identity information, or when a signed authentication identifier is received. Then, response logic corresponding to the user request can be executed to ensure the microservice is securely invoked. This response logic includes, but is not limited to: querying database resources and returning query results; executing user operation requests, such as placing an order; modifying system or resource status; initiating background tasks, asynchronous processes, and notification mechanisms; and invoking downstream services for request distribution and data integration.

[0056] In some implementations, the microservice authentication device can determine that a user request has not been authenticated by the gateway if it detects that the user request does not contain a specific identifier; wherein the specific identifier is used to associate with the gateway.

[0057] In this embodiment, the specific identifier refers to a field / value injected by the gateway that cannot be bypassed or forged. The specific identifier can be defined in the header of the HTTP request, or it can be defined as a gateway signature field in a JWT or Token; this embodiment does not limit this.

[0058] In this implementation, if the result after parsing a user request contains a specific identifier, it indicates that the user request has been authenticated by the gateway and can be responded to directly. If the result after parsing a user request does not contain a specific identifier, it indicates that the user request is a request sent directly to the microservice bypassing the gateway. To ensure that the microservice is called securely, the authentication service needs to be invoked to authenticate the user request.

[0059] In some implementations, the microservice authentication device can execute response logic corresponding to the target request upon receiving a target request sent via the gateway; wherein the target request is a request that has been authenticated and authorized by the gateway, and the target request includes user information added by the gateway to indicate the source of the target request.

[0060] In this implementation, the target request refers to a request authenticated and authorized by the gateway. The target request includes a specific identifier and user information added by the gateway (e.g., userId, roles, tenantId, etc.) to enable backend microservices to identify the user and avoid repeated parsing of the authentication identifier by each microservice. The user information can be extracted from the authentication identifier.

[0061] Please see Figure 4 This application also provides a microservice authentication device. The device is applied in a microservice architecture with a heterogeneous language environment. The microservice architecture includes an authentication service, a gateway, and microservices built in different programming languages. The authentication service generates an authentication identifier used as the basis for authentication. The gateway authenticates requests calling each microservice based on the authentication identifier. The device includes: a configuration module for performing authentication checks on user requests through interceptors configured in the microservices; and an authentication module for, when the interceptor intercepts a user request that has not been authenticated by the gateway, calling the authentication service to authenticate the authentication identifier in the user request.

[0062] The specific functions and effects of the microservice authentication device implemented in this embodiment can be explained by referring to other embodiments of this application, and will not be repeated here.

[0063] Please see Figure 5 This application also provides a computer device comprising: a memory and a processor, wherein the memory stores at least one computer program, and the at least one computer program is loaded and executed by the processor to implement the method described above.

[0064] It is understood that the specific examples in this document are only intended to help those skilled in the art better understand the embodiments of this application, and are not intended to limit the scope of the invention.

[0065] It is understood that in the various embodiments of this application, the sequence number of each process does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0066] It is understood that the various implementation methods described in this application can be implemented individually or in combination, and the implementation methods in this application are not limited in this respect.

[0067] Unless otherwise stated, all technical and scientific terms used in the embodiments of this application have the same meaning as commonly understood by one of ordinary skill in the art. The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The term "and / or" as used in this application includes any and all combinations of one or more of the associated listed items. The singular forms "a," "the," and "the" as used in the embodiments of this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise.

[0068] It is understood that the processor in the embodiments of this application can be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method embodiments can be completed by the integrated logic circuits in the processor's hardware or by instructions in software form. The processor can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory; the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

[0069] It is understood that the memory in the embodiments of this application may be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. Specifically, non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory may be random access memory (RAM). It should be noted that the memory in the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0070] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software 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.

[0071] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the aforementioned method implementations, and will not be repeated here.

[0072] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0073] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0074] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0075] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0076] The above description is merely a specific embodiment of this application, but the scope of protection of this invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this invention should be determined by the scope of the claims. < / filter> < / token>

Claims

1. A microservice authentication method, characterized in that, The method is applied to a microservice architecture in a heterogeneous language environment, which includes authentication services, gateways, and microservices built in different programming languages. The authentication service is used to generate authentication identifiers that serve as the basis for authentication; The gateway is used to authenticate requests for calling microservices based on authentication identifiers; The method includes: Authentication checks on user requests are performed using interceptors configured in the microservices; If the interceptor intercepts a user request that has not been authenticated by the gateway, it invokes the authentication service to authenticate the authentication identifier in the user request.

2. The method according to claim 1, characterized in that, The method further includes: Interceptors corresponding to each microservice are constructed based on the programming language of each microservice. Configure the interceptor in the corresponding microservice.

3. The method according to claim 1, characterized in that, The steps for performing authentication checks on user requests using interceptors configured in microservices include: User requests are checked sequentially by multiple interceptors configured in the microservice; wherein there is a logical execution order among the multiple interceptors, and the subsequent interceptor is triggered if the previous interceptor fails to intercept it. The first interceptor in the logical execution order is used to perform authentication checks.

4. The method according to claim 1, characterized in that, The method further includes: Upon receiving a signal from the authentication service indicating successful authentication, the system executes response logic corresponding to the user's request.

5. The method according to claim 1, characterized in that, The method further includes: If the user request does not contain a specific identifier, the user request is deemed to have not been authenticated by the gateway; wherein the specific identifier is used to associate with the gateway.

6. The method according to any one of claims 1 to 5, characterized in that, The method further includes: Upon receiving a target request sent via the gateway, execute response logic corresponding to the target request; wherein the target request is a request that has been authenticated and authorized by the gateway, and the target request includes user information added by the gateway to indicate the source of the target request.

7. A microservice authentication device, characterized in that, The device is applied in a microservice architecture in a heterogeneous language environment, the microservice architecture including authentication services, gateways, and microservices built in different programming languages; The authentication service is used to generate authentication identifiers that serve as the basis for authentication; The gateway is used to authenticate requests for calling each microservice based on the authentication identifier; The device includes: The configuration module is used to perform authentication checks on user requests through interceptors configured in the microservice; The authentication module is used to invoke the authentication service to authenticate the authentication identifier in the user request when the interceptor intercepts a user request that has not been authenticated by the gateway.

8. A computer device, characterized in that, The computer device includes a memory and a processor, wherein the memory stores at least one computer program, which is loaded and executed by the processor to implement the microservice authentication method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores at least one computer program, which, when executed by a processor, is capable of implementing the microservice authentication method as described in any one of claims 1 to 6.

10. A computer program product, characterized in that, The computer program product is used to implement the microservice authentication method as described in any one of claims 1 to 6.

Images