Token verification system and program

Abstract

To provide a token verification system which can sufficiently ensure security and can be configured at low cost.SOLUTION: A token verification system 10 is provided with a request cooperation system 20 which receives a request for remote access, in a public cloud environment and transmits an introspection API request in which an access token or a refresh token of a verification object in the request for remote access are set, from request parameter check means 24 of the request cooperation system 20 to token verification means 44 of an API base system 30 and receives a verification result of validity of the access token or the refresh token as an introspection API response from the token verification means 44.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to a token verification system and program configured by a computer that executes processing to verify access tokens and refresh tokens included in requests for external access via the Internet, and can be used, for example, when an external end user uses an API (Application Programming Interface) to access a business processing system located in an internal cloud environment and execute business processing. [Background technology]

[0002] Traditionally, securities and financial systems have accepted communications via the Internet from FinTech companies and other entities (hereinafter referred to as "external access") and provided the resources they hold (such as customer information and data on trading transactions) in order to realize financial services in collaboration with FinTech companies and other entities.

[0003] As shown in Fig. 7, in a conventional system 90 that collaborates with FinTech companies and the like, a client terminal 92 operated by an end user of the FinTech company, who is an external consumer, is connected to the Internet 91. Also connected to the Internet 91 via a router 93 and a DMZ firewall 94 is a gateway server 95 for internet access that is located in a DMZ (demilitarized zone).

[0004] Furthermore, an internal network 97 such as an in-house intranet or in-house LAN is connected to the internet-disclosure gateway server 95 via an internal firewall 96. Connected to this internal network 97 are servers 98 of other in-house systems (systems other than those targeted for external access in FIG. 7) that are in-house consumers, in-house terminals 99 operated by in-house users, an in-house gateway server 100, and a business processing system 101 related to financial operations at a bank, securities company, or the like that is targeted for external access.

[0005] In this system 90 , a request from a client terminal 92 passes through the Internet 91 , a router 93 , a DMZ firewall 94 , a gateway server 95 for Internet access, and an internal firewall 96 before entering an internal network 97 and reaching a business processing system 101 .

[0006] On the other hand, requests from servers 98 of other systems within the company or from terminals 99 within the company, which are in-house consumers, reach an in-house gateway server 100 via an internal network 97, and from there reach a business processing system 101 via the internal network 97.

[0007] Therefore, from the viewpoint of security, such a conventional system 90 is configured to include a gateway server 95 for public access to the Internet, which is placed in a DMZ (demilitarized zone) to process communications from external consumers, and an internal gateway server 100 for processing communications from internal consumers. In other words, conventionally, the gateway server is configured to be separated into one for external access via the Internet 91 and one for internal access via the internal network 97 but not via the Internet 91.

[0008] By adopting this type of DMZ (demilitarized zone) configuration, the security of the systems within the internal cloud (business processing system 101 connected to internal network 97) was ensured by preventing unauthorized requests from entering internal network 97 even in the event of a cyber attack.

[0009] Additionally, for external access, the validity of requests is ensured by using OAuth2.0 as the authorization protocol, which can be achieved by using standard functions such as IBM API Connect.

[0010] As will be described later, the present invention utilizes an introspection API. However, there is a known technology for performing introspection and handling access tokens and refresh tokens, which provides efficient and intuitive data binding for mobile applications (see Patent Document 1). [Prior art documents] [Patent documents]

[0011] [Patent Document 1] Special Publication No. 2017-533503 (Claim 4) Summary of the Invention [Problem to be solved by the invention]

[0012] As mentioned above, in the conventional system 90 shown in Fig. 7, a gateway server 95 for public access to the Internet, which serves as a receiving point for external access, is deployed in a DMZ (demilitarized zone) in addition to the in-house gateway server 100. As a result, gateway servers with similar configurations (for example, gateway servers both built using IBM API Connect or the like) are deployed in two locations. This poses a problem of high system construction costs. Therefore, there has been a demand for the development of a system that can be constructed inexpensively while still ensuring sufficient security similar to conventional systems.

[0013] An object of the present invention is to provide a token verification system and program that can ensure sufficient security and can be constructed inexpensively. [Means for solving the problem]

[0014] The present invention provides a token verification system configured by a computer that executes a process for verifying an access token and a refresh token included in a request for external access via the Internet, the system comprising: An API infrastructure system that is placed in an internal cloud environment and issues access tokens and refresh tokens, and accepts API (Application Programming Interface) usage; It is equipped with a request integration system that is placed in a public cloud environment and connects external access requests to the API infrastructure system. The API-based system is a token issuing means for issuing an access token and a refresh token; a token verification means for verifying the validity of an access token set in a business API request requesting the execution of a business process and a refresh token set in an access token reissue request requesting the reissue of the access token; The request linkage system is a request reception service means for receiving requests for external access via the Internet; request parameter check means, when the request for external access received by the request reception service means is a business API request, for setting the access token set in the business API request in an introspection API request and sending it to the token verification means, and receiving an introspection API response including the verification result of the access token from the token verification means, and when the request for external access is an access token reissue request, for setting the refresh token set in the access token reissue request in the introspection API request and sending it to the token verification means, and receiving an introspection API response including the verification result of the refresh token from the token verification means; an API gateway that executes a process of transmitting the request for external access received by the request reception service means to the API infrastructure system, and at this time, if the verification result acquired by the request parameter check means indicates that the token is not valid, does not transmit the request for external access to the API infrastructure system. It is characterized by the following.

[0015] In the token verification system of the present invention, a request integration system that accepts requests for external access is provided in a public cloud environment, and an introspection API request that sets the access token and refresh token to be verified in the request for external access is sent from the request parameter checking means of this request integration system to the token verification means of the API infrastructure system, and the verification result of the legitimacy of the access token and refresh token is received as an introspection API response from the token verification means.

[0016] This makes it possible to obtain the results of verifying the validity of the access token set in a business API request or an access token reissue request, which are requests for external access, using a request integration system located in a public cloud environment, without allowing these requests to intrude into the internal cloud environment.

[0017] Therefore, if the verification result of an access token or refresh token obtained in a public cloud environment indicates that the token is not valid, the API gateway of the request integration system can prevent business API requests or access token reissue requests for which the invalid access token or refresh token was set, i.e., requests for external access that pose security issues, from being sent to the API infrastructure system located in the internal cloud environment.

[0018] In other words, in the present invention, access tokens and refresh tokens are issued by a token issuing means of an API infrastructure system, and the token issuing entity is the API infrastructure system located in an internal cloud environment. Since the issued tokens can only be verified by the token issuing entity, token verification is performed in the API infrastructure system, and a token verification means is provided in the API infrastructure system. However, verifying the legitimacy of access tokens and refresh tokens in an API infrastructure system located in an internal cloud environment would result in business API requests and access token reissue requests, which are requests for external access and may contain security issues, being infiltrated into the internal cloud environment. Therefore, in the present invention, an introspection API is used to obtain token verification results by sending the token to be verified set in the request from a request integration system located in a public cloud environment to a token verification means of the API infrastructure system located in the internal cloud environment, rather than the external access request itself. If the verification result indicates that the token is not valid, the request itself is not sent (integrated) to the API infrastructure system. This means that requests for external access that may pose security risks can be prevented from infiltrating the internal cloud environment, ensuring sufficient security.

[0019] Furthermore, in the present invention, the results of token verification performed in an internal cloud environment are obtained by using an introspection API from a request collaboration system placed in a public cloud environment, so it is possible to avoid placing gateway servers with similar configurations in two locations, one for external access and one for internal access, as in the conventional system 90 shown in Figure 7. This makes it possible to reduce system construction costs, thereby achieving the above-mentioned object.

[0020] <Configuration for authenticating a client application using information from a client ID / client secret storage means provided in a request integration system>

[0021] In addition, in the token verification system described above, The request linkage system is a client ID / client secret storage means for storing a client ID and a client secret issued to a client application that is a sender of a request for external access via the Internet; The request parameter check method is If the request for external access is a business API request or an access token reissue request, it is desirable that the configuration also executes a process to authenticate the client application based on whether the combination of the client ID and client secret set in the request for external access matches the combination of the client ID and client secret stored in the client ID / client secret storage means.

[0022] In this way, if the request integration system is configured to authenticate the client application (which can also be thought of as authenticating the request sent from the client application) using information from the client ID / client secret storage means provided in the system, it is also possible to authenticate the client application in a request integration system located in a public cloud environment, further improving security.

[0023] <Configuration in which parameter copying means is provided in the request linkage system>

