Server system and method for detecting unauthorized users

Abstract

To achieve detection of an unauthorized user, and improve security of a server system.SOLUTION: A server system includes a client 120 for receiving access from a user, and an authorization server 130 for receiving assignment from the client 120, and acting as a server for processing a request of authorization and / or approval of the user. The server receives the request, acquires an identifier representing the user, stores the acquired identifier in a response to the request, and the client 120 receives the response from the user, acquires an identifier representing the user, compares the acquired identifier with the identifier stored in the response, and determines whether or not the transmission source of the response is a correct user.SELECTED DRAWING: Figure 2

Description

[Technical field]

[0001] The present invention relates to a server system and a method for detecting an unauthorized user. [Background technology]

[0002] Conventionally, known authentication and authorization technologies include OAuth 2.0 (RFC6749), OpenID Connect Core 1.0 authorization code flow, and SAML SP-initiated. In addition, a technology for selecting an appropriate authorization server when multiple authorization servers exist is described in JP 2020-53100 A (Patent Document 1). This publication states that "the authorization server has a first transmission means for identifying a first authorization server where user information is located upon receiving an authorization request and transmitting an authentication request to the first authorization server, the first authorization server authenticates the user, and a second transmission means for transmitting an authorization response to the client together with information indicating the first authorization server where the user information is located as a transmission destination, the client identifies the first authorization server by a second identification means based on the authorization response, and transmits a token request to the first authorization server to request an authorization token for accessing a resource server, and the first authorization server has an issuing means for issuing an authorization token in response to the token request." [Prior art documents] [Patent documents]

[0003] [Patent Document 1] JP 2020-53100 A Summary of the Invention [Problem to be solved by the invention]

[0004] Conventional technologies could not prevent unauthorized users from logging in to a client as a legitimate user. Taking OAuth as an example, there was a problem in which a user (unauthorized user) other than the user who was authenticated and authorized (consented) by the authorization server could log in to the client. Thus, conventional technologies had insufficient security against unauthorized access.

[0005] Therefore, an object of the present invention is to realize detection of unauthorized users and improve the security of a server system. [Means for solving the problem]

[0006] In order to achieve the above-mentioned object, one representative server system of the present invention comprises a client that accepts access from a user, and a server that receives delegation from the client and processes authentication and / or authorization requests of the user, wherein the server receives the request, obtains an identifier representing the user and stores it in a response to the request, and the client receives the response from the user, obtains an identifier representing the user, and compares the obtained identifier with the identifier stored in the response to determine whether the response has been sent by a valid user. Furthermore, one representative unauthorized user detection method of the present invention is a method for detecting unauthorized users in a server system having a client that accepts access from a user and a server that receives delegation from the client and processes authentication and / or authorization requests of the user, characterized in including a step in which the server receives the request, obtains an identifier representing the user, and stores the identifier in a response to the request, and a step in which the client receives the response from the user, obtains an identifier representing the user, and compares the obtained identifier with the identifier stored in the response to determine whether the source of the response is a valid user. Effect of the Invention

[0007] According to the present invention, it is possible to detect unauthorized users and improve the security of a server system. Problems, configurations and effects other than those described above will become apparent from the following description of the embodiments. [Brief description of the drawings]

[0008] [Figure 1] Explanation of basic authentication and authorization processing [Diagram 2] FIG. 1 is an explanatory diagram of authentication and authorization processing by the system of the first embodiment. [Diagram 3] Diagram of blocking unauthorized access [Figure 4] System element diagram [Diagram 5] Overall system configuration [Figure 6] Flowchart showing the processing procedure of the authorization server [Figure 7] Flowchart showing client processing steps [Figure 8] Diagram of data managed by the system [Figure 9] Data usage diagram [Figure 10] Data management diagram DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0009] Hereinafter, the embodiments will be described with reference to the drawings. EXAMPLES

