[go: up one dir, main page]

WO2024176494A1 - サーバシステム及び不正ユーザ検知方法 - Google Patents

サーバシステム及び不正ユーザ検知方法 Download PDF

Info

Publication number
WO2024176494A1
WO2024176494A1 PCT/JP2023/030661 JP2023030661W WO2024176494A1 WO 2024176494 A1 WO2024176494 A1 WO 2024176494A1 JP 2023030661 W JP2023030661 W JP 2023030661W WO 2024176494 A1 WO2024176494 A1 WO 2024176494A1
Authority
WO
WIPO (PCT)
Prior art keywords
user
client
server
identifier
response
Prior art date
Application number
PCT/JP2023/030661
Other languages
English (en)
French (fr)
Inventor
義之 田畑
Original Assignee
株式会社日立製作所
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社日立製作所 filed Critical 株式会社日立製作所
Publication of WO2024176494A1 publication Critical patent/WO2024176494A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/33—User authentication using certificates

Definitions

  • the present invention relates to a server system and a method for detecting unauthorized users.
  • 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 transmits 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, requesting 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.”
  • the present invention aims to detect unauthorized users and improve the security of server systems.
  • 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.
  • one representative unauthorized user detection method of the present invention is a method for detecting unauthorized users in a server system comprising 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 the steps of the server receiving the request, acquiring an identifier representing the user and storing it in a response to the request, and the client receiving the response from the user, acquiring an identifier representing the user, and comparing the acquired identifier with the identifier stored in the response to determine whether the source of the response is a valid user.
  • the present invention makes it possible to detect unauthorized users and improve the security of a server system. Problems, configurations, and advantages other than those described above will become clear from the description of the embodiment below.
  • FIG. 1 is an explanatory diagram of authentication and authorization processing by the system of the first embodiment. Diagram of blocking unauthorized access System element diagram Overall system configuration Flowchart showing the processing procedure of the authorization server Flowchart showing client processing steps Diagram of data managed by the system Data usage diagram Data management diagram
  • Fig. 1 is an explanatory diagram of basic authentication and authorization processing, and shows a specific example of an authorization code flow for OAuth 2.0 and OIDC Core 1.0.
  • a user accesses a client 120 via a browser 110 of a user terminal.
  • the client 120 is requesting the provision of data stored in a resource server 140.
  • 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.
  • the authorization server 130 which receives the authorization request, executes authentication and authorization processing (2). Specifically, the authorization server 130 sends 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 consent screen and accepts input from the user. The browser 110 sends 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.
  • the authorization server 130 returns the result of 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 an authorization response to the client 120.
  • the client 120 sends a token request to the authorization server 130 and receives a token response from the authorization server 130.
  • the client 120 then sends 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.
  • FIG. 2 is an explanatory diagram of the authentication and authorization process by the system of the first embodiment.
  • the browser 110 transmits a client certificate to the authorization server 130 together with the user input data on the login screen and the consent screen.
  • the authorization server 130 stores the hash value of the client certificate in the authorization response.
  • the client 120 receives the authorization response and obtains the hash value of the client certificate from the browser 110.
  • the client 120 compares the client certificate obtained from the browser 110 with the hash value of the client certificate included in the authorization response. If the comparison shows that they are identical, the client 120 determines that the access is from a legitimate user and provides the data of the resource server 140.
  • 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, like a client certificate, and that cannot be obtained by a phishing attack. For example, with a client certificate, even if a user is subjected to a phishing attack 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 authorization server.
  • the identifier that represents a user may be the identification number of an IC card.
  • FIG. 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.
  • 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.
  • the attacker sends an email with the authorization request set as a hyperlink to the legitimate user.
  • the browser 110 sends an authorization request to the authorization server 130.
  • the authorization server 130 which receives the authorization request, executes authentication and authorization processing. Specifically, the authorization server 130 sends 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 consent screen, and accepts input from a legitimate user. The browser 110 sends 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. In other words, this authentication and authorization is performed by the legitimate user.
  • 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. At this point, an attacker, who is an unauthorized user, acts as a man in the middle, stops the process, and unauthorizedly obtains the authorization response.
  • the authorization server 130 stores the hash value of the client certificate acquired from the browser 110 as data in the authorization response. Then, the 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, the client 120 can determine that the access is from an unauthorized user and block the access.
  • Fig. 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 the 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.
  • the authorization server has a function of acquiring an identifier representing the user and storing it in the authorization response.
  • the client has a function of acquiring an identifier representing the user and comparing it with the identifier stored in the authorization response to determine whether or not the user is a legitimate user.
  • FIG. 5 is a diagram showing the configuration of the entire system.
  • 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.
  • the CPU 121 reads 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.
  • 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.
  • the CPU 131 reads out a predetermined program from the storage 133, loads it into the memory 132, and executes it sequentially to realize various functions of the authorization server 130.
  • the communication interface 134 communicates with the browser 110 and the client 120.
  • Step S201 The authorization server 130 acquires an identifier ID1 representing the user from a request received when authenticating the user or when obtaining the user's consent. 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.
  • 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 the process proceeds to step S205.
  • Step S205 The authorization server 130 sends an 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.
  • Step S301 The client 120 acquires an 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.
  • Step S303 The client 120 obtains the identifier ID1 representing the user stored in the authorization response.
  • 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.
  • 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.
  • FIG. 8 is an explanatory diagram of data managed by the system.
  • the client 120 manages the following data: 1.
  • a signature verification key for verifying the signature of the authentication and authorization result.
  • the authorization server 130 manages the following data: 10. The client's endpoint that the authorization server accesses when sending the result of authentication and authorization to the client 11. An identifier for identifying the client 12. The user's user credentials 13. A signing key for signing the result of authentication and authorization 14. Login screen 15. Consent screen
  • the user or browser 110 manages the following data: 20.
  • User credentials e.g. username and password
  • Identifier representing the user 22.
  • Endpoint for accessing the client
  • 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 with identifier 2 and 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 .
  • the authorization server 130 authenticates the user with the user credentials 20 and 12. Then, it stores the identifier 21 in the authentication authorization result (authorization response), signs the authentication 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.
  • 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.
  • 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 receiving the request, acquiring an identifier representing the user, and storing the identifier in a response to the request, the client 120 receiving the response from the user, acquiring an identifier representing the user, and comparing the acquired 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the present invention is not limited to the above-mentioned embodiment, and various modifications are included.
  • 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.
  • the present invention is not limited to the deletion of the configurations, and it is also possible to replace or add the configurations.
  • the present invention is also applicable to a configuration in which delegation of authentication and authorization is performed in multiple stages.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer And Data Communications (AREA)

