Spoofing prevention system and program

Abstract

To provide a spoofing prevention system which can prevent spoofing of an employee at the time of API execution.SOLUTION: In a spoofing prevention system 10, an open ID provider system 20 issues an ID token including a user name constituted by partially including an employee ID, a client terminal 60 generates an API request including the client ID, the ID token and so on and transmits the API request to an API base system 30, the API base system 30 cuts out the employee ID from the user name included in the ID token and sets the employee ID to the API request, and API use object person information storage means 54 is used to determine whether the client ID and the employee ID in the API request correspond to each other or not by spoofing check means (41D and 42B).SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to an impersonation prevention system and program configured by a computer that executes processing to prevent employees from impersonating other employees when using an API (Application Programming Interface), and can be used, for example, when each employee uses a business API from a client terminal equipped with a client application to access various data in a back-end system and perform business processing. [Background technology]

[0002] Traditionally, when an employee executes an API, they log in to a client terminal (such as a 2-in-1 terminal provided by the company) equipped with a client application using their employee ID and password, and then use two pieces of authentication information, the client ID and client secret, to access various data in the backend system via an API infrastructure system with a gateway server and perform the necessary business processing.

[0003] To enable employees to execute APIs, the above client ID and client secret are issued to each employee who is an API user by the API infrastructure system and stored in the API infrastructure system. The client ID and client secret issued to each employee are managed by that individual. Therefore, each employee makes an API request by setting the client ID and client secret issued to them in the request parameters (header).

[0004] As will be described later, in this invention, an ID token issued by an open ID provider is used as information other than the client ID and client secret to check that the client ID at the time of API execution belongs to the executor himself / herself. However, known examples of processes that use APIs and ID tokens include an "electronic voting management method" (see Patent Document 1) that can realize highly confidential electronic voting, and a "method and system for seamless single sign-on (SSO) for native mobile application-initiated Open ID Connect (OIDC) flow and Security Assertion Markup Language (SAML) flow" (see Patent Document 2), which provides a method for accessing resources hosted on a relying party server from a mobile device.

[0005] Also, although there is no mention of ID tokens, known technologies related to preventing employee impersonation during API execution include a "network communication method and network communication system" (see Patent Document 3), which allows the first server, third server, and second server to generate and compare execution proof information based on dynamic common information, thereby preventing impersonation; a "transmitting device and its program, as well as a receiving device and API execution program" (see Patent Document 4), which provides technology that disables fraud even if a receiving device used to receive data broadcasts receives fraudulent data broadcasts; a "system for preventing unauthorized use of authority" (see Patent Document 5) in proxy operations, which can suppress self-approval of invoice slips issued by a proxy when proxy processing is performed; and an "information provision device, information provision method, information provision program, and recording medium, as well as a user authentication device, user authentication method, user authentication program, and recording medium" (see Patent Document 6), which can provide user information that is managed independently in an integrated manner. [Prior art documents] [Patent documents]

[0006] [Patent Document 1] JP 2022-107556 A (paragraphs

[0012] ,

[0026] ,

[0027] , and

[0032] ) [Patent Document 2] Japanese Patent Publication No. 2020-126602 [Patent Document 3] Re-tabled publication No. 2016-158908 (paragraphs

[0045] ,

[0078] ) [Patent Document 4] JP 2009-147808 A (Abstract) [Patent Document 5] JP 2008-243023 A (paragraph

[0028] ) [Patent Document 6] JP 2004-303202 A (Claim 1, paragraph

[0170] ) Summary of the Invention [Problem to be solved by the invention]

[0007] As mentioned above, the client ID and client secret issued to each employee who is an API user are managed by that individual. Therefore, if the client ID and client secret are leaked, they will become available to anyone.

[0008] Therefore, if a malicious person obtains another person's client ID and client secret, they can execute the API using that person's client ID and client secret to illegally obtain customer information stored in the backend system, and in the case of APIs that perform update-related business processes, they can illegally register, update, or delete data.

[0009] An object of the present invention is to provide a spoofing prevention system and program that can prevent employees from spoofing when executing APIs. [Means for solving the problem]

[0010] The present invention provides an impersonation prevention system configured by a computer that executes a process to prevent employees from impersonating other employees when using an API (Application Programming Interface), a user information storage means for storing an employee ID for identifying each employee in an open ID provider system that issues ID tokens, in association with a username for the open ID provider that includes a portion of the employee ID; an API user information storage means for storing employee IDs and client IDs and client secrets assigned to each employee in association with each other within an API infrastructure system that accepts and manages API usage by employees; an authorization code issuance request sending means for sending an authorization code issuance request to the open ID provider system via a network from a client terminal to which the employee has logged in using the employee ID; an authorization code issuing means, within the open ID provider system that has received the authorization code issuance request, that receives the employee ID used for logging in from the client terminal via a network, issues an authorization code, associates the authorization code with the employee ID, stores the authorization code in an authorization code issuance information storage means, and transmits the issued authorization code to the client terminal via the network; an authorization code receiving means in the client terminal for receiving an authorization code transmitted from the open ID provider system via a network by the authorization code issuing means; a token issuance request sending means for sending a token issuance request including the authorization code received by the authorization code receiving means from the client terminal to the open ID provider system via a network; a token issuing means in the open ID provider system that receives the token issuance request, for acquiring an employee ID from an authorization code issuance information storage means using the authorization code included in the token issuance request, acquiring a username from a user information storage means using the acquired employee ID, issuing an ID token including the acquired username, and transmitting the issued ID token to the client terminal via a network; a token receiving means in the client terminal for receiving an ID token transmitted from the open ID provider system via a network by the token issuing means; an API calling means for receiving input from a client application installed on the client terminal, creating an API request including a client ID and a client secret that are stored in the client terminal or that are written in the program of the client application, and an ID token received by the token receiving means, and transmitting the created API request from the client terminal to the API infrastructure system via a network; an employee ID setting means in the API infrastructure system for extracting an employee ID from a user name included in an ID token set in a received API request and setting the extracted employee ID in the API request; an impersonation check means for determining whether an employee ID stored in an API user information storage means in association with a client ID set in an API request matches the employee ID set in the API request within the API infrastructure system, and determining that an attempt is being made to impersonate another employee if the employee ID does not match; The present invention is characterized by the following features.

[0011] In the impersonation prevention system of the present invention, by utilizing OpenID Connect, a specification for issuing ID tokens, an ID token issued by the open ID provider system is used as information other than the client ID and client secret to check that the client ID at the time of API execution belongs to the person executing the API (impersonation check by an employee).

[0012] That is, when a token issuance request is received from a client terminal by a token issuance means provided in the open ID provider system, the token issuance means uses the authorization code included in the received token issuance request to obtain an employee ID from the authorization code issuance information storage means, uses the obtained employee ID to obtain a username (a username for the open ID provider that partially includes the employee ID) from the user information storage means, issues an ID token including the obtained username, and transmits the issued ID token to the client terminal.

[0013] When an employee executes an API, the employee uses the API calling means on the client terminal into which the employee has logged in to create an API request including a client ID, client secret, and ID token, and then sends the created API request from the client terminal to the API infrastructure system.

[0014] In the API infrastructure system, an employee ID setting means extracts the employee ID from the username for the open ID provider (this username partially contains the employee ID) included in the ID token set in the API request received from the client terminal, and sets the extracted employee ID in the API request.

[0015] Then, within the API infrastructure system, the impersonation checking means determines whether the client ID set in the API request matches the employee ID associated with it and stored in the API user information storage means, and whether the employee ID (employee ID cut from the username for the open ID provider) set in the API request matches. If they do not match, it is determined that impersonation of another employee is being carried out.

