Microservice authentication method, storage medium and electronic device

Abstract

The invention discloses a micro-service authentication method, a storage medium and an electronic device, and relates to the technical field of smart home, the micro-service authentication method comprises the following steps: a gateway receives a micro-service interface calling request sent by a client, and if the gateway determines that the micro-service interface calling request comprises a legal token issued by an authentication server, the micro-service interface calling request is sent to the client; if yes, the micro-service interface calling request is sent to a micro-server side, the micro-server side sends a token authentication request to an authentication server side, and under the condition that token authentication is passed, the micro-server side sends a micro-service interface calling response to the client side through the gateway; according to the method, through a dual token verification mechanism of the gateway and the authentication server, only the client holding the legal token can successfully call the micro-service interface, so that the security under the micro-service architecture is enhanced.

Description

Technical Field

[0001] The present application relates to the field of smart home technology, and more specifically, to a microservice authentication method, storage medium, and electronic device. Background Art

[0002] The rise of microservice architecture has brought about a complex distributed system environment, which has put forward higher requirements for authentication and authorization mechanisms. In this context, OAuth 2.0, as an open standard authorization protocol, has become one of the important authentication methods in microservice architecture.

[0003] Currently, in the microservice architecture, OAuth 2.0 implements access control to microservice resources by issuing access tokens through the authentication server. When the user passes the authentication, the authentication server will generate an access token containing the user's identity and permission information and return it to the client. When the client subsequently requests microservice resources, it will carry this access token for identity authentication. The microservice confirms the user's identity and permissions by verifying the validity of the access token, and then decides whether to allow access to the corresponding resources.

[0004] However, the use of OAuth 2.0 technology for microservice authentication has the problem of low security under the microservice architecture. Summary of the invention

[0005] The present application provides a microservice authentication method, a storage medium, and an electronic device to solve the problem of low security under a microservice architecture.

[0006] In a first aspect, the present application provides a microservice authentication method, which is applied to a server, wherein the server includes a gateway, a microservice, and an authentication server, including:

[0007] The gateway receives the microservice interface call request sent by the client;

[0008] If the gateway determines that the microservice interface call request includes a legal token issued by the authentication server, the microservice interface call request is sent to the microservice;

[0009] The microservice sends a token authentication request to the authentication service. If the token authentication is successful, the microservice sends a microservice interface call response to the client through the gateway.

[0010] Optionally, also include:

[0011] The gateway receives the authentication request sent by the client, and sends the authentication request to the authentication server, where the authentication request is used to request to obtain the token;

[0012] The gateway receives the token returned by the authentication server and sends the token to the client.

[0013] Optionally, the authentication request includes an authorization code, and the method further includes:

[0014] The gateway receives the authorization code acquisition request sent by the client, and sends the authorization code acquisition request to the authentication server;

[0015] The authentication server returns the authorization code to the gateway, and the gateway sends the authorization code to the client.

[0016] Optionally, the authentication server returns the authorization code to the gateway, including:

[0017] When the authorization code acquisition request is in a non-logged-in state, the authentication server returns a login page to the client through the gateway;

[0018] In response to the user name and password returned by the client for successful login, the authentication service returns the authorization code to the gateway.

[0019] Optionally, the gateway determines that the microservice interface call request includes a legal token issued by the authentication server, including:

[0020] The gateway determines whether the microservice interface call request includes a token. If the microservice interface call request includes a token, the format, validity period and issuer of the token are verified. If the verification passes, it is determined that the token is a legal token issued by the authentication server.

[0021] Optionally, when the token authentication is passed, before the microservice sends a microservice interface call response to the client through the gateway, the method further includes:

[0022] The authentication server determines whether the permissions corresponding to the token include permissions to access the microservice end. If the permissions corresponding to the token include permissions to access the microservice end, it is determined that the token authentication is successful.

[0023] Optionally, also include:

[0024] If the gateway determines that the microservice interface call request does not include a legitimate token issued by the authentication server, a microservice interface rejection response is sent to the client.

[0025] In a second aspect, the present application provides an authentication device for a microservice, comprising:

[0026] The receiving module is used for the gateway to receive the microservice interface call request sent by the client;

[0027] A determination module, used if the gateway determines that the microservice interface call request includes a legal token issued by the authentication server;

[0028] A sending module, used to send the microservice interface call request to the microservice end;

