System and control method thereof

Abstract

To solve the problem that transfer work is not safe or troublesome when transferring authority to another user.SOLUTION: When registering the second user as a transfer destination of the first user, the server 103 transmits a transfer source user ID and a registration request for a public key to be used for FIDO to the authentication terminal 102 of the second user. When the biometric authentication in response to the registration request is successful, the authentication terminal 102 creates a secret key and a public key to be used in FIDO, sends information including the public key to the server 103, and saves the transfer source user ID. When the public key is registered, the server 103 registers the transfer information. The transfer source user ID of the transfer information and a FIDO authorization request are sent to the authentication server 102 (S707). When the biometric verification (S709) in response to the verification request is successful, the verification device 102 determines whether or not the transfer source user ID matches the saved transfer source user ID (S710), and when the transfer source user ID matches the saved transfer source user ID, signs the challenge included in the verification request with the private key and sends the challenge to the server 103 (S711, S712). If the FIDO is successfully authenticated, the server 103 takes over (S716).SELECTED DRAWING: Figure 7

Description

[Technical Field]

[0001] The present invention relates to a system and a control method thereof. [Background technology]

[0002] FIDO (registered trademark) is an authentication system that includes biometric authentication. FIDO stands for Fast Identity Online. FIDO works by registering an authenticator, such as a user's device, in advance with an authentication server, whereby credentials such as a private key and user ID are registered in the authenticator, and a public key is registered in the authentication server. The authenticator also includes fingerprint and facial recognition methods for verifying the user's identity, which allows for highly secure authentication with simpler procedures than the traditional method of entering a user ID and password combination, and is used in a variety of situations.

[0003] Patent Document 1 discloses a technology that uses authentication by a third party using FIDO authentication as a method for recovering an account that a user can no longer access. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Patent Publication No. 2021-51395 Summary of the Invention [Problem to be solved by the invention]

[0005] Meanwhile, systems operated by organizations must ensure that users can access the system securely, and that appropriate permissions are assigned to each user's account for management purposes. For example, it is common for users to access secure systems by logging in using FIDO authentication, and for access rights to specific resources to be set only for specific accounts.

[0006] However, users who belong to an organization do not necessarily retain the access rights they have been granted. For example, there are cases where the work they are responsible for changes when they are transferred to another department, or where they no longer need access to the system after leaving the organization. In such cases, it is necessary to properly transfer the user's authority, etc., but depending on the situation, the transfer process may not be carried out safely or the transfer process itself may be time-consuming.

[0007] For example, one possible way to transfer the user ID and login password of the original user is to notify the new user verbally or by email, or to set a new user ID and initial password for the new user and notify them of this. However, this method could result in the user ID and password being leaked to a third party, which could allow access by a malicious user.

[0008] Additionally, if the original user used FIDO biometric authentication to log in, only the original user can log in. This can result in a lot of hassle during the transfer, such as having to delete FIDO biometric authentication and reset the account separately. Although the technology of Patent Document 1 makes it possible to recover an account, it does not take into consideration the case where it becomes necessary to take over the account.

[0009] The present invention has been made to solve the above-mentioned problems, and aims to provide a mechanism that enables the transfer of authority assigned to user information to another user easily and safely. [Means for solving the problem]

[0010] The present invention provides a system including a server that provides a service, a first terminal used by a first user registered with the service, and a second terminal used by a second user who is registered with the service and different from the first user, wherein the first terminal has a first request means that makes a first request to the server to register a target user who will take over authority assigned to user information of the first user who uses the first terminal, specifying the second user as the target user, and the server has a first authentication processing means that transmits a registration request for user identification information of the first user who will be the source user in the first request and a public key to be used in FIDO authentication to the second terminal used by the second user specified as the target user in the first request, a registration means that, when registration of the public key is completed, registers takeover information in which the first user is the source user and the second user is the target user, and a registration means that transmits the takeover information to the second terminal used by the second user who is registered as the target user in the registered takeover information. a second authentication processing means for transmitting user identification information of a user registered as the takeover source user and an authentication request for FIDO authentication in the second terminal; and a transfer means for performing a transfer process for granting, if the FIDO authentication is successful, the authority granted to the user information of the takeover source user to the user information of the takeover destination user in accordance with the transfer information, wherein the second terminal performs user authentication for the registration request, and, if the user authentication is successful, creates a pair of a private key and a public key to be used in the FIDO authentication and transmits information for registering the public key to the server; a storage means for storing the private key and the user identification information received in association with the registration request; and a fourth authentication processing means for performing user authentication for the authentication request, and, if the user authentication is successful, determines whether second identification information, which is the user identification information received from the server in association with the authentication request, matches first identification information, which is the stored user identification information, and, if they match, transmits an authentication result to the server, the authentication result including information obtained by signing information included in the authentication request with the stored private key.The present invention is characterized by having the following features. [Effects of the Invention]

[0011] According to the present invention, it is possible to easily and safely transfer the authority assigned to the user information to another user. [Brief explanation of the drawings]

[0012] [Figure 1] FIG. 1 is a diagram illustrating an example of the overall configuration of a system according to a first embodiment. [Figure 2] FIG. 2 is a diagram illustrating an example of the hardware configuration of each device in the present embodiment. [Figure 3] FIG. 2 is a diagram illustrating an example of the module configuration of each device in the first embodiment. [Figure 4] FIG. 4 is a diagram illustrating a takeover-related screen in the first embodiment. [Figure 5] FIG. 4 is a sequence diagram illustrating a user authentication process according to the embodiment. [Figure 6] FIG. 4 is a sequence diagram illustrating a takeover destination user setting process and a takeover destination user registration process according to the first embodiment. [Figure 7] FIG. 4 is a sequence diagram illustrating a takeover execution process according to the first embodiment. [Figure 8] 10 is a flowchart illustrating details of a takeover source user determination process in this embodiment. [Figure 9] FIG. 10 is a diagram illustrating an example of the overall configuration of a system according to a second embodiment. [Figure 10] FIG. 10 is a diagram illustrating an example of the module configuration of each device in the second embodiment. [Figure 11] FIG. 10 is a sequence diagram illustrating a takeover execution process according to the second embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0013] Hereinafter, embodiments of the present invention will be described with reference to the drawings. [First embodiment] In this embodiment, a method is disclosed in which a takeover source user sets and registers a takeover destination user, and the takeover is carried out by the takeover destination user.

[0014] <System configuration> FIG. 1 is a diagram illustrating an example of the overall configuration of a system according to a first embodiment of the present invention. 1, an authentication terminal 101 is an authentication terminal (device) owned by a user who is the source of the data transfer. An authentication terminal 102 is an authentication terminal owned by a user who is the destination of the data transfer. The authentication terminal 101 and the authentication terminal 102 are connected to each other via a local network 106. Furthermore, the application server 103, the authentication server 104, and the credential information management server 105 are connected via a global network .

[0015] The local network 106 is a communication network realized by, for example, any one or a combination of a LAN, a WAN, a telephone line, a dedicated digital line, an ATM or frame relay line, a cable television line, a wireless line for data broadcasting, and the like. The global network 108 has the same configuration as the local network 106 .

[0016] In the example shown in FIG. 1, authentication terminal 101 and authentication terminal 102 exist on the same local network, but they may belong to different local networks and be connected via global network 108. It is assumed that the user who uses authentication terminal 101 and the user who uses authentication terminal 102 are different users, and that each user is registered with the service provided by application server 103 .

[0017] <Hardware configuration of authentication terminal and information processing device> First, the hardware configuration of the authentication terminals 101 and 102 will be described. 2(a) is a diagram showing an example of the hardware configuration of the authentication terminals 101 and 102. Here, the authentication terminals that make up the authentication terminals 101 and 102 are simply referred to as "authentication terminals."

[0018] The authentication terminal includes a CPU 201 that executes software stored in a storage device, a hard disk drive (HDD) 203. The CPU 201 controls all the hardware components connected to a system bus 204. The memory 202 functions as the main memory, work area, etc. of the CPU 201 . The HDD 203 is a large-capacity storage device that records data. Note that the configuration may include other storage devices such as an SSD (Solid State Drive) or an eMMC (embedded MultiMediaCard) instead of or in addition to the HDD.