[0010] Figure 1 is an explanatory diagram of the basic process of authentication and authorization. This figure shows a specific example of the authorization code flow of OAuth 2.0 and OIDC Core 1.0. A user accesses a client 120 via a browser 110 of a user terminal. It is assumed here that the client 120 is requesting the provision of data stored in a resource server 140.

[0011] The client 120 delegates user authentication and authorization to the authorization server 130 (1). Specifically, the client 120 redirects the browser 110 to the authorization server 130. As a result, the browser 110 sends an authorization request to the authorization server 130.

[0012] Upon receiving the authorization request, the authorization server 130 executes authentication and authorization processing (2). Specifically, the authorization server 130 transmits a screen for accepting input of login information (login screen) and a screen for accepting confirmation input (consent screen) to the browser 110. The browser 110 displays the login screen and the consent screen and accepts input by the user. The browser 110 transmits the accepted data to the authorization server 130. The authorization server 130 uses the data received from the browser 110 to authenticate and authorize the user.

[0013] The authorization server 130 returns the result of the authentication and authorization to the client 120 as an authorization response (3). Specifically, the authorization server 130 redirects the client 120 to the browser 110. As a result, the browser 110 sends the authorization response to the client 120.

[0014] The client 120 transmits a token request to the authorization server 130 and receives a token response from the authorization server 130. After that, the client 120 transmits an API (Application Programming Interface) request to the resource server 140. The resource server 140 provides data to the client 120 in the API response.

[0015] 1, it is not possible to confirm that the user who logged in in the authentication and authorization process (2) is the same as the user who returned the result in the result return process (3). Therefore, in the system of this embodiment, an identifier representing the user is obtained to determine whether the user in the authentication and authorization process (2) is the same as the user in the result return process (3).

[0016] Fig. 2 is an explanatory diagram of authentication and authorization processing by the system of the embodiment 1. In the authentication and authorization processing (2) in Fig. 2, the browser 110 transmits a client certificate together with the user input data on the login screen and the consent screen to the authorization server 130. The authorization server 130 stores the hash value of the client certificate in the authorization response.

[0017] In the result return process (3) in Fig. 2, the client 120 receives the authorization response and also acquires the hash value of the client certificate from the browser 110. The client 120 compares the client certificate acquired from the browser 110 with the hash value of the client certificate included in the authorization response. If the comparison results in an identical connection, the client 120 determines that the access is from a valid user and provides the data of the resource server 140.

[0018] In this way, the system of the first embodiment obtains data related to the client certificate in the authentication and authorization process (2) and the result return process (3), and compares them. The client certificate is an example of an identifier that represents a user. The identifier that represents a user uses data that can be used as a user credential, such as a client certificate, and that cannot be obtained by a phishing attack. For example, in the case of a client certificate, even if a user is phished and directed to a fake site prepared by an attacker, the attacker cannot steal the client's private key. For this reason, an attacker cannot pose as a legitimate user and present a client certificate to the client or the authorization server. The identifier that represents a user may be an IC card identification number.

[0019] 3 is an explanatory diagram of blocking unauthorized access. An attacker, who is an unauthorized user, accesses the client 120 via a browser on the attacker's user terminal. The client 120 delegates user authentication and authorization to the authorization server 130. Specifically, the client 120 redirects the attacker's browser to the authorization server 130 as the destination. The attacker stops processing at this point and obtains an authorization request. Then, the attacker sends an email with the authorization request set as a hyperlink to the legitimate user. When the legitimate user opens the email and clicks the hyperlink, the browser 110 sends the authorization request to the authorization server 130.

[0020] Upon receiving the authorization request, the authorization server 130 executes authentication and authorization processing. Specifically, the authorization server 130 transmits to the browser 110 a screen for accepting input of login information (login screen) and a screen for accepting confirmation input (consent screen). The browser 110 displays the login screen and the consent screen, and accepts input by a legitimate user. The browser 110 transmits the accepted data to the authorization server 130. The authorization server 130 performs authentication and authorization of the user using the data received from the browser 110. In other words, this authentication and authorization is performed by the legitimate user.