[0029] The sending module is also used for the microservice end to send a token authentication request to the authentication service end. When the token authentication is passed, the microservice end sends a microservice interface call response to the client through the gateway.

[0030] Optionally, the receiving module is further used for the gateway to receive an authentication request sent by the client;

[0031] The sending module is further used to send the authentication request to the authentication server, where the authentication request is used to request to obtain the token;

[0032] The receiving module is also used for the gateway to receive the token returned by the authentication server;

[0033] The sending module is further used to send the token to the client.

[0034] Optionally, the receiving module is further used for the gateway to receive the authorization code acquisition request sent by the client;

[0035] The sending module is further used to send the authorization code acquisition request to the authentication server;

[0036] The sending module is also used for the authentication server to return the authorization code to the gateway, and the gateway sends the authorization code to the client.

[0037] Optionally, the microservice authentication device further includes: a return module 304;

[0038] The return module is used for, when the authorization code acquisition request is in a non-logged-in state, the authentication server returns a login page to the client through the gateway;

[0039] The return module is further configured to cause the authentication server to return the authorization code to the gateway in response to a successful login of the user name and password returned by the client.

[0040] Optionally, the microservice authentication device further includes: a judgment module and a processing module;

[0041] The judgment module is also used by the gateway to judge whether the microservice interface call request includes a token;

[0042] The processing module is further configured to verify the format, validity period and issuer of the token if the microservice interface call request includes a token;

[0043] The determination module is further configured to determine, if the verification passes, that the token is a legal token issued by the authentication server.

[0044] Optionally, the determination module is also used by the authentication server to determine whether the permissions corresponding to the token include permissions to access the microservice end. If the permissions corresponding to the token include permissions to access the microservice end, it is determined that the token authentication is successful.

[0045] Optionally, the sending module is further used to send a microservice interface rejection response to the client if the gateway determines that the microservice interface call request does not include a legitimate token issued by the authentication server.

[0046] In a third aspect, the present application provides an authentication device for a microservice, including:

[0047] Memory;

[0048] processor;

[0049] Wherein, the memory stores computer-executable instructions;

[0050] The processor executes the computer-executable instructions stored in the memory to implement the microservice authentication method as described in the first aspect and various possible implementations of the first aspect.

[0051] In a fourth aspect, the present application provides a computer storage medium, characterized in that the computer storage medium stores computer execution instructions, and when the computer execution instructions are executed by a processor, they are used to implement the authentication method of the microservice as described in the first aspect and various possible implementations of the first aspect.

[0052] The microservice authentication method provided in the present application receives a microservice interface call request sent by a client through a gateway. If the gateway determines that the microservice interface call request includes a legal token issued by an authentication server, the microservice interface call request is sent to the microservice. The microservice sends a token authentication request to the authentication server. If the token authentication is successful, the microservice sends a microservice interface call response to the client through the gateway. The method uses a dual token verification mechanism between the gateway and the authentication server to ensure that only clients holding legal tokens can successfully call the microservice interface, thereby enhancing the security under the microservice architecture. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0054] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0055] Figure 1 It is a flow chart of the authentication method of the microservice provided by this application;

[0056] Figure 2 It is an interaction diagram of the authentication method of the microservice provided by this application;

[0057] Figure 3 It is a schematic diagram of the structure of the authentication device of the microservice provided by this application;

[0058] Figure 4 It is a schematic diagram of the structure of the authentication device of the microservice provided in this application. DETAILED DESCRIPTION

[0059] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present application.

[0060] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0061] In order to make the purpose, technical solutions and advantages of this application clearer, the technical solutions in this application will be clearly and completely described below in conjunction with the drawings in this application. Obviously, the described embodiments are part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0062] The terms "first", "second", "third", "fourth", etc. (if any) in the description and claims of the present invention and the above drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the numbers used in this way can be interchanged where appropriate, so that the embodiments of the present invention described herein can be implemented in sequences other than those illustrated or described herein, for example.

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

[0064] The rise of microservice architecture has brought about a complex distributed system environment, which has put forward higher requirements for authentication and authorization mechanisms. In this context, OAuth 2.0, as an open standard authorization protocol, has become one of the important authentication methods in microservice architecture. OAuth 2.0 defines a standardized authorization process that allows users to authorize third-party applications to access their resources without directly providing usernames and passwords. This feature makes OAuth 2.0 particularly suitable for microservice architecture because it can implement single sign-on and cross-domain authentication, greatly simplifying the user login process between multiple microservices and improving the security of the system.