[0019] A UI control unit 205 controls input from an input device 206 such as a touch panel. The network control unit 207 exchanges data bidirectionally with other nodes via the network. The TPM (Trusted Platform Module) 208 is a tamper-resistant storage device that prevents stored data from being read from an external source for the purpose of processing and storing confidential information. In this embodiment, the TPM 208 manages credential information, such as biometric information itself used for authentication and a private key corresponding to the biometric information.

[0020] The biometric information sensor 209 is a sensor that reads biometric information of a user using the authentication terminal, and reads information such as the user's fingerprint, vein pattern, voiceprint, iris, and facial image and converts it into a signal. The biometric information sensor 209 is realized using a dedicated reader such as a fingerprint sensor, a camera, a microphone, etc.

[0021] Next, the hardware configurations of the application server 103, the authentication server 104, and the credential information management server 105 will be described. 2(b) is a diagram showing an example of the hardware configuration of each information processing device constituting the application server 103, the authentication server 104, and the credential information management server 105. Here, each information processing device constituting the application server 103, the authentication server 104, and the credential information management server 105 will be simply referred to as an "information processing device."

[0022] The information processing device includes a CPU 210 that executes software stored in a storage device, that is, an HDD 212. The CPU 210 controls each piece of hardware connected to a system bus 213 in an overall manner. The memory 211 functions as the main memory, work area, etc. of the CPU 210 . The HDD 212 is a large-capacity storage device that records data. Note that the configuration may include other storage devices such as an SSD or eMMC instead of or in addition to the HDD.

[0023] The input control unit 214 controls input from an input device 215 such as a keyboard. Depending on the role of the information processing device, the input control unit 214 and the input device 215 may not be provided. The display control unit 216 controls the display on a display device 217 such as a liquid crystal display. Depending on the role of the information processing device, the display control unit 216 and the display device 217 may be omitted. The network control unit 218 exchanges data bidirectionally with other nodes via the network.

[0024] In this embodiment, each of the information processing devices constituting the application server 103, the authentication server 104, and the credential information management server 105 is realized by an information processing device provided as a cloud computing service. Cloud computing includes serverless computing and virtual machines. In cloud computing, multiple hardware resources shown in FIG. 2 are used. Each of the application server 103, the authentication server 104, and the credential information management server 105 may be realized by one physical machine or multiple physical machines.

[0025] <Functional configuration> FIG. 3 is a block diagram showing an example of the functional configuration of the authentication terminals 101 and 102, the application server 103, the authentication server 104, and the credential information management server 105 in the first embodiment. (Authentication terminal) The authentication terminals 101 and 102 each include a browser 310 , an authentication client 320 , and an authenticator 330 .

[0026] The browser (Web browser) 310 provides functions such as interpreting HTML (HyperText Markup Language) and displaying Web pages, accepting input from a user, and sending requests. In this embodiment, the browser 310 provides functions for displaying a takeover setting screen, a takeover destination registration screen, and a takeover execution screen provided by the application server 103. Examples of these screens are shown in FIG. 4.

[0027] FIG. 4 is a diagram showing an example of a screen provided by the application server 103 and displayed on the browser 310 of the authentication terminal. FIG. 4(a) corresponds to an example of a takeover destination setting screen, FIG. 4(b) corresponds to an example of a takeover destination registration screen, and FIG. 4(c) corresponds to an example of a takeover execution screen. In this embodiment, a takeover setting screen is displayed on the browser 310 of the authentication terminal 101 of the takeover source user, and a takeover destination registration screen and a takeover execution screen are displayed on the browser 310 of the authentication terminal 102 of the takeover destination user.

[0028] Returning to the explanation of Figure 3 below. The authentication client 320 provides a function for controlling the registration of credential information and the authentication process in the takeover destination registration process and the takeover execution process, which will be described later. The credential information will be described in the functional description of the credential information storage unit 332, which will be described later. Note that the authentication client 320 is not limited to these functions and may also provide a function for controlling the registration of credential information and the authentication process according to general FIDO.

[0029] The authentication device 330 includes a biometric authentication processing unit 331 , a credential information storage unit 332 , and a biometric information management unit 333 . The biometric authentication processing unit 331 provides a function to request the user to input biometric information and a function to execute biometric authentication. Biometric authentication is executed by a process to confirm that the biometric information received from the user exists in a biometric information table held by the biometric information management unit 333. The biometric information and the biometric information table will be described in the functional description of the biometric information management unit 333. In addition, the biometric authentication processing unit 331 provides a function to create credential information. The credential information will be described in the functional configuration of the credential information storage unit 332.

[0030] The credential information storage unit 332 provides a function of storing, in the TPM 208, for example, the credential information created when executing the takeover destination user setting process described later. Table 1 shows an example of a credential information table stored in the credential information storage unit 332 of the authentication terminal 101. [Table 1] Table 2 shows an example of the credential information table stored in the credential information storage unit 332 of the authentication terminal 102. [Table 2]

[0031] As shown in Tables 1 and 2, the credential information record in the credential information table includes an authentication information ID, a secret key, a user ID, a source user ID, and a service URL. The authentication information ID is an ID that uniquely identifies the authentication information. The user ID is an ID that uniquely identifies the user information (user identification information). The source user ID is the user ID of the source user. The service URL is the URL of the service provided by the application server 103.

[0032] The biometric information management unit 333 manages the biometric information stored in the authentication device 330 . Table 3 shows an example of a biometric information table managed by the biometric information management unit 333 of the authentication terminal 101. [Table 3] Table 4 shows an example of a biometric information table managed by the biometric information management unit 333 of the authentication terminal 102. [Table 4] As shown in Tables 3 and 4, the biometric information record in the biometric information table includes a user ID and a biometric information ID that is an ID that uniquely identifies the biometric information.

[0033] (Application Server 103) The application server 103 includes a takeover information management unit 340 , an authentication processing unit 341 , and a credential registration processing unit 342 . The takeover information management unit 340 manages takeover information used in the takeover destination setting process, takeover destination registration process, and takeover execution process, which will be described later. Table 5 shows an example of a handover information table managed by the handover information management unit 340 of the application server 103. [Table 5]

[0034] As shown in Table 5, the takeover information record of the takeover information table includes a takeover ID, a takeover source user ID, a takeover destination user ID, and a parameter indicating the takeover status. The takeover ID is identification information that uniquely identifies the takeover information. The takeover source user ID is identification information that uniquely identifies the takeover source user. The takeover destination user ID is identification information that uniquely identifies the takeover destination user. The takeover status includes parameters such as "not registered" which indicates that the takeover destination setting process has been completed, "registered" which indicates that the takeover destination registration process has been completed, and "taken over" which indicates that the takeover execution process has been completed.

[0035] The authentication processing unit 341 provides a function for requesting the credential information management server 105 to acquire information about a user who uses a service provided by the application server 103. The authentication processing unit 341 acquires the user authentication result from the credential information management server 105. In this embodiment, OpenID Connect is used for user authentication, but other authentication methods such as HTTP authentication (Basic authentication / Digest authentication) may also be used.

[0036] The credential registration processing unit 342 provides a function to receive a credential registration request from the authentication terminals 101 and 102 and transmit the credential registration request to the authentication server 104. The credential registration processing unit 342 also provides a function to receive a credential registration result from the authentication terminals 101 and 102 and transmit a request to the authentication server 104 to verify the credential registration result.

[0037] (Authentication Server 104) The authentication server 104 includes an authentication request management unit 350 and a public key management unit 351 . The authentication request management unit 350 provides a function to receive a credential information creation request sent from the application server 103 and to send a challenge at the time of credential registration. The authentication request management unit 350 also provides a function to verify the credential information creation result sent from the authentication terminals 101 and 102 and to send the creation result to the application server 103. The authentication request management unit 350 also provides a function to send a request to the public key management unit 351 to save the public key information included in the credential information creation result.