Abstract

不正なユーザの検知を実現し、サーバシステムのセキュリティを向上することを課題とする。ユーザからのアクセスを受け付けるクライアント１２０と、前記クライアント１２０からの委譲を受け、前記ユーザの認証及び／又は認可のリクエストを処理するサーバとしての認可サーバ１３０とを備え、前記サーバは、前記リクエストを受信するとともに、前記ユーザを代表する識別子を取得し、前記リクエストに対するレスポンスに格納し、前記クライアント１２０は、前記ユーザから前記レスポンスを受信するとともに、前記ユーザを代表する識別子を取得し、該取得した識別子と前記レスポンスに格納された識別子とを比較して、前記レスポンスの送信元が正しいユーザであるか否かを判定する。

Description

サーバシステム及び不正ユーザ検知方法
　本発明は、サーバシステム及び不正ユーザ検知方法に関する。
　従来、認証や認可の技術として、ＯＡｕｔｈ　２．０（ＲＦＣ６７４９）、ＯｐｅｎＩＤ　Ｃｏｎｎｅｃｔ　Ｃｏｒｅ　１．０の認可コードフロー、ＳＡＭＬのＳＰ－ｉｎｉｔｉａｔｅｄなどが知られている。
　また、複数の認可サーバが存在した際に、適切な認可サーバを選択する技術として、特開２０２０－５３１００号公報（特許文献１）に記載の技術がある。この公報には、「認可サーバーは、認可リクエストを受信したことに伴って、ユーザー情報が所在する第一の認可サーバーを特定し、第一の認可サーバーに対して認証要求を送信する第一の送信手段と、第一の認可サーバーはユーザーを認証し、ユーザー情報が所在する第一の認可サーバーを送信先として示す情報とともに認可レスポンスをクライアントに送信する第二の送信手段と、クライアントは認可レスポンスに基づいて、第二の特定手段により前記第一の認可サーバーを特定し、第一の認可サーバーに対して、リソースサーバーにアクセスするための認可トークンを要求するトークン要求を送信する第三の送信手段と、第一の認可サーバーはトークン要求に対して認可トークンを発行する発行手段と、を有する。」という記載がある。
特開２０２０－５３１００号公報
　従来の技術では、不正なユーザがクライアントに正規のユーザとしてログインする事態を防ぐことができなかった。ＯＡｕｔｈを例に説明すると、認可サーバが認証し、認可（同意）を取得したユーザとは別のユーザ（不正なユーザ）がクライアントにログインできる問題が発生していた。このように、従来の技術では不正アクセスに対するセキュリティが不十分であった。
　そこで、本発明では、不正なユーザの検知を実現し、サーバシステムのセキュリティを向上することを目的とする。
　上記目的を達成するために、代表的な本発明のサーバシステムの一つは、ユーザからのアクセスを受け付けるクライアントと、前記クライアントからの委譲を受け、前記ユーザの認証及び／又は認可のリクエストを処理するサーバとを備え、前記サーバは、前記リクエストを受信するとともに、前記ユーザを代表する識別子を取得し、前記リクエストに対するレスポンスに格納し、前記クライアントは、前記ユーザから前記レスポンスを受信するとともに、前記ユーザを代表する識別子を取得し、該取得した識別子と前記レスポンスに格納された識別子とを比較して、前記レスポンスの送信元が正しいユーザであるか否かを判定することを特徴とする。
　また、代表的な本発明の不正ユーザ検知方法の一つは、ユーザからのアクセスを受け付けるクライアントと、前記クライアントからの委譲を受け、前記ユーザの認証及び／又は認可のリクエストを処理するサーバとを備えるサーバシステムの不正ユーザ検知方法であって、前記サーバが、前記リクエストを受信するとともに、前記ユーザを代表する識別子を取得し、前記リクエストに対するレスポンスに格納するステップと、前記クライアントが、前記ユーザから前記レスポンスを受信するとともに、前記ユーザを代表する識別子を取得し、該取得した識別子と前記レスポンスに格納された識別子とを比較して、前記レスポンスの送信元が正しいユーザであるか否かを判定するステップとを含むことを特徴とする。
　本発明によれば、不正なユーザの検知を実現し、サーバシステムのセキュリティを向上できる。上記した以外の課題、構成及び効果は以下の実施の形態の説明により明らかにされる。
認証及び認可の基本的な処理の説明図 実施例１のシステムによる認証及び認可の処理の説明図 不正なアクセスのブロックについての説明図 システム要素の説明図 システム全体の構成図 認可サーバの処理手順を示すフローチャート クライアントの処理手順を示すフローチャート システムが管理するデータの説明図 データの利用の説明図 データの管理の説明図
　以下、実施例を図面を用いて説明する。
　図１は、認証及び認可の基本的な処理の説明図である。この図１は、ＯＡｕｔｈ　２．０やＯＩＤＣ　Ｃｏｒｅ　１．０の認可コードフローの具体例である。
　ユーザは、ユーザ端末のブラウザ１１０を介して、クライアント１２０にアクセスする。ここでは、クライアント１２０は、リソースサーバ１４０に格納されたデータの提供を求めているものとする。
　クライアント１２０は、ユーザの認証及び認可を認可サーバ１３０に委譲する（１）。具体的には、クライアント１２０は、認可サーバ１３０を宛先としてブラウザ１１０にリダイレクトさせる。この結果、ブラウザ１１０は、認可サーバ１３０に認可リクエストを送ることになる。
　認可リクエストを受信した認可サーバ１３０は、認証及び認可処理を実行する（２）。具体的には、認可サーバ１３０は、ログイン情報の入力を受け付ける画面（ログイン画面）、確認入力を受け付ける画面（同意画面）をブラウザ１１０に送信する。ブラウザ１１０は、ログイン画面及び同意画面を表示し、ユーザによる入力を受け付ける。ブラウザ１１０は受け付けたデータを認可サーバ１３０に送信する。認可サーバ１３０は、ブラウザ１１０から受信したデータを用いてユーザの認証と認可を行う。
　認可サーバ１３０は、認証及び認可の結果を認可レスポンスとしてクライアント１２０に返却する（３）。具体的には、認可サーバ１３０は、クライアント１２０を宛先としてブラウザ１１０にリダイレクトさせる。この結果、ブラウザ１１０は、クライアント１２０に認可レスポンスを送ることになる。
　クライアント１２０は、認可サーバ１３０にトークンリクエストを送信し、認可サーバ１３０からトークンレスポンスを受信する。その後、クライアント１２０は、リソースサーバ１４０にＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ　Ｐｒｏｇｒａｍｍｉｎｇ　Ｉｎｔｅｒｆａｃｅ）リクエストを送信する。リソースサーバ１４０は、ＡＰＩレスポンスでクライアント１２０にデータを提供する。
　図１に示した基本的な処理では、認証及び認可処理（２）でログインしたユーザと、結果返却処理（３）で結果を返したユーザとが同一であることを確認できない。そこで、本実施例のシステムでは、ユーザを代表する識別子を取得して、認証及び認可処理（２）と結果返却処理（３）のユーザが同一であるかを判定している。
　図２は、実施例１のシステムによる認証及び認可の処理の説明図である。図２の認証及び認可処理（２）では、ブラウザ１１０は、ログイン画面と同意画面に対するユーザ入力データととともに、クライアント証明書を認可サーバ１３０に送信する。認可サーバ１３０は、認可レスポンスにクライアント証明書のハッシュ値を格納する。
　図２の結果返却処理（３）では、クライアント１２０は、認可レスポンスを受信するとともに、ブラウザ１１０からクライアント証明書のハッシュ値を取得する。クライアント１２０は、ブラウザ１１０から取得したクライアント証明書と、認可レスポンスに含まれていたクライアント証明書のハッシュ値とを比較する。比較の結果、同一であれば、クライアント１２０は正当なユーザからのアクセスであると判定し、リソースサーバ１４０のデータを提供する。
　このように、実施例１のシステムは、認証及び認可処理（２）と結果返却処理（３）でそれぞれクライアント証明書に関するデータを取得し、それらを比較する。クライアント証明書は、ユーザを代表する識別子の一例である。ユーザを代表する識別子は、クライアント証明書のように、ユーザクレデンシャルとして使用でき、かつフィッシング攻撃によって取得できないデータを用いる。例えばクライアント証明書であれば、フィッシング攻撃を受けて攻撃者の準備した偽サイトに誘導されたとしても、攻撃者はクライアントの秘密鍵までは奪うことができない。このため、攻撃者は、正規ユーザになりすましてクライアントや認可サーバにクライアント証明書を提示することはできない。ユーザを代表する識別子は、ＩＣカードの識別番号であってもよい。
　図３は、不正なアクセスのブロックについての説明図である。不正なユーザである攻撃者は、攻撃者のユーザ端末のブラウザを介して、クライアント１２０にアクセスする。クライアント１２０は、ユーザの認証及び認可を認可サーバ１３０に委譲する。具体的には、クライアント１２０は、認可サーバ１３０を宛先として攻撃者のブラウザにリダイレクトさせる。攻撃者は、この時点で処理を止め、認可リクエストを取得する。そして、認可リクエストをハイパーリンクにセットした電子メールを正当なユーザに送る。正当なユーザが電子メールを開き、ハイパーリンクをクリックすると、ブラウザ１１０は認可リクエストを認可サーバ１３０に送る。
　認可リクエストを受信した認可サーバ１３０は、認証及び認可処理を実行する。具体的には、認可サーバ１３０は、ログイン情報の入力を受け付ける画面（ログイン画面）、確認入力を受け付ける画面（同意画面）をブラウザ１１０に送信する。ブラウザ１１０は、ログイン画面及び同意画面を表示し、正当なユーザによる入力を受け付ける。ブラウザ１１０は受け付けたデータを認可サーバ１３０に送信する。認可サーバ１３０は、ブラウザ１１０から受信したデータを用いてユーザの認証と認可を行う。すなわち、この認証と認可は、正当なユーザによって行われる。
　認可サーバ１３０は、認証及び認可の結果を認可レスポンスとしてクライアント１２０に返却する。具体的には、認可サーバ１３０は、クライアント１２０を宛先としてブラウザ１１０にリダイレクトさせる。この結果、ブラウザ１１０は、クライアント１２０に認可レスポンスを送る。ここで、不正なユーザである攻撃者が中間者（Ｍａｎ　Ｉｎ　ｔｈｅ　Ｍｉｄｄｌｅ）として介在して処理を止め、認可レスポンスを不正に取得する。
　攻撃者は、不正に取得した認可レスポンスをクライアント１２０に送信することで、不正なアクセスを試みる。
　図１に示した基本的な処理であれば、クライアント１２０はユーザが入れ替わったことを検知できず、攻撃者によるアクセスが成功する。
　しかし、図３においては、認可サーバ１３０は、ブラウザ１１０から取得したクライアント証明書のハッシュ値を認可レスポンスにデータとして格納している。そして、クライアント１２０は、ブラウザが認可レスポンスを送るときにＴＣＰレイヤでクライアント証明書を取得し、認可レスポンスにデータとして含まれたクライアント証明書のハッシュ値と、認可レスポンスを送るときにＴＣＰレイヤで送られたクライアント証明書とを比較する。攻撃者が認可レスポンスを送信していれば、クライアント証明書が取得できない、もしくはクライアント証明書が不一致となる。このため、クライアント１２０は、不正なユーザからのアクセスであると判定し、アクセスをブロックできる。
　図４は、システム要素の説明図である。この図４は、ＯＡｕｔｈ　２．０やＯＩＤＣ　Ｃｏｒｅ　１．０を例とした説明図を示している。
　ブラウザは、ユーザが使用するブラウザである。ユーザは、ブラウザを介してクライアントや認可サーバにアクセスする。
　クライアントは、ユーザにサービスを提供する。クライアントは、認可サーバにユーザの認証を委譲する。また、クライアントは、認可サーバが発行したトークンを用いてユーザを認証する。場合によってはリソースサーバからユーザのリソース(情報)を取得するために、トークンを用いてＡＰＩコールする。
　認可サーバは、ユーザを認証し、必要に応じてユーザから同意を取得し、クライアントにトークンを発行する。
　リソースサーバは、ユーザのリソース(情報)を保持している。当該情報をリソースサーバはＡＰＩで公開する。また、リソースサーバは、認可サーバが発行したトークンを用いてアクセス制御する。なお、リソースサーバは、本システムに必須ではない。
　さらに、本実施例のシステムでは、認可サーバは、ユーザを代表する識別子を取得して、認可レスポンスに格納する機能を有する。また、クライアントは、ユーザを代表する識別子を取得し、認可レスポンスに格納された識別子と比較して、正当なユーザであるか否かを判定する機能を有する。
　図５は、システム全体の構成図である。
　ブラウザ１１０は、ユーザの端末で動作している。
　クライアント１２０は、ＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）１２１、メモリ１２２、ストレージ１２３及び通信インタフェース１２４を有するコンピュータである。具体的には、ＣＰＵ１２１は、ストレージ１２３から所定のプログラムを読み出してメモリ１２２に展開し、順次実行することで、クライアント１２０としての各種機能を実現する。また、通信インタフェース１２４は、ブラウザ１１０や認可サーバ１３０との通信を行う。
　認可サーバ１３０は、ＣＰＵ１３１、メモリ１３２、ストレージ１３３及び通信インタフェース１３４を有するコンピュータである。具体的には、ＣＰＵ１３１は、ストレージ１３３から所定のプログラムを読み出してメモリ１３２に展開し、順次実行することで、認可サーバ１３０としての各種機能を実現する。また、通信インタフェース１３４は、ブラウザ１１０やクライアント１２０との通信を行う。
　図６は、認可サーバの処理手順を示すフローチャートである。認可サーバ１３０は、次のステップＳ２０１～Ｓ２０６の処理を順次実行する。
　ステップＳ２０１：認可サーバ１３０は、ユーザ認証時、またはユーザの同意取得時に受け取ったリクエストからユーザを代表する識別子ＩＤ１を取得する。その後、ステップＳ２０２に進む。
　ステップＳ２０２：認可サーバ１３０は、ユーザを代表する識別子ＩＤ１を取得できたか否かを判定する。取得できたならば、ステップＳ２０３に進む。取得できなかったならば、ステップＳ２０６に進む。
　ステップＳ２０３：認可サーバ１３０は、認可レスポンスにユーザを代表する識別子ＩＤ１を格納する。その後、ステップＳ２０４に進む。
　ステップＳ２０４：認可サーバ１３０は、認可レスポンスに署名する。その後、ステップＳ２０５に進む。
　ステップＳ２０５：認可サーバ１３０は、認可レスポンスをリダイレクトでクライアント１２０に送信し、処理を終了する。
　ステップＳ２０６：認可サーバ１３０は、エラーレスポンスをリダイレクトでクライアント１２０に送信し、処理を終了する。
　図７は、クライアント１２０の処理手順を示すフローチャートである。クライアント１２０は、次のステップＳ３０１～Ｓ３０８の処理を順次実行する。
　ステップＳ３０１：クライアント１２０は、認可レスポンス受信時に受け取ったリクエストからユーザを代表する識別子ＩＤ２を取得する。その後、ステップＳ３０２に進む。
　ステップＳ３０２：クライアント１２０は、ユーザを代表する識別子ＩＤ２を取得できたか否かを判定する。取得できたならば、ステップＳ３０３に進む。取得できなかったならば、ステップＳ３０８に進む。
　ステップＳ３０３：クライアント１２０は、認可レスポンスに格納されたユーザを代表する識別子ＩＤ１を取得する。
　ステップＳ３０４：クライアント１２０は、ユーザを代表する識別子ＩＤ１を取得できたか否かを判定する。取得できたならば、ステップＳ３０５に進む。取得できなかったならば、ステップＳ３０８に進む。
　ステップＳ３０５：クライアント１２０は、識別子ＩＤ１と識別子ＩＤ２を比較し、等しいことを確認する処理を行う。その後、ステップＳ３０６に進む。
　ステップＳ３０６：クライアント１２０は、クライアント１２０は、識別子ＩＤ１と識別子ＩＤ２が等しいか否かを判定する。等しければ、ステップＳ３０７に進む。取得できなかったならば、ステップＳ３０８に進む。
　ステップＳ３０７：クライアント１２０は、ユーザを代表する識別子チェック成功とみなし、処理を終了する。言い換えれば、クライアント１２０は、認可レスポンスの送信元が正しいユーザであると判定して、処理を終了する。
　ステップＳ３０８：クライアント１２０は、ユーザを代表する識別子チェック失敗とみなし、処理を終了する。言い換えれば、クライアント１２０は、認可レスポンスの送信元が不正なユーザであると判定して、処理を終了する。
　図８は、システムが管理するデータの説明図である。
　クライアント１２０は、次のデータを管理する。
　　１．クライアントが認可サーバに認証認可を委譲する際にアクセスする認可サーバのエンドポイント
　　２．クライアントを識別するための識別子
　　３．認証認可結果の署名を検証するための署名検証鍵
　認可サーバ１３０は、次のデータを管理する。
　　１０．認可サーバがクライアントに認証認可の結果を送付する際にアクセスするクライアントのエンドポイント
　　１１．クライアントを識別するための識別子
　　１２．ユーザのユーザクレデンシャル
　　１３．認証認可結果に署名するための署名鍵
　　１４．ログイン画面
　　１５．同意画面
　ユーザまたはブラウザ１１０は、次のデータを管理する。
　　２０．認可サーバで認証するためのユーザクレデンシャル(例：ユーザ名とパスワード)
　　２１．ユーザを代表する識別子
　　２２．クライアントへアクセスするためのエンドポイント
　図９は、図８に示したデータの利用の説明図である。
　ブラウザ１１０は、エンドポイント２２を宛先とすることで、クライアント１２０にアクセスする。
　クライアント１２０は、識別子２を付与し、エンドポイント１を宛先とすることで、認可サーバ１３０にリダイレクトする。
　認可サーバ１３０は、識別子２と識別子１１でクライアントを識別して、ログイン画面１４や同意画面１５をブラウザ１１０に送付する。
　ユーザは、ユーザクレデンシャル２０を入力し、ブラウザ１１０はユーザクレデンシャル２０と識別子２１を認可サーバ１３０に送付する。
　認可サーバ１３０は、ユーザクレデンシャル２０とユーザクレデンシャル１２でユーザを認証する。そして、識別子２１を認証認可結果（認可レスポンス）に格納し、署名鍵１３で認証認可結果に署名して、エンドポイント１０（クライアント１２０）にリダイレクトする。
　ブラウザ１１０は、認証認可結果をクライアント１２０にリダイレクトする際に、識別子２１を送付する。
　クライアント１２０は、署名検証鍵３で認証認可結果の署名を検証する。そして、送付された識別子２１と認証認可結果内の識別子２１が同一であることを検証する。
　図１０は、データの管理の説明図である。
　ユーザを代表する識別子２１は、ブラウザ１１０に管理される。
　認証認可の結果を送付する際にアクセスするクライアントのエンドポイント１、クライアントを識別するための識別子２、署名検証鍵３は、クライアント１２０のメモリ１２２に格納される。
　認証認可の結果を送付する際にアクセスするクライアントのエンドポイント１０、クライアントを識別するための識別子１１、ユーザクレデンシャル１２、署名鍵１３、ログイン画面１４、同意画面１５は、認可サーバ１３０のメモリ１３２に格納される。
　上述してきたように、開示のサーバシステムは、ユーザからのアクセスを受け付けるクライアント１２０と、前記クライアント１２０からの委譲を受け、前記ユーザの認証及び／又は認可のリクエストを処理するサーバとしての認可サーバ１３０とを備え、前記サーバは、前記リクエストを受信するとともに、前記ユーザを代表する識別子を取得し、前記リクエストに対するレスポンスに格納し、前記クライアント１２０は、前記ユーザから前記レスポンスを受信するとともに、前記ユーザを代表する識別子を取得し、該取得した識別子と前記レスポンスに格納された識別子とを比較して、前記レスポンスの送信元が正しいユーザのブラウザであるか否かを判定する。
　このため、不正なユーザを検知し、サーバシステムのセキュリティを向上できる。
　また、前記サーバは、前記ユーザの認証及び認可を行い、前記クライアントは、前記比較の結果が不一致である場合に、レスポンスの送信元からのアクセスを拒否する。
　このため、不正なユーザが、正当なユーザによる認証及び認可の結果を悪用して行うアクセスをブロックできる。
　前記ユーザを代表する識別子には、クライアント証明書を用いることができる。
　また、前記ユーザを代表する識別子には、ユーザの端末が所定の媒体から読み取った識別情報を用いることができる。
　ユーザを代表する識別子は、クライアント証明書のように、ユーザクレデンシャルとして使用でき、かつフィッシング攻撃によって取得できないデータを用いる。例えばクライアント証明書であれば、フィッシング攻撃を受けて攻撃者の準備した偽サイトに誘導されたとしても、攻撃者はクライアントの秘密鍵までは奪うことができない。このため、攻撃者は、正規ユーザになりすましてクライアントや認可サーバにクライアント証明書を提示することはできない。
　また、前記サーバは、前記ユーザを代表する識別子を格納したレスポンスに電子署名し、前記クライアントは、前記電子署名を検証した上で前記比較を行う。
　このため、レスポンスに格納された識別子が書き換えられていないことを確認でき、セキュリティが向上する。
　また、開示の前記ユーザに提供するリソースデータを保持するリソースサーバ１４０をさらに備え、前記サーバは、前記リソースデータに対するアクセスの認可を行う。
　このためリソースデータに対する不正なアクセスを防止できる。
　なお、本発明は上記の実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、かかる構成の削除に限らず、構成の置き換えや追加も可能である。
　例えば、認証や認可の委譲が多段階で行われる構成であっても、本発明は適用可能である。
１１０：ブラウザ、１２０：クライアント、１３０：認可サーバ、１４０：リソースサーバ
 