[0065] Currently, in the microservice architecture, OAuth 2.0 implements access control to microservice resources by issuing access tokens through the authentication server. When the user passes the authentication, the authentication server generates an access token containing the user's identity and permission information and returns it to the client. When the client subsequently requests microservice resources, it will carry this access token for identity authentication. The microservice confirms the user's identity and permissions by verifying the validity of the access token, and then decides whether to allow access to the corresponding resources. This approach is particularly suitable for scenarios that require multiple microservices to work together, because it can effectively reduce the redundancy and complexity of the authentication logic. Instead of implementing complex authentication logic independently, each microservice can obtain the user's authentication information through a unified OAuth 2.0 authorization process. This not only simplifies the development process, but also improves the maintainability and scalability of the system.

[0066] However, the use of OAuth 2.0 technology for microservice authentication has the problem of low security under the microservice architecture.

[0067] In response to the above problems, the microservice authentication method provided by the present application requires that when a client initiates a microservice interface call request, the microservice interface call request must contain a legal token issued by the authentication server as the basis for identity authentication. The gateway first verifies the validity of the token to ensure that the request comes from an authorized client. Once the token verification is passed, the gateway forwards the microservice interface call request to the microservice. After receiving the request, the microservice initiates an authentication request to the authentication server. If the authentication is successful, it indicates that the microservice interface call request is indeed from an authenticated client, and the microservice executes the corresponding business logic and returns the processing result (i.e., the microservice interface call response) to the client securely through the gateway; this method uses a dual token verification mechanism between the gateway and the authentication server to ensure that only clients holding legal tokens can successfully call the microservice interface, thereby enhancing the security under the microservice architecture.

[0068] The technical solution of the present application and how the technical solution of the present application solves the above-mentioned technical problems are described in detail below with specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of the present application will be described below in conjunction with the accompanying drawings.

[0069] Figure 1 Flowchart of the microservice authentication method provided by this application. The execution subject of this embodiment is, for example, a server, which includes a gateway, a microservice, and an authentication server. Figure 1 As shown, the microservice authentication method provided in this embodiment includes:

[0070] S101: The gateway receives a microservice interface call request sent by the client.

[0071] Among them, in the microservice architecture, a microservice interface call request refers to a request initiated by a user through the interface of a client application, a request sent to the service on the microservice side through HTTP or other protocols, and is intended to obtain, update, delete or execute the information or resources managed by the microservice.

[0072] As a key component in the microservice architecture, the gateway is responsible for receiving microservice interface call requests from clients (such as web browsers, mobile applications or other services). These requests are routed, filtered, authenticated, and throttled by the gateway, and then forwarded to the corresponding microservice instance for execution, thus achieving secure and efficient communication between the client and the microservice.

[0073] S102: If the gateway determines that the microservice interface call request includes a legal token issued by the authentication server, the microservice interface call request is sent to the microservice.

[0074] Among them, the gateway needs to integrate a token verification mechanism. When the gateway receives a microservice interface call request, it will parse the token in the microservice interface call request and verify the token in the microservice interface call request. When the token in the microservice interface call request is a legal token, the gateway will send the microservice interface call request to the microservice end. When the token in the microservice interface call request is invalid or expired, the gateway will reject the microservice interface call request and return a corresponding error response to the client.

[0075] The gateway can verify whether the token in the microservice interface call request has been authorized to access the microservice interface. The gateway's token verification in the microservice interface call request helps prevent unauthorized tokens from accessing microservices and protects the data and business logic of microservices from being maliciously exploited.

[0076] S103: The microservice sends a token authentication request to the authentication service. If the token authentication is successful, the microservice sends a microservice interface call response to the client through the gateway.

[0077] Among them, the token authentication request is used to indicate a request sent by the microservice end to the authentication server in the microservice architecture to verify whether the access token it holds is valid and has the corresponding authority.

[0078] When the client sends a microservice interface call request, it needs to carry an access token in the request header or request body. After receiving the microservice interface call request, the gateway first checks whether the microservice interface call request contains a legal token. If it does, the token is sent to the microservice end, and the microservice end sends the token to the authentication server for authentication. The authentication server verifies the validity of the token, which usually includes checking the signature, validity period, issuer and other information of the token. If the token is valid, the microservice end will process the client's microservice interface call request, execute the corresponding business logic, prepare the response data, and return the microservice interface call response to the gateway. The gateway sends the microservice interface call response to the client.