[0038] The public key management unit 351 provides a function of receiving a public key storage request sent from the authentication request management unit 350 and storing the public key. Table 6 shows an example of a public key table managed by the public key management unit 351. [Table 6] As shown in Table 6, a public key record in the public key table includes a credential ID and a public key.

[0039] (Credential information management server 105) The credential information management server 105 includes a credential information management unit 360 , a credential synchronization control unit 361 , and a user management unit 362 . The credential information management unit 360 receives credential information registration requests from the authentication terminals 101 and 102 and stores the credential information. In addition, the credential information management unit 360 provides a function of receiving requests from the authentication terminals 101 and 102 to send URLs linked to the credential information, and transmitting the URLs of the credential information linked to the users who use the authentication terminals 101 and 102 in a batch.

[0040] Table 7 shows an example of a credential information table held by the credential information management unit 360. [Table 7] As shown in Table 7, the credential information record in the credential information table includes an authentication information ID, a secret key, a user ID, and a service URL.

[0041] The credential synchronization control unit 361 provides a function of receiving a credential information synchronization request from the authentication terminals 101 and 102 and transmitting credential information linked to the user who uses the authentication terminals 101 and 102 to the authentication terminals 101 and 102 .

[0042] The user management unit 362 provides a function to hold user information of users who use the authentication terminals 101 and 102. The user management unit 362 also provides a function to receive a user authentication request from the application server 103, perform user authentication processing, and issue token information for using the application server 103. In addition, the user management unit 362 provides a function to authenticate users who use the credential management server 105 when using the function to synchronize credential information provided by the credential management server 105. In this embodiment, authentication is performed using the HTTP authentication method (Basic authentication / Digest authentication), but another authentication method such as OpenID Connect may also be used.

[0043] Table 8 is an example of a user information table held in the user management unit 362. [Table 8] As shown in Table 8, the user information record in the user information table contains a user ID and a password.

[0044] <User authentication process> The user authentication process will be described with reference to FIG. In order for the user of the authentication terminal 101, 102 to perform the takeover destination setting process, takeover destination registration process, and takeover execution process described below, it is necessary to verify whether the user is registered with the service. In this process, authentication information of the user using the credential information management server 105 is used to authenticate the service provided by the application server 103.

[0045] 5 is a sequence diagram illustrating the processing of the authentication terminal 101, application server 103, and credential information management server 105 in the user authentication processing of this embodiment. Here, the description will be given using the authentication terminal 101 as an example of an authentication terminal, but the processing is similar for other authentication terminals. In addition, the processing of the authentication terminal 101 in this diagram is realized by the CPU 201 of the authentication terminal 101 reading a program stored in the HDD 203 into the memory 202 and executing it. In addition, the processing of the application server 103 and the credential information management server 105 is realized by the CPU 210 of each server reading a program stored in the HDD 212 into the memory 211 and executing it.

[0046] When the user authentication process starts, in S501, the browser 310 of the authentication terminal 101 transmits a login request to the service to the application server 103. When the application server 103 receives this request, the process proceeds to S502.

[0047] In S502, the authentication processing unit 341 of the application server 103 creates and stores a nonce (number used once) associated with the session. A nonce is a disposable random character used during encrypted communication. A specific example is "1 999 888 777 666 555 444".

[0048] Next, in S503, the authentication processing unit 341 of the application server 103 transmits an access request to the credential information management server 105 to the authentication terminal 101. For example, a callback URL (set in the application server 103 itself) and the nonce created in S502 above are assigned as parameters, and the request is redirected to the credential information management server 105. In response to this, the browser 310 of the authentication terminal 101 redirects to the credential information management server 105, and an authentication screen (not shown) of the credential information management server 105 is displayed on the browser 310. When authentication information (here described as a user ID and password) of the user using the authentication terminal 101 is entered on this authentication screen and an instruction to execute authentication is given, the browser 310 of the authentication terminal 101 proceeds to S504.

[0049] In S504, the browser 310 of the authentication terminal 101 sends an authentication request to the credential information management server 105. This authentication request includes the user ID and password of the user who uses the authentication terminal 101. Here, the description will be given assuming that the user ID is "user001" and the password is "userpass1". When the credential information management server 105 receives the authentication request, it proceeds to S505.

[0050] In S505, the user management unit 362 of the credential information management server 105 verifies the user ID and password included in the authentication request received from the authentication terminal 101. If this user ID and password combination exists in a user information table such as Table 8 held by the user management unit 362 (if verification is successful), the user management unit 362 stores the nonce that was assigned as the above parameter, linking it to the session, and proceeds to S506.

[0051] Table 9 shows an example of a nonce information table held by the user management unit 362. [Table 9] As shown in Table 9, the nonce information record in the nonce information table includes a session ID, which is an identifier for the session, and a nonce.

[0052] In S506, the user management unit 362 of the credential information management server 105 transmits the authorization code to the authentication terminal 101. For example, the authorization code is assigned as a parameter, and the authentication terminal 101 is redirected to the application server 103 set as the callback URL. In response to this, the authentication terminal 101 proceeds to S507. The authorization code is a time-limited token issued from an authorization endpoint, and a specific example is "dd1231FBC3123a987=".

[0053] In S507, the browser 310 of the authentication terminal 101 transmits the authorization code to the application server 103. Upon receiving this authorization code, the application server 103 advances the process to S508.

[0054] In S508, the authentication processing unit 341 of the application server 103 sends an ID token and nonce acquisition request along with the authorization code to the credential information management server 105. An ID token is a token defined in OpenID Connect that proves that the user who made the issuance request has been authenticated.

[0055] Here, we will explain about ID tokens. An ID token consists of a header, payload, and signature, in that order. Note that it may not include a signature. Specific examples of ID tokens are shown below, but are not limited to these.

[0056] (Header) { “typ”: “assertion”, “alg”: “ES256”, “kid”: “aaaaaaaa-bbbb-1111-8888-999999999999”} (payload) { “response_type”: “id_token”, “redirect_url”: “http: / / example_srv.com / customer”, “iss”: “ODBIMWUwasdasd123UUUMXw”, “sub”: “dXIIMM123KKllss”, “iat”: 1903144999, "exp": 1903149999 } (signature)

[0057] When the credential information management server 105 receives the request to acquire the ID token and nonce, the process proceeds to S509. In S509, the user management unit 362 of the credential information management server 105 transmits the ID token and the nonce from S505 to the application server 103. For example, the ID token including the nonce is transmitted. Upon receiving the ID token and the nonce, the application server 103 proceeds to S510.

[0058] In S510, the authentication processing unit 341 of the application server 103 verifies the ID token and nonce. For example, the nonce verification verifies whether it matches the nonce saved in S502 above. If the nonce verification is successful, the authentication processing unit 341 deletes the nonce saved in S502 above. Note that if the authentication processing unit 341 succeeds in verifying the ID token and nonce, it determines that authentication is successful; on the other hand, if these verifications fail, it determines that authentication is unsuccessful. Next, in S511, the authentication processing unit 341 of the application server 103 transmits the authentication result to the authentication terminal 101, and the process ends.

[0059] The user authentication process is not limited to the example shown in this embodiment. For example, authentication may be performed directly to the application server 103 using a user ID and password for using the application server 103, or authentication may be performed using FIDO using credential information for using the application server 103 in advance and biometric information stored in the authentication terminals 101 and 102.

[0060] <Transfer destination user settings and registration process> The takeover destination user setting process and the takeover destination user registration process will be described with reference to FIG. 6 is a sequence diagram showing the processes of the authentication terminal 101 of the takeover source user, the authentication terminal 102 of the takeover destination user, the application server 103, and the authentication server 104 in the takeover destination user setting process and the takeover destination user registration process of this embodiment. In this diagram, the processes of the authentication terminals 101 and 102 are respectively realized by the CPU 201 of each authentication terminal loading a program stored in the HDD 203 into the memory 202 and executing it. Furthermore, the processes of the application server 103 and the authentication server 104 are respectively realized by the CPU 210 of each server loading a program stored in the HDD 212 into the memory 211 and executing it.