[0021] The authorization server 130 returns the result of authentication and authorization to the client 120 as an authorization response. Specifically, the authorization server 130 redirects the client 120 to the browser 110. As a result, the browser 110 sends the authorization response to the client 120. Here, an attacker, who is an unauthorized user, acts as a man in the middle to stop the process and unauthorizedly obtain the authorization response.

[0022] An attacker attempts unauthorized access by sending a fraudulently obtained authorization response to the client 120. If the basic processing shown in FIG. 1 is performed, the client 120 will not be able to detect that the user has been changed, and the attacker will be able to gain access successfully. 3, however, authorization server 130 stores the hash value of the client certificate acquired from browser 110 as data in the authorization response. Then, client 120 acquires the client certificate at the TCP layer when the browser sends the authorization response, and compares the hash value of the client certificate included as data in the authorization response with the client certificate sent at the TCP layer when the authorization response is sent. If an attacker has sent the authorization response, the client certificate cannot be acquired, or the client certificates do not match. For this reason, client 120 can determine that the access is from an unauthorized user and block the access.

[0023] Figure 4 is an explanatory diagram of system elements, taking OAuth 2.0 and OIDC Core 1.0 as examples. The browser is a browser used by a user. The user accesses the client and the authorization server via the browser. The client provides services to the user. The client delegates user authentication to the authorization server. The client also authenticates the user using a token issued by the authorization server. In some cases, the client makes an API call using the token to obtain the user's resources (information) from the resource server. The authorization server authenticates the user, obtains consent if necessary, and issues a token to the client. The resource server holds user resources (information). The resource server publishes this information via an API. The resource server also controls access using tokens issued by the authorization server. Note that the resource server is not essential for this system.

[0024] Furthermore, in the system of this embodiment, the authorization server has a function of acquiring an identifier representing a user and storing it in an authorization response, and the client has a function of acquiring an identifier representing a user and comparing it with the identifier stored in the authorization response to determine whether the user is a legitimate user.

[0025] FIG. 5 is a diagram showing the overall system configuration. The browser 110 runs on a user's terminal. The client 120 is a computer having a CPU (Central Processing Unit) 121, a memory 122, a storage 123, and a communication interface 124. Specifically, the CPU 121 reads out a predetermined program from the storage 123, loads it into the memory 122, and executes it sequentially to realize various functions of the client 120. In addition, the communication interface 124 communicates with the browser 110 and the authorization server 130. The authorization server 130 is a computer having a CPU 131, a memory 132, a storage 133, and a communication interface 134. Specifically, the CPU 131 reads a predetermined program from the storage 133, expands it in the memory 132, and executes it sequentially to realize various functions of the authorization server 130. In addition, the communication interface 134 communicates with the browser 110 and the client 120.

[0026] 6 is a flowchart showing the processing procedure of the authorization server 130. The authorization server 130 sequentially executes the following steps S201 to S206. Step S201: The authorization server 130 acquires an identifier ID1 representing a user from a request received when authenticating a user or acquiring consent from the user. Then, the process proceeds to step S202. Step S202: The authorization server 130 judges whether or not the identifier ID1 representing the user has been acquired. If it has been acquired, the process proceeds to step S203. If it has not been acquired, the process proceeds to step S206.

[0027] Step S203: The authorization server 130 stores the identifier ID1 representing the user in the authorization response, and then proceeds to step S204. Step S204: The authorization server 130 signs the authorization response, and then proceeds to step S205. Step S205: The authorization server 130 sends the authorization response to the client 120 by redirection, and ends the process. Step S206: The authorization server 130 sends an error response to the client 120 by redirection, and ends the process.

[0028] 7 is a flowchart showing the processing procedure of the client 120. The client 120 sequentially executes the following steps S301 to S308. Step S301: The client 120 acquires the identifier ID2 representing the user from the request received when the authorization response is received, and then proceeds to step S302. Step S302: The client 120 judges whether or not the identifier ID2 representing the user has been acquired. If it has been acquired, the process proceeds to step S303. If it has not been acquired, the process proceeds to step S308.