[0079] The microservice authentication method provided in this embodiment receives a microservice interface call request sent by a client through a gateway. If the gateway determines that the microservice interface call request includes a legal token issued by an authentication server, the microservice interface call request is sent to the microservice. The microservice sends a token authentication request to the authentication server. If the token authentication is successful, the microservice sends a microservice interface call response to the client through the gateway. This method uses a dual token verification mechanism between the gateway and the authentication server to ensure that only clients holding legal tokens can successfully call the microservice interface, thereby enhancing the security under the microservice architecture.

[0080] Figure 2 This is an interaction diagram of the authentication method of the microservice provided by this application. Figure 2 As shown, in this embodiment Figure 1 Based on the embodiment, the authentication method of the microservice is described in detail. The authentication method of the microservice shown in this embodiment includes:

[0081] S201: The client sends an authentication request to the gateway.

[0082] The authentication request is used to request a token for the corresponding user of the client.

[0083] Before accessing the microservice, the client first constructs an authentication request containing authentication information to the gateway. The authentication information exists in the form of query parameters, request headers, or request bodies. Then, the client sends the authentication request to the gateway.

[0084] S202: The gateway sends an authentication request to the authentication server.

[0085] As a bridge between the client and the authentication server, the gateway is responsible for encapsulating the client's authentication information (such as user name, password, token, etc.) into an authentication request and forwarding it to the authentication server for identity authentication and authorization processing. After the authentication server processes the authentication request, it generates a token.

[0086] Optionally, the authentication request includes an authorization code, and before step S201 and step S202, the process also includes: the gateway receives the authorization code acquisition request sent by the client, and sends the authorization code acquisition request to the authentication server; the authentication server returns the authorization code to the gateway, and the gateway sends the authorization code to the client.

[0087] Optionally, the specific implementation method of the authentication server returning the authorization code to the gateway is: when the authorization code acquisition request is in a non-logged-in state, the authentication server returns a login page to the client through the gateway; in response to the successful login of the username and password returned by the client, the authentication server returns the authorization code to the gateway.

[0088] The authorization code is a security code used to confirm user access to microservice resources, usually composed of a string of numbers or characters. It is used to verify user identity and permissions to ensure that only authorized users can access microservice resources or perform specific operations.

[0089] The client (such as a web browser, mobile application, etc.) initiates an authentication request to the authentication server through the gateway, and the authentication request contains an authorization code. After the gateway receives the authorization code acquisition request from the client, it forwards the authorization code acquisition request to the authentication server. If the authorization code acquisition request from the client indicates that the user is not logged in, the authentication server will display a login page to the client through the gateway. After the user enters the username and password on the login page and submits it, if the login is successful, the authentication server will generate an authorization code and return it to the client through the gateway.

[0090] S203: The gateway receives the token sent by the authentication server.

[0091] When the client successfully completes the authentication process (such as user login and authorization) to the authentication server through the gateway, the authentication server will generate an access token and send this token to the gateway.

[0092] As the entry point and security barrier of the microservice side, the gateway needs to ensure that only authenticated clients can access the resources or services of the microservice side. By receiving and passing tokens, the gateway can verify the client's access rights and make routing decisions and access control based on the information in the token (such as user identity, permission scope, etc.). This not only protects the security of the microservice side, but also improves the scalability and maintainability of the microservice side.

[0093] S204: The gateway sends a token to the client.

[0094] The gateway sends a token to the client, which means that after the client successfully passes the authentication process of the authentication server, the gateway, as an intermediary, is responsible for securely passing the access token received from the authentication server to the client. This token is the client's credential for accessing the microservice, and contains the client's identity information, permission scope, and other information.

[0095] The gateway sends a token to the client to ensure that the client can access the resources or services of the microservice securely and effectively.

[0096] S205: The client sends a microservice interface call request to the gateway.

[0097] In the microservice architecture, clients (such as web applications, mobile applications, etc.) do not communicate directly with each microservice instance, but send call requests to the microservice interface through a unified gateway entry. The gateway, as a reverse proxy server, is responsible for receiving requests from clients and routing the requests to the corresponding microservice instance based on the URL or header information of the request.