[0061] First, the "takeover destination user setting process" shown in S601 to S604 will be described. In S601, the authentication terminal 101 performs user authentication processing with the application server 103, making it possible to use the services of the application server 103. The user authentication processing has already been explained in FIG. 5, and therefore will not be explained here. If this user authentication processing is successful, a screen for using the services of the application server 103 is sent from the application server 103 and displayed on the browser 310 of the authentication terminal 101. For example, when a predetermined operation is performed on this screen, a takeover destination setting screen such as that shown in FIG. 4(a) is displayed on the browser 310 of the authentication terminal 101. When the user using the authentication terminal 101 inputs (specifies) the user ID of the takeover destination user on this takeover destination setting screen and instructs setting (the "Register" button in the example of FIG. 4(a)), the browser 310 of the authentication terminal 101 proceeds to processing in S602. Note that the user ID of the takeover destination user may be input by selecting and inputting from the user IDs of users registered in the services of the application server 103.

[0062] In S602, the browser 310 of the authentication terminal 101 sends a takeover destination user setting request to the application server 103. At this time, the takeover destination user setting request includes the takeover source user ID and the takeover destination user ID. Note that the user ID of the user using the authentication terminal 101 authenticated in S601 above is set as the takeover source user ID, and the user ID of the takeover destination user entered on the takeover destination setting screen is set as the takeover destination user ID. Furthermore, before sending the user takeover request, the process may include a step of sending a takeover information acquisition request to the application server 103, causing the UI control unit 205 to display the takeover source user ID included in the acquired takeover information, and having the takeover destination user ID confirmed by the takeover destination user. When the application server 103 receives this takeover destination user creation request, the process proceeds to S603.

[0063] In S603, the handover information management unit 340 of the application server 103 checks whether the user information identified by the handover source user ID and the handover destination user ID included in the handover destination user setting request received from the authentication terminal 101 exists on the application server 103. If both user information exist, the handover information including the handover information ID issued to uniquely identify the handover information is saved as a record in the handover information table as shown in Table 5. The handover information also includes a handover status parameter, to which a value indicating "unregistered" is set. The value of the handover status parameter is not limited to the above example, and may be a character string such as "Unregistered" or may be expressed as a specific numeric value.

[0064] Next, in S604, the handover information management unit 340 of the application server 103 sends a handover destination user setting request to the authentication terminal 102 identified from the handover destination user ID included in the handover information. Note that the user information identified from the handover destination user ID stored in the application server 103 includes an email address, terminal information, etc. The handover destination user setting request may be sent to the authentication terminal 102 by sending an email to the aforementioned email address, or by sending a push notification based on the terminal information.

[0065] Next, the "takeover destination user registration process" shown in S605 to S621 will be described. In S605, the authentication terminal 102 performs user authentication processing with the application server 103, thereby enabling the use of the services of the application server 103. The user authentication processing has already been described, and therefore will not be described here. For example, the user of the authentication terminal 102 may start the user authentication processing of S605 by accessing the application server 103 from the browser 310 of the authentication terminal 102 using the URL included in the takeover destination user setting request received in S604. In this case, if the user authentication processing is successful, for example, a takeover destination registration screen such as that shown in FIG. 4B is sent from the application server 103 to the authentication terminal 102 and displayed on the browser 310 of the authentication terminal 102. Alternatively, the user authentication processing of S605 may be started simply by accessing the application server 103 from the authentication terminal 102. After the user authentication processing is successful, the user may access the application server 103 from the browser 310 of the authentication terminal 102 using the URL included in the takeover destination user setting request received in S604, and receive the takeover destination registration screen such as that shown in FIG. 4B. In addition, after the user authentication process in S605 above is successful, the application server 103 may be configured to receive a takeover destination registration screen such as that shown in Figure 4(b) by allowing the user authenticated in S605 above to select one from a list of takeover information set as the takeover destination user.

[0066] When the user using the authentication terminal 101 selects registration (the "Yes" button in the example of FIG. 4(b)) on the takeover destination registration screen as shown in FIG. 4(b), the browser 310 of the authentication terminal 101 proceeds to S606.

[0067] In S606, the browser 310 of the authentication terminal 102 transmits a takeover destination user registration request to the application server 103. The takeover destination user registration request includes a takeover information ID and a takeover destination user ID. The takeover destination user registration request is assumed to be included in the information on the takeover destination registration screen transmitted from the application server 103 based on access to the application server 103 in response to the takeover destination user setting request described above, but the takeover information ID may be obtained by other methods. For example, the information included in the takeover destination user setting request of S604 may be displayed on the UI control unit 205 of the authentication terminal 102 using an email application or push notification, and the user may input the information on the takeover destination registration screen by operating the touch panel 205. Alternatively, after user authentication, the authentication terminal 102 may request and obtain a takeover information ID list in which the takeover destination user ID is registered from the application server 103, display the list on the takeover destination registration screen, and the user may select the information by operating the touch panel 205. Alternatively, other methods may be used.

[0068] When the application server 103 receives the takeover destination user registration request in S606, the process proceeds to S607. In S607, the credential registration processing unit 342 of the application server 103 transmits a credential information registration start request to the authentication server 104. Upon receiving this credential information registration start request, the authentication server 104 advances the process to S608.

[0069] In S608, the authentication request management unit 350 of the authentication server 104 issues a challenge at the time of credential registration, and transmits the challenge to the application server 103, which stores the challenge. Note that the challenge is, for example, a randomly generated character string that cannot be reused. Upon receiving this challenge, the application server 103 proceeds to S609.

[0070] In S609, the credential registration management unit 342 of the application server 103 acquires from the handover information management unit 340 the handover source user ID included in the handover information identified based on the handover information ID received in S606 above. Next, in S610, the credential registration management unit 342 of the application server 103 requests the authentication terminal 102 to register a public key to be used in FIDO authentication by transmitting the takeover source user ID acquired in S609 above and the challenge received from the authentication server 104. Upon receiving this challenge and the takeover source user ID, the authentication terminal 102 proceeds to S611.

[0071] In S611, the authentication terminal 102 acquires biometric information of the user who uses the authentication terminal 102. Specifically, the authentication client 320 of the authentication terminal 102 transmits a biometric information acquisition request to the biometric authentication processing unit 331. Upon receiving the biometric information acquisition request, the biometric authentication processing unit 331 waits until the user's biometric information is input. When the user's biometric information is input, the biometric authentication processing unit 331 acquires the feature quantities of the input biometric information. The feature quantities of biometric information are values ​​that are unique to each individual, such as a fingerprint pattern, iris pattern, or vein shape, converted into values ​​that do not impair the uniqueness. Biometric authentication identifies an individual using these unique feature quantities. When transmitting biometric information, it is desirable to encrypt it using a known encryption technology so that only the authentication device 103 can decrypt it.

[0072] Next, in S612, the biometric authentication processing unit 331 of the authentication terminal 102 performs authentication processing. Specifically, the biometric authentication processing unit 331 of the authentication terminal 102 transmits a request to the biometric information management unit 333 to confirm that the biometric information acquired in S611 above has been registered. If the biometric authentication processing unit 331 receives from the biometric information management unit 333 that the biometric information has already been registered, it determines that the authentication has been successful, but if not, it terminates this processing.

[0073] If the biometric authentication process in S612 is successful, the biometric authentication processing unit 331 of the authentication terminal 102 proceeds to S613. In S613, the biometric authentication processing unit 331 of the authentication terminal 102 creates credential information including a pair of a private key and a public key. Next, in S614, the credential information storage unit 332 of the authentication terminal 102 stores the credential information including the private key created in S612 above and the takeover source user ID received together with the public key registration request in S610 above (i.e., received in connection with the public key registration request), as shown in the record in the second row of Table 2.

[0074] Next, in S615 and S616, the authentication client 320 of the authentication terminal 102 transmits the credential information creation result to the authentication server 104 via the application server 103. The credential information creation result includes the public key information created when the credential information was created, and a challenge signed with the private key. Upon receiving this credential information creation result, the authentication server 104 proceeds to S617.

