JP2018037025A - Program, authentication system, and authentication cooperative system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To reduce the risk of leakage of authentication information of a large number of users more than a system of conducting central control of authentication information of a user group can reduce the risk.SOLUTION: An authentication application 310 of a mobile apparatus 300 of a user has a user authentication unit for authenticating the user. In a user information DB 222 of an ID provider, information on an access destination for specifying the authentication application 310 of the mobile apparatus 300 of each user is registered. A service provider which has received a log-in request from a user requests an ID provider 200 to conduct authentication for the service provider. The ID provider 200 demands authentication from authentication application 310 of the mobile apparatus 300 of a user, using the access destination information for the user ID input by the user, receives the result of the authentication, and reports the result of the authentication to the service provider.SELECTED DRAWING: Figure 1

Description

  The present invention relates to a program, an authentication system, and an authentication cooperation system.

  In order to realize single sign-on, a mechanism that uses an authentication server or an ID provider conforming to an authentication linkage standard such as Open ID is becoming widespread.

  In addition, the following technologies are known as technologies for entrusting authentication of a user who has accessed to another system.

  The center server disclosed in Patent Literature 1 has a condition table for selecting an authentication device, manages a back-end Web system, and receives a request for requesting use of this system. When the client terminal sends a request, the center server receives the request, determines whether there is authenticated cookie information in the request, and if not, searches the condition table based on the request and selects an authentication device that performs authentication processing Then, request the authentication process to the selected authentication device. The selected authentication device performs an authentication process and returns an authentication result to the center server. The center server receives the authentication result, and if authentication is established, creates an authenticated cookie and transmits it to the client terminal.

  The system disclosed in Patent Document 2 includes a first terminal device that can be connected to an information server via a network line, and a second terminal device that can be connected to the information server via a communication line independent of the network line. The information server generates a new password, transmits it to the second terminal device via the communication line, and transmits it to the authentication server via the network line, and the second terminal device transmits the transmitted password. The first terminal device accepts the password from the user, transmits the password to the authentication server via the network line, and the authentication server transmits the password transmitted from the first terminal device and the information server. User authentication is performed according to the match with the password.

  In the method disclosed in Patent Document 3, a dedicated telephone number (called telephone number) is assigned to each authentication terminal for verifying authentication data used for authentication for personal authentication, and user authentication is performed from a mobile phone to a user. Make a call to the phone number assigned to the authentication terminal. Upon receiving this, the authentication center server identifies the authentication terminal from the destination telephone number (the destination telephone number transmitted by the user), and transmits the authentication data to the identified authentication terminal, so that the user can It is possible to reliably transmit authentication data used for authentication to an authentication terminal that receives personal authentication. In this method, user authentication data such as vein data is centrally managed by the authentication center server, and this authentication data is sent to the authentication terminal. Then, the authentication terminal performs authentication by comparing the authentication data received from the authentication center server with the data input by the user (for example, vein data read while holding the palm or the like).