[0098] As an intermediary between the client and the microservice, the gateway can hide the internal details of the microservice and achieve decoupling between the client and the microservice. The client only needs to communicate with the gateway and does not need to care about the specific implementation and deployment of the backend microservice. The gateway can centrally process client requests and implement unified access control strategies such as authentication, authorization, current limiting, and fuses to ensure the security and stability of the microservice. The gateway can intelligently select routing paths and load balancing strategies based on the characteristics of the request and the status of the microservice to improve the availability and response speed of the microservice.

[0099] S206: The gateway determines whether the microservice interface call request includes a token. If the microservice interface call request includes a token, the format, validity period and issuer of the token are verified. If the verification passes, it is determined that the token is a legal token issued by the authentication server.

[0100] The process by which the gateway determines whether a token is included in a microservice interface call request is a common security authentication mechanism in microservice architecture. In this mechanism, the gateway, as the entry point of the microservice architecture, is responsible for receiving requests from clients and checking whether the request carries a valid authentication token before forwarding the request to a specific microservice. This token is issued by the authentication server after a user successfully logs in or authorizes, and is used to identify the user's identity and authorization information.

[0101] In a microservice architecture, calls between services are frequent and complex, and directly exposing service interfaces may lead to the risk of unauthorized access and data leakage. By strictly verifying the format, validity period, and issuer of the token before forwarding the request, the gateway can ensure that only requests with valid tokens can be processed, thereby enhancing the security of the microservice end.

[0102] Optionally, if the gateway determines that the microservice interface call request does not include a legitimate token issued by the authentication server, a microservice interface rejection response is sent to the client.

[0103] First, the gateway will perform token verification on the microservice interface call request, check whether the request contains a legal token, and verify its format, validity period, and issuer. If the token verification fails, that is, the request does not contain a legal token issued by the authentication server, the gateway will make a decision to reject the request. Subsequently, the gateway will send a rejection response to the client. This response usually contains information such as error code and error message, so that the client can understand the specific reason why the request was rejected.

[0104] Without a valid token, it is impossible to confirm the identity and authorization information of the requester, and thus it is impossible to ensure that the request is secure and legitimate. By sending a rejection response, the gateway can inform the client that its request is rejected due to unauthenticated authentication, which helps the client to promptly identify the problem and take appropriate measures (such as re-login or apply for a token). At the same time, this is also a defense mechanism that can prevent potential malicious access attempts.

[0105] S207: The gateway sends a microservice interface call request to the microservice end.

[0106] As a unified entry point for requests, the gateway can hide the specific implementation and deployment details of microservices and achieve decoupling between clients and microservices. The gateway can intelligently select routing paths and load balancing strategies based on the request URL, request header and other information, as well as the status of microservices, and distribute requests to the most appropriate microservice end for processing, thereby improving the availability and response speed of the microservice end.

[0107] S208: The microservice sends a token authentication request to the authentication service.

[0108] After the microservice receives the microservice interface call request from the client, if the microservice interface call request requires permission verification, the token carried in the microservice interface call request will be sent to the authentication server for authentication. The authentication server verifies the validity and permission information of the token to confirm whether the requester has permission to access the microservice.

[0109] The microservice sends the extracted token as part of the authentication request to the authentication server for verification. The authentication request may also contain other information, such as the requested resource path, request method, etc. After receiving the authentication request, the authentication server verifies the token. The verification content includes but is not limited to the token's signature, validity period, permission information, etc.

[0110] S209: The authentication server determines whether the permissions corresponding to the token include permissions to access the microservice end. If the permissions corresponding to the token include permissions to access the microservice end, it is determined that the token authentication is successful.

[0111] The authentication server first parses the token carried in the request and extracts the permission information. This usually involves decoding the token, verifying the signature, and other operations to ensure the authenticity and integrity of the token. After extracting the permission information of the token, the authentication server compares it with the preset permission rules. The preset permission rules define the access rights required for different microservice resources. Through the comparison, the authentication server can determine whether the requester has the permission to access the microservice resources.

[0112] Based on the comparison results, the authentication server returns a response of authentication success or authentication failure to the microservice. If the permissions corresponding to the token include the permission to access the microservice, the authentication server determines that the token authentication is successful and allows the microservice to continue processing the request; otherwise, the authentication server will reject the request and may return an error code or error message indicating authentication failure to the microservice so that the microservice can perform corresponding error processing.

[0113] S210: The authentication server sends the token authentication pass to the microservice.