[0075] In S617, the authentication request management unit 350 of the authentication server 104 acquires the public key included in the credential information creation result and verifies the signature of the challenge included in the credential information creation result. If this verification is successful, a public key storage request is sent to the public key management unit 351, and the acquired public key is stored in the public key management unit 351 as shown in Table 6.

[0076] Next, in S618, the authentication request management unit 350 of the authentication server 104 transmits a credential information registration completion notification to the application server 103. Upon receiving this notification, the application server 103 advances the process to S619.

[0077] In S619, the handover information management unit 340 of the application server 103 updates the value of the handover status parameter of the handover information registered in S603 as shown in Table 5 to a value indicating "Registered." This value is not limited to the above example, and may be a character string such as "Registered," or may be expressed as a specific numeric value. Subsequently, in S620 and S621, the credential registration processing unit 342 of the application server 103 transmits a takeover destination user registration completion notice to the authentication terminal 102 and the authentication terminal 101, respectively.

[0078] Instead of sending the takeover destination user setting request to the authentication terminal 102 in S604, the takeover source user may orally request the takeover destination user to register the takeover destination user.

[0079] <Handover execution process> Next, the takeover execution process will be described with reference to FIG. 7 is a sequence diagram showing the processes of the authentication terminal 102, application server 103, and authentication server 104 of the takeover destination user in the takeover execution process of the first embodiment. In this diagram, the process of the authentication terminal 102 is realized by the CPU 201 of the authentication terminal 102 reading a program stored in the HDD 203 into the memory 202 and executing it. Furthermore, the processes of the application server 103 and the authentication server 104 are realized by the CPU 210 of each server reading a program stored in the HDD 212 into the memory 211 and executing it.

[0080] In S701, the authentication terminal 102 performs user authentication processing with the application server 103, making it possible to use the services of the application server 103. The user authentication processing has already been explained, so a detailed description is omitted here. If this user authentication processing is successful, a screen for using the services of the application server 103 is sent from the application server 103 and displayed on the browser 310 of the authentication terminal 101. For example, when a predetermined operation is performed on this screen, a handover execution screen such as that shown in FIG. 4(c) is displayed on the browser 310 of the authentication terminal 101. Alternatively, the user authenticated in S701 above may receive the handover execution screen such as that shown in FIG. 4(c) by selecting one of the handover information items registered as the handover destination user from a list. When the user of the authentication terminal 101 selects execution on this takeover execution screen (the "Yes" button in the example of FIG. 4(c)), the browser 310 of the authentication terminal 101 advances the process to S702.

[0081] Next, in S702, the browser 310 of the authentication terminal 102 sends a user takeover request to the application server 103. At this time, the takeover destination user setting request includes a takeover information ID and a takeover destination user ID. For example, the takeover information ID is assumed to be included in the information on the takeover execution screen. Furthermore, the takeover destination user ID is assumed to be the user ID of the user using the authentication terminal 101 authenticated in S701 above. When the application server 103 receives this user takeover request, the process proceeds to S703.

[0082] In S703, the handover information management unit 340 of the application server 103 compares the pair of handover information ID and handover destination user ID received from the authentication terminal 102 with the handover information managed by the handover information management unit 340, and determines whether handover is possible. If the pair of the received handover information ID and handover destination user ID exists in the handover information managed by the handover information management unit 340, it determines that handover is possible, and proceeds to S704. On the other hand, if the pair of the received handover information ID and handover destination user ID does not exist in the handover information managed by the application server 103, it determines that handover is not possible, returns an error in a step not shown, and ends this process.

[0083] In S704, the authentication processing unit 341 of the application server 103 transmits an authentication start request to the authentication server 104. Upon receiving this authentication start request, the authentication server 104 advances the process to S705.

[0084] In S705, the authentication request management unit 350 of the authentication server 104 transmits a challenge to the application server 103. Upon receiving this challenge, the application server 103 advances the process to S706.

[0085] In S706, the authentication processing unit 341 of the application server 103 acquires from the handover information management unit 340 the handover source user ID included in the handover information identified from the handover information ID determined to be handover possible in the above step 703.

[0086] Next, in S707, the authentication request management unit 341 of the application server 103 requests FIDO authentication by transmitting the takeover source user ID acquired in S706 above and the challenge received from the authentication server 104 in S705 above to the authentication terminal 102. Upon receiving the challenge and the takeover source user ID, the authentication terminal 102 proceeds to S708.

[0087] In S708, the authentication terminal 102 acquires biometric information of the user who uses the authentication terminal 102, similar to S611 in FIG. Next, in S709, the authentication terminal 102 performs biometric authentication processing in the same manner as in S612 of Fig. 6. If the biometric authentication processing is successful, the authentication terminal 102 proceeds to S710.

[0088] In S710, the credential information management unit 332 of the authentication terminal 102 checks whether the source user ID received together with the FIDO authentication request from the application server 103 in S707 (i.e., received in relation to the FIDO authentication request) matches the source user ID stored in the credential information management unit 332 (saved in S614 of FIG. 6), and if they match, proceeds to S711. Details of this process will be explained in the source user determination process in FIG. 8, which will be described later. On the other hand, if they do not match, an error is returned in a step not shown, and this process ends.

[0089] In S711, the biometric authentication processing unit 331 of the authentication terminal 102 signs the challenge received in S707 above using the stored private key. Next, in S712 and S713, the authentication client 320 of the authentication terminal 102 transmits the authentication result to the authentication server 104 via the application server 103. Note that this authentication result includes the challenge signed in S711 above. Upon receiving this authentication result, the authentication server 104 proceeds to S714.

[0090] In S714, the authentication request management unit 350 of the authentication server 104 sends a public key acquisition request from the public key management unit 351, acquires the public key, and verifies the signature of the challenge included in the authentication result. If the verification is successful, the authentication request management unit 350 proceeds to S715. On the other hand, if the verification is unsuccessful, the authentication request management unit 350 returns an error in a step not shown and ends this process.

[0091] In S715, the authentication request management unit 350 of the authentication server 104 transmits an authentication completion notification to the application server 103. Upon receiving this authentication completion notification, the application server 103 advances the process to S716.

[0092] In S716, the application server 103 executes the takeover process in accordance with the takeover information determined to be transferable in S703. Specifically, the application server 103 merges the authority granted to the user information (account) of the takeover source user with the user information of the takeover destination user, and further deletes the user information of the takeover source user or stops all access to the user information of the takeover source user.

[0093] Next, in S717, the handover information management unit 340 of the application server 103 further updates the value of the handover status parameter of the handover information updated in S619 of Fig. 6 to a value indicating "handover completed." This value is not limited to the above example, and may be a character string such as "Succeeded," or may be expressed as a specific numeric value. Furthermore, the handover information management unit 340 deletes the handover management information, such as temporary information, used for the above handover.

[0094] Subsequently, in S718, the authentication processing unit 341 of the application server 103 transmits a takeover process completion notice to the authentication terminal 102. At this time, a takeover completion notice may also be transmitted to the authentication terminal 101 (not shown).

[0095] <Transfer source user determination process> Next, the source user determination process shown in S710 of FIG. 7 will be described in detail with reference to FIG. 8 is a flowchart showing the details of the processing of S710, which corresponds to the processing for determining whether the information of the takeover source user is correct in the authentication processing in the authentication terminal 102 of the takeover destination user. That is, the processing of FIG. 8 is realized by the CPU 201 of the authentication terminal 102 reading a program stored in the HDD 203 into the memory 202 and executing it.

[0096] When the source user determination process starts, in S801, the biometric information management unit 333 of the authentication terminal 102 determines whether the source user ID is stored in the credential information record corresponding to the service URL corresponding to the service provided by the application server 103.

[0097] If the takeover source user ID is not saved (NO in S801), the biometric information management unit 333 advances the process to S804, returns a failure, and ends this process. On the other hand, if the source user ID is stored (YES in S801), the biometric information management unit 333 advances the process to S802.