JP 2010-205166 A Japanese Patent Laid-Open No. 2002-082910 JP 2011-215940 A

  In a method in which an authentication terminal acquires authentication information of a target user from a server that centrally manages authentication information and performs authentication based on this and data input by the user, the data input by the user goes out of the terminal device. Because there is no risk of leakage of input data. However, when the server is hacked, there is a risk that authentication information of a large number of users is leaked at one time.

  An object of the present invention is to reduce a risk that authentication information of a large number of users is leaked, as compared with a method of centrally managing authentication information of a group of users.

  According to the first aspect of the present invention, the storage means for storing information for identifying the personal authentication device of each user, and the storage means for receiving an authentication request including authentication information input from a user requesting use of a service device. Providing means for transmitting to the personal authentication device of the user using information stored in the service device and providing an authentication response to the service device according to an authentication result returned from the personal authentication device in response to the transmission; It is a program to make it function.

  In the invention according to claim 2, when the computer receives the authentication result indicating the authentication success from the personal authentication device with respect to the authentication information input from the user, the authentication result indicating the authentication success is received. In addition to further functioning as an authentication success holding means for holding the user in association with the user, the providing means has an authentication result indicating an authentication success corresponding to the user who has requested use of the service device in the authentication success holding means. 2. The program according to claim 1, wherein an authentication response indicating successful authentication is provided to the service device without transmitting the authentication request to the personal authentication device of the user.

  The invention according to claim 3 is a list of service devices in which the authentication success holding means applies the authentication result together with the authentication result indicating the authentication success from the personal authentication device to the authentication information input from the user. When the user is requested to use the second service device, the providing means stores the authentication result indicating the authentication success and the list in association with the user. When the authentication result indicating the authentication success corresponding to the user is in the authentication success holding means and the second service device is included in the list held in the authentication success holding means corresponding to the user, The program according to claim 2, wherein an authentication response indicating authentication success is provided to the second service device.

  In the invention according to claim 4, when the providing unit can obtain the authentication result by communicating with the personal authentication device of the user who requests use of the service device, the authentication result is obtained from the personal authentication device. And providing the authentication response according to the authentication result to the service device and communicating with the personal authentication device of the user requesting the use of the service device, the authentication result cannot be obtained, 3. The program according to claim 2, wherein if the authentication success holding means has an authentication result indicating an authentication success corresponding to the user, an authentication response indicating an authentication success is provided to the service device.

  According to a fifth aspect of the present invention, the providing unit cannot communicate with the personal authentication device of the user who requests the use of the service device to obtain the authentication result, and the authentication success holding unit includes the user. 5. The process of causing the user to receive a notification prompting confirmation of the personal authentication device when there is no authentication result indicating that the authentication has succeeded corresponding to is performed. It is a program.

  In the invention according to claim 6, when the attribute information of the user is requested from the service device, the attribute is stored in the personal authentication device of the user using the information stored in the storage unit. 6. The information processing apparatus according to claim 1, further requesting information and further functioning as attribute response means that responds to the service device with attribute information provided from the personal authentication device in response to the request. It is a program.

  In the invention according to claim 7, the attribute response means holds the attribute information of the user provided from the personal authentication device for a predetermined period, and the attribute information of the user again from the service device within the period. If the attribute information can be obtained by communicating with the personal authentication device of the user, the attribute information obtained from the personal authentication device is provided to the service device, and the user The program according to claim 6, wherein when the attribute information cannot be obtained by communicating with the personal authentication device, the held attribute information of the user is provided to the service device.

  The invention according to claim 8 stores in the storage means a storage means for storing information for identifying each user's personal authentication device, and an authentication request including authentication information input from a user who requests use of the service device. Providing means for transmitting to the personal authentication device of the user using the information being provided, and providing the service device with an authentication response according to an authentication result returned from the personal authentication device in response to the transmission. It is an authentication system.

  The invention according to claim 9 includes an authentication system and a personal authentication device for each user. The authentication system uses storage means for storing information for identifying each user's personal authentication device and use of the service device. An authentication request including authentication information input from the requesting user is transmitted to the personal authentication device of the user using information stored in the storage means, and returned from the personal authentication device in response to the transmission. Providing means for providing an authentication response according to an authentication result to the service device, wherein the personal authentication device authenticates whether the authentication information received from the authentication system is that of a user having the authentication device. And an authentication means for returning an authentication result to the authentication system.

  According to the first, eighth, or ninth aspect of the present invention, it is possible to reduce a risk that authentication information of a large number of users is leaked as compared with a method of centrally managing authentication information of a user group.

  According to the second aspect of the present invention, even if the authentication result cannot be obtained from the user's personal authentication device, if the authentication result indicating the authentication success acquired in the past is in the authentication success holding means, the service device is authenticated. A response can be made.

  According to the invention of claim 3, after receiving the authentication result indicating the authentication success from the user's personal authentication device, when the user intends to use the second service device to which the authentication result is applied, Authentication can be performed without accessing the authentication device.

  According to the invention of claim 4, personal authentication of a user is always performed in comparison with a case where an authentication response indicating authentication success acquired in the past is present in the authentication success holding means and an authentication response is made to the service device based on the authentication result. It is possible to reduce a delay in response when the authentication condition of the device is changed.

  According to the fifth aspect of the present invention, when the authentication result cannot be obtained from the personal authentication device of the user and there is no authentication result indicating the authentication success corresponding to the user, an authentication failure is simply returned to the service device. Compared with the method, the possibility that the user can use the service device can be increased.

  According to the invention which concerns on Claim 6, compared with the system which centrally manages the attribute information of a user group, the risk that the attribute information of many users leaks can be reduced.

  According to the invention of claim 7, even if the attribute information of the user cannot be obtained from the user personal authentication device, the attribute information is provided to the service device if the attribute information of the user acquired in the past is available. it can.