[0024] Furthermore, in a configuration in which the client application is authenticated using information from a client ID / client secret storage means provided in the request collaboration system described above, The request linkage system is a parameter copy means for copying a refresh token set in a body of the access token reissue request to a header of the access token reissue request when the request for external access is an access token reissue request; The request parameter check method is If the request for external access is an access token reissue request, it is desirable that the refresh token copied and set in the header of the access token reissue request is set in the introspection API request and sent to the token verification means, and that an introspection API response including the verification result of the refresh token is received from the token verification means.

[0025] When the request integration system is configured with a parameter copy means in this manner, even in a situation where the request parameter check means is unable to read the refresh token set in the body of the access token reissue request, the parameter copy means copies and sets the refresh token set in the body of the access token reissue request in the header, thereby enabling the request parameter check means to read the refresh token and setting the refresh token in the introspection API request.

[0026] <Configuration in which the validity of an access token or a refresh token is verified by a token verification means using an expiration date and an expiration flag>

[0027] In addition, in the token verification system described above, The API-based system is a token information storage means for storing, when an access token and a refresh token are issued by a token issuing means, an expiration date and an expiration flag for each of the access token and the refresh token in association with an access token ID or the access token itself and a refresh token ID or the refresh token itself; The token validation method is A configuration can be adopted in which the validity of the access token is verified using the access token ID for the access token set in the introspection API request or the expiration date and expiration flag stored in the token information storage means in association with the access token itself, or the validity of the refresh token is verified using the refresh token ID for the refresh token set in the introspection API request or the expiration date and expiration flag stored in the token information storage means in association with the refresh token itself.

[0028] In this manner, when the token verification means is configured to verify the validity of the access token or refresh token using the expiration date and expiration flag, it is possible to reliably verify the validity of each token in an internal cloud environment using information at the time of issuance of the access token and refresh token by the token issuance means.

[0029] <Program invention>

[0030] The program of the present invention is for causing a computer to function as the above-described token verification system.

[0031] The above program or a portion thereof may be recorded on a recording medium such as a magneto-optical disk (MO), compact disk (CD), digital versatile disk (DVD), flexible disk (FD), magnetic tape, read-only memory (ROM), electrically erasable and programmable read-only memory (EEPROM), flash memory, random access memory (RAM), hard disk drive (HDD), solid-state drive (SSD), or flash disk, and may be transmitted using a transmission medium such as a wired network (e.g., local area network (LAN), metropolitan area network (MAN), wide area network (WAN), the Internet, an intranet, or an extranet), a wireless communication network, or a combination thereof, or may be carried on a carrier wave. Furthermore, the above program may be a portion of another program, or may be recorded on a recording medium together with a separate program. [Effects of the Invention]

[0032] As described above, according to the present invention, by using an introspection API from a request integration system placed in a public cloud environment, the results of token verification performed in an internal cloud environment are obtained, thereby ensuring sufficient security and enabling a token verification system to be constructed inexpensively. [Brief explanation of the drawings]

[0033] [Figure 1] 1 is a diagram showing the overall configuration of a token verification system according to an embodiment of the present invention. [Figure 2] FIG. 10 is a flowchart showing the processing flow (part 1) from an OAuth authentication / authorization request to receiving an API response result in the embodiment. [Figure 3]FIG. 10 is a flowchart showing the processing flow (part 2) from an OAuth authentication and authorization request to receiving an API response result in the embodiment. [Figure 4] FIG. 10 is a flowchart showing the flow of a process for reissuing an access token using a refresh token according to the embodiment. [Figure 5] FIG. 2 is a flowchart showing the flow of processing by a request linkage system in a public cloud environment, which is a main part of the embodiment. [Figure 6] FIG. 10 is an explanatory diagram of a token issuance and verification process by an API infrastructure system in an internal cloud environment, which is another main part of the embodiment. [Figure 7] FIG. 1 is a diagram illustrating a conventional system configuration. DETAILED DESCRIPTION OF THE INVENTION

[0034] An embodiment of the present invention will be described below with reference to the drawings. FIG. 1 shows the overall configuration of a token verification system 10 of this embodiment. FIGS. 2 to 4 show flowcharts of the execution flow of a business API, including the token verification process by the token verification system 10. FIG. 5 shows a flowchart of the processing flow by the request linkage system 20 in a public cloud environment, as a main part of the processing by the token verification system 10. Furthermore, FIG. 6 shows a detailed explanation of the token issuance and verification process by the gateway server 40 of the API infrastructure system 30 in an internal cloud environment, as another main part of the processing by the token verification system 10.

[0035] <Overall configuration of token verification system 10>

[0036] 1, a token verification system 10 is configured to include a request collaboration system 20 placed in a public cloud environment connected to the Internet 1, an API infrastructure system 30 connected to the request collaboration system 20 via a dedicated line 2 and to an internal network 3 placed in an internal cloud environment, and a backend system 60 connected to the API infrastructure system 30 via the internal network 3 and placed in the internal cloud environment. An internal consumer 70 (here, a consumer is considered as a device) is connected to the internal network 3. A client terminal 80 operated by an external end user (e.g., a person in charge of a FinTech company) is also connected to the Internet 1.

[0037] Here, as the dedicated line 2, for example, a dedicated line provided by the direct connection service (AWS Direct Connect) of Amazon Web Services (AWS) of Amazon can be adopted.

[0038] The internal network 3 may be, for example, a company intranet or company LAN, and may be wired or wireless, or may be a combination of wired and wireless, as long as it can transmit information at a certain speed between multiple points (regardless of distance). Each device connected to this internal network 3 is placed in an internal cloud environment.

[0039] The request collaboration system 20 is placed in a public cloud environment connected to the Internet 1 and collaborates with (transmits) requests for external access (requests sent via the Internet 1 from client terminals 80 operated by external end users) to the API infrastructure system 30 via a dedicated line 2. The request collaboration system 20 is configured with one or more computers and includes a request reception service means 21, a parameter copy means 22, an API gateway 23, a request parameter check means 24, and a client ID / client secret storage means 25. A web application firewall 26 is provided between the request collaboration system 20 and the Internet 1. In this embodiment, the request collaboration system 20 uses Amazon API Gateway, and therefore the public cloud environment is built using Amazon's AWS Cloud, but the present invention is not limited to this.

[0040] Here, the request reception service means 21, parameter copy means 22, API gateway 23, and request parameter check means 24 are realized by a central processing unit (CPU) provided inside a computer constituting the request linkage system 20, one or more programs that define the operation procedures of this CPU, and working memories such as main memory and cache memory. Details of each of these means 21 to 24 will be described later.

[0041] Furthermore, for example, a nonvolatile memory such as a hard disk drive (HDD) or a solid state drive (SSD) can be used as the client ID / client secret storage means 25. Details of this client ID / client secret storage means 25 will be described later.

[0042] The API infrastructure system 30 is placed in an internal cloud environment connected to the internal network 3, accepts and manages API usage, and is configured with one or more computers, including a gateway server 40 and an API management server 50. The gateway server 40 and the API management server 50 may each be configured with any number of computers, or may be configured with the same single computer. In this embodiment, the API infrastructure system 30 uses IBM API Connect, but is not limited to this.

[0043] The gateway server 40 executes the reception process of API requests and includes an authentication system guidance means 41, an authorization code issuing means 42, a token issuing means 43, a token verification means 44, various business API definition execution means 45, an API post-processing means 46, a token information storage means 47, and an encryption key storage means 48.

[0044] Here, the authentication system guiding means 41, authorization code issuing means 42, token issuing means 43, token verifying means 44, business API definition and execution means 45, and API post-processing means 46 are realized by a central processing unit (CPU) provided inside a computer constituting the gateway server 40, one or more programs that define the operation procedures of this CPU, and working memory such as a main memory and a cache memory. Details of each of these means 41 to 46 will be described later.

[0045] Furthermore, for example, nonvolatile memories such as hard disk drives (HDDs) and solid state drives (SSDs) can be used as the token information storage means 47 and the encryption key storage means 48. Details of these storage means 47 and 48 will be described later.

[0046] The API management server 50 manages data required to execute APIs, and includes an API usage catalog storage means 51. For example, a non-volatile memory such as a hard disk drive (HDD) or solid state drive (SSD) can be used as this API usage catalog storage means 51. Details of this API usage catalog storage means 51 will be described later.

[0047] The back-end system 60 is configured to include a user authentication system 61 that authenticates external end users and authorizes the content of their requests, and various business processing systems 62 that execute various business processes in response to API requests from API executors (those who actually use the API among the target API users, and include not only humans but also systems).