[0098] In S802, the biometric information management unit 333 of the authentication terminal 102 checks whether the stored source user ID matches the source user ID received from the application server 103 in S707 of FIG.

[0099] Here, if the stored source user ID does not match the received source user ID (NO in S802), the biometric information management unit 333 proceeds to S804, returns a failure, and terminates this process. On the other hand, if the stored source user ID matches the received source user ID (YES in S802), the biometric information management unit 333 advances the process to S803. In S803, the biometric information management unit 333 of the authentication terminal 102 returns a judgment success, and this process ends.

[0100] As described above, in the first embodiment, an authenticated account of a target user that can take over the account of the source user is registered. Furthermore, the target user executes a process involving authentication at the time of transfer, and merges the authority of the source user's account with the authority of the target user's account. Furthermore, the source user's account is deleted or access to it is suspended. The authentication may be FIDO authentication. This makes it possible to easily and safely transfer a user's account.

[0101] Second Embodiment In the second embodiment, a configuration is shown in which approval is required from a user (a takeover approval user) different from the takeover source user and the takeover destination user during takeover execution processing.

[0102] <System configuration> FIG. 9 is a diagram illustrating an example of the overall configuration of a system according to the second embodiment of the present invention. 9, reference numeral 901 denotes an authentication terminal owned by the takeover approved user. The authentication terminal 101, authentication terminal 102, application server 103, authentication server 104, and credential information management server 105 are the same as those in the system of the first embodiment, and therefore description thereof will be omitted. The authentication terminal 901 receives the takeover approval request from the application server 103 and transmits the takeover approval result to the application server 103 . It should be noted that the user using authentication terminal 901 is a third user different from the user using authentication terminal 101 and the user using authentication terminal 102, and is assumed to be registered as a user in the services provided by application server 103.

[0103] <Hardware configuration of devices and information processing devices> The authentication terminal 901 in the second embodiment has the same configuration as the authentication terminals 101 and 102 in the first embodiment, and therefore a description thereof will be omitted. In addition, the hardware configurations of the information processing devices that can constitute the application server 103, authentication server 104, and credential information management server 105 are also the same as those in the first embodiment, and therefore a description thereof will be omitted.

[0104] <Functional configuration> FIG. 10 is a block diagram showing an example of the functional configuration of the authentication terminals 101, 102, and 901, the application server 103, the authentication server 104, and the credential information management server 105 in the second embodiment.

[0105] (Authentication terminal) The authentication terminals 101, 102, and 901 each include a browser 1010, an authentication client 320, and an authenticator 330. In addition to the functions provided by the browser 310 of the first embodiment, the browser 1010 receives a takeover approval request from the application server 103 and displays a takeover approval screen. Although not shown, the takeover approval screen displays the takeover source user ID and the takeover destination user ID, and includes buttons for selecting approve or reject. Furthermore, the browser 1010 transmits a takeover approval result to the application server 103 depending on whether the takeover approval user selects approve or reject on the takeover approval screen. The functions provided by the authentication client 320 and the authentication device 330 are the same as those in the first embodiment, and therefore a description thereof will be omitted.

[0106] (Application Server 103) The application server 103 includes a takeover information management unit 1040 , an authentication processing unit 1041 , and a credential registration processing unit 342 . The handover information management unit 1040 provides the function of storing handover information including handover approved users in addition to the function provided by the handover information management unit 340 of the first embodiment.

[0107] Table 10 shows an example of the handover information held by the handover information management unit 1040. [Table 10] As shown in Table 10, the handover information record of the handover information table according to the second embodiment includes, in addition to the information shown in Table 5, a handover approved user ID that uniquely identifies the handover approved user.

[0108] The authentication processing unit 1041 provides the function of transmitting a takeover approval request to the authentication terminal 901 and receiving a takeover approval result from the authentication terminal 901 in addition to the function provided by the authentication processing unit 341 of the first embodiment. The credential registration processing unit 342 has the same configuration as in the first embodiment, and therefore a description thereof will be omitted.

[0109] (Authentication server 104, Credential information management server 105) The authentication server 104 and the credential information management server 105 have the same configuration as in the first embodiment, and therefore a description thereof will be omitted.

[0110] <Transfer destination user settings and registration process> The takeover destination user setting process and takeover destination user registration process are the same as those in the first embodiment, and therefore a description thereof will be omitted.

[0111] <Handover execution process> The takeover execution process will be described with reference to FIG. 11 is a sequence diagram showing the processes of the authentication terminal 102 of the takeover destination user, the authentication terminal 901 of the takeover approved user, the application server 103, and the authentication server 104 in the takeover execution process of the second embodiment. In this diagram, the processes of the authentication terminals 102 and 901 are respectively realized by the CPU 201 of each authentication terminal loading a program stored in the HDD 203 into the memory 202 and executing it. Also, the processes of the application server 103 and the authentication server 104 are respectively realized by the CPU 210 of each server loading a program stored in the HDD 212 into the memory 211 and executing it.

[0112] In S1101, the authentication terminal 102 performs user authentication processing with the application server 103, enabling the use of the services of the application server 103. The user authentication processing has already been described, and therefore will not be described here. If this user authentication processing is successful, a screen for using the services of the application server 103 is sent from the application server 103 and displayed on the browser 1010 of the authentication terminal 101. For example, when a predetermined operation is performed on this screen, a handover execution screen is displayed on the browser 310 of the authentication terminal 101. Alternatively, the user authenticated in S1101 above may receive the handover execution screen by selecting one of the handover information items registered as the handover destination user from a list. The handover execution screen of the second embodiment is, for example, a handover execution screen as shown in FIG. 4(c), further including an input field for the user ID of the handover approved user. When the user using the authentication terminal 901 enters the user ID of the takeover approved user on the takeover execution screen and selects takeover execution (the "Yes" button in the example of FIG. 4(c)), the browser 310 of the authentication terminal 101 proceeds to S1102. Alternatively, the takeover approved user may not be entered by the user but may be registered in advance. For example, the takeover approved user may be a pre-registered administrator of the system, or may be a user whose user information includes a position corresponding to the superior of the takeover destination user or the takeover source user.

[0113] Next, in S1102, the browser 1010 of the authentication terminal 102 transmits a user transfer request to the application server 103. At this time, the transfer destination user setting request includes a transfer information ID, a transfer destination user ID, and a transfer approved user ID. For example, the transfer information ID is included in the information on the transfer execution screen. The transfer destination user ID is the user ID of the user using the authentication terminal 101 authenticated in S1101 above. The transfer approved user ID may be included in the information on the transfer execution screen, or may be separately obtained from the application server 103. Furthermore, the process may include a step of transmitting a transfer information acquisition request to the application server 103 before transmitting the user transfer request, causing the UI control unit 205 to display the transfer source user ID included in the acquired transfer information, and having the transfer destination user confirm the transfer source user ID and the transfer destination user ID. When the application server 103 receives this user takeover request, the process proceeds to S1103.

[0114] In S1103, the handover information management unit 340 of the application server 103 compares the pair of the handover information ID and the handover destination user ID received from the authentication terminal 102 with the handover information managed by the handover information management unit 340 and determines whether handover is possible. If the pair of the received handover information ID and the handover destination user ID exists in the handover information managed by the handover information management unit 340 itself, it determines that handover is possible. Furthermore, the presence of a handover approved user ID may also be determined to determine whether handover is possible. If handover is possible, the handover information management unit 340 updates the handover approved user ID in the handover information with the handover approved user received in S1102 above, and proceeds to S1104. On the other hand, if the pair of the received handover information ID and the handover destination user ID does not exist in the handover information managed by the handover information management unit 340 itself, it determines that handover is not possible, returns an error in a step not shown, and ends this processing.

[0115] In S1104, the authentication processing unit 341 of the application server 103 transmits an authentication start request to the authentication server 104. Upon receiving this authentication start request, the authentication server 104 advances the process to S1105.

[0116] In S1105, the authentication request management unit 350 of the authentication server 104 transmits a challenge to the application server 103. Upon receiving this challenge, the application server 103 advances the process to S1106.