[0029] Step S303: The client 120 obtains the identifier ID1 representing the user stored in the authorization response. Step S304: The client 120 judges whether or not the identifier ID1 representing the user has been acquired. If it has been acquired, the process proceeds to step S305. If it has not been acquired, the process proceeds to step S308.

[0030] Step S305: The client 120 performs a process of comparing the identifier ID1 with the identifier ID2 and confirming that they are equal, and then proceeds to step S306. Step S306: The client 120 judges whether the identifier ID1 and the identifier ID2 are equal. If they are equal, the process proceeds to step S307. If they cannot be acquired, the process proceeds to step S308.

[0031] Step S307: The client 120 determines that the identifier representing the user has been successfully checked, and ends the process. In other words, the client 120 determines that the sender of the authorization response is a valid user, and ends the process. Step S308: The client 120 determines that the check of the identifier representing the user has failed and ends the process. In other words, the client 120 determines that the sender of the authorization response is an unauthorized user and ends the process.

[0032] FIG. 8 is an explanatory diagram of data managed by the system. The client 120 manages the following data: 1. The endpoint of the authorization server that the client accesses when delegating authentication and authorization to the authorization server. 2. An identifier to identify a client 3. Signature verification key for verifying the signature of the authentication and authorization result

[0033] The authorization server 130 manages the following data: 10. The client endpoint that the authorization server accesses when sending the authentication and authorization result to the client. 11. Identifier for identifying the client 12. User Credentials of the User 13. Signing key for signing authentication and authorization results 14.Login Screen 15. Consent screen

[0034] The user or browser 110 manages the following data: 20. User credentials (e.g. username and password) to authenticate with the authorization server 21. User Representative Identifiers 22.Endpoints for accessing clients

[0035] FIG. 9 is an explanatory diagram of the use of the data shown in FIG. The browser 110 accesses the client 120 by addressing the endpoint 22 . The client 120 redirects to the authorization server 130 by adding an identifier 2 and targeting the endpoint 1 as the destination. The authorization server 130 identifies the client using the identifier 2 and the identifier 11, and sends a login screen 14 and a consent screen 15 to the browser 110. The user enters the user credentials 20 and the browser 110 sends the user credentials 20 and an identifier 21 to the authorization server 130 .

[0036] The authorization server 130 authenticates the user with the user credentials 20 and 12. Then, it stores the identifier 21 in the authentication and authorization result (authorization response), signs the authentication and authorization result with the signature key 13, and redirects it to the endpoint 10 (client 120). The browser 110 sends the identifier 21 when redirecting the authentication and authorization result to the client 120 . The client 120 verifies the signature of the authentication and authorization result with the signature verification key 3. Then, it verifies that the sent identifier 21 is the same as the identifier 21 in the authentication and authorization result.

[0037] FIG. 10 is an explanatory diagram of data management. The identifier 21 representing the user is managed by the browser 110 . The client's endpoint 1 to be accessed when sending the result of authentication and authorization, an identifier 2 for identifying the client, and a signature verification key 3 are stored in the memory 122 of the client 120 . The client endpoint 10 to be accessed when sending the authentication and authorization result, an identifier 11 for identifying the client, user credentials 12, signing key 13, login screen 14, and consent screen 15 are stored in memory 132 of the authorization server 130.

[0038] As described above, the disclosed server system comprises a client 120 that accepts access from a user, and an authorization server 130 that receives delegation from the client 120 and processes authentication and / or authorization requests of the user, the server receives the request, obtains an identifier representing the user, and stores the identifier in a response to the request, the client 120 receives the response from the user, obtains an identifier representing the user, and compares the obtained identifier with the identifier stored in the response to determine whether the response was sent from the correct user's browser. This makes it possible to detect unauthorized users and improve the security of the server system.