Claims (7)

  1. 　ユーザからのアクセスを受け付けるクライアントと、
    　前記クライアントからの委譲を受け、前記ユーザの認証及び／又は認可のリクエストを処理するサーバとを備え、
    　前記サーバは、前記リクエストを受信するとともに、前記ユーザを代表する識別子を取得し、前記リクエストに対するレスポンスに格納し、
    　前記クライアントは、前記ユーザから前記レスポンスを受信するとともに、前記ユーザを代表する識別子を取得し、該取得した識別子と前記レスポンスに格納された識別子とを比較して、前記レスポンスの送信元が正しいユーザであるか否かを判定することを特徴とするサーバシステム。
  2. 　請求項１に記載のサーバシステムであって、
    　前記サーバは、前記ユーザの認証及び認可を行い、
    　前記クライアントは、前記比較の結果が不一致である場合に、レスポンスの送信元からのアクセスを拒否することを特徴とするサーバシステム。
  3. 　請求項１に記載のサーバシステムであって、
    　前記ユーザを代表する識別子は、クライアント証明書であることを特徴とするサーバシステム。
  4. 　請求項１に記載のサーバシステムであって、
    　前記ユーザを代表する識別子は、ユーザの端末が所定の媒体から読み取った識別情報であることを特徴とするサーバシステム。
  5. 　請求項１に記載のサーバシステムであって、
    　前記サーバは、前記ユーザを代表する識別子を格納したレスポンスに電子署名し、
    　前記クライアントは、前記電子署名を検証した上で前記比較を行うことを特徴とするサーバシステム。
  6. 　請求項１に記載のサーバシステムであって、
    　前記ユーザに提供するリソースデータを保持するリソースサーバをさらに備え、
    　前記サーバは、前記リソースデータに対するアクセスの認可を行うことを特徴とするサーバシステム。
  7. 　ユーザからのアクセスを受け付けるクライアントと、
    　前記クライアントからの委譲を受け、前記ユーザの認証及び／又は認可のリクエストを処理するサーバとを備えるサーバシステムの不正ユーザ検知方法であって、
    　前記サーバが、前記リクエストを受信するとともに、前記ユーザを代表する識別子を取得し、前記リクエストに対するレスポンスに格納するステップと、
    　前記クライアントが、前記ユーザから前記レスポンスを受信するとともに、前記ユーザを代表する識別子を取得し、該取得した識別子と前記レスポンスに格納された識別子とを比較して、前記レスポンスの送信元が正しいユーザであるか否かを判定するステップとを含むことを特徴とする不正ユーザ検知方法。
     