[0114] The authentication server sends the result of token authentication back to the microservice. In the microservice architecture, calls between services need to ensure security and permission control. By verifying the token by the authentication server, it can be ensured that only authorized requesters can access specific microservice resources, thereby protecting the data and business logic of the microservice from illegal access. At the same time, notifying the microservice of the authentication result in a timely manner helps the microservice to respond quickly and improve the overall performance and user experience of the microservice.

[0115] S211: The microservice sends a microservice interface call response to the gateway.

[0116] In the microservice architecture, when the microservice end completes the processing of the microservice interface call request sent by the client, it will send the processing result (i.e. the response of the interface call) back to the gateway through which the request originally passed. As a key component in the microservice architecture, the gateway has multiple functions such as request routing, security control, and protocol conversion. The microservice end does not send the response directly to the original requester, but first sends it to the gateway, which is then responsible for forwarding the response to the requester.

[0117] S212: The gateway sends a microservice interface call response to the client.

[0118] In a microservice architecture, when a client initiates a call request to a microservice interface through a gateway, the gateway forwards the request to the corresponding microservice end for processing. After the microservice end completes the processing, it returns the result to the gateway, and then the gateway sends the processing result (i.e., the response of the interface call) back to the original client. As the intermediary layer in the microservice architecture, the gateway is responsible for request routing, forwarding, and response aggregation and return.

[0119] The microservice authentication method provided in this embodiment is as follows: the client sends an authentication request to the gateway, the gateway sends the authentication request to the authentication server, the gateway receives the token sent by the authentication server, the gateway sends the token to the client, the client sends a microservice interface call request to the gateway, the gateway determines whether the microservice interface call request includes the token, if the microservice interface call request includes the token, the format, validity period and issuer of the token are verified, if the verification passes, it is determined that the token is a legal token issued by the authentication server, the gateway sends the microservice interface call request to the microservice, the microservice sends the token authentication request to the authentication server, the authentication server determines whether the authority corresponding to the token includes the authority to access the microservice, if the authority corresponding to the token includes the authority to access the microservice, it is determined that the token authentication passes, the authentication server sends the token authentication to the microservice, the microservice sends the microservice interface call response to the gateway, and the gateway sends the microservice interface call response to the client; the method ensures that only clients holding legal tokens can successfully call the microservice interface through the dual token verification mechanism of the gateway and the authentication server, thereby enhancing the security under the microservice architecture.

[0120] Figure 3 This is a schematic diagram of the structure of the authentication device of the microservice provided by this application. Figure 3 As shown, the present application provides a microservice authentication device, and the microservice authentication device 300 includes:

[0121] Receiving module 301, used for the gateway to receive the microservice interface call request sent by the client;

[0122] Determination module 302, used if the gateway determines that the microservice interface call request includes a legal token issued by the authentication server;

[0123] A sending module 303 is used to send a microservice interface call request to a microservice end;

[0124] The sending module 303 is also used for the micro-service end to send a token authentication request to the authentication service end. When the token authentication is successful, the micro-service end sends a micro-service interface call response to the client through the gateway.

[0125] Optionally, the receiving module 301 is also used for the gateway to receive an authentication request sent by the client;

[0126] The sending module 303 is also used to send an authentication request to the authentication server, where the authentication request is used to request to obtain a token;

[0127] The receiving module 301 is also used for the gateway to receive the token returned by the authentication server;

[0128] The sending module 303 is also used to send the token to the client.

[0129] Optionally, the receiving module 301 is also used for the gateway to receive the authorization code acquisition request sent by the client;

[0130] The sending module 303 is also used to send the authorization code acquisition request to the authentication server;

[0131] The sending module 303 is also used for the authentication server to return an authorization code to the gateway, and the gateway sends the authorization code to the client.

[0132] Optionally, the microservice authentication device further includes: a return module 304;

[0133] Return module 304, used for returning the login page to the client through the gateway when the authorization code acquisition request is in a non-logged-in state;

[0134] The return module 304 is also used for the authentication server to return an authorization code to the gateway in response to the user name and password returned by the client for successful login.

[0135] Optionally, the microservice authentication device further includes: a judgment module 305 and a processing module 306;

[0136] The judgment module 305 is also used by the gateway to judge whether the microservice interface call request includes a token;

[0137] The processing module 306 is further configured to verify the format, validity period and issuer of the token if the microservice interface call request includes a token;

[0138] The determination module 302 is further configured to determine that the token is a legal token issued by the authentication server if the verification is successful.