[0016] Therefore, even if an employee who is an offender performing impersonation of another employee attempts to execute the API using their own employee ID (the offender's own) and the client ID and client secret of another employee obtained illegally, the impersonation checking means will detect such illegal behavior. That is, the employee ID set in the API request is the employee ID of the offender who logged in to the terminal. On the other hand, the employee ID associated with the illegally obtained client ID of another employee and stored in the API user information storage means is the employee ID of another employee, so they do not match, and the act of impersonation can be found.

[0017] Thus, it becomes possible to prevent an employee who is an offender from illegally obtaining customer information etc. stored in the back-end system. Also, in the case of an API that performs update-related business processing, it becomes possible to prevent an employee who is an offender from illegally registering, updating, or deleting data, and the above object is achieved thereby.

[0018] <Configuration to send an authentication error to the client terminal when no ID token is set in the API request>

[0019] Also, in the above-mentioned impersonation prevention system, the employee ID setting means Preferably, when no ID token is set in the API request received from the client terminal, it is also configured to execute a process of sending information indicating that an authentication error has occurred to the client terminal via the network.

[0020] In this way, if an authentication error is sent to the client terminal when an ID token is not set in an API request, the information necessary for processing by the impersonation check means will be missing, making it possible to prevent unauthorized API execution before proceeding to processing by the impersonation check means.

[0021] <Configuration for token validation>

[0022] Furthermore, if the above-mentioned API request is configured to send an authentication error to the client terminal when an ID token is not set, The API-based system is a parameter storage means for storing a key ID and an algorithm; a public key storage means for storing a public key of the open ID provider system; a token verification means for verifying whether the key ID and algorithm stored in the parameter storage means match the key ID and algorithm in the ID token included in the header of the API request, and for verifying whether the ID token is issued by the open ID provider system using the signature in the ID token included in the header of the API request and the public key stored in the public key storage means; It is desirable to have a configuration including the above.

[0023] When configured to perform token verification in this manner, it becomes possible to verify whether the ID token was issued by an open ID provider system, thereby further improving security functions.

[0024] <Program invention>

[0025] The program of the present invention is for causing a computer to function as the above-described spoofing prevention system.

[0026] 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]

[0027] As described above, according to the present invention, by utilizing OpenID Connect, an ID token issued by an open ID provider system is used as information other than a client ID and client secret to check that the client ID at the time of API execution is that of the person executing the API, thereby having the effect of preventing employees from impersonating others when executing the API. [Brief explanation of the drawings]

[0028] [Figure 1] 1 is a diagram showing the overall configuration of a spoofing prevention system according to an embodiment of the present invention; [Figure 2] FIG. 2 is another overall configuration diagram of the spoofing prevention system according to the embodiment. [Figure 3] FIG. 2 is a configuration diagram showing a main part of the spoofing prevention system according to the embodiment. [Figure 4] FIG. 10 is a flowchart showing the flow (part 1) of the spoofing prevention process when an employee executes an API according to the embodiment. [Figure 5] FIG. 10 is a flowchart showing the flow (part 2) of the spoofing prevention process when an employee executes an API according to the embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0029] An embodiment of the present invention will be described below with reference to the drawings. Figures 1 and 2 show the overall configuration of a spoofing prevention system 10 according to this embodiment. Figure 3 shows the configuration of the main components of the spoofing prevention system 10, and Figures 4 and 5 show a flowchart of the spoofing prevention process when an employee executes an API.

[0030] <Overall configuration of spoofing prevention system 10>

[0031] 1 and 2, the spoofing prevention system 10 is configured to include an open ID provider system 20 managed by an OpenID provider, an API infrastructure system 30 that accepts and manages API usage by target API users (e.g., employees, internal departments, and internal systems), and a large number of client terminals 60 operated by the employees. Also connected to the network 1 is a backend system 80 that executes various business processes in conjunction with the execution of APIs by the employees as target API users. Furthermore, although not shown, other systems that use data from the backend system 80 as target API users are also connected to the network 1.

[0032] Here, network 1 is an internal network within a company, for example, composed of an intranet or LAN, but it does not matter whether it is wired or wireless, or even a combination of wired and wireless; in short, it is sufficient if it can transmit information at a certain speed between multiple points (regardless of distance).

[0033] The open ID provider system 20 is configured with one or more computers and includes a processing means 20A that executes various processes in accordance with OpenID Connect, which is a specification for issuing ID tokens, and this processing means 20A includes a login processing means 21, an authorization code issuing means 22, and a token issuing means 23. The open ID provider system 20 also includes a user information storage means 24, an application list storage means 25, and an authorization code issuance information storage means 26 in order to store various data required for the processing means 20A to execute various processes.

[0034] Here, each of the means 21 to 23 included in the processing means 20A is realized by a central processing unit (CPU) provided inside a computer constituting the open ID provider 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 23 will be described later.

[0035] Furthermore, nonvolatile memories such as hard disk drives (HDDs) and solid state drives (SSDs) can be used as the user information storage means 24, the application list storage means 25, and the authorization code issuance information storage means 26. Details of these storage means 24 to 26 will be described later.

[0036] In this embodiment, Azure AD is used as the open ID provider system 20, but this is not limited to this, and any open ID provider can perform various processes in accordance with OpenID Connect, which is a specification for issuing ID tokens, and therefore can be applied to the present invention.

[0037] The API infrastructure system 30 is configured with one or more computers, and includes 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.

[0038] The gateway server 40 includes a processing unit 40A that executes API request reception processing. The processing unit 40A includes a preflow processing unit 41, an API definition execution unit 42, and a postflow processing unit 43. The preflow processing unit 41 includes a URL matching unit 41A, an employee ID setting unit 41B, a token verification unit 41C, an impersonation check API calling unit 41D that constitutes the "impersonation check unit," and a request syntax / size check unit 41E. The API definition execution unit 42 includes various business API definition execution units 42A and an impersonation check API execution unit 42B that constitutes the "impersonation check unit." The postflow processing unit 43 includes various API post-processing units 43A. The gateway server 40 also includes a public key storage unit 44 and a parameter storage unit 45 for storing various data required for the processing unit 40A to execute various processes.

[0039] Here, each of the means 41 (41A, 41B, 41C, 41D, 41E), 42 (42A, 42B), and 43 (43A) included in the processing means 40A is realized by a central processing unit (CPU) provided inside the computer constituting the gateway server 40, 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. The details of each of these means 41 (41A, 41B, 41C, 41D, 41E), 42 (42A, 42B), and 43 (43A) will be described later.

[0040] Furthermore, for example, nonvolatile memories such as hard disk drives (HDDs) and solid state drives (SSDs) can be used as the public key storage means 44 and the parameter storage means 45. Details of these storage means 44 and 45 will be described later.

[0041] The API management server 50 comprises an API definition data transmission means 51, an API employee usage catalog storage means 52, an API user target information transmission means 53, and an API user target information storage means .

[0042] Here, the API definition data transmission means 51 and the API user information transmission means 53 are realized by a central processing unit (CPU) provided inside the computer constituting the API management server 50, one or more programs that define the operating procedures of this CPU, and working memory such as main memory and cache memory. Details of each of these means 51 and 53 will be described later.

[0043] Furthermore, non-volatile memory such as a hard disk drive (HDD) or solid state drive (SSD) can be used as the API employee usage catalog storage means 52 and the API user information storage means 54. Details of these storage means 52 and 54 will be described later.

[0044] The client terminal 60 is configured by a computer or a mobile device. For example, it may be a 2-in-1 terminal or the like distributed to each employee, and may be any device that can perform terminal login authentication using the open ID provider system 20 (in this embodiment, as an example, Azure AD).