[0048] The user authentication system 61 is configured with one or more computers, and includes a user authentication means 61A and an authorization means 61B. These user authentication means 61A and authorization means 61B are realized by a central processing unit (CPU) provided inside the computer that constitutes the user authentication system 61, one or more programs that define the operating procedures of this CPU, and a working memory such as a main memory or a cache memory. Details of these means 61A and 61B will be described later.

[0049] The business processing system 62 is configured with one or more computers, and includes various business processing means 62A that execute back-end business processing for various businesses (for example, referencing customer information, registering, updating, deleting customer trading data related to financial products, etc.). These business processing means 62A are realized by a central processing unit (CPU) provided inside the computer that constitutes the business processing system 62, one or more programs that define the operating procedures of this CPU, and working memories such as main memory and cache memory. Details of these business processing means 62A will be described later.

[0050] Although not shown in the figure, the business processing system 62 is equipped with a business processing data storage means for storing various data (e.g., customer information, data related to sales transactions, etc.) required for various back-end business processes to be executed by various business processing means 62A.

[0051] In this embodiment, the internal consumer 70 is not a human being but is depicted as a device composed of one or more computers, and may be a server of another internal system or an internal terminal operated by an internal user. Note that the internal system referred to here may also be a business processing system 62 that performs back-end business processing in response to an external access request, and may therefore be included in the back-end system 60. However, for ease of explanation, it is depicted as a system that sends business API requests from within the company, not from outside the company, and is not included in the back-end system 60. Furthermore, since the present invention processes external access requests and is not related to the processing of internal access requests by the internal consumer 70, the internal consumer 70 is depicted with a two-dot chain line. The processing of internal access requests is depicted to illustrate that it is the same as that of the conventional system 90 shown in FIG. 7 .

[0052] The client terminal 80 is configured by a computer and includes processing means 81 realized by a client application that transmits various requests to the request collaboration system 20 via the Internet 1 based on operations by an external end user. This client application holds the client ID and client secret issued by the request collaboration system 20, at least at the time of transmitting the request. The client ID and client secret may be held in a manner that accepts input operations by the external end user and stores the input client ID and client secret in a client ID / client secret local storage means (composed of a non-volatile memory, not shown) provided in the client terminal 80, or in a manner that accepts input operations by the external end user each time, or in a manner that the client ID and client secret are written (coded) into the program of the client application.

[0053] Here, the processing means 81 is realized by a central processing unit (CPU) provided in the client terminal 80, a client application which is one or more programs that define the operating procedures of this CPU, various libraries imported by this client application, and working memories such as main memory and cache memory. Details of this processing means 81 will be described later.

[0054] <Configuration of request collaboration system 20 / request reception service means 21>

[0055] The request reception service means 21 receives a request for external access that is sent via the Internet 1 from a client terminal 80 operated by an external end user and that has passed through the web application firewall 26, determines the type of the received request, and executes branching processing for transitioning to each subsequent process according to the determined request type. In this embodiment, Amazon's Cloud Front is used as the request reception service means 21, as an example.

[0056] Specifically, the request reception service means 21 determines the type of request by determining whether the received request is an authentication / authorization request (in the case of step S3 in FIG. 2, which will be described later) or an authorization code issuance request (in the case of step S13 in FIG. 2, which will be described later), as shown in FIG. 5, which will be described later. These determinations are made using the URL path of the request, and in this embodiment, as an example, if the path is, it is determined to be an authentication / authorization request or an authorization code issuance request, and if the request does not contain a confirmation ID and a confirmation code, it is determined to be an authentication / authorization request (in the case of step S3 in FIG. 2), and the process proceeds to step S4 in FIG. 2, which will be described later. If the confirmation ID and a confirmation code are present, it is determined to be an authorization code issuance request (in the case of step S13 in FIG. 2), and the process proceeds to step S14 in FIG. 2, which will be described later.

[0057] 5, the request reception service means 21 determines whether the received request is an access token issuance request (in the case of step S18 in FIG. 3) among token issuance requests. This determination is made using the URL path of the request and the grant type of the body of the request, and in this embodiment, as an example, if the path is and the grant type of the body is authorization_code, it is determined to be an access token issuance request, and the process proceeds to step S19 in FIG. 3, which will be described later.

[0058] Furthermore, the request reception service means 21 determines whether the received request is an access token reissue request using a refresh token (in the case of step S51 in FIG. 4, which will be described later) among token issuance requests, as shown in FIG. 5. This determination is made using the URL path of the request and the grant type of the body of the request, and in this embodiment, as an example, if the path is and the grant type of the body is refresh_token, it is determined to be an access token reissue request using a refresh token, and the process proceeds to step S52 in FIG. 4, which will be described later.

[0059] 5, the request reception service means 21 determines whether the received request is a business API request (step S24 in FIG. 3 or step S58 in FIG. 4, which will be described later) based on the URL path. If it is determined to be a business API request, the process proceeds to step S25 in FIG. 3 or step S59 in FIG. 4, which will be described later.

[0060] <Configuration of request linkage system 20 / parameter copy means 22>

[0061] 5, if the request for external access accepted by the request acceptance service means 21 is an access token issuance request (in the case of step S18 in FIG. 3), the parameter copy means 22 executes a process of copying and setting the client ID and client secret set in the body of the request to the header of the request (process of step S19 in FIG. 3, which will be described later), and if the request is an access token reissue request using a refresh token (in the case of step S51 in FIG. 4, which will be described later), the parameter copy means 22 executes a process of copying and setting the refresh token, client ID, and client secret set in the body of the request to the header of the request (process of step S52 in FIG. 4, which will be described later). Both processes are executed upon receiving a request (instruction) from the request acceptance service means 21, and the token after the copy process is returned to the request acceptance service means 21. In this embodiment, as an example, the parameter copy means 22 employs Lambda@Edge from Amazon.

[0062] The reason for performing this processing by the parameter copy means 22 is that when the request parameter check means 24 authenticates a client application using a client ID and a client secret (when performing the processing of step S20 in FIG. 3 and step S53 in FIG. 4, which will be described later), it may be unable to obtain the client ID and client secret set in the body of the request, and also because when the request parameter check means 24 verifies the validity of a refresh token (when performing the processing of step S54 in FIG. 4, which will be described later), it may be unable to obtain the refresh token set in the body of the request. For example, if Amazon's Lambda Authorizer is used as the request parameter check means 24, it may be impossible to obtain the value of the body of the request.

[0063] The reason why the information to be copied above is set in the body rather than in the header from the beginning is to ensure security. In other words, since the body is encrypted, the contents cannot be confirmed even if it is stolen, so parameters that should not be leaked to the outside are generally set in the body.

[0064] <Configuration of request integration system 20 / API gateway 23>

[0065] The API gateway 23 executes a process of transmitting the request for external access received by the request reception service means 21 to the API infrastructure system 30 via the dedicated line 2 .

[0066] At this time, the API gateway 23 requests the request parameter checking means 24 to authenticate the client application installed on the client terminal 80 that sent the request for external access, and if the authentication result by the request parameter checking means 24 is unsuccessful, the API gateway 23 does not send the request for external access to the API infrastructure system 30, but instead sends a message to the client terminal 80 via the Internet 1 that an authentication error has occurred.

[0067] In addition, if the request for external access includes an access token or a request token (as shown in Figure 5, if the request for external access is a business API request (step S24 in Figure 3 or step S58 in Figure 4 described later), or if it is a request to reissue an access token using a refresh token (step S51 in Figure 4 described later)), the API gateway 23 notifies the request parameter checking means 24 of this fact and requests token verification using the introspection API, and if the verification result of each token obtained as an introspection API response by the request parameter checking means 24 indicates that the token is not a legitimate token, the API gateway 23 does not send the request for external access including the token to the API infrastructure system 30, but instead sends a message to the client terminal 80 via the Internet 1 that an authentication error has occurred.

[0068] Therefore, if authentication of the client application that sent the request fails or if the verification result of the validity of each token obtained as an introspection API response shows that the token is not valid, it is possible to prevent external access requests from entering the internal cloud. Note that in this embodiment, as an example, Amazon's API Gateway is used as the API gateway 23.

[0069] <Configuration of request linkage system 20 / request parameter check means 24>

[0070] The request parameter check means 24 receives a request for authentication of a client application from the API gateway 23, and uses the information stored in the client ID / client secret storage means 25 to authenticate the client application installed on the client terminal 80 that sent the request for external access (you can think of it as authenticating the request sent from that client application), and then performs a process of returning the authentication result (information indicating whether the authentication was successful or unsuccessful) to the API gateway 23. Specifically, it performs the following process.