PCT/JP2023/030661 2023-02-21 2023-08-25 サーバシステム及び不正ユーザ検知方法 WO2024176494A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2023-025451 2023-02-21
JP2023025451A JP7636456B2 (ja) 2023-02-21 2023-02-21 サーバシステム及び不正ユーザ検知方法

Publications (1)

Publication Number Publication Date
WO2024176494A1 true WO2024176494A1 (ja) 2024-08-29

Family

ID=92500516

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2023/030661 WO2024176494A1 (ja) 2023-02-21 2023-08-25 サーバシステム及び不正ユーザ検知方法

Country Status (2)

Country Link
JP (1) JP7636456B2 (ja)
WO (1) WO2024176494A1 (ja)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001186122A (ja) * 1999-12-22 2001-07-06 Fuji Electric Co Ltd 認証システム及び認証方法
JP2005149239A (ja) * 2003-11-17 2005-06-09 Nec Corp ユーザ認証システム
JP2019046060A (ja) * 2017-08-31 2019-03-22 キヤノン株式会社 権限委譲システム、制御方法、およびプログラム

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2019046059A (ja) 2017-08-31 2019-03-22 キヤノン株式会社 権限委譲システム、制御方法、およびプログラム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001186122A (ja) * 1999-12-22 2001-07-06 Fuji Electric Co Ltd 認証システム及び認証方法
JP2005149239A (ja) * 2003-11-17 2005-06-09 Nec Corp ユーザ認証システム
JP2019046060A (ja) * 2017-08-31 2019-03-22 キヤノン株式会社 権限委譲システム、制御方法、およびプログラム