[0045] 1, the client terminal 60 includes a processing means 60A that executes various processes including calling an API and receiving a response, and the processing means 60A includes a terminal login means 61, a client ID / client secret input receiving means 62, an authorization code issuance request sending means 63, an authorization code receiving means 64, a token issuance request sending means 65, a token receiving means 66, an API calling means 67, and an API response receiving means 68. The client terminal 60 also includes a client ID / client secret storage means 70 and a login employee ID / password storage means 71 for storing various data required for the processing means 60A to execute various processes.

[0046] 2, the client terminal 60 is equipped with a client application 60B that calls APIs and receives responses. This client application 60B includes an application 60C written in Python and a Web application 60D. The client terminal 60 also stores a library 60E that is imported by the client application 60B. This library 60E includes an authorization code issuance request library 60F, a token issuance request library 60G, and an API call library 60H. These libraries are intended to operate on a terminal that can perform login authentication using the open ID provider system 20 (Azure AD, as an example, in this embodiment).

[0047] Here, each of the means 61 to 68 included in the processing means 60A (see FIG. 1) is realized by a central processing unit (CPU) provided inside the computer or mobile device constituting the client terminal 60, one or more programs (including the client application 60B shown in FIG. 2 and various libraries 60E imported by the client application 60B) that define the operation procedures of this CPU, and a working memory such as a main memory or a cache memory. The details of each of these means 61 to 68 will be described later.

[0048] Furthermore, non-volatile memory such as a hard disk drive (HDD) or solid state drive (SSD) can be used as the client ID / client secret storage means 70. However, since a client ID and client secret are issued to each employee, each employee may write (code) the client ID and client secret issued to them in the program of the client application 60B installed in the client terminal 60 they operate. Details of this storage means 70 will be described later.

[0049] Furthermore, the login employee ID / password storage means 71 temporarily stores the employee ID and password entered by each employee when logging in, and so may be main memory (volatile memory), but may also be non-volatile memory. Details of this storage means 71 will be described later.

[0050] The backend system 80 executes various business processes in response to API requests from API executors (those who actually use the API among the target API users, including employees, and includes not only humans but also systems), and is composed of one or more computers, and is equipped with various backend business processing means 81 that executes various backend business processes (operations α, β, γ, ... shown in Figure 3) (for example, referencing customer information, registering, updating, deleting customer trading data related to financial products, etc.), and backend business processing data storage means 82 that stores various data (customer information, trading information, etc.) required to execute these various backend business processes.

[0051] Here, the back-end business processing means 81 is realized by a central processing unit (CPU) provided inside a computer constituting the back-end system 80, one or more programs that define the operating procedures of this CPU, and working memory such as main memory and cache memory. The back-end business processing data storage means 82 is realized by non-volatile memory such as a hard disk drive (HDD) or solid state drive (SSD).

[0052] <Configuration of Open ID Provider System 20 / Processing Means 20A / Login Processing Means 21>

[0053] The login processing means 21 executes the login authentication process for each employee at the client terminal 60. Specifically, the login processing means 21 receives an employee ID and password (see FIG. 2) entered at the client terminal 60 and transmitted via the network 1, performs login authentication based on whether the received password matches the password stored in the user information storage means 24 (see FIG. 2) in association with the received employee ID, and transmits a login authentication error to the client terminal 60 via the network 1 if they do not match.

[0054] <Configuration of Open ID Provider System 20 / Processing Means 20A / Authorization Code Issuing Means 22>

[0055] The authorization code issuing means 22 receives an authorization code issuance request (including an application ID that identifies the client application 60B (see Figure 2) installed on the client terminal 60) sent from the client terminal 60 via the network 1 by the authorization code issuance request sending means 63, sends a request to the client terminal 60 via the network 1 to send (acquire) the employee ID and password used for terminal login, receives the employee ID and password sent from the client terminal 60 via the network 1, issues an authorization code, associates this authorization code with the received employee ID and stores it in the authorization code issuance information storage means 26, and executes a process of sending the issued authorization code to the client terminal 60 via the network 1.

[0056] <Configuration of Open ID Provider System 20 / Processing Means 20A / Token Issuing Means 23>

[0057] The token issuing means 23 receives a token issuance request (including an authorization code, an application ID, and an application secret) transmitted from the client terminal 60 via the network 1 by the token issuance request transmitting means 65, verifies whether the client application is valid based on whether the application secret stored in the application list storage means 25 in association with the application ID included in the received token issuance request matches the application secret included in the received token issuance request, and further acquires an employee ID from the authorization code issuance information storage means 26 using the authorization code included in the received token issuance request, acquires a username from the user information storage means 24 using the acquired employee ID, issues an ID token including the acquired username and an access token, and transmits the issued ID token and access token to the client terminal 60 via the network 1. Note that the ID token is related to a feature of the present invention that is effectively utilized in the present invention, but the access token is not directly related to the content of the present invention.

[0058] <Configuration of the Open ID Provider System 20 / User Information Storage Means 24, Application List Storage Means 25, and Authorization Code Issuance Information Storage Means 26>