[0071] That is, when the request for external access received by the request reception service means 21 is an authentication / authorization request or an authorization code issuance request (as shown in FIG. 5, in the case of steps S3 and S13 in FIG. 3, which will be described later), the request parameter check means 24 executes a process of checking whether the client ID set in the query of the request exists among the client IDs stored in the client ID / client secret storage means 25. If it exists, the authentication is successful, and if it does not exist, the authentication is unsuccessful. Note that since the query information is used, the client secret is not used for authentication.

[0072] Furthermore, when the request for external access is an access token issuance request (in the case of step S18 in FIG. 3, which will be described later) or an access token reissue request using a refresh token (in the case of step S51 in FIG. 4, which will be described later), the request parameter check means 24 executes processing to authenticate the client application based on whether the combination of client ID and client secret set in the header of the request (the combination set by copying in advance from the body of the request to the header by the parameter copy means 22) matches the combination of client ID and client secret stored in the client ID / client secret storage means 25. If they match, the authentication is successful, and if they do not match, the authentication is unsuccessful.

[0073] Furthermore, when the request for external access is a business API request (step S24 in FIG. 3 or step S58 in FIG. 4, which will be described later), the request parameter check means 24 executes processing to authenticate the client application based on whether the combination of client ID and client secret set in the header of the request for external access matches the combination of client ID and client secret stored in the client ID / client secret storage means 25. If they match, the authentication is successful, and if they do not match, the authentication is unsuccessful.

[0074] In addition to the above-mentioned authentication process for the client application, the request parameter check means 24 receives a request from the API gateway 23 to verify a token using the introspection API, and performs a process of returning the verification result of the token obtained using the introspection API (the determination result as to whether the token to be verified is valid or not) to the API gateway 23. Specifically, it performs the following process.

[0075] That is, when the request for external access received by the request reception service means 21 is a business API request (as shown in FIG. 5, in the case of step S24 in FIG. 3 or step S58 in FIG. 4, which will be described later), the request parameter check means 24 sets the access token set in the header of the business API request in the body of an introspection API request and sends it to the token verification means 44 of the gateway server 40 via the dedicated line 2, and also executes a process of receiving an introspection API response including the verification result of the access token sent from the token verification means 44 via the dedicated line 2. At this time, in addition to the access token to be verified, a client ID and a client secret are also set in the body of the introspection API request.

[0076] Furthermore, when the request for external access is an access token reissue request using a refresh token (as shown in FIG. 5, in the case of step S51 in FIG. 4, which will be described later), the request parameter check means 24 sets the refresh token set in the header of the access token reissue request (which is set by copying it from the body to the header by the parameter copy means 22) in the body of the introspection API request and transmits it to the token verification means 44 via the dedicated line 2, and also executes a process of receiving an introspection API response including the verification result of the refresh token sent from the token verification means 44 via the dedicated line 2. At this time, in addition to the refresh token to be verified, the client ID and client secret (which are set by copying it from the body to the header by the parameter copy means 22) are also set in the body of the introspection API request.

[0077] In addition, when the request for external access is an access token issuance request (as shown in FIG. 5, in the case of step S18 in FIG. 3 described later), since there is no token to be verified, the introspection API is not used. In the case of an authentication / authorization request and an authorization code issuance request (as shown in FIG. 5, in the cases of steps S3 and S13 in FIG. 3 described later), since there is no token to be verified, the introspection API is not used.

[0078] Also, in this embodiment, as an example, the request parameter checking means 24 employs the Lambda Authorizer of Amazon.

[0079] <Configuration of Request Linkage System 20 / Client ID and Client Secret Storage Means 25>

[0080] The client ID and client secret storage means 25 stores the combination of the client ID and client secret issued by the request linkage system 20 for the client application installed on the client terminal 80.

[0081] <Configuration of API Infrastructure System 30 / Gateway Server 40 / Authentication System Inducing Means 41>

[0082] When the authentication system inducing means 41 receives an authentication / authorization request conforming to the Oauth2.0 specification (including the client ID in the query) transmitted via the dedicated line 2 from the API gateway 23 of the request linkage system 20 (for the branch of processing according to the type of request in the request linkage system 20, refer to FIG. 5), it executes the process of requesting authentication / authorization conforming to the Oauth2.0 specification via the internal network 3 to the user authentication system 61 (the process of step S5 in FIG. 2 described later).

[0083] <Configuration of the API Infrastructure System 30 / Gateway Server 40 / Authorization Code Issuing Means 42>

[0084] When the authorization code issuing means 42 receives an authorization code issuance request (including the client ID, confirmation ID, and confirmation code in the query) sent from the API gateway 23 of the request cooperation system 20 via the dedicated line 2 (for the branch of processing according to the type of request in the request cooperation system 20, refer to FIG. 5), it issues an authorization code and transmits the issued authorization code to the client terminal 80 via the dedicated line 2, the API gateway 23, and the Internet 1. It executes the process (the process of step S15 in FIG. 2 described later).

[0085] <Configuration of the API Infrastructure System 30 / Gateway Server 40 / Token Issuing Means 43>

[0086] When the token issuing means 43 receives an access token issuance request (including the authorization code, client ID, and client secret) sent from the API gateway 23 of the request cooperation system 20 via the dedicated line 2 (for the branch of processing according to the type of request in the request cooperation system 20, refer to FIG. 5), it issues an access token and a refresh token, encrypts the issued access token and refresh token using the encryption key stored in the encryption key storage means 48, and then transmits them to the client terminal 80 via the dedicated line 2, the API gateway 23, and the Internet 1. It executes the process (the process of step S21 in FIG. 3 described later).

[0087] At this time, as shown in FIG. 6, the token issuing means 43 associates the issue date and time, expiration date, and invalidation flag (at the time of issue, the invalidation flag is not set, that is, it is valid) of the issued access token with the access token ID (for example, the hash value of the access token) or the access token itself and stores them in the token information storage means 47. At the same time, the issue date and time, expiration date, and invalidation flag (at the time of issue, the invalidation flag is not set, that is, it is valid) of the issued refresh token are associated with the refresh token ID (for example, the hash value of the refresh token) or the refresh token itself and stored in the token information storage means 47.

[0088] <Configuration of API Infrastructure System 30 / Gateway Server 40 / Token Verification Means 44>

[0089] As shown in FIG. 6, when the token verification means 44 receives an introspection API request transmitted from the request parameter check means 24 of the request cooperation system 20 via the dedicated line 2 (see FIG. 1), it verifies the validity of the token to be verified (access token or refresh token) set in this introspection API request, and transmits (returns) an introspection API response including the verification result (judgment result as to whether the token is legitimate) to the request parameter check means 24 via the dedicated line 2.

[0090] More specifically, if the introspection API request from the request parameter check means 24 includes an access token that was set in the business API request requesting the execution of business processing (see Figure 5 for the branching of processing according to the type of request in the request integration system 20), the token verification means 44 decrypts the access token using the encryption key stored in the encryption key storage means 48, and then performs processing to verify the legitimacy of the access token using the access token ID (e.g., the hash value of the access token) for the decrypted access token or the expiration date and expiration flag associated with the access token itself and stored in the token information storage means 47 (processing of step S26 in Figure 3 and step S60 in Figure 4, which will be described later).

[0091] Furthermore, if the introspection API request from the request parameter check means 24 includes a refresh token set in the access token reissue request (see Figure 5), the token verification means 44 decrypts the refresh token using the encryption key stored in the encryption key storage means 48, and then performs a process to verify the validity of the refresh token (the process of step S54 in Figure 4, which will be described later) using the refresh token ID (e.g., the hash value of the refresh token) for the decrypted refresh token or the expiration date and expiration flag associated with the refresh token itself and stored in the token information storage means 47.

[0092] At this time, the validity of the token to be verified (access token or refresh token) is determined by whether each token is within its expiration date and whether the invalidation flag of each token is not set. That is, if it is within the expiration date and the invalidation flag is not set (if it has not expired), it is determined to be a valid token. On the other hand, if it has passed the expiration date or the invalidation flag is set, it is determined not to be a valid token. Furthermore, when the token to be verified can be decrypted using the encryption key stored in the encryption key storage means 48, it is possible to check that the token to be verified was issued by a legitimate issuer (token issuance means 43, that is, the correct OAuth provider). This is because it can be seen that it matches the encryption key used when the token was issued by the token issuance means 43.

