Information processing apparatus, authentication method, information processing system, and program
Patent Information
- Application Number
- JP2023128666
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2023-08-07
- Publication Date
- 2025-02-20
AI Technical Summary
【0008】 本開示によれば、ユーザによるサービスプロバイダの利用状態を考慮したリスクベース認証が提供される。
Smart Images

Figure 2025024501000001_ABST
Abstract
Description
[Technical field]
[0001] The present invention relates to an information processing device, an authentication method, an information processing system, and a program. [Background technology]
[0002] In recent years, service providers have been providing various services to users via networks. Service providers usually provide services with authenticated users logged in. OpenID Connect (Non-Patent Document 1) is widely used as a method for service providers to authenticate users using an authentication server. The authentication server authenticates users using any authentication method. As an authentication method that can be used by such authentication servers, risk-based authentication that ensures security without impairing user convenience is known. In risk-based authentication, a high-strength authentication such as multi-factor authentication is requested of a user only when a risk level is determined to be high. Information on the access environment such as terminal information and geographical information of the user to be authenticated, and information on the service provider accessed by the user to be authenticated are used to determine the risk level. For example, Patent Document 1 discloses a method for determining the risk level according to user attributes (such as account balance) and transaction attributes (whether or not the operation involves a transfer of funds) at the service provider. Patent Document 2 discloses a method for changing the authentication strength according to the security level required by the service provider. [Prior art documents] [Patent documents]
[0003] [Patent Document 1] JP 2010-097467 A [Patent Document 2] JP 2010-225078 A [Non-patent literature]
[0004] [Non-Patent Document 1] OpenID Connect 1.0(https: / / openid.net / specs / openid-connect-core-1_0.html) Summary of the Invention [Problem to be solved by the invention]
[0005] However, general risk-based authentication as typified by Patent Documents 1 and 2 is based on the access environment of the user at the time of access and the state of the user at the service provider. In other words, the state of past accesses to the service provider by the user to be authenticated is not reflected in the risk level.
[0006] The present disclosure aims to provide risk-based authentication that takes into account a user's usage status of a service provider. [Means for solving the problem]
[0007] An information processing device according to one aspect of the present invention has the following configuration. a first authentication means for authenticating a user identified by an authentication request from a service provider through a first authentication process in response to the authentication request; a determination means for determining whether or not additional authentication is required for the user authenticated by the first authentication means, based on a history of authentication of the user performed in response to a request from the service provider; The device further includes a second authentication means for authenticating the user through a second authentication process different from the first authentication process when it is determined that additional authentication is required. Effect of the Invention
[0008] According to the present disclosure, risk-based authentication is provided that takes into account a user's usage of a service provider. [Brief description of the drawings]
[0009] [Figure 1]FIG. 1 is a diagram showing an example of the configuration of an authentication system. [Diagram 2] FIG. 4 is a block diagram showing an example of the hardware configuration of an authentication server. [Diagram 3] FIG. 1 is a block diagram showing an example of the functional configuration of an authentication system. [Figure 4] FIG. 1A is a diagram showing an example of information managed by a user management unit, FIG. 1B is a diagram showing an example of information managed by a service provider management unit, and FIG. 1C is a diagram showing an example of information managed by an authentication history management unit. [Diagram 5] 4 is a flowchart showing a process performed by the authentication system according to the embodiment. [Figure 6] 10 is a flowchart showing an authentication process performed by an authentication server according to the embodiment. [Figure 7] 13A to 13D are diagrams showing examples of authentication request and token request messages. [Figure 8] 6A and 6B are diagrams showing an example of an authentication screen. [Figure 9] FIG. 13A is a diagram showing an example of information managed by a user management unit of the second embodiment, and FIG. 13B is a diagram showing an example of information managed by a service provider management unit of the third embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0010] Hereinafter, the embodiments will be described in detail with reference to the attached drawings. Note that the following embodiments do not limit the invention according to the claims. Although the embodiments describe a number of features, not all of these features are essential to the invention, and the features may be combined in any manner. Furthermore, in the attached drawings, the same reference numbers are used for the same or similar configurations, and duplicated descriptions are omitted.
[0011] First Embodiment Hereinafter, in each embodiment, an information processing device, an information processing system, and an authentication method that perform risk-based authentication will be described. [System Configuration] An example of the system configuration of the authentication system according to the first embodiment will be described with reference to the block diagram of Fig. 1. The authentication system 10 includes an authentication server 101, a service provider 102, and a user terminal 103. The authentication server 101, the service provider 102, and the user terminal 103 can communicate with each other via a network 104. The network 104 may be configured as a single network such as a LAN, or may be configured as a mixture of multiple networks such as the Internet and a LAN.
[0012] The authentication server 101 is an information processing device that authenticates a user. The service provider 102 is an information processing device that provides a service to a user (user terminal 103). When providing a service to a user (user terminal 103), the service provider 102 requests the authentication server 101 to authenticate the user. A service provider 102 may be prepared for each service, one service provider 102 may provide multiple services, or one service may be realized by multiple service providers 102. The user terminal 103 is a terminal operated by a user to use a service provided by the service provider 102, and is, for example, a personal computer (PC) or a mobile terminal (smartphone, tablet). In this embodiment, for the sake of simplicity, the authentication server 101 and the user terminal 103 are described as being one each, but each may be composed of multiple devices.
[0013] [Hardware configuration] Next, an example of the hardware configuration of the authentication server 101 constituting the authentication system 10 according to this embodiment will be described.
[0014] The authentication server 101 is an information processing device having a CPU 201, a RAM 202, a ROM 203, and a network interface 204. The CPU 201 controls the operation of each part constituting the authentication server 101, and executes various processes to be described later as those performed by the authentication server 101. The RAM 202 is a memory for temporarily storing data and control information, and functions as a work area used when the CPU 201 executes various processes. The ROM 203 stores fixed operating parameters, operating programs, etc. of the authentication server 101. The network interface 204 is an interface that provides a function for connecting to the network 104 and communicating. The authentication server 101 can send and receive data to and from an external device via the network interface 204. The external storage device 205 connected to the authentication server 101 is a device for storing data, and has an interface for receiving I / O commands for reading and writing data.
[0015] The external storage device 205 stores computer programs and data for causing the CPU 201 to execute each process, which will be described later as being performed by the authentication server 101. The external storage device 205 in this embodiment is a hard disk drive (HDD), but may be other storage devices such as a solid state drive (SSD), an optical disk drive, and a semiconductor storage device. The display device 206 connected to the authentication server 101 displays necessary information to the user. For example, an LCD (Liquid Crystal Display) or a CRT (Cathode Ray Tube) display is used as the display device 206, but other display devices may be used. The input device 207 is a keyboard, a mouse, or the like, and accepts necessary input from the user. A touch panel display in which the display device 206 and the input device 207 are integrated may be used.
[0016] The service provider 102 and the user terminal 103 can also be realized by an information processing device having a hardware configuration similar to that of the authentication server 101. However, when the user terminal 103 is a mobile terminal, the display device 206 is generally built into the user terminal 103 as a display unit.
[0017] [Function configuration] Next, an example of the functional configuration of the authentication system 10 according to this embodiment will be described with reference to the block diagram of FIG.
[0018] The authentication server 101 has, as functional units, a request processing unit 300, a first authentication unit 301, a second authentication unit 302, a risk determination unit 303, a user management unit 304, a service provider management unit 305, and an authentication history management unit 306. The user management unit 304 manages user information. The configuration of data (user information) managed by the user management unit 304 will be described later with reference to FIG. 4(a). The service provider management unit 305 manages information about the service provider 102. The configuration of data (service provider information) managed by the service provider management unit 305 will be described later with reference to FIG. 4(b). The authentication history management unit 306 manages the history of authentication of users requested by service providers. The configuration of data (authentication history information) managed by the authentication history management unit 306 will be described later with reference to FIG. 4(c).
[0019] The request processing unit 300 receives an authentication request from the service provider 102. In response to the authentication request, the first authentication unit 301 authenticates the user using a first authentication method. When the risk determination unit 303 determines that the risk level is high, the second authentication unit 302 performs additional authentication using a second authentication method different from the first authentication method. The first authentication unit 301 and the second authentication unit 302 authenticate the user using authentication information managed by the user management unit 304. In this embodiment, the first authentication unit 301 uses authentication using a password (first authentication method), and the second authentication unit 302 uses authentication using a secret question and answer (second authentication method). However, other authentication methods such as biometric authentication and one-time password (OTP) may be used. In addition, each of the first authentication unit 301 and the second authentication unit 302 may use two or more authentication methods. The authentication history by the first authentication unit 301 and the second authentication unit 302 is managed by the authentication history management unit 306.
[0020] The risk determination unit 303 determines the risk level at the time of authentication by the first authentication unit 301 based on information managed by the service provider management unit 305 and the authentication history management unit 306. When the risk determination unit 303 determines that the risk level is high, the second authentication unit 302 performs additional authentication, thereby realizing risk-based authentication. In general, information on the access source, such as IP address, geographical information, terminal information, and user agent information, is used to determine the risk level in risk-based authentication. In addition to these information, or instead of these information, the risk determination unit 303 of the present disclosure determines the risk level by taking into account the user's tendency to use the service provider based on information managed by the authentication history management unit 306. For example, if the user to be authenticated has a tendency to use the service provider that is different from normal, it can be determined that the risk level is high. Whether the tendency to use the service provider is different from normal can be determined by any method. For example, it can calculate the number of times of authentication, the authentication frequency, and the elapsed time since the previous authentication of the user to be authenticated from the history of authentication requests issued by the service provider 102, and determine whether the tendency to use the service provider is different from normal. More specifically, for example, when an authentication request is made for the first time for a user to be authenticated, or when no authentication request has been made for a certain period of time, it is determined that the usage tendency is different from normal.
[0021] [Data Structure] Next, a configuration example of data managed by the authentication server 101 according to this embodiment will be described.
[0022] FIG. 4(a) is an example of user information managed by the user management unit 304. In the user information 400, first authentication information and second authentication information are stored in association with a user ID, which is an identifier for uniquely identifying a user. The first authentication information and the second authentication information are used in the first authentication method and the second authentication method, respectively. In this example, a password is stored as the first authentication information, and a secret question and answer are stored as the second authentication information. Of course, the authentication method is not limited to these, and other authentication information, such as information related to biometric authentication, may be used. In addition, one type of authentication information is stored as each of the first authentication information and the second authentication information, but this is not limited thereto, and multiple types of authentication information may be stored.
[0023] FIG. 4B is an example of the service provider information managed by the service provider management unit 305. The service provider information 420 stores information required for authentication by OpenID Connect in association with a service provider ID, which is an identifier that uniquely identifies the service provider 102 that uses the authentication server 101. In the example of the service provider information 420 in FIG. 4B, a secret, a redirect URL, and a scope are stored in association with the service provider ID. The secret is used to evaluate the legitimacy of the service provider 102 when the service provider 102 acquires a token, which is authenticated user information. The redirect URL is used to evaluate the legitimacy of a transfer destination of an authentication request specified in an authentication request from the service provider 102. The scope is used to evaluate the legitimacy of an access range to a user attribute specified in an authentication request from the service provider 102. Note that, although the service provider information based on OpenID Connect is shown here, it is not limited thereto, and information required for other authentication methods may be stored.
[0024] FIG. 4(c) is an example of authentication history information managed by the authentication history management unit 306. In the authentication history information 440, authentication processing information such as authentication time, access source information, and authentication request attribute information from the service provider 102 is stored in association with a user ID, which is an identifier that uniquely identifies a user. Every time the first authentication unit 301 and the second authentication unit 302 perform authentication processing of a user, authentication processing information is additionally recorded in the authentication history information 440. In the authentication history information 440, an identifier of the service provider (service provider ID) and attributes described in a past authentication request issued by the service provider are held. The authentication time is the time when the authentication processing of the user was performed. The access source information is information about the access environment of the user. In this example, the IP address and the user agent are shown as the access source information, but other access source information such as geographical information and terminal information may be stored. The authentication request attribute is information about an attribute included in the authentication request from the service provider 102. In this example, the authentication request attributes in OpenID Connect, that is, a service provider ID, a redirect URL, and a scope, are shown as authentication request attributes, but other information may also be stored.
[0025] [Authentication system processing flow] Next, the flow of processing in the authentication system 10 according to this embodiment will be described with reference to the flowchart of FIG.
[0026] First, the user transmits a service request to the service provider 102 using the user agent 310 of the user terminal 103 (step S501). The service providing unit 308 of the service provider 102 receives this service request (step S502). If the user is not logged in to the service provider, the authentication request unit 307 transmits an authentication request to the authentication server 101 (step S503). An example of an authentication request message is shown in FIG. 7(a). The message in FIG. 7(a) is formed as a request conforming to the syntax of the HTTP (Hypertext Transfer Protocol) protocol. In the request line of the URL (Uniform Resource Locator) portion 701, GET is specified as the method, and the authentication server 101 is specified as the destination of the authentication request. In the illustrated example, Auth Server is the server name of the authentication server 101, and this specifies the authentication server 101. In addition, in the URL parameters of the URL portion 701, the service provider ID, redirect URL, and scope are specified by client_id=, redirect_uri=, and scope= as authentication request attributes. These attributes enable the authentication server 101 to identify the service provider that made the request, the destination to which the authentication result will be transferred, and the scope of permitted user information.
[0027] Returning to FIG. 5, when the request processing unit 300 of the authentication server 101 receives an authentication request (step S504), the first authentication unit 301, the second authentication unit 302, and the risk determination unit 303 execute authentication processing (step S505). Details of the authentication processing by the first authentication unit 301 and the second authentication unit 302 will be described later with reference to FIG. 6. When the user is authenticated by the authentication processing, the request processing unit 300 issues a temporary code indicating the authentication result and transmits it to the service provider 102 (step S506). An example of a message of the authentication result transmitted to the service provider 102 is shown in FIG. 7(b). The message shown in FIG. 7(b) is formed as a response according to the HTTP syntax. The status unit 702 includes a response line, and in the illustrated example, the status number "302 Found" is indicated. The header unit 703 includes a Location for redirecting the authentication result to the service provider 102, and a temporary code (code specified by code=) indicating the authentication result. The temporary code is used by the service provider 102 to obtain a token including authenticated user information.
[0028] Returning to FIG. 5, the authentication request unit 307 of the service provider 102 receives the authentication result message (temporary code) (step S507). The authentication request unit 307 transmits a token request using the temporary code included in the authentication result to the authentication server 101 (step S508). An example of the token request message using the temporary code is shown in FIG. 7(c). The message shown in FIG. 7(c) is formed as a request according to HTTP syntax, and the authentication server 101 is specified as the destination of the request. The URL part 704 includes a request line, and POST is specified as the method. In the header part 705, authentication information (credentials indicating the legitimacy of the service provider 102) is specified by Authorization. In addition, in the body part 706, the temporary code is specified.
[0029] Returning to FIG. 5, when the request processing unit 300 of the authentication server 101 receives the token request (step S509), it verifies the temporary code and the credentials indicating the legitimacy of the service provider included in the token request, and issues a token (step S510). The token is authenticated user information or data for accessing user information, such as an ID token or an access token of OpenID Connect. The token message is sent to the service provider 102. An example of the token message sent to the service provider 102 as a result of the token request is shown in FIG. 7(d). The message shown in FIG. 7(d) is formed as a response according to the HTTP syntax. A status (200 OK) indicating that the token request was successful is set in the response line of the status section 707. The ID token and the access token issued by the request processing unit 300 are set in the body section 708.
[0030] 5, the authentication request unit 307 of the service provider 102 receives the token (step S511). The service providing unit 308 acquires authenticated user information from the received token, puts the user in a logged-in state, and provides the service (step S512). The user can use the service in the logged-in state by using the user agent 310 (step S513).
[0031] [Authentication process flow] Next, the flow of authentication processing by the authentication server 101 according to this embodiment will be described with reference to the flowchart in Fig. 6. The authentication processing is mainly executed by the first authentication unit 301, the second authentication unit 302, and the risk determination unit 303.
[0032] The first authentication unit 301 authenticates the user by a first authentication method using first authentication information (step S601). In this embodiment, authentication using a password is performed as the first authentication method, but other authentication methods may be used. FIG. 8(a) shows an example of an authentication screen that the first authentication unit 301 presents to the user agent 310 of the user terminal 103. The authentication screen 801 includes an area 811 for inputting a user ID as authentication information, an area 812 for inputting a password, an OK button 813 for confirming the input authentication information and transmitting it to the authentication server 101, and a Cancel button 814 for discarding the input authentication information. When the OK button 813 is pressed, the user ID and password input in the areas 811 and 812 are transmitted from the user terminal 103 to the first authentication unit 301, and the first authentication unit 301 performs user authentication by referring to the user information 400 (user ID and first authentication information).
[0033] Returning to FIG. 6, the first authentication unit 301 judges whether or not the authentication by the first authentication method is successful (step S602). If the authentication is unsuccessful, an authentication failure process such as transferring an authentication error to the service provider 102 that made the authentication request is performed (step S603), and the process is terminated. On the other hand, if the authentication by the first authentication method is successful, the risk determination unit 303 determines whether or not additional authentication is required for the user who was successfully authenticated by the first authentication method based on the risk level in steps S604 to S605. First, the risk determination unit 303 acquires a risk level based on information at the time of authentication by the first authentication unit 301 and the authentication history information 440 managed by the authentication history management unit 306 (step S604).
[0034] In determining the risk level by the risk determination unit 303, in addition to the commonly used information on the access source, the usage tendency of the service provider by the user to be authenticated is used. The risk determination unit 303 combines the risk level obtained based on the information on the access source and the risk level obtained based on the usage tendency to determine the risk level used to determine whether additional authentication is required. The risk level based on the information on the access source is a risk level obtained by a common method based on the access environment, such as IP address, geographical information, terminal information, and user agent information. The risk level based on the usage tendency of the service provider is obtained based on the authentication history information 440. The risk determination unit 303 determines that the risk level is high when the usage tendency of the service provider by the user to be authenticated is different from normal. For example, information on the usage tendency, such as the number of times the service provider authenticates the user to be authenticated, the authentication frequency, and the elapsed time since the last authentication, can be obtained from the user ID, authentication time, and service provider ID of the authentication history information 440. When the risk determination unit 303 determines that the usage tendency is different from normal based on the information on the usage tendency, it sets a high risk level. More specifically, for example, the risk determination unit 303 determines that the usage tendency is different from normal when the service provider that issued the authentication request is a service provider that the user to be authenticated has never used before. Alternatively, for example, the risk determination unit 303 determines that the usage tendency is different from normal when the service provider that issued the authentication request has not made an authentication request for the user to be authenticated for a certain period of time or more. Alternatively, for example, the risk determination unit 303 determines that the usage tendency is different from normal when an authentication request is made for a combination of a service provider and a scope that the user to be authenticated has never used before, further taking into consideration the scope of the authentication request attribute. When the usage tendency is determined to be different from normal in this way, the risk determination unit 303 sets a higher risk level. The risk determination unit 303 obtains a final risk level by combining the value of the risk level determined based on the information of the access source and the value of the risk level determined based on the usage tendency (for example, a simple average, a weighted average, or the like of the obtained risk levels).
[0035] The first authentication unit 301 judges whether the risk level judged in step S604 is higher than a threshold (step S605). If the risk level is equal to or lower than the threshold (NO in step S605), additional authentication is not required, and the first authentication unit 301 regards the authentication as successful, records the authentication result in the authentication history management unit 306 (step S606), and ends the process. If the risk level is judged to be higher than the threshold (YES in step S605), the second authentication unit 302 authenticates the user using a second authentication method (step S607). In this embodiment, a secret question and answer are used as the second authentication method, but other authentication methods may be used. An example of an authentication screen presented by the second authentication unit 302 to the user agent 310 of the user terminal 103 is shown in FIG. 8(b). The authentication screen 802 has areas 821, 822 for inputting a secret question and answer as authentication information, an OK button 823 for confirming the input authentication information and sending it to the authentication server 101, and a Cancel button 824 for discarding the input authentication information. When the OK button 823 is pressed, the secret question and answer input in the areas 821, 822 are sent from the user terminal 103 to the first authentication unit 301, and the first authentication unit 301 performs user authentication by referring to the user information 400 (user ID and second authentication information).
[0036] 6, the second authentication unit 302 judges whether or not the authentication by the second authentication method is successful (step S608). If it is judged that the authentication is unsuccessful (NO in step S608), the second authentication unit 302 performs an authentication failure process (step S603) and ends the process. If it is judged that the authentication is successful (YES in step S608), the second authentication unit 302 records the authentication result as successful authentication in the authentication history management unit 306 (step S606) and ends the process.
[0037] [Effects of the first embodiment] As described above, the authentication server 101 according to the first embodiment judges the risk level based on information at the time of authentication processing by the first authentication method, and performs authentication by the second authentication method if the risk level is high. Here, the risk level is judged based on the generally used risk level determined based on information of the access source, as well as the risk level determined based on the history information of the authentication request attribute included in the authentication request from the service provider. This takes into account the usage tendency of the service provider by the user to be authenticated. For example, a high risk level value is set when the usage tendency of the service provider by the user is different from normal. In this way, by taking into account the usage tendency of the service provider by the user, it is possible to realize risk-based authentication with higher security and convenience.
[0038] <Second embodiment> In the first embodiment, an example was shown in which a risk level was determined using the usage trends of a service provider related to a user to be authenticated. In the second embodiment, a risk level is further determined using usage trends of a service provider related to a user who is highly related to the user to be authenticated. Note that the configuration of the authentication system in the second embodiment is similar to that of the authentication system 10 in the first embodiment, and therefore a description thereof will be omitted. The following mainly describes the parts that differ between the second embodiment and the first embodiment. Note that the same components as those in the first embodiment will be described with the same reference numerals as those used in the first embodiment.
[0039] [Data configuration of user management unit 304] User information managed by the user management unit 304 according to the second embodiment is shown in Fig. 9(a). The user management unit 304 manages user information 900 shown in Fig. 9(a) in addition to the user information 400 shown in Fig. 4(a). The user information 900 stores information about users who are highly related to the user, such as groups to which the user belongs, and social information such as friends and followers, in association with a user ID that uniquely identifies the user. For example, it is assumed that users who belong to the same group or users who are registered as friends or followers are highly related to each other and show the same usage tendency toward the service provider.
[0040] [Risk level determination process (S604)] The risk level determination process executed in step S604 in the second embodiment will be described. The risk determination unit 303 determines the risk level based on the user information 900 managed by the user management unit 304 in addition to the information at the time of authentication by the first authentication unit 301 and the authentication history information 440 managed by the authentication history management unit 306. That is, the risk determination unit 303 uses information on the access source and the service provider usage tendency information related to the user to be authenticated, as well as information on the service provider usage tendency related to the user to be authenticated, for determining the risk level. In this way, in the second embodiment, the risk level obtained for the user related to the user to be authenticated is taken into consideration. That is, multiple risk levels related to multiple users are obtained, and the necessity of additional authentication is determined based on the risk level obtained by combining these multiple risk levels. For the combination, a simple average, a weighted average (for example, the weight of the user to be authenticated is made larger than the weight of other related users), etc., for the multiple risk levels can be used. For example, even if the authentication request is from a service provider that the user to be authenticated has never used before, if the service provider is often used by users who are highly related to the user, the risk level is low.
[0041] [Effects of the second embodiment] As described above, when determining a risk level based on the usage tendency of a service provider, the authentication server 101 according to the second embodiment uses information on the usage tendency of not only the user to be authenticated but also users highly related to the user. This makes it possible to avoid uniformly determining that the risk level is high even for an authentication request from a service provider that the user to be authenticated uses for the first time or that the user to be authenticated uses infrequently. This makes it possible to realize flexible risk-based authentication that balances security and convenience.
[0042] <Third embodiment> In the first and second embodiments, an example was shown in which the risk level was determined using the usage tendency of the service provider of the authentication requester. In determining the risk level in the third embodiment, the usage tendency of a service provider that is highly related to the service provider of the authentication requester is further used. Note that the configuration of the authentication system in the third embodiment is the same as that in the first embodiment, and therefore a description thereof will be omitted. The following mainly describes the parts that differ between the third embodiment and the first embodiment. Note that the same components are described with the same reference numerals.
[0043] [Data configuration of user management unit 304] FIG. 9B shows the service provider information managed by the service provider management unit 305 according to the third embodiment. The service provider management unit 305 manages the service provider information 920 shown in FIG. 9B in addition to the service provider information 420 shown in FIG. 4B. The service provider information 920 stores information about service providers that are highly related to the service provider 102 in association with a service provider ID that uniquely identifies the service provider. A highly related service provider is, for example, a service provider that belongs to a group with the same service provider manager, or a service provider that is determined to be highly related based on the usage trends of many users. It is assumed that highly related service providers will show the same usage trends.
[0044] [Risk level determination process (S604)] The risk level determination process executed in step S604 in the third embodiment will be described. The risk determination unit 303 determines the risk level based on the service provider information 920 managed by the service provider management unit 305 in addition to the information at the time of authentication by the first authentication unit 301 and the authentication history information 440 managed by the authentication history management unit 306. That is, the risk determination unit 303 uses information on the usage trend of a service provider highly related to the service provider of the authentication request source in addition to the information on the access source and the usage trend of the service provider of the authentication request source for determining the risk level. In this way, in the third embodiment, the risk level obtained for a service provider related to the service provider of the authentication request source is taken into consideration. That is, multiple risk levels for multiple service providers are obtained, and the necessity of additional authentication is determined based on the risk level obtained by combining these multiple risk levels. For the combination, a simple average, a weighted average (for example, the weight of the service provider of the authentication request source is made larger than the weights of other service providers), etc. of the multiple risk levels can be used. For example, even if an authentication request is made from a service provider that the user to be authenticated has never used before, the risk level is low if the user has used a service provider that is closely related to the service provider in question.
[0045] [Effects of the third embodiment] As described above, when determining a risk level, the authentication server 101 according to the third embodiment uses not only the usage tendency of the service provider that originated the authentication request, but also information on the usage tendency of service providers that are highly related to the service provider. This makes it possible to avoid uniformly determining that the risk level is high even when an authentication request is made for the first time or from a service provider that is infrequently used, thereby realizing more flexible risk-based authentication.
[0046] <Other embodiments> Although the embodiment has been described above in detail, the present invention can be embodied, for example, as a system, an apparatus, a method, a program, or a recording medium (storage medium), etc. Specifically, the present invention may be applied to a system composed of multiple devices (for example, a host computer, an interface device, an imaging device, a web application, etc.), or may be applied to an apparatus composed of a single device.
[0047] The present invention can also be realized by a process in which a program for implementing one or more of the functions of the above-described embodiments is supplied to a system or device via a network or a storage medium, and one or more processors in a computer of the system or device read and execute the program. The present invention can also be realized by a circuit (e.g., ASIC) that implements one or more of the functions.
[0048] The disclosure of this specification includes the following information processing device, authentication method, information processing system, and program. (Item 1) a first authentication means for authenticating a user identified by an authentication request from a service provider through a first authentication process in response to the authentication request; a determination means for determining whether or not additional authentication is required for the user authenticated by the first authentication means, based on a history of authentication of the user performed in response to a request from the service provider; and second authentication means for authenticating the user through a second authentication process different from the first authentication process when it is determined that additional authentication is required. (Item 2) The information processing device according to item 1, characterized in that the determination means determines whether or not the additional authentication is necessary based on at least one of the number of authentications for the user, the authentication frequency, and the elapsed time since the previous authentication, which are obtained based on the authentication history. (Item 3) The method further includes a first storage means for storing authentication history information based on past authentication requests issued by a service provider, 2. The information processing device according to item 1, wherein the determination means refers to the authentication history information to acquire the authentication history used for determining whether the additional authentication is required. (Item 4) 4. The information processing device according to item 3, wherein the authentication history information includes, for each authentication request, an identifier of a user to be authenticated and an identifier of a service provider that has issued the authentication request. (Item 5) 5. The information processing device according to item 4, wherein the authentication history information includes at least one of a transfer destination of an authentication result and a scope to be included in the authentication result. (Item 6) 6. An information processing device according to any one of items 1 to 5, characterized in that if it is determined that the additional authentication is not required, the authentication result obtained by the first authentication means is determined as the final authentication result, and if it is determined that the additional authentication is required, the authentication result obtained by the second authentication means is determined as the final authentication result. (Item 7) 7. The information processing device according to any one of items 1 to 6, wherein the determination means determines whether additional authentication is required for the user based on information on an access source included in the authentication request. (Item 8) The information processing device described in any one of items 1 to 6, characterized in that the determination means determines whether or not the additional authentication is necessary based on a risk level obtained by combining a risk level obtained based on information about the access source included in the authentication request and a risk level obtained based on the authentication history. (Item 9) A second storage means for storing information indicating a group of users having a relationship with each of the plurality of users, The information processing device according to any one of items 1 to 8, characterized in that the determination means determines whether or not the additional authentication is required based further on the authentication history of users belonging to the same group as the user authenticated by the first authentication means. (Item 10) a third storage means for storing information indicating a group of related service providers for each of the plurality of service providers; The information processing device according to any one of items 1 to 9, characterized in that the determination means determines whether or not the additional authentication is necessary based further on a history of authentication of the user performed in response to a request from a service provider belonging to the same group as the service provider that issued the authentication request. (Item 11) a first authentication step of authenticating a user identified by an authentication request from a service provider through a first authentication process in response to the authentication request; a determination step of determining whether or not additional authentication is required for the user authenticated in the first authentication step, based on a history of authentication of the user performed in response to a request from the service provider; and if it is determined that additional authentication is required, authenticating the user through a second authentication process different from the first authentication process. (Item 12) An information processing device according to any one of items 1 to 10, the service provider; The service provider: a transmitting means for transmitting the authentication request; a receiving means for receiving an authentication result of the user by the information processing device; providing means for providing a service to the user in accordance with a result of the authentication. (Item 13) 11. A program for causing a computer to function as each of the means of the information processing device according to any one of items 1 to 10.
[0049] The invention is not limited to the above-described embodiments, and various modifications and variations are possible without departing from the spirit and scope of the invention. Accordingly, the following claims are appended to apprise the public of the scope of the invention.
Claims
1. a first authentication means for authenticating a user identified by an authentication request from a service provider through a first authentication process in response to the authentication request; a determination means for determining whether or not additional authentication is required for the user authenticated by the first authentication means, based on a history of authentication of the user performed in response to a request from the service provider; and second authentication means for authenticating the user through a second authentication process different from the first authentication process when it is determined that additional authentication is required.
2. 2 . The information processing apparatus according to claim 1 , wherein the determination means determines whether the additional authentication is necessary based on at least one of the number of authentications, the authentication frequency, and the time elapsed since the previous authentication for the user, which are acquired based on the authentication history.
3. The method further includes a first storage unit for storing authentication history information based on past authentication requests issued by the service provider, 2 . The information processing apparatus according to claim 1 , wherein the determination means refers to the authentication history information to acquire the authentication history used for determining whether the additional authentication is required.
4. 4. The information processing apparatus according to claim 3, wherein the authentication history information includes, for each authentication request, an identifier of a user to be authenticated and an identifier of a service provider that has issued the authentication request.
5. 5. The information processing apparatus according to claim 4, wherein the authentication history information includes at least one of a transfer destination of the authentication result and a scope to be included in the authentication result.
6. 2. The information processing device according to claim 1, wherein when it is determined that the additional authentication is not required, the authentication result obtained by the first authentication means is determined as the final authentication result, and when it is determined that the additional authentication is required, the authentication result obtained by the second authentication means is determined as the final authentication result.
7. The information processing apparatus according to claim 1 , wherein the determining means determines whether or not additional authentication is required for the user based on information on an access source included in the authentication request.
8. The information processing device according to claim 1, characterized in that the determination means determines whether or not the additional authentication is necessary based on a risk level obtained by combining a risk level obtained based on information about the access source included in the authentication request and a risk level obtained based on the authentication history.
9. A second storage means for storing information indicating a group of users having a relationship with each of the plurality of users, 2 . The information processing apparatus according to claim 1 , wherein the determining unit determines whether the additional authentication is required based on an authentication history of a user who belongs to the same group as the user authenticated by the first authentication unit.
10. a third storage unit for storing information indicating a group of related service providers for each of the plurality of service providers; 2. The information processing device according to claim 1, wherein the determination means determines whether or not the additional authentication is required based further on a history of authentication of the user performed in response to a request from a service provider belonging to the same group as the service provider that issued the authentication request.
11. a first authentication step of authenticating a user identified by an authentication request from a service provider through a first authentication process in response to the authentication request; a determination step of determining whether or not additional authentication is required for the user authenticated in the first authentication step, based on a history of authentication of the user performed in response to a request from the service provider; and if it is determined that additional authentication is required, authenticating the user through a second authentication process different from the first authentication process.
12. The information processing device according to claim 1 ; the service provider; The service provider: a transmitting means for transmitting the authentication request; a receiving means for receiving an authentication result of the user by the information processing device; providing means for providing a service to the user in accordance with a result of the authentication.
13. A program for causing a computer to function as each of the means of the information processing apparatus according to claim 1.
Citation Information
Patent Citations
Risk-based authentication system and risk-based authentication method
JP2010097467A
Authentication method, authentication system thereof, and authentication processing program thereof
JP2010225078A