[0117] In S1106, the authentication processing unit 341 of the application server 103 acquires from the handover information management unit 340 the handover source user ID included in the handover information identified from the handover information ID determined to be handover possible in the above step 1103.

[0118] Next, in S1107, the authentication request management unit 341 of the application server 103 requests FIDO authentication by transmitting the challenge received from the authentication server 104 and the takeover source user ID to the authentication terminal 102. Upon receiving the challenge and the takeover source user ID, the authentication terminal 102 proceeds to S1108.

[0119] In S1108, the authentication terminal 102 acquires biometric information of the user who uses the authentication terminal 102, similar to S611 in FIG. Next, in S1109, the authentication terminal 102 performs biometric authentication processing in the same manner as in S612 of Fig. 6. If the biometric authentication processing is successful, the authentication terminal 102 proceeds to S1110.

[0120] In S1110, the credential information management unit 332 of the authentication terminal 102 checks whether the takeover source user ID received from the application server 103 in S1107 above matches the takeover source user ID saved in the credential information management unit 332 (saved in S614 of FIG. 6), and if they match, the process proceeds to S1111. On the other hand, if they do not match, an error is returned in a step not shown, and the process ends.

[0121] In S1111, the biometric authentication processing unit 331 of the authentication terminal 102 signs the challenge received in S707 above using the stored private key. Next, in S1112 and S1113, the authentication client 320 of the authentication terminal 102 transmits the authentication result to the authentication server 104 via the application server 103. Note that this authentication result includes the challenge signed in S1111 above. Upon receiving this authentication result, the authentication server 104 proceeds to S1114.

[0122] In S1114, the authentication request management unit 350 of the authentication server 104 sends a public key acquisition request from the public key management unit 351, acquires the public key, and verifies the signature of the challenge included in the authentication result. If the verification is successful, the authentication request management unit 350 proceeds to S1115. On the other hand, if the verification is unsuccessful, the authentication request management unit 350 returns an error in a step not shown and ends this process.

[0123] In S1115, the authentication request management unit 350 of the authentication server 104 transmits an authentication completion notification to the application server 103. Upon receiving this authentication completion notification, the application server 103 advances the process to S1116.

[0124] In S1116, the handover information management unit 1040 of the application server 103 transmits a handover approval request to the authentication terminal 901 identified from the handover approved user ID included in the handover information. Note that the user information identified from the handover approved user ID stored in the application server 103 includes an email address, terminal information, etc. As a means for transmitting to the authentication terminal 901, an email may be sent to the aforementioned email address, or a push notification may be sent based on the terminal information.

[0125] In S1117, the authentication terminal 901 performs user authentication processing with the application server 103, enabling the user to use the services of the application server 103. The user authentication processing has been described above. For example, the user using the authentication terminal 901 may start the user authentication processing of S1117 by accessing the application server 103 from the browser 1010 of the authentication terminal 901 using the URL included in the takeover approval request received in S1116. In this case, if the user authentication processing is successful, for example, a takeover approval screen (not shown) is sent from the application server 103 to the authentication terminal 901 and displayed on the browser 310 of the authentication terminal 901. If the user using the authentication terminal 901 instructs approval / rejection on this takeover approval screen, the browser 1010 of the authentication terminal 901 proceeds to S1118. Alternatively, the user authentication processing of S1117 may be started simply by accessing the application server 103 from the authentication terminal 901. After the user authentication process is successful, the browser 1010 of the authentication terminal 901 may access the application server 103 using the URL or the like included in the takeover approval request in S1116 above, and receive the takeover approval screen. Alternatively, after the user authentication process in S1116 above is successful, the application server 103 may receive the takeover approval screen by allowing the user authenticated in S1116 above to select one from a list of takeover information set as the takeover destination user.

[0126] Next, in S1118, the browser 1010 of the authentication terminal 901 transmits a takeover approval result indicating approval or denial of the takeover approval request to the application server 103. If approved, the application server 103 proceeds to S1119. On the other hand, if denied, an error is returned to the authentication terminal 102, and this process ends.

[0127] In S1119, the application server 103 executes the takeover process. Specifically, the application server 103 merges the authority granted to the user information of the takeover source user with the user information of the takeover destination user, deletes the user information of the takeover source user, or stops all access to the user information (account) of the takeover source user.

[0128] Next, in S1120, the handover information management unit 1040 of the application server 103 further updates the value of the handover status parameter of the handover information updated in S619 of Fig. 6 to a value indicating "handover completed." This value is not limited to the above example, and may be a character string such as "Succeeded," or may be expressed as a specific numeric value. Furthermore, the handover information management unit 340 deletes the handover management information, such as temporary information, used for the above handover.

[0129] Next, in S1121, the authentication processing unit 1041 of the application server 103 transmits a takeover process completion notice to the authentication terminal 102. At this time, a takeover completion notice may also be transmitted to the authentication terminal 101 (not shown).

[0130] Instead of transmitting the takeover approval request to the authentication terminal 901 in S1116, the takeover source user may request takeover approval orally from the takeover approved user.

[0131] As described above, according to the second embodiment, the takeover process is performed after approval by the takeover approved user, so that the user's account can be taken over easily and more safely.

[0132] It goes without saying that the configurations and contents of the various data described above are not limited to those described above, and that the data may be configured in various configurations and contents depending on the application and purpose. Although one embodiment has been described above, the present invention can be embodied as, for example, a system, an apparatus, a method, a program, a storage medium, etc. Specifically, the present invention may be applied to a system made up of multiple devices, or may be applied to an apparatus made up of a single device. Furthermore, the present invention also includes any combination of the above embodiments.

[0133] As described above, according to each embodiment, it is possible to easily and safely carry out the transfer of a user's account.

[0134] Other Embodiments The present invention can also be realized by supplying a program that realizes one or more functions of the above-described embodiments to a system or device via a network or a storage medium, and having one or more processors in the 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 realizes one or more functions. Furthermore, the present invention may be applied to a system made up of multiple devices, or to an apparatus made up of a single device. The present invention is not limited to the above-described embodiments, and various modifications (including organic combinations of the embodiments) are possible based on the spirit of the present invention, and these modifications are not excluded from the scope of the present invention. In other words, all configurations that combine the above-described embodiments and their modifications are included in the present invention.