[0093] <Configuration of API Infrastructure System 30 / Gateway Server 40 / Business API Definition Execution Means 45>

[0094] When the business API definition execution means 45 receives a business API request transmitted from the API gateway 23 of the request cooperation system 20 via the dedicated line 2 (see FIG. 5), according to the content of the business API request, from the API usage catalog storage means 51 of the API management server 50, via the internal network 3, the business API definition data (YAML file) for the business requested by the API executor (here, an external end user operating the client terminal 80) is acquired, and according to the acquired business API definition data (among the defined plurality of processes, the call of the business process is included), the call process (the transmission process of a further API request for requesting the execution of the business process to the business process means 62A) of the business process means 62A of the business process system 62 related to the request of the API executor is executed via the internal network 3.

[0095] Since the present invention handles requests for external access via the Internet 1, requests from in-house consumers 70 that do not go through the Internet 1 are not within the scope of the present invention. However, as shown by the two-dot chain line in FIG. 1, the business API definition execution means 45 also receives business API requests from in-house consumers 70 via the internal network 3 and executes the same processing as in the case of requests for external access.

[0096] <Configuration of API infrastructure system 30 / Gateway server 40 / API post-processing means 46>

[0097] The API post-processing means 46 receives information (e.g., customer information, etc.) obtained as a result of business processing transmitted from the business processing means 62A of the business processing system 62 via the internal network 3, and executes a process of transmitting the received information to the client terminal 80 via the dedicated line 2, the API gateway 23, and the Internet 1.

[0098] Therefore, when the business API request is a request for external access via the Internet 1, the business API definition execution means 45 receives the business API request, obtains business API definition data from the API management server 50, and further transmits an API request from the business API definition execution means 45 to the business processing means 62A via the internal network 3 according to the business API definition data. The business processing means 62A executes business processing using a business database (not shown). After that, the result of the business processing is transmitted from the business processing means 62A to the API post-processing means 46 via the internal network 3, and further transmitted from the API post-processing means 46 to the client terminal 80.

[0099] Incidentally, as shown by the two-dot chain line in FIG. 1, in the case of a business API request from the in-house consumer 70, the API post-processing means 46 receives information (e.g., customer information, etc.) obtained as a result of business processing transmitted from the business processing means 62A of the business processing system 62 via the internal network 3, and transmits the received information to the in-house consumer 70 via the internal network 3.

[0100] Therefore, in the case of a request by the in-house consumer 70 that does not pass through the Internet 1 for the business API request, as shown by the two-dot chain line in FIG. 1, the business API definition execution means 45 receives the business API request, obtains business API definition data from the API management server 50, and a further API request is transmitted from the business API definition execution means 45 to the business processing means 62A via the internal network 3 according to the business API definition data. The business processing means 62A executes business processing using a business database (not shown), and then the result of the business processing is transmitted from the business processing means 62A to the API post-processing means 46 via the internal network 3, and further transmitted from the API post-processing means 46 to the in-house consumer 70.

[0101] <Configuration of API Infrastructure System 30 / Gateway Server 40 / Token Information Storage Means 47>

[0102] As shown in FIG. 6, the token information storage means 47 stores the issue date and time, expiration date, and invalidation flag of the access token issued by the token issuing means 43 in association with the access token ID (e.g., the hash value of the access token) or the access token itself, and stores the issue date and time, expiration date, and invalidation flag of the refresh token issued by the token issuing means 43 in association with the refresh token ID (e.g., the hash value of the refresh token) or the refresh token itself.

[0103] <Configuration of API Infrastructure System 30 / Gateway Server 40 / Encryption Key Storage Means 48>

[0104] The encryption key storage means 48 stores encryption keys used for the encryption and decryption processes of access tokens and refresh tokens (see Fig. 6). The encryption process is performed when the token issuing means 43 transmits the access token and the refresh token to the client terminal 80 after issuing them. The decryption process is performed when the token verification means 44 verifies the token to be verified (access token or refresh token) included in the introspection API request.

[0105] <Configuration of API Base System 30 / API Management Server 50 / API Usage Catalog Storage Means 51>

[0106] The API usage catalog storage means 51 stores, for each API usage target (including servers of other systems within the company and company users in addition to external end-users), various business API definition data used by each API usage target in YAML files.

[0107] <Configuration of Back-end System 60 / User Authentication System 61 / User Authentication Means 61A>

[0108] The user authentication means 61A receives an authentication / authorization request conforming to the Oauth2.0 specification (including the client ID in the query) transmitted from the authentication system guidance means 41 via the internal network 3, transmits display data for the user authentication screen to the client terminal 80 via the Internet 1, receives the user ID and password transmitted from the client terminal 80 via the Internet 1, and executes user authentication processing for external end-users using the received user ID and password. This user authentication processing is performed in accordance with Oauth2.0.

[0109] If the user authentication is successful, the user authentication means 61A transfers the process to the authorization means 61B. On the other hand, if the user authentication is unsuccessful, the user authentication means 61A executes a process of transmitting information indicating that an authentication error has occurred to the client terminal 80 via the Internet 1.

[0110] <Configuration of Backend System 60 / User Authentication System 61 / Authorization Means 61B>

[0111] If the user authentication by the user authentication means 61A is successful, the authorization means 61B transmits display data for a user authority authorization screen (a screen for obtaining authorization that the user has the authority to execute business processing by a business API request) to the client terminal 80 via the Internet 1, and also receives information on the scope (the range of authority for which authorization is obtained, i.e., the extent to which data held by the business processing system 62 of the backend system 60 may be provided to the client application) transmitted from the client terminal 80 via the Internet 1, and executes authorization processing for the user's authority using the received scope information. This authorization processing is performed in accordance with Oauth 2.0.

[0112] If the authorization is successful, the authorization means 61B issues a confirmation ID and a confirmation code and executes a process of transmitting the issued confirmation ID and confirmation code to the client terminal 80 via the Internet 1. On the other hand, if the authorization is unsuccessful, the authorization means 61B executes a process of transmitting information to the effect that an authorization error has occurred to the client terminal 80 via the Internet 1.

[0113] <Configuration of Back-End System 60 / Business Processing System 62 / Business Processing Means 62A>

[0114] The business processing means 62A receives a further API request (a secondary API request resulting from the original business API request by the API executor) for requesting the execution of business processing, which is sent from the business API definition execution means 45 of the gateway server 40 via the internal network 3, executes the business processing requested by the API executor using various data (e.g., customer information, data related to sales transactions, etc.) stored in a business database (not shown) provided in the business processing system 62, and transmits the information obtained as a result of the business processing (e.g., customer information, etc.) to the API post-processing means 46 of the gateway server 40 via the internal network 3.

[0115] <Configuration of client terminal 80 / processing means 81>

[0116] The processing means 81 executes various processes realized by a client application (for example, an application written in Python or a Web application) installed on the client terminal 80 and various libraries imported by this client application (a library for an authorization code issuance request, a library for a token issuance request, and a library for an API call).

[0117] Specifically, the processing means 81 performs processing for sending an authorization code issuance request, processing for receiving an authorization code, processing for sending a token issuance request, processing for receiving tokens (access tokens and refresh tokens), processing for calling an API (processing for sending a business API request), and processing for receiving an API response.

[0118] <Processing flow by the token validation system 10 / Processing flow from OAuth authentication / authorization request to receiving API response result: Figures 2 and 3>

[0119] As shown in FIGS. 2 and 3, the token validation system 10 executes the processes from the OAuth authentication and authorization request to the reception of the API response result as follows.

[0120] In Figure 2, an external end user operates a client terminal 80 equipped with a client application, accesses various business processing systems 62 in a back-end system 60 using a business API, and begins using a service that executes business processing using various data stored in various business databases (not shown) provided in these business processing systems 62 (step S1).

[0121] First, the processing means 81 of the client terminal 80 transmits an authentication and authorization request (including a client ID in the query) conforming to the Oauth2.0 specifications to the request linkage system 20 via the Internet 1 (step S2).

[0122] In the request linkage system 20, the request reception service means 21 receives a request for external access from the client terminal 80 and determines the type of the received request. Here, for example, since the request path is and the request does not include a confirmation ID or a confirmation code, it is determined to be an authentication / authorization request (step S3).

[0123] Next, this authentication and authorization request is sent to the API gateway 23, and upon receiving a request from the API gateway 23, the request parameter checking means 24 uses the information stored in the client ID and client secret storage means 25 to authenticate the client application installed on the client terminal 80 that sent the request for external access, and returns the authentication result (information indicating whether the authentication was successful or unsuccessful) to the API gateway 23.