[0059] As shown in Figure 2, the user information storage means 24 stores and associates the employee ID (e.g., AXXXXXXX) that identifies the employee, the username for the open ID provider (e.g., AXXXXXXX@o365daiwa.co.jp, which partially includes the employee ID), the display name (in this embodiment, this is the employee's name), the email address, the name of the company to which the employee belongs, the employee ID (different from the employee ID), the password, etc.

[0060] As shown in FIG. 2, the application list storage means 25 stores, for each client application, an associated application ID and an application secret. There are multiple types of client applications, such as applications X, Y, ….

[0061] As shown in FIG. 2, the authorization code issuance information storage means 26 stores the issued authorization code in association with the employee ID.

[0062] <Configuration of API Infrastructure System 30 / Gateway Server 40 / Processing Means 40A / Preflow Processing Means 41 / URL Matching Means 41A>

[0063] The URL matching means 41A of the prefow processing means 41 receives an API request (the client ID, client secret, and ID token are set in the header) transmitted from the client terminal 60 via the network 1 by the API call means 67, and executes URL matching processing.

[0064] Specifically, the URL matching means 41A checks whether the path (URL) of the API included in the received API request is the path of the API employee usage catalog and whether the HTTP method is other than OPTIONS. Here, the path of the API employee usage catalog is the path when using the data (referred to as a product as shown in FIG. 3) stored in the API employee usage catalog storage means 52, and is described (coded) in the program that realizes the URL matching means 41A. Since there are also catalogs other than the API employee usage catalog, the above conditions are not satisfied in the case of the paths of such catalogs. Also, other than OPTIONS means GET, POST, etc.

[0065] And when the URL matching means 41A satisfies the above conditions, it transfers the process to the employee ID setting means 41B. On the other hand, when the above conditions are not satisfied, it transfers the process to the request syntax / size check means 41E.

[0066] <Configuration of API base system 30 / gateway server 40 / processing means 40A / preflow processing means 41 / employee ID setting means 41B>

[0067] The employee ID setting means 41B of the preflow processing means 41 first, when an ID token is not set in the header of the API request received from the client terminal 60, transmits information indicating that an authentication error has occurred to the client terminal 60 via the network 1. Next, it extracts the employee ID from the user name in the ID token included in the API request (in this embodiment, as shown in FIG. 2, the part before @ is extracted), and executes a process of setting the extracted employee ID in the header of the API request.

[0068] <Configuration of API base system 30 / gateway server 40 / processing means 40A / preflow processing means 41 / token verification means 41C>

[0069] The token verification means 41C of the preflow processing means 41 executes a process (ID token forgery detection process) of verifying whether the ID token included in the API request is issued by the OpenID provider system 20 using the public key and parameters (key ID, algorithm) received from the OpenID provider.

[0070] Specifically, the token verification means 41C first decodes the ID token using the definition (e.g., base64url) used for encoding in the OpenID provider system 20, and makes the two parameters (key ID, algorithm) included in the header of the ID token into a state where the content can be grasped as JSON-formatted data. Here, the value of the key ID indicates the key used to secure the JSON Web Signature (JWS) of the ID token. Also, the algorithm is the signature algorithm. Note that the ID token has each part of a header, a payload, and a signature.

[0071] Then, the token verification means 41C verifies whether the key ID and algorithm stored in the parameter storage means 45 (see FIGS. 1 and 2) match the key ID and algorithm (decoded key ID and algorithm) in the ID token included in the header of the API request, and uses the signature (decoded signature) in the ID token included in the header of the API request and the public key stored in the public key storage means 44 (see FIGS. 1 and 2) to verify whether the ID token was issued by the OpenID provider system 20.

[0072] Also, when the token verification means 41C determines that the ID token was not issued by the OpenID provider system 20, it transmits information indicating that an authentication error has occurred to the client terminal 60 via the network 1.

[0073] <Configuration of API infrastructure system 30 / Gateway server 40 / Processing means 40A / Preflow processing means 41 / Spoofing check API call means 41D: FIG. 3>

[0074] The spoofing check API call means 41D of the preflow processing means 41, together with the spoofing check API execution means 42B of the API definition execution means 42, constitutes the "spoofing check means" in the present invention (the "spoofing check means" described in the claims).

[0075] Specifically, as shown in FIG. 3, the spoofing check API calling means 41D first performs a process of calling the spoofing check API to the spoofing check API execution means 42B, that is, a process of sending a spoofing check API request (in which the client ID, client secret, and employee ID extracted from the user name are set in the header), and also performs a process of receiving a spoofing check API response sent (returned) from the spoofing check API execution means 42B. At this time, the spoofing check API request is executed to obtain the target API user ID (employee ID) stored in the target API user information storage means 54 in association with the client ID set in the header of the original API request (API request from client terminal 60). In other words, in this case, the spoofing check API response returned from the spoofing check API execution means 42B is the target API user ID (employee ID).

[0076] The impersonation check API calling means 41D then verifies that the API user is not impersonating someone else by checking whether or not the API user ID (employee ID) stored in the API user information storage means 54 in association with the client ID set in the header of the original API request (API request from client terminal 60), that is, the employee ID obtained as the impersonation check API response returned from the impersonation check API execution means 42B, matches (confirms that they match) the employee ID set in the header of the original API request (the employee ID extracted from the user name in the ID token by the employee ID setting means 41B).

[0077] In addition, if the impersonation check API calling means 41D determines that the API user is impersonating someone else (if there is no match), it sends information to the client terminal 60 via the network 1 indicating that an authentication error has occurred.

[0078] The correspondence between employee IDs and client IDs is obtained in two ways, and it is sufficient to verify that the correspondences obtained in these two ways match. That is, as a first way, the correspondence between the employee ID extracted from the user name in the ID token set in the header of the original API request (API request from client terminal 60) by employee ID setting means 41B and the client ID set in the header of the original API request (API request from client terminal 60) is obtained. Furthermore, as a second way, the correspondence between the target API user ID (employee ID) as the target API user information stored in target API user information storage means 54 and the client ID is obtained.

[0079] Therefore, the spoofing check API calling means 41D may make an spoofing check API request that obtains a client ID instead of an employee ID as the spoofing check API response returned from the spoofing check API execution means 42B. In other words, the spoofing check API request may be made in order to obtain the client ID that is stored in the API user information storage means 54 in association with the employee ID extracted from the user name in the ID token that was set in the header of the original API request (the API request from the client terminal 60) by the employee ID setting means 41B. In this case, the impersonation check API calling means 41D verifies that the API user is not impersonating someone else by checking whether or not the client ID stored in the API user information storage means 54 in association with the employee ID extracted from the user name in the ID token set in the header of the original API request (API request from client terminal 60) by the employee ID setting means 41B, i.e., the client ID obtained as the impersonation check API response returned from the impersonation check API execution means 42B, matches (confirms that they match) the client ID set in the header of the original API request (API request from client terminal 60).

[0080] Since it is only necessary to verify the correspondence between the employee ID and the client ID obtained by the 2 system, it is equivalent to check whether the employee IDs match or whether the client IDs match. Therefore, in the "impersonation check means" (the "impersonation check means" described in the claims) of the present invention, the description is centered on the matching of employee IDs. However, even when checking the matching of client IDs, it is included in the description of the claims of the present invention.

[0081] Also, the division of labor between the impersonation check API calling means 41D and the impersonation check API execution means 42B is not limited to the division of labor described above. For example, in the above description, the impersonation check API calling means 41D verifies the match of the employee ID (or the client ID). However, the impersonation check API execution means 42B may verify the match of the employee ID (or the client ID) and return the verification result (whether it matches) to the impersonation check API calling means 41D as an impersonation check API response.

[0082] Therefore, the information to be included in the header of the impersonation check API request is, as described above, all of the employee IDs cut out from the client ID, client secret, and username set in the original API request. However, depending on the way of dividing the work between the impersonation check API calling means 41D and the impersonation check API execution means 42B, it may be a part (either the client ID or the employee ID cut out from the username).

[0083] <Configuration of API infrastructure system 30 / gateway server 40 / processing means 40A / preflow processing means 41 / request syntax and size check means 41E>

[0084] The request syntax and size check means 41E of the preflow processing means 41 executes a syntax check and a size check on the API request received from the client terminal 60.

[0085] <Configuration of API Infrastructure System 30 / Gateway Server 40 / Processing Means 40A / API Definition Execution Means 42 / Business API Definition Execution Means 42A>

[0086] Each of the various business API definition execution means 42A in the API definition execution means 42 obtains, from the API employee use catalog storage means 52 of the API management server 50, business API definition data (YAML file) 52A for the business (any one of the businesses α, β, γ,... shown in FIG. 3) requested by the API executor according to the API request that has undergone the processing by the request syntax and size check means 41E, and executes the business processing related to the request of the API executor (set in the API request) according to the obtained business API definition data 52A.

[0087] At this time, as shown in FIG. 3, a plurality of processes (described as processes 1, 2, 3,... in the example of FIG. 3) to be executed by the business API definition execution means 42A are defined in the business API definition data (YAML file) 52A, and since the call of the business processing of the back-end business (any one of the businesses α, β, γ,...) is included therein, the business API definition execution means 42A makes a call of the business processing related to the request of the API executor to the back-end system 80 via the network 1. As a result, as shown in FIG. 3, the business processing by the back-end business processing means 81 (business processing using the data stored in the back-end business processing data storage means 82 shown in FIG. 1) is executed, and the information (for example, customer information, etc.) obtained as the result of the business processing is transmitted from the back-end system 80 to the API post-processing means 43A of the post-flow processing means 43 of the gateway server 40 via the network 1 by the back-end business processing means 81, and further transmitted to the client terminal 60 via the network 1 by the API post-processing means 43A.

[0088] <Configuration of API Infrastructure System 30 / Gateway Server 40 / Processing Means 40A / API Definition Execution Means 42 / Spoof Check API Execution Means 42B: FIG. 3>

[0089] The spoofing check API execution means 42B of the API definition execution means 42, together with the spoofing check API call means 41D of the preflow processing means 41, constitute the "spoofing check means" of the present invention ("spoofing check means" as claimed).

[0090] 3, spoofing check API execution means 42B receives a spoofing check API request from spoofing check API calling means 41D, and executes processing in accordance with spoofing check API definition data 52B stored as a YAML file in API employee usage catalog storage means 52. At this time, spoofing check API execution means 42B transmits a request to API definition data transmission means 51 (see FIG. 1) to acquire spoofing check API definition data 52B, and receives spoofing check API definition data 52B transmitted from API definition data transmission means 51. The impersonation check API definition data 52B of the received Yaml file defines multiple processes (denoted as processes 1, 2, 3, ... in Figure 3) to be executed by the impersonation check API execution means 42B, including a process for obtaining API user information.Therefore, the impersonation check API execution means 42B accesses the API management server 50, receives the API user information (employee ID or client ID, or employee ID and client ID related to the acquisition request by the impersonation check API request) sent from the API user information sending means 53 (see Figure 1), and sends the received API user information to the impersonation check API calling means 41D.

[0091] As already mentioned in the explanation of the impersonation check API calling means 41D, the impersonation check API execution means 42B may verify whether the employee IDs match (or the client IDs match), in which case the verification result (whether there is a match or not) will be sent to the impersonation check API calling means 41D as an impersonation check API response.

[0092] <Configuration of API Infrastructure System 30 / Gateway Server 40 / Processing Means 40A / Post - flow Processing Means 43 / API Post - processing Means 43A>

[0093] Each of the various API post - processing means 43A in the post - flow processing means 43 receives information (for example, customer information, etc.) obtained as a result of the processing of various (businesses α, β, γ,...) business processes (processing by the back - end business processing means 81) transmitted from the back - end system 80 via the network 1, and executes a process of transmitting it to the client terminal 60 via the network 1.

[0094] <Configuration of API Infrastructure System 30 / Gateway Server 40 / Public Key Storage Means 44, Parameter Storage Means 45>

[0095] The public key storage means 44 stores the public key of the OpenID provider received from the OpenID provider system 20 for use in the token verification process by the token verification means 41C.

[0096] The parameter storage means 45 stores parameters (including key ID and algorithm) adopted in the ID token issued by the OpenID provider system 20 for use in the token verification process by the token verification means 41C.

[0097] <Configuration of API Infrastructure System 30 / API Management Server 50 / API Definition Data Transmission Means 51, API Employee Usage Catalog Storage Means 52>

[0098] The API definition data transmission means 51 (see FIG. 1, but omitted from FIGS. 2 and 3) executes a process to retrieve the relevant business API definition data (YAML file) 52A from the business API definition execution means 42A of each type (business α, β, γ, ...) of the API definition execution means 42, and then retrieves the relevant business API definition data 52A (business API definition data 52A for any of the businesses α, β, γ, ... prepared for the employee who is the API implementer) from the API employee usage catalog storage means 52 and transmits it to the business API definition execution means 42A. The business to be executed by the API (any of the businesses α, β, γ, ...) is set in the API request received from the client terminal 60. The employee who is the API implementer (any of employees A, B, ...) is identified by the employee ID set in the API request.

[0099] In addition, in response to a request to acquire impersonation check API definition data (Yamle file) 52B from the impersonation check API execution means 42B of the API definition execution means 42, the API definition data transmission means 51 also executes a process of acquiring the impersonation check API definition data 52B from the API employee usage catalog storage means 52 and transmitting it to the impersonation check API execution means 42B.

[0100] The API employee usage catalog storage means 52 (see Figures 1, 2, and 3) stores data called products (API employee usage products) that can be used by target API users (each employee, each department, each system, etc.) for each target API user. In the example of Figure 3, API employee usage products are prepared for employee A, employee B, J department K section, etc.

[0101] Each API employee use product contains business API definition data 52A for business operations α, β, γ, ... that can be used by the target API users (each employee, each department, each system, etc.), and impersonation check API definition data 52B, both of which are stored in a Yaml file.

[0102] <Configuration of API Base System 30 / API Management Server 50 / API Target User Information Sending Means 53 and API Target User Information Storage Means 54>

[0103] API Target User Information Sending Means 53 (see Figure 1, but not shown in Figures 2 and 3) responds to the acquisition request for API target user information from the spoofing check API execution means 42B of the API definition execution means 42, and transmits the API target user ID (employee ID) stored in the API target user information storage means 54 in association with the client ID sent from the spoofing check API execution means 42B to the spoofing check API execution means 42B. It executes the process of doing so.

[0104] Also, the API target user information sending means 53 may execute a process of transmitting the client ID stored in the API target user information storage means 54 in association with the employee ID sent from the spoofing check API execution means 42B to the spoofing check API execution means 42B, or extract a combination of the employee ID and the client ID including the employee ID or the client ID sent from the spoofing check API execution means 42B from the API target user information storage means 54, and execute a process of transmitting the extracted combination of the employee ID and the client ID (correct combination) to the spoofing check API execution means 42B.

[0105] API Target User Information Storage Means 54 (see Figures 1, 2, and 3) stores, as API target user information, the client ID and client secret paid out to the employee of the employee ID in association with the API target user ID (employee ID).

[0106] <Configuration of Client Terminal 60 / Processing Means 60A / Terminal Login Means 61>

[0107] 2, the terminal login means 61 accepts an employee ID and password input by an employee for terminal login, and executes a process of transmitting the accepted employee ID and password to the open ID provider system 20 via the network 1. If the authentication process by the login processing means 21 in the open ID provider system 20 is successful, the terminal login means 61 temporarily stores the employee ID and password used for login in the login employee ID / password storage means 71. On the other hand, if the authentication process by the login processing means 21 fails, the terminal login means 61 receives login authentication error information transmitted from the open ID provider system 20 via the network 1, and displays that information on the screen of the client terminal 60.

[0108] <Configuration of Client Terminal 60 / Processing Means 60A / Client ID / Client Secret Input Accepting Means 62>

[0109] The client ID / client secret input receiving means 62 is realized by the client application 60B (see FIG. 2), receives the input of a client ID and a client secret by an employee, and stores the received client ID and client secret in the client ID / client secret storage means 70. This client ID and client secret are issued to each employee by the API infrastructure system 30. Each employee may write (code) the client ID and client secret issued to them in the program of the client application 60B installed on the client terminal 60 they operate.

[0110] <Configuration of Client Terminal 60 / Processing Means 60A / Authorization Code Issuance Request Transmission Means 63>

[0111] The authorization code issuance request sending means 63 is realized by the client application 60B (see FIG. 2) that has imported the authorization code issuance request library 60F, and executes the process of sending an authorization code issuance request (including the application ID for the client application 60B) to the open ID provider system 20 via the network 1 from the client terminal 60 to which the employee has logged in using their employee ID and password. This application ID is written in the program of the client application 60B.

[0112] The application ID and application secret for the client application referred to in this application are issued by the open ID provider system 20 to identify the client application, and are generally also referred to as the client ID and client secret. However, in this application, since there are also client IDs and client secrets issued to each employee by the API infrastructure system 30, they are referred to as the application ID and application secret to distinguish them from these names and avoid confusion.

[0113] <Configuration of client terminal 60 / processing means 60A / authorization code receiving means 64>

[0114] The authorization code receiving means 64 executes a process of receiving the authorization code transmitted by the authorization code issuing means 22 from the open ID provider system 20 via the network 1 .

[0115] <Configuration of Client Terminal 60 / Processing Means 60A / Token Issuance Request Transmission Means 65>

[0116] The token issuance request sending means 65 is realized by the client application 60B (see FIG. 2) that has imported the token issuance request library 60G, and executes a process of sending a token issuance request including the authorization code received by the authorization code receiving means 64, as well as the application ID and application secret, from the client terminal 60 to the open ID provider system 20 via the network 1. The application ID and application secret are described in the program of the client application 60B.

[0117] <Configuration of client terminal 60 / processing means 60A / token receiving means 66>

[0118] The token receiving means 66 executes a process of receiving the ID token (including a user name that partially includes an employee ID) and access token sent by the token issuing means 23 from the open ID provider system 20 via the network 1.

[0119] <Configuration of client terminal 60 / processing means 60A / API calling means 67>

[0120] The API calling means 67 is realized by the client application 60B (see Figure 2) that has imported the API calling library 60H, and creates an API request that includes the client ID and client secret that are received by the client ID / client secret input receiving means 62 and stored in the client ID / client secret storage means 70, or that are written within the program of the client application 60B (see Figure 2), and the ID token (including a user name that partially includes an employee ID) received by the token receiving means 66, and executes the process of transmitting the created API request from the client terminal 60 to the gateway server 40 of the API infrastructure system 30 via the network 1.

[0121] Furthermore, when information indicating that an authentication error has occurred is sent from the gateway server 40 via the network 1, the API calling means 67 receives the information and displays it on the screen of the client terminal 60.

[0122] <Configuration of client terminal 60 / processing means 60A / API response receiving means 68>

[0123] The API response receiving means 68 executes a process of receiving an API response (data indicating the contents of the business processing requested in the API request by the API calling means 67) sent via the network 1 from the API post-processing means 43A of the post-flow processing means 43 of the API infrastructure system 30.

[0124] <Configuration of client terminal 60 / processing means 60A / client ID / client secret storage means 70, login employee ID / password storage means 71>

[0125] The client ID / client secret storage means 70 stores the client ID and client secret input from the employee received by the client ID / client secret input receiving means 62. However, the client ID and client secret may be written (coded) in the program of the client application 60B (see FIG. 2).

[0126] The login employee ID / password storage means 71 temporarily stores the employee ID and password used by the employee when logging in to the terminal.

[0127] <Flow of the process to prevent spoofing when an employee executes an API: Figures 4 and 5>

[0128] In this embodiment, as shown in FIGS. 4 and 5, the spoofing prevention system 10 performs the spoofing prevention process when an employee executes an API as follows.

[0129] 4, first, an employee who is an API user inputs an employee ID and password to log in to a client terminal 60 (step S1). This input is accepted by the terminal login means 61, and the input employee ID and password are sent to the open ID provider system 20 via the network 1. In the open ID provider system 20, the login processing means 21 performs authentication processing for the login using information stored in the user information storage means 24 (step S2). The login processing means 21 sends the authentication result to the client terminal 60 via the network 1, and if the login authentication is successful, the terminal login means 61 temporarily stores the employee ID and password used for the terminal login in the login employee ID / password storage means 71.

[0130] Next, the client ID and client secret input receiving means 62 receives input of the client ID and client secret by the employee who is the API executor, and stores the received client ID and client secret in the client ID and client secret storage means 70 (step S3). Note that if the client ID and client secret are written (coded) within the program of the client application 60B (see FIG. 2), there is no need to input them.

[0131] Then, the authorization code issuance request sending means 63 sends an authorization code issuance request (including the application ID for the client application 60B (see Figure 2)) from the client terminal 60 to the open ID provider system 20 via the network 1 (step S4).

[0132] In the open ID provider system 20, the authorization code issuing means 22 receives the authorization code issuance request (including the application ID that identifies the client application 60B (see Figure 2) installed on the client terminal 60) sent from the client terminal 60 via the network 1 (step S5), and sends a request to send (acquire) the employee ID and password used to log in to the client terminal 60 via the network 1 (step S6).

[0133] In the client terminal 60, the authorization code issuance request sending means 63 receives a request to send (acquire) the employee ID and password (step S7), and sends the employee ID and password used at the time of login, which are temporarily stored in the login employee ID / password storage means 71, to the open ID provider system 20 via the network 1 (step S8).

[0134] In the open ID provider system 20, the authorization code issuing means 22 receives the employee ID and password (step S9), issues an authorization code, associates this authorization code with the received employee ID and stores it in the authorization code issuance information storage means 26, and also transmits the issued authorization code to the client terminal 60 via the network 1 (step S10). In the client terminal 60, the authorization code receiving means 64 receives the authorization code transmitted from the open ID provider system 20 (step S11).

[0135] Next, the token issuance request sending means 65 sends a token issuance request including the received authorization code, the application ID, and the application secret from the client terminal 60 to the open ID provider system 20 via the network 1 (step S12).

[0136] In the open ID provider system 20, the token issuing means 23 receives a token issuance request (including an authorization code, an application ID, and an application secret) sent from the client terminal 60 (step S13), and verifies whether the client application is valid by checking whether the application secret stored in the application list storage means 25 in association with the application ID included in the received token issuance request matches the application secret included in the received token issuance request (step S14). Furthermore, the token issuing means 23 acquires an employee ID from the authorization code issuance information storage means 26 using the authorization code included in the received token issuance request, acquires a username from the user information storage means 24 using the acquired employee ID, issues an ID token and an access token including the acquired username, and transmits the issued ID token and access token to the client terminal 60 via the network 1 (step S14).

[0137] In the client terminal 60, the token receiving means 66 receives the ID token (including the user name that partially includes the employee ID) and the access token sent from the open ID provider system 20 (step S15).

[0138] Thereafter, the client terminal 60 uses the API calling means 67 to create an API request including the client ID and client secret that have been received by the client ID / client secret input receiving means 62 and stored in the client ID / client secret storage means 70, or that are written within the program of the client application 60B (see Figure 2), and the ID token (including a username that partially includes the employee ID) received by the token receiving means 66, and sends the created API request to the gateway server 40 of the API infrastructure system 30 via the network 1 (step S16).

[0139] In the gateway server 40 of the API-based system 30, the URL matching means 41A of the preflow processing means 41 receives the API request (the header contains the client ID, client secret, and ID token) sent from the client terminal 60 (step S17 in Figure 4), and executes the URL matching process shown in Figure 15.

[0140] In FIG. 15, the URL matching means 41A checks whether the API path (URL) included in the received API request is the path of the API employee usage catalog and whether the HTTP method is other than OPTIONS (step S18 in FIG. 15).

[0141] If the URL matching means 41A determines that the above conditions are met (step S19), the process proceeds to processing by the employee ID setting means 41B (step S20). On the other hand, if the URL matching means 41A determines that the above conditions are not met (step S19), the process proceeds to processing by the request syntax / size checking means 41E (step S32).

[0142] If it is determined that the above conditions are met (step S19), the employee ID setting means 41B first determines whether an ID token is set in the header of the API request received from the client terminal 60 (step S20), and if it is not set, sends information to the client terminal 60 via the network 1 that an authentication error has occurred (step S21).If the client terminal 60 receives information to the effect that an authentication error has occurred sent from the gateway server 40 by the API calling means 67, the client terminal 60 displays this information on the screen of the client terminal 60 (step S22).

[0143] Next, if it is determined that an ID token has been set in the received API request (step S20), the employee ID setting means 41B cuts out the employee ID from the user name in the ID token included in the API request (in this embodiment, the part before @ is cut out, as shown in Figure 2), and sets the cut employee ID in the header of the API request (step S23).

[0144] Next, the token verification means 41C uses the public key and parameters (key ID, algorithm) received from the open ID provider to perform a process (ID token tamper detection process) to verify whether the ID token included in the API request was issued by the open ID provider system 20 (step S24).

[0145] Specifically, the token verification means 41C decodes the ID token and verifies whether the key ID and algorithm stored in the parameter storage means 45 (see FIGS. 1 and 2) match the key ID and algorithm (decoded key ID and algorithm) in the ID token included in the header of the API request (step S24).The token verification means 41C also verifies whether the ID token was issued by the open ID provider system 20 by using the signature (decoded signature) in the ID token included in the header of the API request and the public key stored in the public key storage means 44 (see FIGS. 1 and 2) (step S24).

[0146] Then, if the token verification means 41C determines that the ID token is not issued by the open ID provider system 20 (step S25), it transmits information that an authentication error has occurred to the client terminal 60 via the network 1 (step S26). When the client terminal 60 receives the information that an authentication error has occurred transmitted from the gateway server 40 by the API calling means 67, it displays the information on the screen of the client terminal 60 (step S27).

[0147] Then, if it is determined that the ID token was issued by the open ID provider system 20 (step S25), the spoofing check API calling means 41D of the preflow processing means 41 and the spoofing check API execution means 42B of the API definition execution means 42 execute the spoofing check API to perform the spoofing check processing (step S28). The processing contents of the spoofing check API calling means 41D and the spoofing check API execution means 42B have already been described in detail in the explanation of their respective configurations, so a detailed explanation will be omitted here.

[0148] Specifically, in the impersonation check process by these means 41D, 42B, the target API user ID (employee ID) stored in the target API user information storage means 54 in association with the client ID set in the header of the original API request (API request from client terminal 60) is checked to verify that the target API user ID (employee ID extracted from the user name in the ID token by the employee ID setting means 41B) set in the header of the original API request matches (confirms that they match) to verify that the API user is not impersonating someone else (step S28).

[0149] Furthermore, the spoofing check API calling means 41D determines whether or not the comparison and verification results in a match (step S29), and if it is determined that the API user is spoofing (if there is no match), it sends information to the effect that an authentication error has occurred to the client terminal 60 via the network 1 (step S30). When the client terminal 60 receives information to the effect that an authentication error has occurred sent from the gateway server 40 by the API calling means 67, it displays this information on the screen of the client terminal 60 (step S31).

[0150] Next, the request syntax / size check means 41E checks the syntax and size of the API request received from the client terminal 60 (step S32).

[0151] Thereafter, the business API definition execution means 42A of the API definition execution means 42 calls the business API (sends a business API request) via the network 1 to the backend business processing means 81 of the backend system 80 in accordance with the business API definition data (YAML file) 52A of the business requested by the employee who is the API user (one of the businesses α, β, γ, ... shown in Figure 3) stored in the API employee usage catalog storage means 52, and executes the business API by having the backend business processing means 81 execute the business processing using the data stored in the backend business processing data storage means 82 (see Figure 1) (step S33).

[0152] Next, the API post-processing means 43A of the postflow processing means 43 receives the business API response (information obtained as a result of business processing by the backend business processing means 81) transmitted from the backend business processing means 81 of the backend system 80 via the network 1, and transmits the received business API response (business processing result) to the client terminal 60 via the network 1 (step S33). In the client terminal 60, the API response receiving means 68 receives the business processing result from the gateway server 40 (step S34). This completes a series of processes related to API execution by the employee.

[0153] <Processing flow to prevent fraudulent activity by employee B impersonating employee A>

[0154] If employee B fraudulently impersonates employee A and executes an API, the process to prevent this impersonation is as follows:

[0155] In step S1 of Fig. 4, employee B, the fraudster, logs in to the client terminal 60 that he or she operates using his or her own employee ID and password. Login authentication by the login processing means 21 of the open ID provider system 20 (step S2 of Fig. 4) is successful because the combination of employee ID and password is correct (because it is correct as the combination for employee B).

[0156] In step S3 of FIG. 4, employee B, the fraudster, inputs the client ID and client secret of another person (employee A) that he / she has obtained through fraudulent means and stores them in the client ID / client secret storage means 70 of the client terminal 60 that he / she (employee B) operates, or rewrites the client ID and client secret written in the client application 60B (see FIG. 2) installed on the client terminal 60 that he / she (employee B) operates with the client ID and client secret of the other person (employee A).

[0157] In step S4 of FIG. 4, an application ID is included in the authorization code issuance request, and this application ID is the application ID for the client application 60B installed on the client terminal 60 operated by the employee (employee B).

[0158] In step S8 of Figure 4, the employee ID and password used when logging in to the terminal, which are stored in the login employee ID / password storage means 71, are sent to the open ID provider system 20, and these employee ID and password are the employee ID and password of employee B, the fraudster.

[0159] In step S10 of FIG. 4, the correspondence between the issued authorization code and the employee ID is stored in the authorization code issuance information storage means 26, and the employee ID at this time is the employee ID of employee B, the fraudster.

[0160] In step S12 of FIG. 4, the authorization code, application ID, and application secret are included in the token issuance request, and the application ID and application secret at this time are the application ID and application secret for client application 60B installed on client terminal 60 operated by employee B, the fraudster.

[0161] 4, the application ID and the application secret are used to verify whether the client is authentic, using the combination of the application ID and the application secret stored in the application list storage means 25. Since the combination of the application ID and the application secret is correct (because it is correct as a combination for the client application 60B installed on the client terminal 60 operated by employee B), no fraud is detected in this verification.

[0162] 4, an employee ID is obtained from the authorization code issuance information storage means 26 using the authorization code included in the token issuance request, and the employee ID obtained at this time is the employee ID of employee B, the fraudster. Furthermore, a username for the open ID provider is obtained from the user information storage means 24 using the obtained employee ID (employee B's employee ID), and this username is the username of employee B, and partially contains employee B's employee ID. Then, an ID token and an access token including this username (partially containing employee B's employee ID) are issued.

[0163] In step S16 of Fig. 4, the client ID, client secret, and ID token are set in the header of the API request, but the client ID and client secret at this time are the client ID and client secret of another person (employee A) that were obtained through fraudulent means. The ID token also includes the username of employee B, which partially contains employee B's employee ID.

[0164] 5, the employee ID (employee ID of employee B) is extracted from the username (employee B's username) in the ID token included in the API request, and the extracted employee ID (employee ID of employee B) is set in the header of the API request. As a result, the header of the API request contains the employee ID of employee B, the fraudster, and the client ID and client secret of another person (employee A) who was obtained through fraudulent means.

[0165] In step S24 of Figure 5, the ID token included in the API request is verified using the public key and parameters (key ID, algorithm) received from the open ID provider. However, if employee B, the fraudster, has not tampered with the ID token, the fraud will not be detected by this ID token tampering detection process.

[0166] In the impersonation check process in step S28 of Figure 5, the API user target ID (employee ID of employee A) stored in the API user target information storage means 54 in association with the client ID set in the header of the API request (client ID of another person (employee A) obtained through fraudulent means) does not match the employee ID set in the header of the API request (employee ID of employee B extracted from the username of employee B in the ID token), and so it is determined for the first time that impersonation is occurring.

[0167] <Effects of this embodiment>

[0168] This embodiment has the following advantages: In other words, by utilizing OpenID Connect, a specification for issuing ID tokens, the spoofing prevention system 10 can check whether the client ID at the time of API execution belongs to the person executing the API (check for spoofing by an employee) by using an ID token issued by the open ID provider system 20 as information other than the client ID and client secret.

[0169] Note that issuing an ID token in the open ID provider system 20 is an existing process that conforms to the OpenID Connect specifications, but using the issued ID token to perform processing to prevent impersonation by employees and setting information for this purpose in the ID token are unique features of the present invention.

[0170] That is, when the token issuing means 23 provided in the open ID provider system 20 receives a token issuance request from the client terminal 60, it acquires the employee ID from the authorization code issuance information storage means 26 using the authorization code included in the received token issuance request, acquires a username (a username for the open ID provider that partially includes the employee ID) from the user information storage means 24 using the acquired employee ID, issues an ID token including the acquired username, and sends the issued ID token to the client terminal 60, so that the information necessary to verify whether or not impersonation is occurring can be set in the ID token.

[0171] Furthermore, when an employee executes an API, the employee creates an API request including the client ID, client secret, and ID token using the API calling means 67 on the client terminal 60 into which the employee has logged in, and sends the created API request from the client terminal 60 to the API infrastructure system 30, so that the information necessary to verify whether or not impersonation is taking place can be set within the API request.

[0172] Furthermore, in the API infrastructure system 30, the employee ID setting means 41B extracts the employee ID from the username for the open ID provider (this username partially contains the employee ID) included in the ID token set in the API request received from the client terminal 60, and sets the extracted employee ID in the API request, thereby making it possible to prepare the information included in the API request in a state that is easy to use for verifying whether or not impersonation is occurring.

[0173] Within the API infrastructure system 30, the impersonation check API calling means 41D of the preflow processing means 41, which constitutes the impersonation check means, and the impersonation check API execution means 42B of the API definition execution means 42 determine whether the employee ID stored in the API user information storage means 54 in association with the client ID set in the API request matches the employee ID set in the API request (the employee ID extracted from the username for the open ID provider), and if they do not match, it can be determined that impersonation of another employee is occurring.

[0174] Therefore, even if a fraudulent employee who is impersonating another employee attempts to execute an API using his or her own employee ID and the fraudulently obtained client ID and client secret of the other employee, the fraudulent act will be discovered by the impersonation check means. In other words, the employee ID set in the API request is the employee ID of the fraudulent employee who logged in to the terminal, while the employee ID stored in the API user information storage means in association with the fraudulently obtained client ID of the other employee is the employee ID of the other employee, so they do not match and the act of impersonation can be detected.

[0175] This prevents fraudulent employees from fraudulently obtaining customer information stored in the backend system 80, and in the case of APIs that perform update-related business processes, prevents fraudulent employees from fraudulently registering, updating, or deleting data.

[0176] Furthermore, even if the number of API users to whom client IDs and client secrets have been issued increases, no additional maintenance is required to prevent spoofing.

[0177] Furthermore, the employee ID setting means 41B is configured to send an authentication error to the client terminal 60 if an ID token is not set in the API request, so that it can determine that information necessary for the impersonation check processing by the impersonation check API calling means 41D and the impersonation check API execution means 42B is missing, and if this information is missing, it can prevent the execution of an unauthorized API before proceeding to the impersonation check processing.

[0178] Furthermore, since the impersonation prevention system 10 is equipped with a token verification means 41C, it is possible to verify whether the ID token was issued by the open ID provider system 20, thereby further improving security functions.

[0179] <Transformation Form>

[0180] 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.

[0181] For example, in the above embodiment, the employee ID setting means 41B cuts out the entire part before the @ symbol in the username for the open ID provider as the part corresponding to the employee ID, as in the user information storage means 24 shown in Figure 2, but the part to be cut out (i.e., the part corresponding to the employee ID) is not limited to this position, and it is sufficient if the username contains the employee ID and that part is cut out.

[0182] Furthermore, in the above embodiment, the spoofing check API calling means 41D of the preflow processing means 41 was configured to send spoofing check API requests and receive spoofing check API responses between the spoofing check API execution means 42B of the API definition execution means 42, but the "spoofing check means" in the present invention (the "spoofing check means" described in the claims) is not limited to this configuration and may also be configured not to use the spoofing check API (a configuration in which the preflow processing means 41 is provided with an "spoofing check means" that includes the functions of the spoofing check API execution means 42B). [Industrial Applicability]

[0183] As described above, the impersonation prevention system and program of the present invention are suitable for use, for example, in situations where each employee uses a business API from a client terminal equipped with a client application to access various data in a back-end system and perform business processing. [Explanation of symbols]

[0184] 1 Network 10. Anti-spoofing system 20 Open ID Provider System 22 Authorization Code Issuance Method 23 Token Issuance Method 24 User information storage means 25 Application list storage means 26 Authorization code issuance information storage means 30 API-based system 40 Gateway Server 41B Employee ID setting method 41C Token Validation Method 41D Spoofing check API calling means constituting the "spoofing check means" 42B Spoofing check API execution means constituting the "spoofing check means" 44 Public key storage means 45 Parameter storage means 50 API management servers 54 API user information storage means 60 client terminals 63 Authorization Code Issuance Request Transmission Method 64 Authorization Code Receiving Means 65 Token issuance request transmission method 66 Token Receiving Method 67 API call method 80 Backend Systems

Claims

1. An impersonation prevention system configured by a computer that executes a process to prevent an employee from impersonating another employee when using an API (Application Programming Interface), a user information storage means for storing an employee ID for identifying each employee in an open ID provider system that issues ID tokens, in association with a user name for the open ID provider that includes a portion of the employee ID; an API user information storage means for storing the employee ID and a client ID and client secret issued to each employee in association with each other within an API-based system that accepts and manages the use of APIs by employees; an authorization code issuance request sending means for sending an authorization code issuance request to the open ID provider system via a network from a client terminal to which the employee has logged in using the employee ID; an authorization code issuing means, within the open ID provider system that has received the authorization code issuance request, that receives the employee ID used for the login from the client terminal via a network, issues an authorization code, associates the authorization code with the employee ID, stores the authorization code in an authorization code issuance information storage means, and transmits the issued authorization code to the client terminal via a network; an authorization code receiving means in the client terminal for receiving an authorization code transmitted from the open ID provider system via a network by the authorization code issuing means; a token issuance request sending means for sending a token issuance request including the authorization code received by the authorization code receiving means from the client terminal to the open ID provider system via a network; a token issuing means, within the open ID provider system that has received the token issuance request, for acquiring the employee ID from the authorization code issuance information storage means using the authorization code included in the token issuance request, acquiring the user name from the user information storage means using the acquired employee ID, issuing an ID token including the acquired user name, and transmitting the issued ID token to the client terminal via a network; a token receiving means in the client terminal for receiving the ID token transmitted from the open ID provider system via a network by the token issuing means; an API calling means for receiving input via a client application installed on the client terminal, creating an API request including a client ID and a client secret stored in the client terminal or described in a program of the client application, and the ID token received by the token receiving means, and transmitting the created API request from the client terminal to the API infrastructure system via a network; an employee ID setting means, within the API-based system, for extracting the employee ID from the user name included in the ID token set in the received API request and setting the extracted employee ID in the API request; an impersonation check means for determining whether the employee ID stored in the API user information storage means in association with the client ID set in the API request matches the employee ID set in the API request within the API-based system, and determining that impersonation of another employee is being attempted if they do not match; A spoofing prevention system comprising:

2. The employee ID setting means If the ID token is not set in the API request received from the client terminal, the system is configured to also execute a process of transmitting information indicating that an authentication error has occurred to the client terminal via a network.

2. The spoofing prevention system according to claim 1.

3. The API-based system is a parameter storage means for storing a key ID and an algorithm; a public key storage means for storing a public key of the open ID provider system; a token verification means for verifying whether the key ID and the algorithm stored in the parameter storage means match the key ID and the algorithm in the ID token included in the header of the API request, and for verifying whether the ID token is issued by the open ID provider system by using the signature in the ID token included in the header of the API request and the public key stored in the public key storage means; 3. The spoofing prevention system according to claim 2, further comprising:

4. A program for causing a computer to function as the spoofing prevention system according to any one of claims 1 to 3.

Images