Authorization and authentication method and device, gateway, medium and computer equipment
By introducing API gateway as an OIDC client to interact with the OIDC authentication center, the problem of high access cost for application systems in the existing technology is solved, and zero-cost access and unified authentication of new application systems are realized, which improves the user experience.
Patent Information
- Application Number
- CN202211393776.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2022-11-08
- Publication Date
- 2024-12-24
- Estimated Expiration
- 2042-11-08
AI Technical Summary
In the prior art, the application system needs to interact with the OIDC authentication center multiple times to realize the OIDC client logic, resulting in high access cost for new application systems and strong coupling of the application system with the authentication logic.
The API gateway is introduced as a unified client to access the OIDC authentication center. The API gateway interacts with the OIDC authentication center as an OIDC client to obtain the token. The new application system can be accessed from the OIDC authentication center without additional modification.
It reduces the access cost of new application systems, decouples the application system and authentication logic, realizes unified authentication and authentication, and improves user experience.
Smart Images

Figure CN115913568B_ABST
Abstract
Description
Technical Field
[0001] The embodiments of the present invention relate to the field of computer software technology, and more specifically, the embodiments of the present invention relate to an authorization and authentication method and apparatus, a gateway, a medium, and a computer device. Background Art
[0002] This section is intended to provide a background or context to embodiments of the invention that are recited in the claims. No description herein is admitted to be prior art by inclusion in this section.
[0003] At present, many application systems require authorization and authentication of accessing users. In order to simplify the authorization and authentication process and reduce the cost of authorization and authentication, the OIDC (OpenID Connect) protocol can be used to build a unified and standardized authentication center to achieve unified authorization and authentication of users, and allow users to access other application systems after successfully accessing one application system without repeated authentication. Summary of the invention
[0004] The authorization and authentication method in the related technology requires the application system to implement the OIDC client logic. In this logic, the application system needs to interact with the OIDC authentication center multiple times, which makes the application system and the authentication logic strongly coupled, increasing the access cost of the new application system.
[0005] To this end, the present invention provides an authorization and authentication method and apparatus, a gateway, a medium and a computer device.
[0006] In a first aspect of an embodiment of the present invention, an authorization and authentication method is provided, which is applied to a gateway including a callback interface; the method comprises: in response to receiving a first authentication request sent by a client, sending a second authentication request to an OIDC authentication center, wherein the second authentication request carries information of the callback interface; receiving an authorization code returned by the OIDC authentication center after successfully authenticating the second authentication request; the OIDC authentication center calls the callback interface to return the authorization code, and the callback interface is determined based on the information of the callback interface carried in the second authentication request; based on the authorization code, a token acquisition request is sent to the OIDC authentication center, and after receiving the token returned by the OIDC authentication center, the token is forwarded to the client; the OIDC authentication center returns the token in response to the token acquisition request; in response to receiving a service request carrying the token sent by the client, the service request is forwarded to a target application system among multiple application systems connected to this gateway.
[0007] In one embodiment of the present invention, the information of the callback interface is pre-registered with the OIDC authentication center; the OIDC authentication center returns the authorization code when the following conditions are met: the information of the callback interface carried in the second authentication request is consistent with the information of the callback interface pre-registered by this gateway.
[0008] In another embodiment of the present invention, the second authentication request also carries the identity information of the present gateway; the OIDC authentication center returns the authorization code if the following conditions are met: the information of the callback interface carried in the second authentication request is consistent with the information of the callback interface pre-registered by the present gateway; and the identity information carried in the second authentication request is the pre-registered identity information.
[0009] In another embodiment of the present invention, the token acquisition request carries information of the callback interface; the OIDC authentication center returns the token if the following conditions are met: the authorization code carried in the token acquisition request is valid; the information of the callback interface carried in the token acquisition request matches the information of the callback interface pre-registered by this gateway.
[0010] In yet another embodiment of the present invention, forwarding the token to the client includes: verifying the token; if the verification is successful, forwarding the token to the client.
[0011] In another embodiment of the present invention, the token is returned after being encrypted by the OIDC authentication center based on a pre-stored private key; the method also includes: decrypting the token based on a pre-stored public key; if the decryption is successful, it is determined that the token verification is successful.
[0012] In another embodiment of the present invention, the token carries first identity information for indicating the sender of the token; the method further comprises: authenticating the first identity information carried in the token based on the identity information of the OIDC authentication center; if the authentication is successful, determining that the token verification is successful.
[0013] In another embodiment of the present invention, the token carries second identity information for indicating the recipient of the token; the method further includes: authenticating the second identity information carried in the token based on the identity information of the present gateway; the identity information of the present gateway is issued by the OIDC authentication center after the present gateway is successfully registered with the OIDC authentication center; if the authentication is successful, it is determined that the token verification is successful.
[0014] In still another embodiment of the present invention, the token carries a valid time range of the token; the method further comprises: if the system time is within the valid time range, determining that the token verification is successful.
[0015] In another embodiment of the present invention, forwarding the service request to a target application system among multiple application systems connected to the gateway includes: in response to receiving the service request sent by the client, authenticating the token in the service request; if the authentication is successful, forwarding the service request to the target application system.
[0016] In yet another embodiment of the present invention, the method further comprises: refreshing the token when a refresh condition is met.
[0017] In another embodiment of the present invention, the token includes a first token for determining a user identity and a second token for requesting user information; the method further includes: parsing the first token to determine a target user corresponding to the first token; and sending a user information acquisition request carrying the second token to the OIDC authentication center to request user information of the target user from the OIDC authentication center.
[0018] In still another embodiment of the present invention, the OIDC authentication center returns the user information after successfully verifying the token carried in the user information acquisition request.
[0019] In a second aspect of an embodiment of the present invention, a gateway is provided, comprising: a first communication interface, a second communication interface, a third communication interface and a callback interface; the first communication interface is used to communicate with a client, the second communication interface is used to communicate with an OIDC authentication center, the third communication interface is used to communicate with multiple application systems, and the callback interface is used for the OIDC authentication center to perform a callback; the second communication interface is used to send a second authentication request to the OIDC authentication center in response to the first communication interface receiving a first authentication request sent by the client, the second authentication request carries information of the callback interface; the callback interface is used to obtain information of the OIDC authentication center after successfully authenticating the second authentication request The authorization code returned after the success is used, so that the second communication interface sends a token acquisition request to the OIDC authentication center based on the authorization code; the OIDC authentication center calls the callback interface to return the authorization code, and the callback interface is determined based on the information of the callback interface carried in the second authentication request; the first communication interface is used to forward the token to the client after the second communication interface receives the token returned by the OIDC authentication center; the OIDC authentication center returns the token in response to the token acquisition request; the third communication interface is used to forward the business request to the target application system among the multiple application systems in response to the first communication interface receiving the business request carrying the token sent by the client.
[0020] In a third aspect of the embodiments of the present invention, a medium is provided, on which a computer program is stored, and when the program is executed by a processor, the method described in any embodiment of the present invention is implemented.
[0021] In a fourth aspect of an embodiment of the present invention, an authorization and authentication device is provided, which is applied to a gateway including a callback interface; the device includes: a first sending module, which is used to send a second authentication request to an OIDC authentication center in response to receiving a first authentication request sent by a client, and the second authentication request carries information of the callback interface; a receiving module, which is used to receive an authorization code returned by the OIDC authentication center after successfully authenticating the second authentication request; the OIDC authentication center calls the callback interface to return the authorization code, and the callback interface is confirmed based on the information of the callback interface carried in the second authentication request; a second sending module, which is used to send a token acquisition request to the OIDC authentication center based on the authorization code, and after receiving the token returned by the OIDC authentication center, forward the token to the client; the OIDC authentication center returns the token in response to the token acquisition request; a third sending module, which is used to forward the service request to a target application system among multiple application systems connected to this gateway in response to receiving a service request carrying the token sent by the client.
[0022] In a fifth aspect of the embodiments of the present invention, a computing device is provided, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the method described in any embodiment of the present invention when executing the program.
[0023] According to the authorization and authentication method and apparatus, gateway, medium and computer equipment of the implementation mode of the present invention, an API gateway is introduced as a unified client to access the OIDC authentication center. Subsequently, the API gateway acts as an OIDC client to interact with the OIDC authentication center to exchange for tokens. The new application system can be connected to the OIDC authentication center without additional modification, which brings a better experience to users. BRIEF DESCRIPTION OF THE DRAWINGS
[0024] The above and other objects, features and advantages of the exemplary embodiments of the present invention will become readily understood by reading the detailed description below with reference to the accompanying drawings. In the accompanying drawings, several embodiments of the present invention are shown in an exemplary and non-limiting manner, in which:
[0025] Figure 1 and Figure 2 The timing diagrams of the authorization and authentication methods of the related technologies are schematically shown respectively;
[0026] Figure 3A schematic diagram schematically shows an application scenario according to an embodiment of the present invention;
[0027] Figure 4 The flowchart of the authorization and authentication method according to the embodiment of the present invention is schematically shown;
[0028] Figure 5 The following schematically shows a timing diagram of an authorization and authentication method according to an embodiment of the present invention;
[0029] Figure 6 A schematic diagram schematically shows a specific flow of the authorization and authentication process according to an embodiment of the present invention;
[0030] Figure 7 A schematic diagram of a gateway according to an embodiment of the present invention is schematically shown;
[0031] Figure 8 Schematically shows a schematic diagram of a medium according to an embodiment of the present invention;
[0032] Fig. 9 A block diagram of an apparatus according to an embodiment of the present invention is schematically shown;
[0033] Fig.10 A schematic diagram of the structure of a computing device according to an embodiment of the present invention is shown;
[0034] In the drawings, the same or corresponding reference numerals represent the same or corresponding parts. DETAILED DESCRIPTION
[0035] The principles and spirit of the present invention will be described below with reference to several exemplary embodiments. It should be understood that these embodiments are provided only to enable those skilled in the art to better understand and implement the present invention, and are not intended to limit the scope of the present invention in any way. On the contrary, these embodiments are provided to make the present invention more thorough and complete, and to fully convey the scope of the present invention to those skilled in the art.
[0036] Those skilled in the art know that the embodiments of the present invention can be implemented as a system, device, apparatus, method or computer program product. Therefore, the present invention can be specifically implemented in the following forms, namely: complete hardware, complete software (including firmware, resident software, microcode, etc.), or a combination of hardware and software.
[0037] It should be understood herein that any number of elements in the drawings is for illustration rather than limitation, and any naming is only for distinction rather than having any limiting meaning.
[0038] The principle and spirit of the present invention are explained in detail below with reference to several representative embodiments of the present invention. SUMMARY OF THE INVENTION
[0040] When the client (for example, a browser) needs to access the resources of an application system, the client must first perform authorization authentication (i.e., authenticate the user) with the OIDC authentication center. When the authentication request arrives, the OIDC authentication center will redirect to the login page. After the user successfully logs in, the OIDC authentication center can issue an authorization code to the client. The client can use the authorization code to exchange a token from the OIDC authentication center, and obtain the resources of the application system based on the token. Among them, the client, which can also be referred to as the user end, refers to a program that corresponds to the server and provides local services to customers. Except for some applications that only run locally, they are generally installed on ordinary client computers and need to cooperate with the server to run. The client in the embodiment of the present invention is the party that needs to obtain application system resources, and may also be referred to as a third-party client.
[0041] The inventors found that the authorization and authentication methods in the related art require the application system to implement the OIDC client logic. Different from the above-mentioned client, the OIDC client of the present invention refers to the client registered before the access device is connected to the OIDC authentication center under the OIDC protocol. The OIDC client needs to provide a callback interface for receiving the authorization code and exchanging the authorization code for a token from the OIDC authentication center. Figure 1 and Figure 2 The authorization and authentication methods in related technologies are illustrated with examples.
[0042] exist Figure 1 In the illustrated embodiment, the OIDC client and token authentication are implemented by the application system. Among them, OIDC is a standard authorization and authentication protocol based on the OAuth 2.0 protocol, which can send the user's authorization and authentication information to the application system in the form of a token, so that the application system can authenticate the user's identity. Under the OIDC protocol, the application system needs to register the OIDC client to access the OIDC authentication system. The OIDC authentication system is called the OIDC authentication center, which is a trusted and centralized authentication service built on the OIDC protocol. It manages the identity information of all users, provides authorization and authentication capabilities, and allows the client to obtain user information in a secure manner. The OIDC client needs to provide a callback interface for receiving an authorization code (code) and exchange the authorization code for a token from the OIDC authentication center. Token is a temporary identity credential issued by the system to the user, equivalent to a username and password, which is used to decide whether to allow the request to be processed and to determine which user the request belongs to.
[0043] In this authorization and authentication method, the application system registers with the OIDC authentication center to obtain unified login capabilities. When an authentication request arrives, the application system itself intercepts and verifies the authentication request. If the token carried in the authentication request does not exist or is invalid, the application system interacts with the OIDC authentication center to authorize and authenticate the user who initiated the authentication request, and obtains a new token and returns it to the client. The specific process steps are as follows:
[0044] Step S101: The client initiates an authentication request, hoping to authenticate the user;
[0045] Step S102: The OIDC authentication center redirects to the login page, and the user performs a login operation;
[0046] Step S103: (optional) After the login operation is completed, the page will be redirected to the authorization page, and the user will perform the authorization operation;
[0047] Step S104: After the OIDC authentication center successfully authenticates the user, it returns an authorization code to the client;
[0048] Step S105: The client calls back the callback interface of the application system and brings the authorization code;
[0049] Step S106: The application system requests a token from the OIDC authentication center and brings the authorization code;
[0050] Step S107: OIDC authentication center returns a token after successful authentication;
[0051] Step S108: The application system returns the authentication result to the client and sets a token;
[0052] Step S109: The client sends a service request with a token;
[0053] Step S110: After verifying that the token is valid, the application system processes and responds to the service request.
[0054] In this method, the application system needs to implement the following logic:
[0055] OIDC client logic, that is, exposing a callback interface to the OIDC authentication center. When the OIDC authentication center successfully authenticates the user, the callback interface will be called back. At the same time, in the callback interface, the application system needs to implement the logic of exchanging the authorization code for a token from the OIDC authentication center;
[0056] Token authentication logic: Token authentication is performed on the business request sent by the client to determine whether the business request is legal.
[0057] exist Figure 2 In the illustrated embodiment, the OIDC client is implemented by the application system, and the token authentication is implemented by the gateway. The gateway is also called an API (Application Programming Interface) gateway. Two independent LANs communicate through a router, and the router in the middle is called a gateway. If any application system needs to be called by other systems, it needs to expose APIs, which represent functional points one by one. If two systems communicate, a mediator is added between the systems to assist in the API call. This mediator is the API gateway.
[0058] In the current microservice environment, many business parties have their own API gateways. At this time, the authentication request is generally intercepted and authenticated by the API gateway. At the same time, the application system still needs to register with the OIDC authentication center to obtain unified login capabilities. When the OIDC authentication center authenticates the user identity, it will interact with the application system, send the generated token to the application system, and the application system will return the token to the client. The specific process steps are as follows:
[0059] Step S201: The client initiates an authentication request, hoping to authenticate the user;
[0060] Step S202: The OIDC authentication center redirects to the login page, and the user performs a login operation;
[0061] Step S203: (optional) After the login operation is completed, the page will be redirected to the authorization page, and the user will perform the authorization operation;
[0062] Step S204: After the OIDC authentication center successfully authenticates the user, it returns an authorization code to the client;
[0063] Step S205: The client requests a callback interface from the application system and brings an authorization code;
[0064] Step S206: The application system requests a token from the OIDC authentication center and brings the authorization code;
[0065] Step S207: OIDC authentication center returns a token after successful authentication;
[0066] Step S208: The application system returns the authentication result to the client and sets a token;
[0067] Step S209: The client sends a service request with a token. The API gateway intercepts the service request and authenticates the token. After successful authentication, the request is forwarded to the application system.
[0068] Step S210: The application system processes and responds to the request.
[0069] In this method, the application system needs to implement the OIDC client logic and expose a callback interface to the OIDC authentication center. When the OIDC authentication center successfully authenticates the user, the interface will be called back. At the same time, in the callback interface, the application system needs to implement the logic of exchanging the authorization code with the OIDC authentication center for a token.
[0070] It can be seen that in the above two solutions for application systems to access the OIDC authentication center, the access cost of the new application system is very high, and the application system itself needs to implement the OIDC client logic. In this logic, the application system needs to interact with the OIDC authentication center many times, which makes the application system and the authentication logic strongly coupled, thereby greatly increasing the threshold for application system access.
[0071] To this end, the present invention introduces the API gateway as a unified client to access the OIDC authentication center. Subsequently, the API gateway acts as the OIDC client to interact with the OIDC authentication center to exchange tokens. The new application system can be connected to the OIDC authentication center without additional modification (the additional modification refers to the implementation of the OIDC client logic and the implementation of the token authentication logic), which brings a better experience to users.
[0072] After introducing the basic principles of the present invention, various non-limiting embodiments of the present invention are described in detail below.
[0073] Application Scenario Overview
[0074] First reference Figure 3 , is a schematic diagram of an application scenario of an exemplary embodiment of the present invention. In this application scenario, it includes a client 301, a gateway 302, an OIDC authentication center 303 and an application system 304. Among them, the client 301 is used to initiate authentication requests and service requests, the gateway 302 implements the OIDC client logic and token authentication logic, the OIDC authentication center 303 is used to issue authorization codes and tokens, and each application system 304 connected to the gateway 302 only needs to implement the service logic.
[0075] Exemplary Methods
[0076] Combine the following Figure 3 For application scenarios, refer to Figure 4 To describe the method according to an exemplary embodiment of the present invention. It should be noted that the above application scenarios are only shown to facilitate understanding of the spirit and principle of the present invention, and the embodiments of the present invention are not limited in this respect. On the contrary, the embodiments of the present invention can be applied to any applicable scenario.
[0077] The method of the present invention can be performed by Figure 3 The gateway 302 in the application scenario is executed, and the gateway 302 includes a callback interface. Figure 4 As shown, the authorization authentication method of the present invention includes:
[0078] Step S401: in response to receiving the first authentication request R1 sent by the client 301, a second authentication request R2 is sent to the OIDC authentication center 303, where the second authentication request R2 carries information about the callback interface;
[0079] Step S402: receiving the authorization code code returned by the OIDC authentication center 303 after successfully authenticating the second authentication request R2; the OIDC authentication center 303 calls the callback interface to return the authorization code code, and the callback interface is determined based on the information of the callback interface carried in the second authentication request R2;
[0080] Step S403: Send a token acquisition request R to the OIDC authentication center 303 based on the authorization code code t , and after receiving the token token returned by the OIDC authentication center 303, forward the token token to the client 301; the OIDC authentication center 303 responds to the token acquisition request R t Returns token;
[0081] Step S404: In response to receiving the service request R carrying the token sent by the client 301 s , the business request R s Forwarded to the target application system among the multiple application systems 304 connected to the gateway 302.
[0082] In step S401, the gateway 302 may receive a first authentication request R1 sent by the client 301. The client 301 may be a client of the type of a browser, an e-mail box, or an instant messaging software, and the present invention does not limit this. After receiving the first authentication request R1, the gateway 302 may add the information of the callback interface of the gateway 302 to the first authentication request R1 to obtain a second authentication request R2. The information of the callback interface may include the uniform resource locator (URL) of the callback interface. Then, the gateway 302 may send the second authentication request R2 to the OIDC authentication center 303. After receiving the second authentication request R2, the OIDC authentication center 303 may redirect to a login page. The user may log in through the login page, for example, by entering an account name and password in the login page, or by scanning a QR code included in the login page, or by using other login methods to log in.
[0083] In some embodiments, after a successful login, the OIDC authentication center 303 may redirect to an authorization page, where the user can confirm or cancel the authorization. If the user confirms the authorization, the authorization is determined to be successful; if the user cancels the authorization, the authorization is determined to be unsuccessful. In other embodiments, after a successful login, the OIDC authentication center 303 may directly determine that the authorization is successful. If the login fails, the OIDC authentication center 303 may also redirect to another page to display a prompt message of the login failure to the user through the page.
[0084] In step S402, if the authorization is successful, the OIDC authentication center 303 can determine the callback interface of the gateway 302 based on the callback interface information (for example, the URL of the callback interface) carried in the second authentication request R2, and call the callback interface to return the authorization code code to the gateway 302.
[0085] In some embodiments, the gateway 302 may be pre-registered with the OIDC authentication center 303. During registration, the gateway 302 may submit relevant information of the gateway to the OIDC authentication center 303, which may include information of the callback interface of the gateway 302, and may also include other information, such as model, serial number, MAC address and / or IP address, etc. When the gateway 302 registers with the OIDC authentication center 303, the OIDC authentication center 303 may also issue identity information to the gateway 302, which may include the client ID (recorded as client_id) and client key (recorded as client_secret) of the gateway 302. The OIDC authentication center 303 may associate and store various information when the gateway 302 is registered (for example, information of the callback interface of the gateway 302, identity information of the gateway 302) locally.
[0086] Before returning the authorization code, the OIDC authentication center 303 can first confirm whether the information of the callback interface carried in the second authentication request R2 is consistent with the information of the callback interface pre-registered by the gateway 302. If the two are consistent, the OIDC authentication center 303 calls the callback interface and returns the authorization code. If the two are inconsistent, the OIDC authentication center 303 can also return a prompt message to the gateway 302 indicating that the information of the callback interface is invalid.
[0087] Further, in the embodiment where the OIDC authentication center 303 issues identity information to the gateway 302, the second authentication request R2 may carry not only the information of the callback interface but also the identity information of the gateway 302. Before returning the authorization code code, the OIDC authentication center 303 may first determine whether the identity information carried in the second authentication request R2 is pre-registered identity information.
[0088] If yes, the OIDC authentication center 303 can further confirm whether the information of the callback interface carried in the second authentication request R2 is consistent with the information of the callback interface pre-registered by the gateway 302. If the two are consistent, the OIDC authentication center 303 calls the callback interface and returns the authorization code code. If the identity information carried in the second authentication request R2 is not the pre-registered identity information, the OIDC authentication center 303 can return a prompt message to the gateway 302 indicating that the gateway 302 is not registered.
[0089] Specifically, after receiving the second authentication request R2, the OIDC authentication center 303 can parse the identity information from the second authentication request R2 and search for the parsed identity information from the locally stored identity information. If found, it is determined that the identity information carried in the second authentication request R2 is pre-registered identity information, otherwise it is determined that the identity information carried in the second authentication request R2 is not pre-registered identity information. If the parsed identity information is found from the locally stored identity information, the information of the callback interface associated with the parsed identity information can be further searched. If the information of the callback interface found is consistent with the information of the callback interface carried in the second authentication request R2, it is determined that the information of the callback interface carried in the second authentication request R2 is consistent with the information of the callback interface pre-registered by the gateway 302.
[0090] In the above embodiment, the OIDC authentication center 303 first confirms the identity information carried in the second authentication request R2, and then confirms the information of the callback interface carried in the second authentication request R2. In other embodiments, the OIDC authentication center 303 may also first confirm the information of the callback interface carried in the second authentication request R2, and if the information of the callback interface carried in the second authentication request R2 is consistent with the information of the callback interface pre-registered by the gateway 302, then confirm whether the identity information carried in the second authentication request R2 is the pre-registered identity information.
[0091] The embodiment of the present invention authenticates the identity information and callback interface information carried in the second authentication request R2 through the OIDC authentication center 303, so as to determine the legitimacy of the gateway 302. The authorization code is returned only when the gateway 302 is a legal gateway (the identity information is pre-registered, and the callback interface information is consistent with the information at the time of registration), thereby improving the security of authorization authentication.
[0092] In step S403, after the gateway 302 obtains the authorization code code, it can generate a token acquisition request R carrying the authorization code code t , and send the token acquisition request R tThe OIDC authentication center 303 can obtain the token request R t If the verification is successful, the OIDC authentication center 303 can return a token to the gateway 302.
[0093] In some embodiments, the OIDC authentication center 303 may request the token to obtain R t The authorization code carried in is verified. If the authorization code is valid, the token acquisition request R is confirmed t Verification is successful; otherwise, confirm the token acquisition request R t Verification failed.
[0094] In some embodiments, the token acquisition request R t The gateway 302 callback interface information can also be carried in the OIDC authentication center 303. t If the information of the callback interface is consistent with the information of the callback interface pre-registered by the gateway 302, the token acquisition request R is determined. t Verification is successful; otherwise, confirm the token acquisition request R t Verification failed.
[0095] In some embodiments, the token acquisition request R t The gateway 302 identity information can also be carried in the OIDC authentication center 303. t If the identity information is pre-registered, the token acquisition request R is determined. t Verification is successful; otherwise, confirm the token acquisition request R t Verification failed.
[0096] Furthermore, if the token acquisition request R t If the verification fails, the OIDC authentication center 303 may also return a prompt message indicating the verification failure to the gateway 302. The prompt message may include information indicating the type of verification failure, for example, the authorization code is invalid, the gateway 302 is not registered, or the information of the call interface is inconsistent with the information of the pre-registered callback interface.
[0097] As an implementation method, the token acquisition request R t The authorization code, the callback interface information of gateway 302 and the identity information of gateway 302 can be carried in the token acquisition request R t The token acquisition request R is confirmed only when the above three types of information carried in the t Verification is successful; if any of the above information verification fails, the token acquisition request R is determinedt Verification failed.
[0098] After the gateway 302 obtains the token, it can return the token to the client 301. For example, the gateway 302 can write the token into the cookie of the client 301. After the client 301 obtains the token, it can generate a service request R carrying the token. s , and the service request R s Sent to gateway 302.
[0099] Furthermore, after the gateway 302 obtains the token, it can also verify the token. Only when the token verification is successful, the token is forwarded to the client 301. By verifying the token by the gateway 302, it is possible to verify whether the OIDC authentication center 303 that sends the token is legitimate, thereby reducing the risk of information leakage caused by the forgery of the OIDC authentication center 303, thereby improving the security of authorization authentication.
[0100] In some embodiments, the OIDC authentication center 303 may encrypt the token and return the encrypted token to the gateway 302. On this basis, the gateway 302 may decrypt the token sent by the OIDC authentication center 303. If the decryption is successful, it is determined that the token verification is successful; otherwise, it is determined that the token verification fails. Specifically, the OIDC authentication center 303 may pre-store a private key for encrypting the token, and encrypt the token based on the private key. The gateway 302 may store the public key corresponding to the private key, and decrypt the token based on the public key. If the decryption is successful, the decrypted token may also be sent to the client 301.
[0101] In some embodiments, the token token may also carry the identity information of the sender of the token token (referred to as the first identity information). The gateway 302 may pre-store the identity information of the OIDC authentication center 303 (referred to as the designated issuance information). The designated issuance information may be the domain name of the OIDC authentication center 303. The gateway 302 may authenticate the first identity information carried in the token token based on the designated issuance information. If the first identity information carried in the token token is consistent with the designated issuance information, it is determined that the authentication of the first identity information is successful; otherwise, it is determined that the authentication of the first identity information has failed. If the authentication of the first identity information is successful, it can be determined that the token token verification is successful; otherwise, it is determined that the token token verification has failed.
[0102] In some embodiments, the token carries the identity information of the recipient of the token (referred to as the second identity information). The gateway 302 can authenticate the second identity information carried in the token based on the identity information issued to the gateway by the OIDC authentication center 303 during registration. If the two are consistent, it is determined that the authentication of the second identity information is successful; otherwise, it is determined that the authentication of the second identity information fails. If the authentication of the second identity information is successful, it can be determined that the token verification is successful; otherwise, it is determined that the token verification fails.
[0103] In some embodiments, the token token carries the valid time range of the token token. The gateway 302 can determine whether the system time is within the valid time range. If so, the token token is determined to be valid; otherwise, the token token is determined to be invalid. If the token token is valid, it can be determined that the token token verification is successful; otherwise, it is determined that the token token verification fails. As an implementation method, the valid time range of the token token can be represented by the expiration time of the token token. If the current system time is later than the expiration time, it means that the token token is invalid; otherwise, it means that the token token is valid.
[0104] Furthermore, if the token verification fails, the gateway 302 may return a prompt message indicating that the token acquisition failed to the client 301. The prompt message may include information indicating the type of token acquisition failure, such as token decryption failure, identity information authentication failure of the OIDC authentication center 303, or token expiration.
[0105] In the above embodiment, the gateway 302 can verify the token immediately after receiving the token. In this way, there is no need to cache the token after receiving the token, thereby reducing the delay caused by reading the cached data and improving the performance of the gateway 302.
[0106] In step S404, the gateway 302 receives the service request R s After that, you can request R s The token in the gateway 302 is used for authentication, that is, to determine whether the token is valid. If the authentication is successful (that is, the token is valid), the gateway 302 can send the service request R s Forward to the target application system among the multiple application systems connected to the gateway 302; otherwise, a prompt message indicating that the token authentication failed can be returned to the client 301.
[0107] In some embodiments, the gateway 302 can also refresh the token if the refresh condition is met. Specifically, the token returned by the OIDC authentication center 303 to the gateway 302 may include an ID token, an access token, and a refresh token. Among them, the ID token is equivalent to the user's identity credential, which can parse the user's basic information (for example, user name, avatar), and the client will bring this information when sending a service request to determine whether the service request is legal. The access token is the only credential for accessing resources. Possessing this token means that the user has been authorized and can be used to request detailed information about the user (for example, network resources that the user can access, etc.). The refresh token can be used to refresh the access token to extend the validity period of the access token. Refreshing the token in the above embodiment may specifically refer to refreshing the access token. Among them, the refresh condition may be that the access token is invalid or about to expire (that is, the time interval between the system time and the expiration time of the access token is less than the preset duration).
[0108] In some embodiments, the token includes a first token for determining the user identity (i.e., the ID token) and a second token for requesting user information (i.e., the access token). In step S403, after obtaining the token returned by the OIDC authentication center 303, the gateway 302 can also parse the ID token to determine the target user corresponding to the ID token, and send the user information acquisition request R with the access token. u The data is sent to the OIDC authentication center 303 to request the user information of the target user from the OIDC authentication center 303 .
[0109] The OIDC authentication center 303 can request R u The access token carried in is verified and the user information of the target user is returned after successful verification.
[0110] See also Figure 5 , is a timing diagram of an authorization and authentication method according to an embodiment of the present invention. The authorization and authentication method of the present invention may include the following steps:
[0111] Step S501: the client 301 initiates an authentication request, hoping to authenticate the user.
[0112] Step S502: The OIDC authentication center 303 redirects to the login page, and the user performs a login operation.
[0113] Step S503: (Optional) After the login operation is completed, the authorization page will be redirected, and the user will perform the authorization operation on the authorization page.
[0114] Step S504: After successfully authorizing and authenticating the user, the OIDC authentication center 303 calls the callback interface of the gateway 302 and brings the authorization code.
[0115] Step S505: Gateway 302 requests a token from OIDC authentication center 303 and brings an authorization code.
[0116] Step S506: After successful authentication, the OIDC authentication center 303 returns a token (including an ID token, an access token, and a refresh token).
[0117] Step S507: The gateway 302 verifies the returned token.
[0118] Step S508: After the token verification is successful, the gateway 302 returns the authentication result to the client 301 and sets the token.
[0119] Step S509: the client 301 sends a service request with a token, and the gateway 302 intercepts and authenticates the service request. After successful authentication, the service request is forwarded to the application system 304.
[0120] Step S510: the application system 304 processes and responds to the service request.
[0121] Figure 6 The schematic diagram shows the specific process of the OIDC client in the authorization and authentication process according to the embodiment of the present invention. In this embodiment, for the convenience of understanding and explanation, the OIDC authentication center 303 can be functionally divided into an authorization endpoint, a token endpoint and a user endpoint, wherein the authorization endpoint is used to provide functions such as user login, authorization, and issuing authorization codes, the token endpoint is used to issue tokens, and the user endpoint is used to receive user information acquisition requests and return user information. The steps performed by the OIDC client specifically include the following steps:
[0122] Step S601: When the user sends an authentication request for the first time, or the token carried in the authentication request is invalid, the gateway 302 will initiate an authentication request to the OIDC authentication center 303, and the authentication request carries request parameters such as client_id (identity information of the gateway 302) and redirect_uri (information of the callback interface);
[0123] Step S602: After receiving the authentication request, the authorization endpoint of the OIDC authentication center 303 verifies the request parameters in the authentication request. The verification process is as follows:
[0124] Determine whether client_id exists, and if not, return an exception message to the gateway 302;
[0125] Determine whether the redirect_uri (callback interface information) is consistent with the callback interface information during registration. If not, return an exception message to the gateway 302.
[0126] Step S603: If the verification in step S602 is passed, the OIDC authentication center 303 will redirect to the login page, and the user performs the login operation;
[0127] Step S604: (optional) After the login operation is completed, the page will be redirected to the authorization page, and the user will perform the authorization operation;
[0128] Step S605: After the OIDC authentication center 303 successfully authenticates the user identity, it will generate a one-time authorization code and pass it to the gateway 302 by calling the callback interface ( / callback) during registration;
[0129] Step S606: After receiving the callback request ( / callback) from the OIDC authentication center 303, the gateway 302 obtains the authorization code carried in the callback request, and uses it to initiate a request ( / token) to obtain a token from the OIDC authentication center 303. The request parameters include:
[0130] grant_type: the value is a fixed string of authorization_code;
[0131] Authorization code code;
[0132] redirect_uri: needs to be exactly the same as the registered redirect_uri;
[0133] At the same time, you need to add Authorization information to the request header information, where the Key is Authorization and the value is Basic base64 (${client_id}:${client_secret}), such as:
[0134] Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW;
[0135] Step S607: After receiving the token acquisition request ( / token), the OIDC authentication center 303 verifies the request parameters. The verification process is as follows:
[0136] Determine whether the authorization code is valid. If not, return an exception message to the gateway 302;
[0137] Determine whether the redirect_uri (callback interface information) is consistent with the callback interface information during registration. If not, return an exception message to the gateway 302.
[0138] Step S608: After the verification in step S607 is passed, the OIDC authentication center 303 will generate a token according to the rules. The token includes an ID token, an access token, a refresh token, etc.;
[0139] Step S609: The OIDC authentication center 303 returns the token to the gateway 302.
[0140] Step S610: After obtaining the token, the gateway 302 will parse and verify the ID token in the token. The ID token may include:
[0141] Iss: represents the identity information of the authentication center 303, which is generally the domain name of the authentication center 303, for example, https: / / server.example.com;
[0142] Sub: indicates the user ID, for example, "24400320";
[0143] Aud: represents the ID of the gateway 302, for example, "s6BhdRkqt3";
[0144] nonce: "n-0S6_WzA2Mj";
[0145] exp: indicates the expiration time of the token, usually expressed as a timestamp, for example, 1311281970;
[0146] iat: indicates the issuance time of the token, usually expressed as a timestamp, for example, 1311280970;
[0147] auth_time: indicates the time when the authentication center 303 authenticates the authentication request, generally expressed as a timestamp, for example, 1311280969;
[0148] acr: "urn:mace:incommon:iap:silver".
[0149] The validation rules are as follows:
[0150] Determine whether the ID token can be decrypted according to the specified key, and if not, return an exception message to the gateway 302;
[0151] Whether the iss value in the ID token is consistent with the specified issuance information;
[0152] Whether the aud value in the ID token is consistent with the client_id issued during registration;
[0153] Whether the exp in the ID token is later than the current system time.
[0154] Step S611: (Optional) If the verification in step S610 is passed, the user detailed information ( / userInfo) can be requested according to the actual business situation. The request will carry an access token.
[0155] Step S612: (optional) After receiving the user information acquisition request ( / userInfo), the OIDC authentication center 303 verifies the access token carried in the request.
[0156] Step S613: (optional) After the verification in step S612 is passed, the user information is returned to the gateway 302.
[0157] Step S614: After the verification in step S610 is passed, the gateway 302 will return the authentication result to the client and set a token.
[0158] The solution of the embodiment of the present invention has the following advantages:
[0159] (1) Improved the access efficiency of application systems, enabling zero-cost access to new application systems (no need to modify application systems to implement IODC client logic and token authentication logic).
[0160] (2) The application system decouples the authentication logic, making the application system unaware of the services provided by the OIDC authentication center.
[0161] (3) Converge the authentication and authorization logic to achieve unified authentication and authorization.
[0162] See also Figure 7 The embodiment of the present invention further provides a gateway, the gateway comprising:
[0163] A first communication interface 701, a second communication interface 702, a third communication interface 703 and a callback interface 704; the first communication interface 701 is used to communicate with the client 301, the second communication interface 702 is used to communicate with the OIDC authentication center 303, the third communication interface 703 is used to communicate with multiple application systems 304, and the callback interface 704 is used for the OIDC authentication center 303 to make a callback;
[0164] The second communication interface 702 is used to send a second authentication request R2 to the OIDC authentication center 303 in response to the first communication interface 701 receiving the first authentication request R1 sent by the client 301, where the second authentication request R2 carries information of the callback interface 704;
[0165] The callback interface 704 is used to obtain the authorization code code returned by the OIDC authentication center 303 after the second authentication request R2 is successfully authenticated, so that the second communication interface 702 sends a token acquisition request R2 to the OIDC authentication center 303 based on the authorization code code. t ; The OIDC authentication center 303 calls the callback interface 704 to return the authorization code code, and the callback interface 704 is determined based on the information of the callback interface 704 carried in the second authentication request R2;
[0166] The first communication interface 701 is used to forward the token to the client 301 after the second communication interface 702 receives the token returned by the OIDC authentication center 303; the OIDC authentication center 303 responds to the token acquisition request R t Returns token;
[0167] The third communication interface 703 is used to respond to the service request R carrying the token token sent by the client 301 received by the first communication interface 701 s , the business request R s Forwarded to a target application system among the multiple application systems 304 .
[0168] The gateway in the embodiment of the present invention may be the gateway 302 in the aforementioned method embodiment. The specific functions implemented by the gateway are detailed in the aforementioned method executed by the gateway 302, which will not be repeated here.
[0169] Exemplary Media
[0170] After introducing the method of the exemplary embodiment of the present invention, next, refer to Figure 8 Examples of the medium according to the exemplary embodiment of the present invention are described.
[0171] In this exemplary embodiment, the above method can be implemented by a program product, such as a portable compact disk read-only memory (CD-ROM) and including program code, which can be run on a device, such as a personal computer. However, the program product of the present invention is not limited to this. In this document, the readable medium 80 can be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, device or device.
[0172] The program product may use any combination of one or more readable media. The readable medium 80 may be a readable signal medium or a readable medium. The readable medium 80 may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of readable media (a non-exhaustive list) include: an electrical connection with one or more wires, a portable disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above.
[0173] Computer readable signal media may include data signals propagated in baseband or as part of a carrier wave, wherein readable program code is carried. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Readable signal media may also be any readable medium other than a readable medium, which may send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device.
[0174] The program code contained on the readable medium 80 may be transmitted using any appropriate medium, including but not limited to wireless, wired, optical cable, RE, etc., or any suitable combination of the above.
[0175] Program code for performing the operations of the present invention may be written in any combination of one or more programming languages, including object-oriented programming languages such as Java, C++, etc., and conventional procedural programming languages such as C or similar programming languages. The program code may be executed entirely on the user computing device, partially on the user computing device, partially on a remote computing device, or entirely on a remote computing device or server. In the case of a remote computing device, the remote computing device may be connected to the user computing device through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computing device (e.g., using an Internet service provider to connect through the Internet).
[0176] Exemplary Devices
[0177] After introducing the medium of the exemplary embodiment of the present invention, next, reference is made to Fig. 9 An example of an authorization and authentication device according to an exemplary embodiment of the present invention is described. The device is applied to a gateway including a callback interface; the device includes:
[0178] The first sending module 901 is used to send a second authentication request to the OIDC authentication center in response to receiving a first authentication request sent by the client, wherein the second authentication request carries information of the callback interface;
[0179] The receiving module 902 is used to receive the authorization code returned by the OIDC authentication center after successfully authenticating the second authentication request; the OIDC authentication center calls the callback interface to return the authorization code, and the callback interface is determined based on the information of the callback interface carried in the second authentication request;
[0180] The second sending module 903 is used to send a token acquisition request to the OIDC authentication center based on the authorization code, and after receiving the token returned by the OIDC authentication center, forward the token to the client; the OIDC authentication center returns the token in response to the token acquisition request;
[0181] The third sending module 904 is used for forwarding the service request carrying the token sent by the client to a target application system among the multiple application systems connected to the gateway in response to receiving the service request.
[0182] Exemplary Computing Devices
[0183] After introducing the method, medium and apparatus of the exemplary embodiments of the present invention, next, reference is made to Fig.10 An example of a computing device according to an exemplary embodiment of the present invention is described.
[0184] Fig.10 The computing device 1000 shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present invention.
[0185] like Fig.10 As shown, the computing device 1000 is in the form of a general computing device. The components of the computing device 1000 may include but are not limited to: at least one processing unit 1001, at least one storage unit 1002, and a bus 1003 connecting different system components (including the processing unit 1001 and the storage unit 1002).
[0186] The bus 1003 includes a data bus, a control bus, and an address bus.
[0187] The storage unit 1002 may include a readable medium in the form of a volatile memory, such as a random access memory (RAM) 10021 and / or a cache memory 10022 , and may further include a readable medium in the form of a non-volatile memory, such as a read-only memory (ROM) 10023 .
[0188] The storage unit 1002 may also include a program / utility 10025 having a set (at least one) of program modules 10024, such program modules 10024 including but not limited to: an operating system, one or more application programs, other program modules, and program data, each of which or some combination may include the implementation of a network environment.
[0189] The computing device 1000 may also communicate with one or more external devices 1004 (eg, keyboards, pointing devices, etc.).
[0190] Such communication may be performed via input / output (I / O) interface 1005. Furthermore, computing device 1000 may also communicate with one or more networks (e.g., a local area network (LAN), a wide area network (WAN), and / or a public network, such as the Internet) via network adapter 1006. Fig.10 As shown, the network adapter 1006 communicates with other modules of the computing device 1000 via the bus 1003. It should be understood that, although not shown in the figure, other hardware and / or software modules can be used in conjunction with the computing device 1000, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.
[0191] It should be noted that although several units / modules or sub-units / modules of the authorization authentication device are mentioned in the above detailed description, this division is merely exemplary and not mandatory. In fact, according to an embodiment of the present invention, the features and functions of two or more units / modules described above can be embodied in one unit / module. Conversely, the features and functions of one unit / module described above can be further divided into multiple units / modules to be embodied.
[0192] In addition, although the operations of the method of the present invention are described in a specific order in the drawings, this does not require or imply that the operations must be performed in this specific order, or that all the operations shown must be performed to achieve the desired results. Additionally or alternatively, some steps may be omitted, multiple steps may be combined into one step, and / or one step may be decomposed into multiple steps.
[0193] Although the spirit and principle of the present invention have been described with reference to several specific embodiments, it should be understood that the present invention is not limited to the disclosed specific embodiments, and the division of various aspects does not mean that the features in these aspects cannot be combined to benefit, and such division is only for the convenience of expression. The present invention is intended to cover various modifications and equivalent arrangements included in the spirit and scope of the attached claims.
Claims
1. An authorization and authentication method, applied to a gateway including a callback interface; the method comprises: In response to receiving the first authentication request sent by the client, sending a second authentication request to the OIDC authentication center, where the second authentication request carries information about the callback interface; Receiving the authorization code returned by the OIDC authentication center after successfully authenticating the second authentication request; the OIDC authentication center calls the callback interface to return the authorization code, and the callback interface is determined based on the information of the callback interface carried in the second authentication request; Sending a token acquisition request to the OIDC authentication center based on the authorization code, and after receiving the token returned by the OIDC authentication center, forwarding the token to the client; the OIDC authentication center returns the token in response to the token acquisition request; In response to receiving the service request carrying the token sent by the client, the service request is forwarded to a target application system among multiple application systems connected to the gateway.
2. According to the method of claim 1, the information of the callback interface is pre-registered with the OIDC authentication center; the OIDC authentication center returns the authorization code when the following conditions are met: The information of the callback interface carried in the second authentication request is consistent with the information of the callback interface pre-registered by the gateway.
3. According to the method of claim 2, the second authentication request also carries the identity information of the gateway; the OIDC authentication center returns the authorization code when the following conditions are met: The information of the callback interface carried in the second authentication request is consistent with the information of the callback interface pre-registered by the gateway; and The identity information carried in the second authentication request is pre-registered identity information.
4. According to the method of claim 1, the token acquisition request carries the information of the callback interface; the OIDC authentication center returns the token when the following conditions are met: The authorization code carried in the token acquisition request is valid; The information of the callback interface carried in the token acquisition request matches the information of the callback interface pre-registered by the gateway.
5. The method according to claim 1, forwarding the token to the client, comprising: Verifying the token; If the verification is successful, the token is forwarded to the client.
6. According to the method of claim 5, the token is returned after being encrypted by the OIDC authentication center based on a pre-stored private key; The method further comprises: Decrypting the token based on a pre-stored public key; If the decryption is successful, it is determined that the token verification is successful.
7. The method according to claim 5, wherein the token carries first identity information for indicating a sender of the token; The method further comprises: Authenticate the first identity information carried in the token based on the identity information of the OIDC authentication center; If the authentication is successful, it is determined that the token verification is successful.
8. The method according to claim 5, wherein the token carries second identity information for indicating a recipient of the token; The method further comprises: Authenticate the second identity information carried in the token based on the identity information of the gateway; the identity information of the gateway is issued by the OIDC authentication center after the gateway is successfully registered with the OIDC authentication center; If the authentication is successful, it is determined that the token verification is successful.
9. The method according to claim 5, wherein the token carries a valid time range of the token; the method further comprises: If the system time is within the valid time range, it is determined that the token verification is successful.
10. The method according to claim 1, wherein the step of forwarding the service request to a target application system among a plurality of application systems connected to the gateway comprises: In response to receiving a service request sent by the client, authenticating a token in the service request; If the authentication is successful, the service request is forwarded to the target application system.
11. The method according to claim 1, further comprising: When the refresh condition is met, the token is refreshed.
12. The method of claim 1, wherein the token comprises a first token for determining a user identity and a second token for requesting user information; The method further comprises: Parsing the first token to determine a target user corresponding to the first token; A user information acquisition request carrying the second token is sent to the OIDC authentication center to request the user information of the target user from the OIDC authentication center.
13. According to the method of claim 12, the OIDC authentication center returns the user information after successfully verifying the token carried in the user information acquisition request.
14. A gateway, comprising: A first communication interface, a second communication interface, a third communication interface and a callback interface; The first communication interface is used to communicate with the client, the second communication interface is used to communicate with the OIDC authentication center, the third communication interface is used to communicate with multiple business systems, and the callback interface is used for the OIDC authentication center to perform a callback; The second communication interface is used to send a second authentication request to the OIDC authentication center in response to the first communication interface receiving the first authentication request sent by the client, wherein the second authentication request carries information of the callback interface; The callback interface is used to obtain the authorization code returned by the OIDC authentication center after successfully authenticating the second authentication request, so that the second communication interface sends a token acquisition request to the OIDC authentication center based on the authorization code; The OIDC authentication center calls the callback interface to return the authorization code, and the callback interface is determined based on the information of the callback interface carried in the second authentication request; The first communication interface is used to forward the token to the client after the second communication interface receives the token returned by the OIDC authentication center; the OIDC authentication center returns the token in response to the token acquisition request; The third communication interface is used for forwarding the service request carrying the token sent by the client to a target application system among the multiple application systems in response to the first communication interface receiving the service request.
15. A computer-readable storage medium having a computer program stored thereon, wherein the program, when executed by a processor, implements the method according to any one of claims 1 to 13.
16. An authorization and authentication device, applied to a gateway including a callback interface; the device comprises: A first sending module, configured to send a second authentication request to the OIDC authentication center in response to receiving a first authentication request sent by a client, wherein the second authentication request carries information of the callback interface; A receiving module, configured to receive an authorization code returned by the OIDC authentication center after successfully authenticating the second authentication request; the OIDC authentication center calls the callback interface to return the authorization code, and the callback interface is determined based on information of the callback interface carried in the second authentication request; A second sending module is used to send a token acquisition request to the OIDC authentication center based on the authorization code, and after receiving the token returned by the OIDC authentication center, forward the token to the client; the OIDC authentication center returns the token in response to the token acquisition request; The third sending module is used for forwarding the service request carrying the token sent by the client to a target application system among the multiple application systems connected to the gateway in response to receiving the service request.
17. A computing device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the method according to any one of claims 1 to 13 when executing the program.
Citation Information
Patent Citations
Authentication and authorization method, authorization server, API gateway, system and storage medium
CN112804258A
Systems and methods for secure remote identity verification
US20180013565A1