[0124] In this case, since the request for external access is an authentication / authorization request, the request parameter check means 24 checks whether the client ID set in the query of the request exists among the client IDs stored in the client ID / client secret storage means 25 (step S4). If it exists, the authentication is successful; if it does not exist, the authentication is unsuccessful. Note that since the query information is used, the client secret is not used for authentication here.

[0125] If the authentication of the client application is successful, the API gateway 23 sends an authentication and authorization request to the authentication system guiding means 41 of the gateway server 40 of the API infrastructure system 30 via the dedicated line 2, and the authentication system guiding means 41 further sends the authentication and authorization request to the user authentication means 61A of the user authentication system 61 of the backend system 60 via the internal network 3 (step S5). On the other hand, if the authentication of the client application is unsuccessful, the authentication and authorization request is not sent to the authentication system guiding means 41, and the API gateway 23 sends information to the effect that an authentication error has occurred to the client terminal 80 via the Internet 1.

[0126] Next, in the user authentication system 61, the user authentication means 61A receives an Oauth2.0 specification authentication / authorization request (including a client ID in the query) sent from the authentication system guidance means 41 via the internal network 3, and sends display data for the user authentication screen to the client terminal 80 via the Internet 1 (step S6).

[0127] In the client terminal 80, the processing means 81 receives the display data for the user authentication screen transmitted from the user authentication means 61A via the Internet 1, and displays the user authentication screen to the external end user. The end user then inputs a user ID and password on the displayed user authentication screen, and the processing means 81 transmits the input user ID and password to the user authentication means 61A via the Internet 1 (step S7).

[0128] The user authentication means 61A receives the user ID and password transmitted from the client terminal 80 via the Internet 1, and executes user authentication processing for the external end user using the received user ID and password (step S8). If the user authentication is successful, the user authentication means 61A transfers processing to the authorization means 61B. On the other hand, if the user authentication is unsuccessful, the user authentication means 61A transmits information to the effect that an authentication error has occurred to the client terminal 80 via the Internet 1.

[0129] If the user authentication is successful, the authorization means 61B transmits display data for the user authority authorization screen to the client terminal 80 via the Internet 1 (step S9). In the client terminal 80, the processing means 81 receives the display data for the user authority authorization screen transmitted from the authorization means 61B via the Internet 1, and displays the user authority authorization screen to the external end user. The end user then inputs a scope (the range of user authority for which authorization is to be obtained) on the displayed user authority authorization screen, and the processing means 81 transmits the input scope to the authorization means 61B via the Internet 1 (step S10).

[0130] The authorization means 61B receives information about the scope (the range of user authority for which authorization is obtained) transmitted from the client terminal 80 via the Internet 1, and executes authorization processing for the user's authority using the received scope information (step S11). If authorization is successful, the authorization means 61B issues a confirmation ID and a confirmation code, and transmits the issued confirmation ID and confirmation code to the client terminal 80 via the Internet 1. On the other hand, if authorization is unsuccessful, the authorization means 61B transmits information to the effect that an authorization error has occurred to the client terminal 80 via the Internet 1.

[0131] Thereafter, in the client terminal 80, the processing means 81 receives the confirmation ID and confirmation code sent from the authorization means 61B via the Internet 1, creates an authorization code issuance request (including the client ID, confirmation ID, and confirmation code in the query), and sends it to the request integration system 20 via the Internet 1 (step S12).

[0132] In the request linkage system 20, the request reception service means 21 receives a request for external access from the client terminal 80 and determines the type of the received request. Here, for example, since the request path is and the request includes a confirmation ID and a confirmation code, it is determined to be an authorization code issuance request (step S13).

[0133] Next, this authorization code issuance request (the query includes the client ID, confirmation ID, and confirmation code) is sent to the API gateway 23, and upon receiving the request from the API gateway 23, the request parameter checking means 24 uses the information stored in the client ID / client secret storage means 25 to authenticate the client application installed on the client terminal 80 that sent the request for external access, and returns the authentication result (information indicating whether the authentication was successful or unsuccessful) to the API gateway 23.

[0134] In this case, since the request for external access is a request for issuing an authorization code, the request parameter check means 24 checks whether the client ID set in the query of the request exists among the client IDs stored in the client ID / client secret storage means 25 (step S14). If it exists, authentication is successful; if it does not exist, authentication is unsuccessful. Note that since the query information is used, the client secret is not used for authentication here.

[0135] Then, if authentication of the client application is successful, the API gateway 23 sends an authorization code issuance request to the authorization code issuing means 42 of the gateway server 40 of the API infrastructure system 30 via the dedicated line 2, the authorization code issuing means 42 issues an authorization code, and the issued authorization code is sent to the client terminal 80 via the dedicated line 2, the API gateway 23, and the Internet 1 (step S15).

[0136] In FIG. 3, in the client terminal 80, the processing means 81 receives the authorization code sent from the authorization code issuing means 42 (step S16), creates an access token issuance request (the body of which includes the authorization code, client ID, and client secret), and sends the created access token issuance request to the request integration system 20 via the Internet 1 (step S17).

[0137] In the request linkage system 20, the request reception service means 21 receives a request for external access from the client terminal 80 and determines the type of the received request. Here, for example, since the request URL path is and the grant type in the body of the request is authorization_code, it is determined to be an access token issuance request (step S18).

[0138] Next, the request reception service means 21 determines that the received request for external access is an access token issuance request, and therefore requests (instructs) the parameter copy means 22 to perform copy processing. The parameter copy means 22 receives the access token issuance request related to the copy request from the request reception service means 21, copies and sets the client ID and client secret set in the body of the received request into the header of the request, and returns the access token issuance request after the copy processing to the request reception service means 21 (step S19).

[0139] Then, the request reception service means 21 sends the access token issuance request after the copy process (with the client ID and client secret set in the header) to the API gateway 23. Then, the API gateway 23 sends the received access token issuance request after the copy process to the request parameter check means 24 to check the parameters of the request.

[0140] Upon receiving a parameter check request from the API gateway 23, the request parameter check means 24 executes processing to authenticate the client application based on whether the combination of client ID and client secret set in the header of the access token issuance request after copy processing matches the combination of client ID and client secret stored in the client ID / client secret storage means 25 (step S20). If they match, authentication is successful; if they do not match, authentication is unsuccessful. The authentication result of this client application is returned to the API gateway 23.

[0141] When the API gateway 23 receives an authentication result indicating successful authentication of the client application, it sends an access token issuance request to the token issuing means 43 of the gateway server 40 of the API infrastructure system 30 via the dedicated line 2. On the other hand, when the API gateway 23 receives an authentication result indicating unsuccessful authentication, it sends information to the effect that an authentication error has occurred to the client terminal 80 via the Internet 1. This prevents unauthorized access token issuance requests from entering the internal cloud.

[0142] In the gateway server 40, when the token issuing means 43 receives an access token issuance request (including an authorization code, a client ID, and a client secret) sent from the API gateway 23 via the dedicated line 2, the token issuing means 43 issues an access token and a refresh token, encrypts the issued access token and refresh token using the encryption key stored in the encryption key storage means 48, and then sends them to the client terminal 80 via the dedicated line 2, the API gateway 23, and the Internet 1 (step S21).

[0143] At this time, as shown in Figure 6, the token issuing means 43 stores the issue date and time, expiration date, and expiration flag for each of the issued access tokens and refresh tokens in the token information storage means 47, associating them with the ID of each token (e.g., the hash value of each token) or each token itself.

[0144] In the client terminal 80, the processing means 81 receives the access token and refresh token sent from the token issuing means 43 via the dedicated line 2, the API gateway 23, and the Internet 1 (step S22), creates a business API request (including the access token, client ID, and client secret in the header), and sends the created business API request to the request integration system 20 via the Internet 1 (step S23).

[0145] In the request linkage system 20, the request reception service means 21 receives a request for external access from the client terminal 80 and determines the type of the received request. Here, it is determined that the request is a business API request based on the request path (step S24).

[0146] Next, the request reception service means 21 determines that the received external access request is a business API request, and sends the business API request to the API gateway 23. Then, the API gateway 23 sends the received business API request to the request parameter check means 24 to check the request parameters.

[0147] Upon receiving a parameter check request from the API gateway 23, the request parameter check means 24 first executes processing to authenticate the client application based on whether the combination of client ID and client secret set in the header of the business API request matches the combination of client ID and client secret stored in the client ID / client secret storage means 25 (step S25). If they match, the authentication is successful, and if they do not match, the authentication is unsuccessful.