[0039] The server also performs authentication and authorization of the user, and the client denies access from the source of the response if the comparison results in a mismatch. This makes it possible to block access by unauthorized users who exploit the results of authentication and authorization by legitimate users.

[0040] The identifier representing the user may be a client certificate. Furthermore, the identifier representing the user may be identification information read by the user's terminal from a predetermined medium. The identifier representing the user is data that can be used as a user credential, such as a client certificate, and cannot be obtained through phishing attacks. For example, if a client certificate is used, even if a user is phished and directed to a fake site prepared by an attacker, the attacker cannot steal the client's private key. Therefore, an attacker cannot pose as a legitimate user and present a client certificate to the client or authorization server.

[0041] The server also digitally signs a response that stores an identifier representing the user, and the client performs the comparison after verifying the digital signature. This makes it possible to confirm that the identifier stored in the response has not been tampered with, improving security.

[0042] The system further includes a resource server 140 that holds resource data to be provided to the disclosed user, and the server authorizes access to the resource data. This makes it possible to prevent unauthorized access to resource data.

[0043] The present invention is not limited to the above-mentioned embodiment, and various modifications are included. For example, the above-mentioned embodiment is described in detail to easily explain the present invention, and is not necessarily limited to the embodiment having all the described configurations. Moreover, the present invention is not limited to the deletion of the configurations, and it is also possible to replace or add the configurations. For example, the present invention is also applicable to a configuration in which delegation of authentication and authorization is performed in multiple stages. [Explanation of symbols]

[0044] 110: Browser, 120: Client, 130: Authorization Server, 140: Resource Server

Claims

1. A client that accepts access from a user; A server that receives delegation from the client and processes a request for authentication and / or authorization of the user according to a flow of a specification based on OAuth 2.0 or OIDC Core 1.0; The server receives the request, obtains an identifier representing the user, and stores the identifier in a response to the request; the client receives the response from the user, acquires an identifier representing the user, and compares the acquired identifier with an identifier stored in the response to determine whether the source of the response is a valid user; The client determines that the sender of the response is a valid user if the identifier acquired upon receiving the response matches the identifier stored in the response, and determines that the sender of the response is an unauthorized user if the identifier acquired upon receiving the response does not match the identifier stored in the response, if an identifier could not be acquired when the response was received, or if the identifier stored in the response could not be acquired. A server system comprising:

2. 2. The server system according to claim 1, The server authenticates and authorizes the user; The server system is characterized in that the client denies access from the source of the response if the comparison result is a mismatch.

3. 2. The server system according to claim 1, A server system, wherein the identifier representing the user is a client certificate.

4. 2. The server system according to claim 1, A server system, wherein the identifier representing the user is identification information read by the user's terminal from a predetermined medium.

5. 2. The server system according to claim 1, The server digitally signs a response that includes an identifier representing the user; A server system, wherein the client performs the comparison after verifying the electronic signature.

6. 2. The server system according to claim 1, A resource server that stores resource data to be provided to the user is further provided. The server system is characterized in that the server authorizes access to the resource data.

7. A client that accepts access from a user; A method for detecting an unauthorized user in a server system comprising: a server that receives delegation from the client and processes a request for authentication and / or authorization of the user in accordance with a flow of a specification based on OAuth 2.0 or OIDC Core 1.0, the server receiving the request, obtaining an identifier representing the user, and storing the identifier in a response to the request; a determination step in which the client receives the response from the user, acquires an identifier representing the user, and compares the acquired identifier with an identifier stored in the response to determine whether the source of the response is a valid user; The determination step determines that the sender of the response is a valid user if the identifier acquired upon receiving the response matches the identifier stored in the response, and determines that the sender of the response is an unauthorized user if the identifier acquired upon receiving the response does not match the identifier stored in the response, if an identifier could not be acquired when the response was received, or if the identifier stored in the response could not be acquired. A method for detecting an unauthorized user.

Images