[0139] Optionally, the determination module 302 is also used for the authentication server to determine whether the permissions corresponding to the token include permissions to access the microservice end. If the permissions corresponding to the token include permissions to access the microservice end, it is determined that the token authentication is successful.

[0140] Optionally, the sending module 303 is further configured to send a microservice interface rejection response to the client if the gateway determines that the microservice interface call request does not include a legitimate token issued by the authentication server.

[0141] Figure 4 This is a schematic diagram of the structure of the authentication device of the microservice provided by this application. Figure 4 As shown, the present application provides an authentication device for a microservice, and the authentication 400 of the microservice includes: a receiver 401 , a transmitter 402 , a processor 403 , and a memory 404 .

[0142] Receiver 401, for receiving instructions and data;

[0143] A transmitter 402, used for sending instructions and data;

[0144] Memory 404, for storing computer-executable instructions;

[0145] The processor 403 is used to execute the computer-executable instructions stored in the memory 404 to implement the various steps performed by the microservice authentication method in the above embodiment. For details, please refer to the relevant description in the above microservice authentication method embodiment.

[0146] Optionally, the memory 404 may be independent or integrated with the processor 403 .

[0147] When the memory 404 is independently provided, the electronic device further includes a bus for connecting the memory 404 and the processor 403 .

[0148] The present application also provides a computer-readable storage medium, in which computer-executable instructions are stored. When a processor executes the computer-executable instructions, an authentication method for a microservice as performed by the authentication device for the above-mentioned microservice is implemented.

[0149] The above are only preferred implementations of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A microservice authentication method, characterized in that: Applied to a server, the server includes a gateway, a micro server and an authentication server, and the method includes: The gateway receives the microservice interface call request sent by the client; If the gateway determines that the microservice interface call request includes a legal token issued by the authentication server, the microservice interface call request is sent to the microservice; The microservice sends a token authentication request to the authentication service. If the token authentication is successful, the microservice sends a microservice interface call response to the client through the gateway.

2. The microservice authentication method according to claim 1, characterized in that: Also includes: The gateway receives the authentication request sent by the client, and sends the authentication request to the authentication server, where the authentication request is used to request to obtain the token; The gateway receives the token returned by the authentication server and sends the token to the client.

3. The microservice authentication method according to claim 2, characterized in that: The authentication request includes an authorization code, and the method further includes: The gateway receives the authorization code acquisition request sent by the client, and sends the authorization code acquisition request to the authentication server; The authentication server returns the authorization code to the gateway, and the gateway sends the authorization code to the client.

4. The microservice authentication method according to claim 3, characterized in that: The authentication server returns the authorization code to the gateway, including: When the authorization code acquisition request is in a non-logged-in state, the authentication server returns a login page to the client through the gateway; In response to the user name and password returned by the client for successful login, the authentication service returns the authorization code to the gateway.

5. The microservice authentication method according to any one of claims 1 to 4, characterized in that: The gateway determines that the microservice interface call request includes a legal token issued by the authentication server, including: The gateway determines whether the microservice interface call request includes a token. If the microservice interface call request includes a token, the format, validity period and issuer of the token are verified. If the verification passes, it is determined that the token is a legal token issued by the authentication server.

6. The microservice authentication method according to any one of claims 1 to 4, characterized in that: In the case where the token authentication is passed, before the microservice end sends a microservice interface call response to the client through the gateway, the method further includes: The authentication server determines whether the permissions corresponding to the token include permissions to access the microservice end. If the permissions corresponding to the token include permissions to access the microservice end, it is determined that the token authentication is successful.

7. The microservice authentication method according to any one of claims 1 to 4, characterized in that: Also includes: If the gateway determines that the microservice interface call request does not include a legitimate token issued by the authentication server, a microservice interface rejection response is sent to the client.

8. A microservice authentication device, characterized in that: include: The receiving module is used for the gateway to receive the microservice interface call request sent by the client; A determination module, used if the gateway determines that the microservice interface call request includes a legal token issued by the authentication server; A sending module, used to send the microservice interface call request to the microservice end; The sending module is also used for the microservice end to send a token authentication request to the authentication service end. When the token authentication is passed, the microservice end sends a microservice interface call response to the client through the gateway.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium includes a stored program, wherein the program executes the method according to any one of claims 1 to 7 when executed.

10. An electronic device comprising a memory and a processor, characterized in that: A computer program is stored in the memory, and the processor is configured to execute the method according to any one of claims 1 to 7 through the computer program.

Images