[0148] Next, the request parameter check means 24 acquires the access token set in the header of the business API request, sets the acquired access token in the body of an introspection API request, and sends this introspection API request to the token verification means 44 of the gateway server 40 via the dedicated line 2, and receives an introspection API response including the verification result of the access token sent from the token verification means 44 via the dedicated line 2 (step S26). Note that the contents of the verification process by the token verification means 44 of the gateway server 40 have already been described in detail in the explanation of the token verification means 44, so a detailed explanation will not be given here.

[0149] The request parameter check means 24 returns to the API gateway 23 the result of the authentication process of the client application in step S25 and the result of the token verification process in step S26.

[0150] If the result of the authentication process of the client application received from the request parameter check means 24 is successful authentication and the result of the token verification process is that the token is valid, the API gateway 23 sends the business API request to the business API definition execution means 45 of the gateway server 40 of the API infrastructure system 30 (one of the various business API definition execution means 45 for executing the business process requested in the business API request) via the dedicated line 2. On the other hand, if the result of the authentication process of the client application is unsuccessful or the result of the token verification is that the token is invalid, the API gateway 23 does not send the business API request to the API infrastructure system 30, but instead sends a message to the client terminal 80 via the Internet 1 that an authentication error has occurred. This prevents invalid business API requests from entering the internal cloud.

[0151] When the gateway server 40 receives a business API request sent from the API gateway 23 via the dedicated line 2, the business API definition execution means 45 obtains business API definition data (YAML file) for the business requested by the API executor (here, an external end user operating the client terminal 80) from the API usage catalog storage means 51 of the API management server 50 via the internal network 3 in accordance with the content of the received business API request, and executes a call process to the business processing means 62A of the business processing system 62 related to the API executor's request via the internal network 3 in accordance with the obtained business API definition data (step S27).

[0152] In the business processing system 62, the business processing means 62A receives request information for the execution of business processing (a secondary API request resulting from the original business API request by the API executor) sent from the business API definition execution means 45 of the gateway server 40 via the internal network 3, executes the business processing requested by the API executor using various data (e.g., customer information, data related to buying and selling transactions, etc.) stored in a business database (not shown) provided in the business processing system 62, and sends the information obtained as a result of the business processing (e.g., customer information, etc.) to the API post-processing means 46 of the gateway server 40 via the internal network 3 (step S28).

[0153] In the gateway server 40, the API post-processing means 46 receives information (e.g., customer information, etc.) obtained as a result of business processing (API response) sent from the business processing means 62A of the business processing system 62 via the internal network 3, and sends the received information to the client terminal 80 via the dedicated line 2, the API gateway 23, and the Internet 1 (step S29).

[0154] In the client terminal 80, the processing means 81 receives the API response sent from the API post-processing means 46 via the dedicated line 2, the API gateway 23, and the Internet 1, and displays the response content on the screen as the service usage result (step S30), and an external end user can confirm this service usage result (step S31).

[0155] <Processing flow by the token verification system 10 / Flow of access token reissue processing using a refresh token: Figure 4>

[0156] In Figure 4, if the processing means 81 of the client terminal 80 determines that the access token has expired, it creates an access token reissue request (the body of which includes the refresh token, client ID, and client secret) and sends the created access token reissue request to the request integration system 20 via the Internet 1 (step S50).

[0157] In the request linkage system 20, the request reception service means 21 receives a request for external access from the client terminal 80 and determines the type of the received request. Here, for example, since the request URL path is and the grant type of the request body is refresh_token, it is determined to be an access token reissue request (step S51).

[0158] Next, the request reception service means 21 determines that the received request for external access is an access token reissue request, and therefore requests (instructs) the parameter copy means 22 to perform copy processing. The parameter copy means 22 receives the access token reissue request related to the copy request from the request reception service means 21, copies and sets the refresh token, client ID, and client secret set in the body of the received request into the header of the request, and returns the access token reissue request after the copy processing to the request reception service means 21 (step S52).

[0159] Then, the request reception service means 21 sends the access token reissue request after the copy process (with the refresh token, client ID, and client secret set in the header) to the API gateway 23. Then, the API gateway 23 sends the received access token reissue request after the copy process to the request parameter check means 24 to check the parameters of the request.

[0160] Upon receiving a parameter check request from the API gateway 23, the request parameter check means 24 first executes processing to authenticate the client application based on whether the combination of the client ID and client secret set in the header of the access token reissue request after the copy processing matches the combination of the client ID and client secret stored in the client ID / client secret storage means 25 (step S53). If they match, the authentication is successful, and if they do not match, the authentication is unsuccessful.

[0161] Next, the request parameter check means 24 acquires the refresh token set in the header of the access token reissue request after the copy process, sets the acquired refresh token in the body of the introspection API request, and sends this introspection API request to the token verification means 44 of the gateway server 40 via the dedicated line 2, and receives an introspection API response including the verification result of the refresh token sent from the token verification means 44 via the dedicated line 2 (step S54). Note that the contents of the verification process by the token verification means 44 of the gateway server 40 have already been described in detail in the explanation of the token verification means 44, so a detailed explanation will not be given here.

[0162] The request parameter check means 24 returns to the API gateway 23 the result of the authentication process of the client application in step S53 and the result of the token verification process in step S54.

[0163] If the result of the authentication process of the client application received from the request parameter check means 24 is successful authentication and the result of the token verification process is that the token is valid, the API gateway 23 sends an access token reissue request to the token issuing means 43 of the gateway server 40 of the API infrastructure system 30 via the dedicated line 2. On the other hand, if the result of the authentication process of the client application is unsuccessful or the result of the token verification is that the token is invalid, the API gateway 23 does not send the access token reissue request to the API infrastructure system 30, but instead sends a message to the client terminal 80 via the Internet 1 that an authentication error has occurred. This prevents invalid access token reissue requests from entering the internal cloud.

[0164] In the gateway server 40, when the token issuing means 43 receives an access token reissue request (including a refresh token, client ID, and client secret) sent from the API gateway 23 via the dedicated line 2, the token issuing means 43 issues an access token and a refresh token, encrypts the issued access token and refresh token using the encryption key stored in the encryption key storage means 48, and then sends them to the client terminal 80 via the dedicated line 2, the API gateway 23, and the Internet 1 (step S55).

[0165] At this time, as shown in Figure 6, the token issuing means 43 stores the issue date and time, expiration date, and expiration flag for each of the issued access tokens and refresh tokens in the token information storage means 47, associating them with the ID of each token (e.g., the hash value of each token) or each token itself.

[0166] The subsequent processing of steps S56 to S65 (processing of the business API request) is the same as the processing of steps S22 to S31 in FIG. 3 described above.

[0167] <Processing flow by the request linkage system 20: Figure 5>

[0168] 5 shows the flow of processing executed by the request collaboration system 20 depending on the type of request for external access received by the request collaboration system 20. This shows the main processing executed by the request collaboration system 20 (the processing of steps S3, S4, S13, S14, S18 to S20, S24 to S26, S51 to S54, and S58 to S60 described above) extracted from the overall processing flow by the token verification system 10 shown in FIGS.

[0169] In the request integration system 20, the request reception service means 21 performs condition determination on the received request for external access (steps S3, S13, S18, S24, S51, and S58 described above), and branches the processing depending on the type of request obtained by the condition determination.

[0170] That is, if the received request for external access is determined to be an authentication / authorization request (step S3 in FIG. 2) or an authorization code issuance request (step S13 in FIG. 2), the request parameter check means 24 executes a client application check process (steps S4 and S14 in FIG. 2), and if the request does not contain a confirmation ID and a confirmation code, the authentication system guidance means 41 proceeds to a guidance process to the user authentication system 61 (step S5 in FIG. 2), and if the request contains a confirmation ID and a confirmation code, the authorization code issuance means 42 proceeds to an authorization code issuance process (step S15 in FIG. 2).

[0171] Furthermore, if the received request for external access is determined to be an access token issuance request (step S18 in FIG. 3), the parameter copy means 22 performs a copy process (step S19 in FIG. 3), the request parameter check means 24 performs a client application authentication process (step S20 in FIG. 3), and then the token issuance means 43 proceeds to an access token and refresh token issuance process (step S21 in FIG. 3).

[0172] Furthermore, if the received request for external access is determined to be a request for reissuing an access token using a refresh token (step S51 in Figure 4), the parameter copy means 22 performs a copy process (step S52 in Figure 4), the request parameter check means 24 performs an authentication process for the client application (step S53 in Figure 4), and the request parameter check means 24 performs a token verification process using an introspection API (step S54 in Figure 4), and then the token issuance means 43 proceeds to an access token and refresh token issuance process (step S55 in Figure 4).