Also Published As

Publication number Publication date
JP7636456B2 (ja) 2025-02-26
JP2024118884A (ja) 2024-09-02

Similar Documents

Publication Publication Date Title
EP1427160B1 (en) Methods and systems for authentication of a user for sub-locations of a network location
US8713644B2 (en) System and method for providing security in browser-based access to smart cards
US10382427B2 (en) Single sign on with multiple authentication factors
US9172541B2 (en) System and method for pool-based identity generation and use for service access
US8800003B2 (en) Trusted device-specific authentication
US8209394B2 (en) Device-specific identity
EP2842258B1 (en) Multi-factor certificate authority
US20080134314A1 (en) Automated security privilege setting for remote system users
US8490168B1 (en) Method for authenticating a user within a multiple website environment to provide secure access
JP7636456B2 (ja) サーバシステム及び不正ユーザ検知方法
US20080060060A1 (en) Automated Security privilege setting for remote system users
Alghawli Analysis of Authentication Methods and Secure Web Application Realization With an Integrated Authentication System
KR101066729B1 (ko) 네트워크 위치의 하위 위치에 대한 사용자의 인증을 위한 방법 및 시스템
Song et al. Building an independent integrated authentication service
WO2005060206A1 (en) Public key infrastructure credential registration
HK1066123B (en) Methods and systems for authentication of a user for sub-locations of a network location
WO2011063827A1 (en) Personal identity management system and method

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23924139

Country of ref document: EP

Kind code of ref document: A1