[0135] The disclosure of this embodiment includes the following configurations and methods. (Configuration 1) A system including a server that provides a service, a first terminal used by a first user who is registered with the service, and a second terminal used by a second user who is registered with the service and different from the first user, The first terminal a first request means for making a first request to the server to register a successor user who will take over the authority assigned to the user information of the first user who uses the first terminal, by designating the second user as the successor user; The server a first authentication processing means for transmitting a registration request for user identification information of the first user who will be the takeover source user in the first request and a public key to be used in FIDO authentication to the second terminal used by the second user who has been designated as the takeover destination user in the first request; a registration means for registering takeover information in which the first user is the takeover source user and the second user is the takeover destination user when the registration of the public key is completed; A second authentication processing means for transmitting user identification information of the user registered as the takeover source user in the registered takeover information and an authentication request for FIDO authentication to the second terminal used by the second user registered as the takeover destination user in the registered takeover information; and a handover means for performing a handover process of granting the authority granted to the user information of the handover source user to the user information of the handover destination user in accordance with the handover information when the FIDO authentication is successful, The second terminal a third authentication processing means for performing user authentication in response to the registration request, and for creating a pair of a private key and a public key to be used in the FIDO authentication if the user authentication is successful, and for transmitting information for registering the public key to the server; storage means for storing said private key and user identification information received in association with said registration request; and a fourth authentication processing means for performing user authentication in response to the authentication request, and, if the user authentication is successful, determining whether second identification information, which is user identification information received from the server in relation to the authentication request, matches first identification information, which is the stored user identification information, and, if they match, transmitting an authentication result to the server, the authentication result including information obtained by signing information included in the authentication request with the stored private key. A system characterized by: (Configuration 2) 2. The system according to configuration 1, wherein the user authentication performed by the third authentication processing means and the fourth authentication processing means is biometric authentication. (Configuration 3) The system described in configuration 1 or 2 is characterized in that the transfer means grants the authority granted to the user information of the source user to the user information of the destination user, and then deletes the user information of the source user or suspends access to the user information. (Configuration 4) The server a first notification means for notifying the second terminal used by the second user designated as a target user in the first request that the second user has been designated as a target user who will take over the authority assigned to the user information of the first user; a second notification means for notifying the second terminal that the handover information has been registered; The second terminal a second request means for transmitting, in response to the notification by the first notification means, a second request to the server, the second request requesting that the second user be registered as a successor user who will succeed the authority assigned to the user information of the first user; a third request means for transmitting a third request to the server in response to the notification by the second notification means, the third request requesting execution of a takeover process in accordance with the registered takeover information; the registration means registers the takeover information in response to the second request; the second authentication processing means transmits the authentication request in response to the second request. 4. The system according to any one of configurations 1 to 3. (Configuration 5) a third terminal used by a third user who is a user registered with the service and is different from the first user and the second user; The server has a fourth request means that, when the FIDO authentication is successful, transmits to the third terminal an approval request inquiring whether to approve execution of a handover process in accordance with the registered handover information; the third terminal has a transmission means for receiving a user selection as to whether to approve the execution of the takeover process according to the takeover information in response to the approval request, and transmitting an approval result according to the user selection to the server; The system according to any one of configurations 1 to 4, characterized in that the handover means performs the handover process when the authentication process corresponding to the second request is successful and the approval result indicates approval. (Method 1) A control method for a system including a server that provides a service, a first terminal used by a first user who is registered with the service, and a second terminal used by a second user who is registered with the service and different from the first user, comprising: a first request step executed by the first terminal, for making a first request to the server to register a target user who will take over the authority assigned to the user information of the first user who uses the first terminal, by specifying the second user as the target user; Executed by the server, a first authentication processing step of transmitting a registration request for user identification information of the first user who will be the takeover source user in the first request and a public key to be used in FIDO authentication to the second terminal used by the second user designated as the takeover destination user in the first request; a registration step of registering takeover information in which the first user is the takeover source user and the second user is the takeover destination user when the registration of the public key is completed; a second authentication processing step of transmitting user identification information of the user registered as the takeover source user in the registered takeover information and an authentication request for FIDO authentication to the second terminal used by the second user registered as the takeover destination user in the registered takeover information; A handover process for performing a handover process in which, when the FIDO authentication is successful, the authority granted to the user information of the handover source user according to the handover information is granted to the user information of the handover destination user; Executed by the second terminal, a third authentication processing step of performing user authentication in response to the registration request, and if the user authentication is successful, creating a pair of a private key and a public key to be used in the FIDO authentication, and transmitting information for registering the public key to the server; a storing step of storing the private key and user identification information received in association with the registration request; a fourth authentication processing step of performing user authentication in response to the authentication request, and if the user authentication is successful, determining whether second identification information, which is user identification information received from the server in relation to the authentication request, matches first identification information, which is the stored user identification information, and if they match, transmitting an authentication result to the server, the authentication result including information obtained by signing information included in the authentication request with the stored private key; A method for controlling a system, comprising:

Claims

1. A system including a server that provides a service, a first terminal used by a first user who is registered with the service, and a second terminal used by a second user who is registered with the service and different from the first user, The first terminal a first request means for making a first request to the server to register a successor user who will take over the authority assigned to the user information of the first user who uses the first terminal, by designating the second user as the successor user; The server a first authentication processing means for transmitting a registration request for user identification information of the first user who will be the takeover source user in the first request and a public key to be used in FIDO authentication to the second terminal used by the second user designated as the takeover destination user in the first request; a registration means for registering takeover information that designates the first user as the takeover source user and the second user as the takeover destination user when the registration of the public key is completed; a second authentication processing means for transmitting user identification information of the user registered as the takeover source user in the registered takeover information and an authentication request for FIDO authentication to the second terminal used by the second user registered as the takeover destination user in the registered takeover information; a takeover means for performing a takeover process in which, when the FIDO authentication is successful, the authority granted to the user information of the takeover source user in accordance with the takeover information is granted to the user information of the takeover destination user; The second terminal a third authentication processing means for performing user authentication in response to the registration request, and, if the user authentication is successful, creating a pair of a private key and a public key to be used in the FIDO authentication, and transmitting information for registering the public key to the server; storage means for storing said private key and user identification information received in association with said registration request; and a fourth authentication processing means for performing user authentication in response to the authentication request, and, if the user authentication is successful, determining whether second identification information, which is user identification information received from the server in relation to the authentication request, matches first identification information, which is the stored user identification information, and, if they match, transmitting an authentication result, which includes information obtained by signing information included in the authentication request with the stored private key, to the server. A system characterized by:

2. 2. The system according to claim 1, wherein the user authentication performed by the third authentication processing means and the fourth authentication processing means is biometric authentication.

3. The system described in claim 1, characterized in that the transfer means grants the authority granted to the user information of the source user to the user information of the target user, and then deletes the user information of the source user or suspends access to the user information.

4. The server a first notification means for notifying the second terminal used by the second user designated as a target user in the first request that the second user has been designated as a target user who will take over the authority assigned to the user information of the first user; a second notification means for notifying the second terminal that the handover information has been registered; The second terminal a second request means for transmitting, in response to the notification by the first notification means, a second request to the server, the second request requesting that the second user be registered as a successor user who will succeed the authority assigned to the user information of the first user; a third request means for transmitting a third request to the server in response to the notification by the second notification means, the third request requesting execution of a takeover process in accordance with the registered takeover information; the registration means registers the takeover information in response to the second request; the second authentication processing means transmits the authentication request in response to the second request. The system according to any one of claims 1 to 3.

5. a third terminal used by a third user who is a user registered with the service and is different from the first user and the second user; the server has a fourth request means for transmitting, when the FIDO authentication is successful, an approval request to the third terminal to inquire whether to approve execution of a takeover process in accordance with the registered takeover information; the third terminal has a transmission means for receiving a user selection as to whether to approve execution of the takeover process in accordance with the takeover information in response to the approval request, and transmitting an approval result in accordance with the user selection to the server; The system described in any one of claims 1 to 3, characterized in that the handover means performs the handover processing when the authentication processing corresponding to the second request is successful and the approval result indicates approval.

6. A control method for a system including a server that provides a service, a first terminal used by a first user who is registered with the service, and a second terminal used by a second user who is registered with the service and different from the first user, comprising: a first request step executed by the first terminal, for making a first request to the server to register a target user who will take over the authority assigned to the user information of the first user who uses the first terminal, by specifying the second user as the target user; Executed by the server, a first authentication processing step of transmitting a registration request for user identification information of the first user who will be the takeover source user in the first request and a public key to be used in FIDO authentication to the second terminal used by the second user designated as the takeover destination user in the first request; a registration step of registering takeover information in which the first user is the takeover source user and the second user is the takeover destination user when the registration of the public key is completed; a second authentication processing step of transmitting user identification information of the user registered as the takeover source user in the registered takeover information and an authentication request for FIDO authentication to the second terminal used by the second user registered as the takeover destination user in the registered takeover information; a takeover step of performing a takeover process in which, if the FIDO authentication is successful, the authority granted to the user information of the takeover source user in accordance with the takeover information is granted to the user information of the takeover destination user; Executed by the second terminal, a third authentication processing step of performing user authentication in response to the registration request, and if the user authentication is successful, creating a pair of a private key and a public key to be used in the FIDO authentication, and transmitting information for registering the public key to the server; a storing step of storing the private key and user identification information received in association with the registration request; a fourth authentication processing step of performing user authentication in response to the authentication request, and if the user authentication is successful, determining whether second identification information, which is user identification information received from the server in relation to the authentication request, matches the first identification information, which is the stored user identification information, and if they match, transmitting an authentication result to the server, the authentication result including information obtained by signing information included in the authentication request with the stored private key; A method for controlling a system, comprising:

Images