[0173] Furthermore, if the received request for external access is determined to be a business API request (step S24 in FIG. 3, step S58 in FIG. 4), the request parameter checking means 24 performs authentication processing of the client application (step S25 in FIG. 3, step S59 in FIG. 4), and the request parameter checking means 24 performs token verification processing using the introspection API (step S26 in FIG. 3, step S60 in FIG. 4), and then the business API definition execution means 45 proceeds to business API definition execution processing (step S27 in FIG. 3, step S61 in FIG. 4).

[0174] <Effects of this embodiment>

[0175] The present embodiment has the following advantages: In the token verification system 10, the request collaboration system 20 that receives requests for external access is provided in a public cloud environment, the request parameter check means 24 of the request collaboration system 20 sends an introspection API request, in which the access token or refresh token to be verified in the request for external access is set, to the token verification means 44 of the API infrastructure system 30, and the token verification means 44 returns an introspection API response containing a verification result of the legitimacy of the access token or refresh token. This makes it possible to obtain the verification result of the legitimacy of the access token set in the business API request or the verification result of the legitimacy of the refresh token set in the access token reissue request in the request for external access by the request collaboration system 20 located in the public cloud environment, without allowing the business API request or the access token reissue request, which is a request for external access, to enter the internal cloud environment.

[0176] Therefore, if the verification result of an access token or refresh token obtained in a public cloud environment indicates that the token is not a valid token, the API gateway 23 of the request integration system 20 can prevent business API requests or access token reissue requests for which the invalid access token or refresh token was set, i.e., requests for external access that pose security problems, from being sent to the API infrastructure system 30 located in an internal cloud environment.

[0177] That is, in the token verification system 10, access tokens and refresh tokens are issued by the token issuing means 43 of the API infrastructure system 30, and therefore the token issuing entity is the API infrastructure system 30 located in an internal cloud environment. Since the issued token can only be verified by the token issuing entity, the token is verified in the API infrastructure system 30, and a token verification means 44 is provided in the API infrastructure system 30. However, verifying the legitimacy of the access token or refresh token in the API infrastructure system 30 located in an internal cloud environment would result in business API requests and access token reissue requests, which are requests for external access that may contain security issues, being allowed into the internal cloud environment. Therefore, the token verification system 10 uses an introspection API to obtain the token verification result by sending the token to be verified set in the request from the request linking system 20 placed in a public cloud environment to the token verification means 44 of the API infrastructure system 30 placed in an internal cloud environment, rather than the external access request itself, and if the verification result indicates that the token is not valid, the request itself is not sent (linked) to the API infrastructure system 30. This makes it possible to prevent the external access request itself, which may pose a security risk, from infiltrating the internal cloud environment, thereby ensuring sufficient security.

[0178] Furthermore, the token validation system 10 obtains the results of token validation performed in an internal cloud environment by using an introspection API from the request linking system 20 placed in a public cloud environment, which makes it possible to avoid placing gateway servers with a similar configuration as in the conventional system 90 shown in Fig. 7 in two locations, one for external access and one for internal access, thereby reducing the system construction costs.

[0179] Furthermore, in the token verification system 10, the token issuing means 43 that issues access tokens and refresh tokens in accordance with OAuth2.0 is provided in the API infrastructure system 30 in an internal cloud environment. In other words, it is possible to utilize the standard functions adopted in the conventional system 90 shown in FIG. 7. Therefore, after the construction of the token verification system 10 of the present invention, external consumers (in this embodiment, client terminals 80 operated by external end users, or client applications installed thereon) can use the access tokens and refresh tokens issued in the conventional system 90 before the construction as they are.

[0180] Furthermore, the token verification system 10 is configured to authenticate a client application (which may be considered as authentication of a request sent from the client application) using information from the client ID / client secret storage means 25 provided in the request integration system 20. Therefore, the request integration system 20 placed in a public cloud environment can authenticate the client application, further improving security.

[0181] Furthermore, since the request linkage system 20 is provided with the parameter copy means 22, even in a situation where the request parameter check means 24 cannot read the refresh token set in the body of the access token reissue request, the parameter copy means 22 can copy and set the refresh token set in the body of the access token reissue request in the header. Therefore, the request parameter check means 24 can read the refresh token, and the refresh token can be set in the introspection API request.

[0182] In addition, the token verification system 10 is configured so that the token verification means 44 verifies the validity of the access token or refresh token using the expiration date and expiration flag stored in the token information storage means 47 (see Figure 6), and therefore the validity of each token can be reliably verified in an internal cloud environment using information at the time of issuance of the access token and refresh token by the token issuance means 43.

[0183] <Transformation Form>

[0184] The present invention is not limited to the above-described embodiment, and modifications within the scope of the present invention are included in the present invention.

[0185] For example, in the above embodiment, the sender of the request for external access via the Internet was a client application installed on a client terminal 80 operated by an external end user, but this is not limited to this, and the sender of the request for external access via the Internet in the present invention may also be a client application installed on a server of another external system (a system other than the token verification system of the present invention). [Industrial Applicability]

[0186] As described above, the token verification system and program of the present invention are suitable for use, for example, in situations where an external end user uses an API to access a business processing system located in an internal cloud environment and perform business processing. [Explanation of symbols]

[0187] 1. Internet 2 Dedicated lines 3 Internal Network 10 Token Validation System 20 Request Integration System 21 Request reception service method 22 Parameter copy method 23 API Gateway 24 Request Parameter Check Method 25 Client ID / Client Secret Storage Means 30 API-based system 43 Token Issuance Method 44 Token Validation Methods 47 Token information storage means

Claims

1. A token verification system configured by a computer that executes a process for verifying an access token and a refresh token included in a request for external access via the Internet, an API infrastructure system that is placed in an internal cloud environment and issues access tokens and refresh tokens and accepts API (Application Programming Interface) usage; a request linking system that is placed in a public cloud environment and links the external access request to the API infrastructure system; The API-based system includes: a token issuing means for issuing an access token and a refresh token; a token verification means for verifying the validity of the access token set in a business API request requesting execution of business processing and the validity of the refresh token set in an access token reissue request requesting reissue of the access token, The request collaboration system includes: a request reception service means for receiving a request for the external access via the Internet; request parameter check means, when the request for external access received by the request reception service means is the business API request, setting the access token set in the business API request in an introspection API request and sending it to the token verification means, and receiving an introspection API response including the verification result of the access token from the token verification means, and when the request for external access is the access token reissue request, setting the refresh token set in the access token reissue request in an introspection API request and sending it to the token verification means, and receiving an introspection API response including the verification result of the refresh token from the token verification means; an API gateway that executes a process of transmitting the request for external access received by the request reception service means to the API infrastructure system, and at this time, if the verification result acquired by the request parameter check means indicates that the token is not valid, does not transmit the request for external access to the API infrastructure system. A token verification system comprising:

2. The request collaboration system includes: a client ID / client secret storage means for storing a client ID and a client secret issued to a client application that has transmitted a request for external access via the Internet; The request parameter check means When the request for external access is the business API request or the access token reissue request, a process of authenticating the client application is also executed depending on whether or not the combination of the client ID and the client secret set in the request for external access matches the combination of the client ID and the client secret stored in the client ID / client secret storage means. The token verification system of claim 1 .

3. The request collaboration system includes: a parameter copy means for copying the refresh token set in a body of the access token reissue request to a header of the access token reissue request when the request for external access is the access token reissue request, The request parameter check means If the request for external access is the access token reissue request, the refresh token copied and set in the header of the access token reissue request is set in the introspection API request and sent to the token verification means, and the introspection API response including the verification result of the refresh token from the token verification means is received. The token verification system of claim 2 .

4. The API-based system includes: a token information storage means for storing, when the access token and the refresh token are issued by the token issuing means, an expiration date and an expiration flag for each of the access token and the refresh token, in association with an access token ID or the access token itself and a refresh token ID or the refresh token itself; The token verification means The validity of the access token is verified by using the expiration date and the expiration flag stored in the token information storage means in association with the access token ID for the access token set in the introspection API request or the access token itself, or the validity of the refresh token is verified by using the expiration date and the expiration flag stored in the token information storage means in association with the refresh token ID for the refresh token set in the introspection API request or the refresh token itself. The token verification system of claim 1 .

5. A program for causing a computer to function as the token verification system according to any one of claims 1 to 4.

Images