It is a figure which shows the example of the system configuration | structure of embodiment. It is a figure which shows an example of the flow of the user authentication in the system of embodiment. It is a figure which shows an example of the flow utilized in the authentication process corresponding to the authentication request | requirement from another service in the system of embodiment by the result of the user authentication performed with the mobile apparatus about a certain service. It is a figure which shows an example of the flow of a process when the service using a user attribute is requested | required in the system of embodiment. It is a figure which shows an example of the process sequence which the apparatus authentication request | requirement part of ID provider performs.

  FIG. 1 shows an example of the system configuration of this embodiment.

  This system includes a service provider 100, an ID provider 200, and an authentication application 310 in a mobile device 300 owned by a user.

  The service provider 100 is a system that provides some information processing service to the user. The user operates the user-side device 350 to access the service provider 100 via a network such as the Internet, and requests service provision. The user-side device 350 may be any device as long as it can communicate with the service provider 100 via a network, and examples thereof include a personal computer, a smartphone, a tablet terminal, a multifunction device, and a kiosk terminal. The service provider 100 requires ID information (identification information for identifying a user, hereinafter referred to as “user ID”) of the user to provide the service, but user authentication for identifying the user ID is performed. It does not execute it by itself, but requests user authentication from the ID provider 200. Although one service provider 100 is shown in the figure, there may be a plurality of service providers 100 that receive an authentication agency service of the ID provider 200 on a network such as the Internet.

  The ID provider 200 is a system that provides an authentication proxy service to various service providers 100 existing on the network. The ID provider 200 performs user authentication processing for the service provider 100 of the cooperation destination in accordance with, for example, a federated identity (Federated Identity) such as OpenID Connect, OpenID, SAML (Security Assertion Markup Language), or an authentication cooperation standard, Authentication result information including the user ID obtained as a result is provided to the service provider 100. The provided user ID is, for example, ID information registered by the user in the ID provider 200, and the service provider 100 identifies the user by the user ID.

  The ID provider 200 of the present embodiment accepts user authentication requests from a plurality of service providers 100 on the network, but does not execute user authentication itself. It is the authentication application 310 executed by the mobile device 300 owned by the user that actually executes the user authentication. Therefore, the ID provider 200 only needs to know the user ID among the authentication information necessary for authenticating the user, and the remaining information in the authentication information, that is, the user to be authenticated corresponds to the user ID. We do not manage information such as passwords to prove that. The ID provider 200 associates the user ID with information for specifying an access destination (authentication application 310 of the mobile device 300 in the illustrated example) for the actual authentication of the user instead of proof information such as a password. As long as it holds. When authenticating a user in response to a request from the service provider 100, the ID provider 200 sends authentication information (for example, a combination of a user ID and a password) input by the user to the mobile device 300 indicated by the access destination information. Request authentication. Then, according to the response of the authentication result from the authentication application 310 of the mobile device 300 to the request, the authentication result information is provided to the service provider 100 that is the authentication request source.

  The mobile device 300 is an information processing device carried by a user, and a smartphone or a tablet terminal is an example. An authentication application 310 is installed in a computer built in the mobile device 300. The authentication application 310 holds information necessary for authenticating a user having the mobile device 300. Then, using this stored information, the authentication request from the ID provider 200 is authenticated, and the authentication result is returned to the ID provider 200. Note that the user side device 350 used by the user to receive a service from the service provider 100 and the mobile device 300 may be the same device.

  Each element of the system will be described in more detail.

  The service provider 100 includes a user authentication request unit 110, a service token management unit 120, and a user attribute request unit 130. When receiving a login request to the user's service provider 100 from the user-side device 350, the user authentication request unit 110 issues an authentication request to the linked ID provider 200. When the service token management unit 120 receives a service access token from the ID provider 200 in response to the authentication request, the service token management unit 120 manages the token. The service access token is information that proves that the user to whom the token is issued has the use qualification for the service of the service provider 100. When a valid service access token corresponding to a user is managed by the service token management unit 120, the user can use the service of the service provider 100. The user attribute requesting unit 130 provides attributes to the ID provider 200 when the service provider 100 provides a service to the user and the user's attribute information (for example, a user name and a department to which the user belongs) is required. Make a request. When receiving a response of attribute information from the ID provider 200 in response to the attribute request, the received attribute information is transferred to the service provider 100 for the service.

  The ID provider 200 includes a device authentication request unit 210, an authentication device management unit 220, a user token management unit 230, and a user attribute acquisition unit 240.

  The device authentication request unit 210 receives an authentication request for a user from the user authentication request unit 110 of the service provider 100, and in this example, an authentication application 310 of the mobile device 300, which is a user side device that actually performs the authentication. , Issue an authentication request. At this time, the device authentication request unit 210 acquires access destination information for specifying an access destination device for the authentication (that is, the authentication application 310 of the mobile device 300 in this example) from the authentication device management unit 220, and the access The authentication application 310 of the mobile device 300 is accessed using the destination information, and an authentication request is sent. If the user authentication by the authentication application 310 is successful, the mobile device access token is returned from the authentication application 310.

  The authentication device management unit 220 includes a user information DB (database) 222. In the user information DB 222, as shown in FIG. 2, an access destination for a device (the mobile device 300 or in particular the authentication application 310 in the device) that actually authenticates the user corresponding to the user ID in association with the user ID. Information is registered. The access destination information is identification information that uniquely identifies each mobile device 300 or the authentication application 310 installed in the mobile device 300. For example, the access destination information is given to the mobile device 300 or an authentication application installed on the mobile device 300 from a push notification service such as GCM (Google Cloud Messaging) (Google, Google Cloud Messaging is a trademark) or APNS (Apple Push Notification Service). The registered ID or device token may be used. As another example, a combination of the mobile phone number of the mobile device 300 and the application name of the authentication application 310 may be used as the access destination information. Each user sets access information indicating the authentication application 310 of his / her mobile device 300 in the user information DB 222.

  The user token management unit 230 holds token information 232. As illustrated in FIG. 2, the token information 232 includes a mobile device access token received by the device authentication request unit 210 from the authentication application 310 of the mobile device 300.

  In response to the attribute request from the user attribute request unit 130 of the service provider 100, the user attribute acquisition unit 240 acquires the attribute information of the user related to the attribute request from the authentication application 310 of the mobile device 300, and the acquired attribute information is This is provided to the attribute request unit 130.

  The computer in the mobile device 300 functions as the user authentication unit 312 and the user attribute management unit 316 by executing the installed authentication application 310. The user authentication unit 312 performs user authentication in response to a request from the device authentication request unit 210 of the ID provider 200. The user authentication unit 312 manages the authentication information / corresponding service list 314. The authentication information / corresponding service list 314 includes user authentication information and a corresponding service list. Of these, the authentication information is authentication information of the user who has the mobile device 300, and is, for example, a set of the user ID and password of the user. This authentication information is registered by the user in the ID provider 200, but the ID provider 200 does not manage the authentication information itself, and the user's own device (mobile device 300) takes charge of the management. The corresponding service list is a list of service providers 100 to which the authentication information corresponds. That is, the user authentication unit 312 performs user authentication in response to an authentication request from the user for the service provider 100 included in the corresponding service list.

  The user attribute management unit 316 manages attribute information (user attribute 318) of the user who has the mobile device 300. The user attribute 318 includes items such as name, e-mail address, telephone number, department, position, etc. In response to a request from the user attribute acquisition unit 240 of the ID provider 200, the user attribute management unit 316 provides information on an item that is a target of the request in the managed user attribute 318.

  Next, with reference to FIG. 2, a processing flow of the present system when a user having the mobile device 300 logs in to the service provider 100 having the identification name “service XYZ” will be described.

  (1) A certain user AAA accesses the service XYZ from the user side device 350 and transmits a login request including a user ID (“User-AAA”) and a password (PW). In this example, the user AAA has not been authenticated by the ID provider 200 for the most recent period, and the ID provider 200 has valid information indicating that the user AAA has been authenticated (access to a mobile device described later). Token) is not held.

  (2) The user authentication request unit 110 of the service XYZ sends an authentication request including the user ID and password received from the user AAA to the ID provider 200.

  When the user authentication request unit 110 accesses from a user who is not logged in (or a user whose valid service access token is not held in the service token management unit 120), the user authentication request unit 110 identifies the access according to the authentication cooperation protocol. You may redirect to the provider 200. In this case, the user directly inputs an authentication request including the user ID and password to the ID provider 200, and the password is not known to the service XYZ.

  (3) When receiving the authentication request including the user ID and password, the device authentication request unit 210 of the ID provider 200 obtains access destination information corresponding to the user ID from the user information DB 222. Then, an authentication request including the user ID and password is transmitted to the authentication application 310 of the mobile device 300 indicated by the access destination information. Although illustration is omitted, the device authentication request unit 210 determines whether there is a valid mobile device access token (described later) corresponding to the user ID in the user token management unit 230 before transmitting this authentication request. Check out. In this example, since there is no such token, an authentication request is transmitted to the authentication application 310.

  (4) The user authentication unit 312 of the authentication application 310 of the mobile device 300 performs user authentication for the authentication request received from the ID provider 200. That is, it is determined whether the authentication information included in the authentication request, that is, the combination of the user ID and the password matches the authentication information held by itself. If it is determined that they match, the user authentication is successful (OK), and if it is determined that they do not match, the authentication is failure (NG).

  At this time, the user authentication unit 312 notifies the user that the authentication is requested from the service XYZ (or the user registered service) from the output device (for example, display) of the mobile device 300, and the authentication is performed. The user may be inquired whether permission is permitted. In this case, if the user gives an instruction not to allow authentication, the user authentication unit 312 fails the authentication result even if the authentication information presented by the user matches the authentication information held (NG ). When the user gives an instruction to permit authentication, the user authentication unit 312 obtains an authentication result according to whether or not the authentication information presented by the user matches the authentication information held.

  When the user authentication is successful, the user authentication unit 312 generates an access token (denoted as “Token-Moble-AAA” in the figure) for the mobile device 300. This access token is called a mobile device access token. The mobile device access token is information certifying that the authentication application 310 has authenticated the user. The ID provider 200 can access the authentication application 310 by presenting the mobile device access token (for example, in the case of user attribute acquisition described later). The mobile device access token includes expiration date information. This expiry date is, for example, the date and time when a predetermined time is added to the date and time when the token is generated. The authentication application 310 stores the mobile device access token provided to the ID provider 200 (at least until its expiration date).

  If the user authentication is successful, the user authentication unit 312 reads identification information (referred to as a service ID) of the service provider 100 corresponding to the set of the user ID and password from the corresponding service list. If the corresponding service list includes a plurality of service IDs corresponding to the set, the plurality of service IDs are read out. In the illustrated example, the service XYZ (service ID is “Service-XYZ”) and the service LMN (same “Service-LMN”) are included in the corresponding service list, so these two service IDs are read out.

  The user authentication unit 312 then sends authentication result information including the read list of service IDs (“token issue permission service”) and the generated mobile device access token “Token-Moble-AAA” to the ID provider 200. return.

  When the user authentication fails, the user authentication unit 312 returns authentication result information indicating that (authentication NG) to the ID provider 200.

  (5) Upon receiving the authentication result information from the authentication application 310 of the mobile device 300, the device authentication request unit 210 of the ID provider 200 returns an authentication result corresponding to the authentication result information to the user authentication request unit 110 of the service XYZ.

  That is, when the authentication result from the authentication application 310 is successful (OK) (that is, when the mobile device access token is included in the authentication result), the device authentication request unit 210 receives the service access token (in the figure, “ Token-UserAAA ”). The service access token is information indicating that the ID provider 200 guarantees that the user who is the target of the token has been authenticated. Further, the service access token includes information on an expiration date (for example, a date and time when a predetermined time is added to the date and time of generation). The device authentication request unit 210 returns an authentication result including the service access token to the user authentication request unit 110.

  If the authentication result from the authentication application 310 is unsuccessful (NG), the service authentication token is not returned to the user authentication request unit 110 but information indicating that the authentication has failed is simply returned.

  Further, when the mobile device access token is included in the authentication result from the authentication application 310, the device authentication request unit 210 sends the authentication result to the user token management unit 230 in parallel with the transmission of the authentication result to the user authentication request unit 110. Then, information such as a mobile device access token and a token issuance permission service included in the authentication result is registered. In the illustrated example, the user token management unit 230 includes items of “user ID”, “service”, “mobile device access token”, and “token issue permission service”. “User ID” is the user ID (“User-AAA” in the illustrated example) of the user who is the target of the mobile device access token received this time (that is, the user to be authenticated). “Service” is identification information (“Service-XYZ” in the illustrated example) of the service provider 100 (service XYZ in the illustrated example) that has sent the current authentication request. The “mobile device access token” is data of a mobile device access token responded from the authentication application 310 (“Token-Mobile-AAA” in the illustrated example). The “token issuance permission service” is a list of token issuance permission services (“Service-XYZ” and “Service-LMN” in the illustrated example) returned from the authentication application 310 together with the mobile device access token. However, the mobile device access token registered in the user token management unit 230 includes information on the expiration date, and when the expiration date has passed, the ID provider 200, for example, designates the entry as a user token management unit. In addition, although not shown, the mobile device access token entry corresponding to the user ID in the user token management unit 230 also records the service access token issued based on the token.

  (6) When the authentication result from the device authentication request unit 210 of the ID provider 200 is authentication success (OK), the user authentication request unit 110 of the service XYZ uses the service access token included in the authentication result as the login request source. Are registered in the service token management unit 120 in association with the user ID of the user. At this time, the expiration date information set in the service access token is also registered in association with the service access token. Then, the user authentication request unit 110 permits the login of the user AAA (user side device 350) as the login request source. Thereafter, the service provider 100 receives a request from the user and executes a service according to the request.

  At this time, the user authentication request unit 110 may provide data such as a cookie including a service access token or information associated therewith to the user side device 350. The user side device 350 presents the data such as the cookie for subsequent access to the service XYZ, for example, without performing the login process again until the expiration date of the service access token expires. Get permission to use.

  Further, if the authentication result from the device authentication request unit 210 of the ID provider 200 is authentication failure (NG), the user authentication request unit 110 does not permit the user AAA to log in and cannot log in to the user side device 350. Returns a response to the effect.

  FIG. 2 shows a case where the authentication is successful and the user AAA logs in to the service XYZ.

  In the above example, if a valid service access token corresponding to the user is in service XYZ, the user is immediately permitted to log in again, but this is only an example. As another example, when the service XYZ has a valid service access token corresponding to the user who requests login, the service XYZ requests the ID provider 200 to verify the token, and allows login according to the verification result. It may be controlled whether or not. That is, when the service XYZ receives a response indicating that the service access token has been successfully verified from the ID provider 200, the service XYZ permits the user to log in, and otherwise rejects the login.

  As described above, whether the service access token is validated by the service XYZ or the ID provider 200, the authentication on the user's mobile device 300 (authentication application 310) is omitted if the service access token is valid. May be. In this way, it is possible to determine whether or not to allow login even when the mobile device 300 cannot be accessed from the ID provider 200 or the like.

  Next, with reference to FIG. 3, the flow of the login process to the service LMN of the user AAA is shown. This flow is similar to that shown in FIG. 2, after the user AAA successfully logs in the service XYZ, before the expiration date of the mobile device access token “Token-Mobile-AAA” held in the ID provider 200 expires, This is a case where the service LMN is requested to log in.

  (1) User AAA makes a login request to service LMN. At this point, it is assumed that the service LMN does not hold a valid service access token corresponding to the user AAA.

  (2) The user authentication request unit 110 of the service LMN requests the ID provider 200 to authenticate the user AAA. The user authentication request unit 110 accepts the login request and processes the authentication request to the ID provider 200 are the same as steps (1) and (2) in FIG.

  (3) The device authentication request unit 210 of the ID provider 200 checks whether a valid mobile device access token corresponding to the user ID in the authentication request is in the user token management unit 230. In the illustrated example, a valid mobile device access token “Token-Mobile-AAA” corresponding to the user AAA is found. The device authentication request unit 210 refers to the information in the user token management unit 230, and checks whether the token issue permission service corresponding to the found mobile device access token includes the service LMN that is the transmission source of the authentication request. judge. In the illustrated example, the service LMN (“Service-LMN”) is included in the token issuance permission service of “Token-Mobile-AAA”. Further, the device authentication request unit 210 confirms that the found mobile device access token has not expired. In the illustrated example, it is assumed that the mobile device access token “Token-Mobile-AAA” has not expired. In this case, the device authentication request unit 210 generates a service access token (“Token-UserAAA ′”) for the service LMN without sending an authentication request to the authentication application 310.

  When a valid mobile device access token corresponding to the user ID included in the authentication request is not found from the user token management unit 230, the device authentication request unit 210 sends the authentication request to the authentication application 310 of the mobile device 300. Transfer and ask for authentication (example in FIG. 2 above).

  (4) The device authentication request unit 210 responds to the user authentication request unit 110 of the service LMN with an authentication result including the generated service access token “Token-UserAAA ′” for the service LMN.

  (5) Upon receiving this response, the user authentication request unit 110 registers the service access token “Token-UserAAA ′” included in the authentication result in the service token management unit 120, and at the same time, logs in the user AAA (user side) Allow login of device 350).

  In the example of FIG. 3, while the mobile device access token received from the mobile device 300 is valid, the ID provider 200 accesses the service with the authority of the token for the authentication request from the token issuance permission service corresponding to the token. Issue a token. For this reason, while the mobile device access token is valid, the authentication request to the authentication application 310 of the mobile device 300 is omitted. This is the same as the case where the user AAA logged out from the service XYZ after the login shown in FIG. 2 logs into the service XYZ again while the mobile device access token “Token-Mobile-AAA” is valid.

  In the above example, while the mobile device access token “Token-Mobile-AAA” is valid, the ID provider 200 responds to the authentication request from the service provider 100 without accessing the authentication application 310 of the user AAA. As another example, when the mobile device access token “Token-Mobile-AAA” is valid, if the authentication application 310 of the user AAA can be accessed, the ID provider 200 accesses the authentication application 310 and makes an authentication request. May be. As a result, even when the setting is changed by the authentication application 310 of the user AAA, authentication is performed according to the latest setting as much as possible. For example, the user AAA may delete one of the service providers 100 from the corresponding service list with respect to the authentication application 310, and prompting for such a setting change by asking the authentication application 310 for authentication as much as possible. Is dealt with. When the mobile device access token is valid in this way and the authentication application 310 of the token issuer is requested to authenticate again and this is successful, the authentication result including the new mobile device access token is the issuer. Provided by. In this case, the ID provider 200 updates the original mobile device access token in the user token management unit 230 to the newly provided one, and also updates the token issue permission service information to the newly provided one.

  2 and 3 described above, the user who requests the login to the service provider 100 is first input both the user ID and the password. Instead, the information that the user inputs first is used instead. Only the user ID may be used. In this case, the device authentication request unit 210 has a valid mobile device access token in the user token management unit 230 corresponding to the input user ID and including the service provider 100 in the “token issue permission service”. Determine whether or not. If there is, the device authentication request unit 210 provides the service provider 100 with a service access token based on the mobile device access token without requiring the user to input a password. If there is no mobile device access token that matches such a condition in the user token management unit 230, the device authentication request unit 210 sends a password to the user directly or via the user authentication request unit 110 of the service provider 100. An input is requested and the password and user ID are sent to the user's mobile device 300 for authentication.

  Next, after the successful login of the user AAA shown in FIG. 2 to the service XYZ, the flow of processing when the user AAA requests the service XYZ for a service that requires the user's attribute information is shown in FIG. This will be described with reference to FIG. In this example, it is assumed that the expiration date of the service access token “Token-UserAAA” of the user AAA held in the service XYZ has not passed.

  (1) The user AAA requests the logged-in service XYZ to execute a certain process. It is assumed that this process is a process that requires a certain attribute (for example, an e-mail address) of the user AAA.

  (2) The user attribute request unit 130 of the service XYZ acquires a valid service access token “Token-UserAAA” corresponding to the user AAA from the service token management unit 120, and sends a user attribute request including this token to the ID provider 200. Send to. This user attribute request may include request item information for specifying a requested attribute item (for example, an e-mail address). The user attribute request may include the service ID “Service-XYZ” of the service XYZ that is the request source.

  (3) Upon receiving the user attribute request, the user attribute acquisition unit 240 of the ID provider 200 verifies the validity of the service access token “Token-UserAAA” included in the request. This verification may be the same as the general token verification in the authentication cooperation field. For example, it is confirmed that there is no falsification, that the ID provider 200 itself has issued, that there is an issued record, that the expiration date has not passed. As a result of the verification, if it is found that the user attribute is not valid, the user attribute acquisition unit 240 returns an error response indicating that the service XYZ has no attribute acquisition authority.

  As a result of the verification, when the service access token “Token-UserAAA” in the user attribute request is valid, the user attribute acquisition unit 240 obtains the valid mobile device access token “Token” of the user corresponding to the token “Token-UserAAA”. -Mobile-AAA "is acquired from the user token management unit 230. Further, the access destination information of the user is acquired from the user information DB 222.

  Then, using the access destination information, a user attribute request including the mobile device access token “Token-Mobile-AAA” is transmitted to the authentication application 310 of the mobile device 300 of the user AAA. This request may include request item information for specifying the requested attribute item, and service ID “Service-XYZ” of the service XYZ requesting the attribute.

  (4) Upon receiving the user attribute request from the ID provider 200, the user attribute management unit 316 of the authentication application 310 verifies the validity of the mobile device access token included therein. This verification may be the same as the general token verification in the authentication cooperation field.

  As a result of the verification, when it is found that the token is not valid, the user attribute management unit 316 returns a response indicating that the attribute cannot be provided to the ID provider 200.

  As a result of the verification, when it is found that the token is valid, the user attribute management unit 316 transmits the managed user attribute 318 to the ID provider 200. In one example, the user attribute request requests all attributes of the user, and the user attribute management unit 316 transmits all of the held user attributes 318 in response to the request. In another example, when the user attribute request includes request item information specifying the attribute item requested by the service XYZ, only the value of the attribute item indicated by the request item information among the user attributes 318 is used as the ID provider. 200. In addition, the user may previously set attribute items that may be disclosed to the service provider 100 for each service provider 100 in the user attribute management unit 316. In this case, in response to a user attribute request from the ID provider 200, the user attribute management unit 316 may include all of the attribute items that may be disclosed to the service provider 100 that requested the request, or an item requested by the user attribute request. Only to the ID provider 200.

  (5) The user attribute acquisition unit 240 of the ID provider 200 returns the user attribute transmitted from the authentication application 310 to the requesting service XYZ.

  (6) The user attribute request unit 130 of the service XYZ executes the process requested by the user AAA using the user attribute information received from the ID provider 200.

  Note that the user attribute acquisition unit 240 of the ID provider 200 may store (cache) information on the user attribute 318 acquired from the authentication application 310 for a predetermined period. In this case, when the user attribute acquisition unit 240 receives a user attribute request from the service XYZ during that period, the user attribute acquisition unit 240 may respond to the request using the stored information without making a request to the authentication application 310. . In addition, in response to a user attribute request from the service XYZ, when the user attribute cannot be acquired from the user's mobile device 300 in response to using the user attribute stored (cached) by the user attribute acquisition unit 240 ( For example, it may be limited to when communication is not possible. When the user attribute can be acquired from the mobile device 300, the latest user attribute is acquired from the mobile device 300, and the acquired user attribute is provided to the service XYZ.

  In this system, user attribute information is collectively managed by the user's mobile device 300. Although the ID provider 200 may temporarily cache the attribute information of the user, the original attribute information is only in the mobile device 300. Therefore, even in a situation where there are a plurality of ID providers 200 used by the user, the user need only register his / her attribute information in his / her mobile device 300 and maintain it correctly. This is because, even if various services request user attributes from any of these ID providers 200, the ID providers 200 acquire the attributes from the mobile device 300 of the user and provide them to the service. In the method of registering user attribute information in each ID provider 200, when a change occurs in the user attribute, the user needs to make necessary changes to his / her attribute information registered in all those ID providers 200. On the other hand, in this system, the user only needs to change the user attribute information registered in the mobile device 300.

  In the above, the authentication device that is actually in charge of user authentication is the mobile device 300, but this is only an example. The authentication device may be a personal computer of a user who is not portable, for example.

  Next, an example of a processing procedure of the device authentication request unit 210 of the ID provider 200 will be described with reference to FIG. This procedure is one variation of the processing flow illustrated with reference to FIGS.

  The device authentication request unit 210 receives a user authentication request from the service provider 100, and acquires the user ID and password input by the user to be authenticated (S10). Next, the device authentication request unit 210 obtains access destination information corresponding to the acquired user ID from the user information DB 222, and tries to access the authentication application 310 of the user's mobile device 300 using the access destination information (S12). ). If this access is successful (the determination result in S14 is Yes), the user ID and password are passed to the access destination authentication application 310 to request authentication (S16), and authentication result information for this request is acquired from the authentication application 310. (S18). Then, an authentication result corresponding to the content (OK / NG) of the authentication result information is returned to the service provider 100 (S20), and if the authentication result information includes information such as a mobile device access token, the information is converted into a user token. Register in the management unit 230.

  If the access-destination authentication application 310 cannot be accessed in S12 (No in S14), the device authentication requesting unit 210 determines that the mobile device access token corresponding to the user ID has not expired and the user token is managed. It is checked whether it is in the unit 230 (S22). If there is (the determination result in S22 is Yes), the device authentication requesting unit 210 checks whether or not the service provider 100 is included in the “token issue permission service” (for example, see FIG. 2) of the mobile device access token. . If it is included, the authentication is successful, and an authentication success (OK) result including the service access token is returned to the service provider 100 (S24). If the service provider 100 is not included in the “token issue permission service”, an authentication result indicating an authentication failure (NG) is returned to the service provider 100 (S24).

  In S22, when the mobile device access token corresponding to the user ID to be authenticated is not in the user token management unit 230, the device authentication request unit 210 cannot access the authentication device (mobile device 300) registered by the user, so that user authentication is performed. A message (for example, a web page including the message) indicating that the user cannot check the status of the device and logging in again after confirming the state of the device is notified to the user (the user-side device 350 in FIG. 2). This notification may be performed via the service provider 100 (when the user ID and password are acquired from the service provider 100) or may be performed directly from the ID provider 200 (redirected from the service provider 100 by the ID provider 200). When the user ID and password are received directly from the user). If authentication cannot be performed because the user's mobile device 300 is turned off or the like, the user activates the mobile device 300 in response to this message, and then logs in to the service provider 100 from the user side device 350 again. Is requested, this time, the mobile device 300 is authenticated.

  The processing procedure of the device authentication request unit 210 of the ID provider 200 has been described above with reference to FIG. 5, but the user attribute acquisition unit 240 of the ID provider 200 may perform processing in the same framework. That is, when the user attribute information is requested from the service provider 100, the user attribute acquisition unit 240 is assumed to have the user attribute information acquired in the past if the user's mobile device 300 can be accessed. Also, the latest attribute information is acquired from the mobile device 300 and provided to the service provider 100. When the mobile device 300 cannot be accessed, if the attribute information of the user acquired in the past is present, the mobile device 300 responds to the service provider 100 using the attribute information.

  As described above, in this embodiment, the ID provider 200 functions as a window for receiving a user authentication request and a user attribute acquisition request to many service providers 100 on the network. Actual user authentication and provision of user attributes are performed by the individual user authentication application 310 registered in the ID provider 200. For this reason, even if the ID provider 200 is hacked, only the access destination information of each user is leaked, and many user IDs, passwords, user attributes and the like are not leaked together. If the user changes the password or user attribute registered in the authentication application 310 of his / her mobile device 300, the change is applied to all the service providers 100 that cooperate.

  The embodiments of the present invention have been described above. The ID provider 200 exemplified above is realized by causing a computer to execute a program representing the above-described functions of the ID provider 200. Here, the computer includes, for example, a microprocessor such as a CPU, a memory (primary storage) such as a random access memory (RAM) and a read only memory (ROM), a flash memory, an SSD (solid state drive), an HDD as hardware. (Hard disk drive) and other controllers that control fixed storage devices, various I / O (input / output) interfaces, network interfaces that perform control for connection to a network such as a local area network, etc. via, for example, a bus Connected to each other. A program in which the processing contents of these functions are described is stored in a fixed storage device such as a flash memory via a network or the like, and is installed in a computer. The program stored in the fixed storage device is read into the RAM and executed by a microprocessor such as a CPU, thereby realizing the functional module group exemplified above.

100 service provider, 110 user authentication request unit, 120 service token management unit, 130 user attribute request unit, 200 ID provider, 210 device authentication request unit, 220 authentication device management unit, 230 user token management unit, 232 token information, 240 user Attribute acquisition unit, 300 mobile device, 310 authentication application, 312 user authentication unit, 314 authentication information / corresponding service list, 316 user attribute management unit, 318 user attribute, 350 user side device.

Claims (9)

Computer
Storage means for storing information for identifying each user's personal authentication device;
An authentication request including authentication information input from a user requesting use of a service device is transmitted to the user's personal authentication device using information stored in the storage means, and the individual is responded to the transmission. Providing means for providing the service device with an authentication response corresponding to the authentication result returned from the authentication device;
Program to function as. The computer,
Authentication success holding means for holding the authentication result indicating the authentication success in association with the user when the authentication result indicating the authentication success is received from the personal authentication device with respect to the authentication information input from the user ,
And further function as
The providing unit does not transmit the authentication request to the personal authentication device of the user when the authentication result indicating the authentication success corresponding to the user who requested the use of the service device is in the authentication success holding unit. Providing an authentication response indicating successful authentication to the service device,
The program according to claim 1. If the authentication success holding means receives a list of service devices to which the authentication result is applied together with the authentication result indicating successful authentication from the personal authentication device for the authentication information input from the user, The authentication result indicating success and the list are stored in association with the user,
In the case where use of the second service device is requested by the user, the providing means has an authentication result indicating successful authentication corresponding to the user in the authentication success holding means, and corresponding to the user If the second service device is included in the list held in the authentication success holding means, an authentication response indicating a successful authentication is provided to the second service device;
The program according to claim 2, wherein: If the providing means can obtain the authentication result by communicating with the personal authentication device of the user who requests the use of the service device, the providing means obtains the authentication result from the personal authentication device and uses the authentication result as the authentication result. If the authentication result cannot be obtained by communicating with the personal authentication device of the user who requests the use of the service device by providing the corresponding authentication response to the service device, the user is sent to the authentication success holding means. If there is an authentication result indicating successful authentication corresponding to, an authentication response indicating successful authentication is provided to the service device.
The program according to claim 2, wherein: The providing means cannot communicate with the personal authentication device of the user who requests use of the service device to obtain the authentication result, and the authentication success holding means authenticates the authentication success corresponding to the user. When there is no result, a process for causing a notification for prompting confirmation of the personal authentication device to be transmitted to the user is performed.
The program according to claim 4. The computer,
When the attribute information of the user is requested from the service device, the attribute information is requested from the personal authentication device of the user using the information stored in the storage means, and the individual is responded to the request. Attribute response means for responding to the service device with attribute information provided from the authentication device;
The program according to any one of claims 1 to 5, further functioning as: The attribute response means holds the attribute information of the user provided from the personal authentication device for a predetermined period, and if the attribute information of the user is requested again from the service device within the period, the user If the attribute information can be obtained by communicating with the personal authentication device, the attribute information obtained from the personal authentication device is provided to the service device and communicated with the personal authentication device of the user. If the attribute information cannot be obtained, the attribute information of the user that is held is provided to the service device.
The program according to claim 6. Storage means for storing information for identifying each user's personal authentication device;
An authentication request including authentication information input from a user requesting use of a service device is transmitted to the user's personal authentication device using information stored in the storage means, and the individual is responded to the transmission. Providing means for providing the service device with an authentication response corresponding to the authentication result returned from the authentication device;
Including authentication system. Including an authentication system and a personal authentication device for each user;
The authentication system includes:
Storage means for storing information for identifying each user's personal authentication device;
An authentication request including authentication information input from a user requesting use of a service device is transmitted to the user's personal authentication device using information stored in the storage means, and the individual is responded to the transmission. Providing means for providing the service device with an authentication response corresponding to the authentication result returned from the authentication device;
Including
The personal authentication device includes:
Authentication means for authenticating whether the authentication information received from the authentication system belongs to a user having the authentication device, and returning an authentication result to the authentication system;
An authentication linkage system characterized by including: