Authentication apparatus, authentication method, and program

Abstract

To improve the security of a one-time password provided as additional authentication means for prescribed authentication means.SOLUTION: An authentication apparatus executes processing for authenticating a user in accordance with a request for a first application that runs on a terminal device of the user, the authentication apparatus including an authentication unit which authenticates the user when first identification information, for the first application, received from the first application in response to the request coincides with second identification information which is identification information of a second application that has accessed to an address provided to the terminal device in response to the request. The address is described so as to designate the first application as entity to access the address. The authentication unit supplies, when the first identification information and the second identification information do not match, display information for displaying the address to the second application, and then authenticates the user when the first identification information coincides with third identification information which is identification information of an application having accessed the address after the supply of the display information.SELECTED DRAWING: Figure 4

Description

[Technical field]

[0001] The present invention relates to an authentication device, an authentication method, and a program. [Background technology]

[0002] Conventionally, in authenticating a user logging in to a service, in addition to the prescribed authentication means, a check is made to see whether the terminal device from which the login request originates is a registered terminal device, and if the terminal device from which the login request originates is not a registered terminal device, additional authentication is performed using a QR code (registered trademark, the same applies below) or SMS (Short Message Service), etc. (see, for example, Patent Documents 1 and 2). [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Patent No. 7247416 [Patent Document 2] Patent No. 7202500 Summary of the Invention [Problem to be solved by the invention]

[0004] In conventional technology, one example of an additional authentication method is authentication using a one-time password. However, in this case, there is a risk that a user who illegally obtains a one-time password through phishing or other methods could misuse a legitimate user's account.

[0005] The present invention has been made in consideration of the above circumstances, and one of its objects is to provide an authentication device, authentication method, and program that can improve the security of one-time passwords provided as an additional authentication means to the standard authentication means. [Means for solving the problem]

[0006] One aspect of the present invention is an authentication device that performs an authentication process to authenticate a user in response to a request from a first application program running on the user's terminal device, and includes an authentication unit that authenticates the user when identification information of the first application program, the first identification information received from the first application program at the time of the request, matches with second identification information, which is identification information of a second application program that has accessed a specified network address notified to the terminal device at the time of the request, and the network address is described in a manner that designates the first application program as the entity accessing the network address, and the authentication unit supplies display information to the second application program for displaying the network address if the first identification information and the second identification information do not match, and authenticates the user when third identification information, which is identification information of the application program that accessed the network address after the display information is supplied, matches the first identification information. Effect of the Invention

[0007] According to one aspect of the present invention, it is possible to provide an authentication device, an authentication method, and a program that can improve the security of a one-time password that is provided as an additional authentication means in addition to a specified authentication means. [Brief description of the drawings]

[0008] [Figure 1] FIG. 1 is a diagram showing an example of a configuration for realizing an electronic payment service. [Diagram 2] This is a sequence diagram (part 1) illustrating the general flow of electronic payment. [Diagram 3] This is a sequence diagram (part 2) illustrating the general flow of electronic payment. [Figure 4] 1 is a configuration diagram of a payment server 100 according to a first embodiment. [Diagram 5] FIG. 13 is a diagram showing an example of the contents of user information 172. [Figure 6] FIG. 13 is a diagram showing an example of the contents of affiliated store / store information 176. [Figure 7] 1 is a flowchart showing an outline of the flow of login authentication in an electronic payment service. [Figure 8] 13 is a sequence chart (part 1) illustrating an example of a process flow related to new third device authentication. [Figure 9] 13 is a sequence chart (part 2) illustrating an example of a process flow related to new third device authentication. [Figure 10] FIG. 13 is a diagram showing an example of a web page on which a takeover URL is described. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0009] Hereinafter, with reference to the drawings, an embodiment of an authentication device, an authentication method, and a program of the present invention will be described. Various devices for providing services to users and performing internal analysis, such as a "server," "management device," and "information providing device" that will appear below, may be realized by a group of distributed devices, and each device may be operated by a different business operator. Furthermore, the owner of the hardware of the device (the provider of the cloud server) and the business that actually operates the device may also be different. An application program and a payment server work together to provide an electronic payment service. In the following description, the application program is referred to as a payment application. An electronic payment service is a service that supports payments related to the purchase of goods and services at a store. A store is, for example, a physical store (real store) that exists in the real world, but may also include a virtual store for electronic commerce. A virtual store may include a store provided by an entity different from the operator of the electronic payment service. In that case, when making a payment for shopping at a virtual store, the screen is controlled to transition to an interface screen of the electronic payment service. In an electronic payment service, a store is treated as belonging to, for example, an affiliated store (brand), and processing such as payment when a purchase is made at a store is mainly performed between the user and the affiliated store. Alternatively, processing such as payment may be carried out between the user and the store.

[0010] [Electronic payment service] Fig. 1 is a diagram showing an example of a configuration for realizing an electronic payment service. The electronic payment service is realized mainly by a payment server 100. The payment server 100 communicates with, for example, one or more user terminal devices 10, one or more first store terminal devices 50, and one or more second store terminal devices 70 via a network NW. The network NW includes, for example, the Internet, a LAN (Local Area Network), a wireless base station, a provider device, and the like.

[0011] The user terminal device 10 is, for example, a portable terminal device such as a smartphone or a tablet terminal. The user terminal device 10 is a computer device having at least an optical reading function, a communication function, a display function, an input reception function, and a program execution function. In the following description, components for realizing these functions are referred to as a camera, a communication device, a touch panel, a CPU (Central Processing Unit), etc. In the user terminal device 10, a processor such as a CPU executes a payment application 20, thereby operating to provide an electronic payment service to a user in cooperation with a payment server 100. The payment application 20 is installed in the user terminal device 10 from, for example, an application store, and controls the camera, communication device, touch panel, etc.

[0012] The first store terminal device 50 is installed, for example, in a store. The first store terminal device 50 is a computer device having at least a product price acquisition function, an optical reading function, a program execution function, and a communication function. The first store terminal device 50 includes a so-called POS (Point of Sale) device, and the product price acquisition function and the optical reading function may be realized by the POS device. The store code image 60 is placed in the store, and is a code image such as a QR code (registered trademark) printed on a paper or plastic medium. The store code image 60 may be displayed on a display placed in the store (which may be the display of a terminal device such as a smartphone).

[0013] The second store terminal device 70 is used by the operator of the affiliated store. The second store terminal device 70 is a smartphone, a tablet terminal, a personal computer, or the like. An interface 72 for affiliated stores runs on the second store terminal device 70. The interface 72 for affiliated stores may be an app for affiliated stores or a browser. The interface 72 for affiliated stores accepts coupon settings and the like made by the operator of the affiliated store and transmits them to the payment server 100. The second store terminal device 70, which is a smartphone, has the function of displaying a code image corresponding to a store code image and reading a code image displayed by the user terminal device 10 by executing the app for affiliated stores.

[0014] The payment server 100 realizes electronic payment based on payment information received from the user terminal device 10 or the first store terminal device 50. The first store terminal device 50 may include a POS device and an affiliated store server, in which case the payment information is sent from the POS device via the affiliated store server to the payment server 100. In the following explanation, no distinction is made between these two and it is assumed that the payment information is sent from the first store terminal device 50.

[0015] 2 and 3 are sequence diagrams illustrating the general flow of electronic payment. There may be two patterns of electronic payment: pattern 1 and pattern 2.

[0016] In the case of pattern 1 (hereinafter referred to as user scan) shown in FIG. 2, the user terminal device 10 with the payment application 20 activated decodes the store code image 60 by the optical reading function (S1). The store code image 60 includes store URL (Uniform Resource Locator) information. This store URL is an electronic payment service domain to which store-identifying information is added, and is associated with an affiliated store ID, a store ID, etc. in the payment server 100 (described later). The payment application 20 transmits the first payment information including the store URL and the account ID to the payment server 100 (S2). The payment server 100 searches for store information (described later) from the affiliated store ID and the store ID corresponding to the store URL, acquires the affiliated store name and the store name information (S3), and transmits it to the payment application 20 (S4). The user inputs the payment amount into the user terminal device 10 on the screen on which the affiliated store name and the store name are displayed (S5). Then, the user terminal device 10 generates second payment information including at least the payment amount, and transmits it to the payment server 100 (S6). The payment server 100 performs electronic payment based on the received second payment information (S7). The payment server 100 then transmits a payment completion notice (information for displaying a payment completion screen) to the payment application 20 (S8), and the payment application 20 displays the payment completion screen (S9). Note that when the store code image 60 is displayed on a display installed in the store, the store code image 60 may include not only the store URL but also information on the payment amount. In this case, the procedure in which the user inputs the payment amount is omitted, and the information on the payment amount is included in the first payment information and transmitted to the payment server 100. Information on the affiliated store name and the store name may be included in the payment completion screen and displayed.

[0017] In the case of pattern 2 (hereinafter referred to as store scan) shown in FIG. 3, when the payment application 20 is started, when a payment operation is performed in the payment application 20, when an automatic update timing (e.g., every minute) occurs, and at other timings, the payment application 20 transmits a request for issuing a one-time code to the payment server 100 (S11). The payment server 100 generates a one-time code (S12) and transmits it to the payment application 20 (S13). The payment application 20 displays a code image such as a QR code or a barcode generated based on the one-time code (S14). The user holds (presents) the display surface of the user terminal device 10 over the first store terminal device 50, and the first store terminal device 50 decodes the code image by an optical reading function and obtains the one-time code, etc. (S15). The first store terminal device 50 then generates payment information including the one-time code, payment amount, affiliated store ID, store ID, etc., and transmits it to the payment server 100 (S16). The payment amount information is acquired in advance by reading a barcode or manually entering it. The payment server 100 identifies the user corresponding to the one-time code based on the received information and performs electronic payment (S17). The payment server 100 then transmits a payment completion notice to the payment application 20 (S18), and the payment application 20 displays a payment completion screen (S19).

[0018] Note that electronic payment may be performed using only one of the above patterns. Furthermore, the "account ID" described in FIG. 2 may be other information (e.g., a phone number) that can be used as user identification information. Furthermore, issuance of a one-time code may be omitted in the store scan, and the payment application 20 may display a code image generated based on the user's account ID. In this case, the payment server 100 identifies the user corresponding to the account ID instead of identifying the user corresponding to the one-time code.

[0019] [Payment server] FIG. 4 is a configuration diagram of the payment server 100 according to the first embodiment. The payment server 100 includes, for example, a communication unit 110, a payment content providing unit 120, a payment processing unit 130, an information management unit 140, a login authentication unit 150, and a storage unit 170. The components other than the communication unit 110 and the storage unit 170 are realized by, for example, a hardware processor such as a CPU executing a program (software). Some or all of these components may be realized by hardware (including circuitry) such as an LSI (Large Scale Integration), an ASIC (Application Specific Integrated Circuit), an FPGA (Field-Programmable Gate Array), or a GPU (Graphics Processing Unit), or may be realized by cooperation between software and hardware. The program may be stored in advance in a storage device (a storage device with a non-transient storage medium) such as an HDD (Hard Disk Drive) or flash memory, or may be stored in a removable storage medium (non-transient storage medium) such as a DVD or CD-ROM, and installed in the storage device by inserting the storage medium into a drive device.

[0020] The storage unit 170 is a HDD, a flash memory, a RAM (Random Access Memory), etc. The storage unit 170 may be a NAS (Network Attached Storage) device that the payment server 100 can access via a network. The storage unit 170 stores information such as user information 172, payment content information 174, and affiliated store / shop information 176.

[0021] The communication unit 110 is a communication interface for connecting to the network NW. The communication unit 110 is, for example, a network interface card.

[0022] The payment content providing unit 120 has, for example, a function of a Web server, and provides information (payment content) for displaying a screen that provides various functions of an electronic payment service to the user terminal device 10. The payment content providing unit 120 appropriately reads out necessary content from the payment content information 174 and provides it to the user terminal device 10. The user terminal device 10 accepts various inputs by the user while the content is being played by the payment application 20, and transmits the above-mentioned payment information and the like to the payment server 100.

[0023] The payment processing unit 130 performs payment processing based on the payment information transmitted by the user terminal device 10 or the first store terminal device 50. The payment processing unit 130 performs payment processing while referring to the user information 172.

[0024] FIG. 5 is a diagram showing an example of the contents of the user information 172. The user information 172 is an example of the registration information of a user. The user information 172 is, for example, a user URL, an account ID, a telephone number, a password, as well as information associated with an email address, a user ID, a name, an address, a date of birth, a registration date, a charge balance, a post-payment setting, a post-payment limit, a post-payment usage amount, a post-payment available amount, a payment method setting, a bank account, a credit card number, charge history information, payment history information, login status information, and registered terminal information. The user URL is used for a remittance process between users. When registering for the electronic payment service, it is necessary to register a telephone number and a password. The account ID is issued to the user by the payment server 100, and the user ID is an ID that can be set by the user at will (does not have to be set). Similarly, the email address, and the name, address, and date of birth are information that can be set by the user at will (does not have to be set). The registration date is the date on which the user registered for the electronic payment service (the date on which the account was created). Hereinafter, the user's instance (electronic payment account) to which this information is associated will be referred to as an account.

[0025] The charge balance is information indicating the balance of electronic money that is set by a user by transferring money to an account in advance. The means of transfer include transfer from an ATM (Automatic Teller Machine) of a designated company (bank) and transfer from a registered bank account. The deferred payment setting is information indicating whether or not the setting for enabling electronic payment by deferred payment has been completed, and is set to either "completed" or "not completed." The deferred payment limit is the limit of deferred payment that can be used each month, the deferred payment usage amount is the amount of deferred payment that has already been used in the current month, and the deferred payment available amount is the amount of deferred payment that can be used in the current month, which is calculated by subtracting the deferred payment usage amount from the deferred payment limit. Although only one deferred payment limit is shown in the figure, in reality, there is also a daily upper limit, and the lower of these may be set as the deferred payment limit. Further details of deferred payment will be described later. The payment method setting is setting information indicating whether the user will perform electronic payment using the charge balance or payment by deferred payment at that time. The bank account and credit card number are information on a bank account or credit card number (account number, card number) that can be used to deposit funds into an electronic payment service. Charge history information is a history of the user's previous transfers to the electronic payment service to increase the charge balance. Payment history information is information that indicates the details of payments made by the user for each payment (date and time, store ID of the store where the purchase was made, payment amount, payment method, etc.).

[0026] The login state information is information that indicates the login state of each user in the electronic payment service. For example, the login state information includes information on whether the user is logged in or logged out in the electronic payment service. The login state information may also include information such as the date and time when the user logged in to the electronic payment service and the date and time when the user logged out. The registered terminal information is identification information of a "registered terminal" described later. The registered terminal information is registered in advance in the payment server 100 by the user.

[0027] 6 is a diagram showing an example of the contents of affiliated store / store information 176. The affiliated store / store information 176 includes, for example, a first table 176A in which an affiliated store ID and a store ID are associated with a store URL, a second table 176B in which an affiliated store name and sales amount (described above) are associated with an affiliated store ID, and a third table 176C in which a store ID is associated with a store name. In addition to this information, the affiliated store / store information 176 may also include information such as the category of the affiliated store or store, the location of the store, and payment patterns.

[0028] The information management unit 140 manages user information 172 and affiliated store / store information 176 based on information acquired from the user terminal device 10 and the second store terminal device 70. The information management unit 140 adds new records to, edits, and deletes the user information 172 and affiliated store / store information 176.

[0029] Login authentication unit 150 performs authentication processing for a user attempting to log in to an electronic payment service in response to a request from payment application 20. Login authentication unit 150 updates the login status of the user in accordance with the authentication result.

[0030] [Electronic payment] When payment information is acquired from the user terminal device 10 or the first store terminal device 50, the payment processing unit 130 refers to the user information 172 to acquire the "payment method setting" of the user. For a user whose "payment method setting" is set to "charge balance", the payment processing unit 130 performs electronic payment as follows. For example, the payment processing unit 130 performs electronic payment by decreasing the charge balance managed in association with the user ID and increasing the item value of the affiliated store's sales. The item value of the affiliated store's sales is not used as electronic money itself, for example, and an amount corresponding to the item value of the sales is transferred to a bank account in a cycle according to an agreement between the affiliated store and the electronic payment service.

[0031] The payment processing unit 130 performs electronic payment for users whose "setting information" is set to "deferred payment" as follows. Deferred payment is set separately from "credit payment" in cooperation with a credit card company, which is a separate entity from the operator of the electronic payment service, and the operator of the electronic payment service acts as a creditor and allows electronic payment that is not dependent on the charge balance within the deferred payment limit. In order to receive the deferred payment service, a credit card provided by the operator of the electronic payment service may be required. The amount used for deferred payment is settled on the payment date of the following month, for example, by debiting from a bank account, for one month. In this case, the payment processing unit 130 performs provisional payment by adding the payment amount to the deferred payment amount and subtracting the same amount from the available deferred payment amount, and when the closing date comes, it performs processing to debit the payment for the current month on the payment date of the following month as described above, or requests the operator of the credit card company to perform such processing. In addition, if the payment amount exceeds the available deferred payment amount at the time of provisional payment, an error notification is returned to the payment application 20.

[0032] [Log in to electronic payment service] In this embodiment, various functions of the electronic payment service are provided to a user who has logged in to the electronic payment service. More specifically, the payment content providing unit 120 is configured to provide payment content to a user whose login state to the electronic payment service is logged in, and not to provide payment content to a user who has not logged in. For example, when a user is not logged in to the electronic payment service (for example, when the application is started), the payment application 20 displays a login screen and accepts input of authentication information (user ID and password), and makes a login request to the payment server 100 based on the input authentication information. In response to this login request, the login authentication unit 150 in the payment server 100 executes authentication processing. If the login authentication unit 150 succeeds in authenticating the user, it changes the login state of the user from not logged in to logged in. After the login state of the user is changed to logged in, the payment content providing unit 120 provides the payment content to the user terminal device 10 of the user.

[0033] However, in conventional login authentication methods, there have been cases where passwords (including passcodes) have been illegally obtained by methods such as phishing, leading to unauthorized use of legitimate user accounts by third parties. The login authentication method in this embodiment is configured to reduce the possibility of unauthorized use occurring due to such password leakage, as compared to conventional methods. More specifically, in conventional login authentication, there has been concern that a password may be stolen when a user who fails device authentication transitions to one-time password authentication. This embodiment aims to reduce the possibility of unauthorized use by improving the method of one-time password authentication that occurs due to failure of device authentication.

[0034] FIG. 7 is a flowchart showing an outline of the flow of login authentication in an electronic payment service. In this embodiment, authentication of a user who logs in to an electronic payment service is performed by combining password authentication (authentication by user ID and password) (S31) and device authentication (S32). That is, if the user succeeds in both password authentication and device authentication, the user can log in to the electronic payment service (login permitted). On the other hand, if the password authentication fails, the user is refused login (login not permitted). Also, if the user fails device authentication, the user is permitted to log in if the user selects either QR code authentication (S33) or SMS authentication (S34) and succeeds in authentication. On the other hand, if the user selects either QR code authentication (S33) or SMS authentication (S34) and fails authentication, the user can perform one-time password authentication (S35: OTP authentication). If the one-time password authentication succeeds, login is permitted, and if it fails, login is refused.

[0035] [Device authentication] Device authentication is to authenticate the user terminal device 10 when the device ID acquired from the user terminal device 10 matches the device ID registered in advance by the user of the user terminal device 10 or the device ID confirmed by another means for the user terminal device 10. More specifically, the device authentication in this embodiment includes a first device authentication that is performed first, and a second device authentication and a third device authentication that can be performed when the first device authentication fails. The first device authentication is to authenticate the user terminal device 10 and permit login when the device ID acquired from the user terminal device 10 at the time of a login request matches the device ID registered in advance by the requesting user. Hereinafter, a user terminal device 10 having a device ID registered in advance by a user is referred to as a "registered terminal". According to the first device authentication, a login request from a user terminal device 10 that is not a registered terminal is rejected, so that it is possible to prevent impersonation by a third party.

[0036] On the other hand, even if a user is legitimate, the user terminal device 10 used for logging in (hereinafter referred to as the "login terminal") may be different from the registered terminal, for example, when changing the model. Therefore, in the electronic payment service of this embodiment, even if the first device authentication fails, the user can log in to the electronic payment service from a login terminal different from the registered terminal by implementing second device authentication or third device authentication.

[0037] Second device authentication is device authentication for a user who can operate both a login terminal (hereinafter also referred to as a "new terminal") and a registered terminal (hereinafter also referred to as an "old terminal") (i.e., a user who has both a new terminal and an old terminal at hand). With second device authentication, the user can operate payment app 20 on the old terminal to display a QR code for transfer, and then read the QR code displayed on the old terminal with payment app 20 on the new terminal, thereby logging in to the electronic payment service from the new terminal.

[0038] Third device authentication is device authentication for users who can operate a new terminal but cannot operate an old terminal (i.e., users who only have a new terminal at hand). In third device authentication, a takeover URL is sent to the new terminal by SMS, and the new terminal is authenticated if the device ID of the user terminal device 10 that accesses the URL matches the device ID of the new terminal recognized in the first device authentication. With third device authentication, the user can log in to the electronic payment service from the new terminal by operating the new terminal and accessing the URL notified by SMS. The takeover URL is generated as a temporarily valid URL (one-time link).

[0039] In both the second device authentication and the third device authentication, if authentication is successful, the registered terminal is changed from the old terminal to the new terminal. As a result, when logging in using the new terminal thereafter, the first device authentication will be successful, and the user will be able to log in to the electronic payment service with only password authentication, without having to perform second device authentication or third device authentication.

[0040] [Phishing concerns over third-device authentication] However, in the conventional third device authentication, there were cases where the handover process was not performed as expected due to reasons that could not be avoided by the payment application 20 (unavoidable reasons). In order to rescue users who failed authentication due to such reasons, the conventional third device authentication provided one-time password authentication as an authentication method that could be used when authentication failed. For this reason, in the conventional third device authentication, there was a possibility that the one-time password could be illegally obtained by a third party by a method such as phishing. One-time password authentication is a method of authentication by displaying a one-time password on a registered terminal (old terminal) and having the user enter it into a new terminal.

[0041] More specifically, the unavoidable reason is that, depending on the operation performed by the user when accessing the URL notified by SMS, a device ID different from the device ID of the payment app 20 of the new terminal is notified to the payment server 100. In the third device authentication, in order to have the payment server 100 acquire the device ID of the payment app 20, it is necessary to have the payment app 20 access the takeover URL. For this reason, in the conventional third device authentication, the payment server 100 described the takeover URL in the form of a deep link so that the payment app 20 performs an operation to access the URL when the takeover URL is selected on the new terminal side. As a result, it was assumed that, when an operation to select the takeover URL is performed on the new terminal that received the SMS, the payment app 20 accesses the URL, and the payment server 100 can recognize the device ID of the payment app 20.

[0042] However, when the takeover URL is selected by a tap operation, the payment application 20 accesses the URL, whereas when the takeover URL is selected by a long press operation, the web browser accesses the URL instead of the payment application 20. When the web browser accesses the takeover URL, the payment server 100 recognizes a device ID different from the device ID of the payment application 20, and the third device authentication fails. In addition, the control of which application program the URL is handed over to in response to the selection operation of the URL included in the SMS message generally depends largely on the operating system, and it is difficult to control from the application program operating under the operating system. For example, when the takeover URL is selected on the received SMS message by a long press operation, the preview function of the web browser may be called depending on the operating system. In this case, the call of the payment application 20 by the deep link does not work well, and the preview function causes the web browser to access the takeover URL, and the device ID of the web browser may be linked to the payment server 100.

[0043] The one-time password authentication described above is an authentication method provided to rescue users who fail third device authentication for such unavoidable reasons, but because password authentication and similar methods tend to be targets of phishing scams, providing such an authentication method can be a factor in reducing the security of electronic payment services. In order to prevent such a reduction in security, this embodiment modifies part of the conventional third device authentication to perform a new third device authentication.

[0044] [New third device authentication] Fig. 8 and Fig. 9 are sequence charts showing an example of a process flow related to new third device authentication. Fig. 8 shows a sequence when a takeover URL received by SMS is selected by a tap operation in the user terminal device 10, and Fig. 9 shows a sequence when a takeover URL received by SMS is selected by a long press operation in the user terminal device 10. In Fig. 8 and Fig. 9, S401 to S403 show a situation where the first device authentication fails (S403) because the device ID (S401: first device ID) acquired from the payment application 20 at the time of a login request does not match the device ID of a registered terminal (S402).

[0045] (In case of tap operation) In FIG. 8, first, S411 is a process in which the payment server 100 notifies the user terminal device 10 of the transfer URL by SMS when the first device authentication fails and the user selects the third device authentication. Next, in S412A, the user selects the notified transfer URL by tapping. As described above, in the case of a tap operation, the transfer URL is passed to the payment application 20, and the payment application 20 accesses the URL (S413), so that the device ID (first device ID) recognized in the first device authentication matches the device ID (second device ID) of the payment application 20 that accessed the transfer URL (S414), and the third device authentication is successful (S415). In addition, in the case of a tap operation, the device ID of the payment application 20 is linked to the payment server 100 as expected, so the process flow in this case is the same as that of the conventional third device authentication.

[0046] On the other hand, when the user selects the notified takeover URL by a long press operation, as described above, even if the URL is described in the form of a deep link for the payment application 20, the takeover URL may be handed over to an application program (typically a web browser) other than the payment application 20. Here, a case where the takeover URL is handed over to the web browser by a long press operation will be described. In this case (S412B), the web browser is started in the user terminal device 10 and accesses the takeover URL (S416). Here, it is assumed that the login authentication unit 150 of the payment server 100 has a function of a web server that publishes the takeover URL.

[0047] Next, in the payment server 100, the login authentication unit 150 accepts the access from the user terminal device 10 to the takeover URL and recognizes that the device ID of the access source does not match the device ID recognized in the first device authentication (S417). When the login authentication unit 150 recognizes that the device IDs do not match, it returns HTML (Hyper-Text Markup Language) data for displaying a web page including both the authentication QR code and the takeover URL to the web browser of the user terminal device 10 (S418). Here, the login authentication unit 150 transmits the takeover URL described in the form of a deep link to the payment application 20, similar to the takeover URL notified by SMS in S411, to the user terminal device 10, including the HTML data.

[0048] Next, in the user terminal device 10, the web browser displays a web page for QR code authentication in which the takeover URL is described based on the HTML data received in S418 (S419). Fig. 10 is a diagram showing an example of a web page WP in which the takeover URL is described. The web page WP displays a QR code CD for authentication and a hyperlink LK that links to the takeover URL. The web page WP shown in Fig. 10 is an example of a method of presenting QR code authentication as the main authentication method, while providing device authentication using the takeover URL as an alternative method for users who cannot scan QR codes.

[0049] Here, for example, it is assumed that the telephone number of the user registered in the electronic payment service is linked to the old terminal. That is, a SIM (Subscriber Identity Module) card having the registered telephone number is inserted in the old terminal. In this case, the notification destination of S411 is the old terminal, so that a QR code for authentication is displayed in the web browser of the old terminal. When the user reads the QR code displayed on the old terminal with the payment application 20 of the new terminal, the read information is linked to the payment server 100 and login is permitted.

[0050] However, if the user does not have the old terminal at hand, it is impossible for the new terminal to read the QR code displayed on the old terminal. In such a case, the user can receive device authentication by accessing the takeover URL from the new terminal as an alternative authentication means. More specifically, the user performs an operation to select the takeover URL displayed on the web browser of the new terminal (S420). For example, in the example of FIG. 10, the user selects the hyperlink LK by tapping or long pressing. In this selection operation, the takeover URL is displayed by the web browser rather than the SMS function, so that the deep link is recognized as expected regardless of whether the tapping or long pressing is performed. As a result, the takeover URL is handed over to the payment application 20, and the payment application 20 accesses the takeover URL (S421).

[0051] That is, in the new third device authentication, the operation of selecting the takeover URL in S420 may be a tap operation or a long press operation. In this case, in the payment server 100, the login authentication unit 150 recognizes that the device ID of the payment application 20 that accessed the takeover URL matches the device ID recognized in the first device authentication (S422), and the third device authentication is successful (S423).

[0052] In this way, in the new third device authentication, the payment server 100 does not immediately perform one-time password authentication for a user who accesses the takeover URL from an application program other than the payment application 20 (due to a mismatch in device IDs), but provides a more reliable method for allowing the payment application 20 to access the takeover URL. As a result, the frequency of failure of SMS authentication by a legitimate user decreases, and the situation in which one-time password authentication is necessary becomes less likely to occur, which inevitably reduces the possibility of one-time passwords being leaked. In other words, the new third device authentication in this embodiment can improve the security of one-time password authentication as an additional authentication means to third device authentication.

[0053] In addition, the fact that the frequency of failure of SMS authentication by legitimate users in the new third device authentication decreases means that, conversely, it is more likely that those who fail SMS authentication and perform one-time password authentication will be considered to have failed SMS authentication with malicious intent. This is because a legitimate user is unlikely to fail device authentication unless they change their model. Furthermore, a legitimate user should be able to succeed in authentication by QR code authentication or SMS authentication even if they change their model. Furthermore, a legitimate user should be able to succeed in authentication by selecting the takeover URL displayed in the web browser (either by tapping or by long pressing) even if they select the takeover URL written in the received SMS message by long pressing in SMS authentication. Even in this case, it is difficult to imagine that a legitimate user will fail SMS authentication and perform one-time password authentication. Furthermore, since it is generally considered that phishing is easier to succeed in between QR code authentication and SMS authentication, it is considered that phishing perpetrators are more likely to choose SMS authentication than QR code authentication.

[0054] For this reason, when the login authentication unit 150 detects that a user who failed in SMS authentication has performed one-time password authentication, it notifies the user accordingly. Here, the login authentication unit 150 may notify the administrator of the electronic payment service, or may notify a contact address (such as a telephone number or email address) registered for the user. Furthermore, when the login authentication unit 150 detects that a user who failed in SMS authentication has performed one-time password authentication, instead of or in addition to the above notification, the login authentication unit 150 may be configured to restrict some of the functions provided by the electronic payment service for the user.

[0055] According to the embodiment described above, it is possible to improve the security of the one-time password provided as an additional authentication means in addition to the specified authentication means.

[0056] In the above embodiment, the authentication device of the present invention is configured as the payment server 100. However, the authentication device may be configured as a separate device that is separate from the electronic payment service function of the payment server 100. In this case, the authentication device may be configured to exchange necessary information with the payment server 100 as necessary by communicating with the payment server 100. In this case, part or all of the information necessary for login authentication among the information stored in the storage unit 170 by the payment server 100 may be held in the storage unit of the authentication device.

[0057] The above describes the form for carrying out the present invention using an embodiment, but the present invention is not limited to such an embodiment, and various modifications and substitutions can be made within the scope that does not deviate from the gist of the present invention. [Explanation of symbols]

[0058] 10 User terminal device 20. Payment App 50 First store terminal device 60 Store Code Image 70 Second store terminal device 72 Merchant Interface 100 Payment Server 110 Communications Department 120 Payment Contents Provider 130 Payment processing unit 140 Information Management Department 150 Login authentication section 170 Storage section 172 User information 174 Payment Content Information 176 Affiliated Stores / Store Information

Claims

1. An authentication device that executes an authentication process for authenticating a user in response to a request from a first application program running on a terminal device of the user, an authentication unit that authenticates the user when first identification information, which is identification information of the first application program and is received from the first application program at the time of the request, matches second identification information, which is identification information of a second application program that has accessed a predetermined network address notified to the terminal device at the time of the request; the network address is written in a manner that designates the first application program as an entity that accesses the network address, the authentication unit supplies display information for displaying the network address to the second application program when the first identification information and the second identification information do not match, and authenticates the user when third identification information, which is identification information of an application program that has accessed the network address after the display information is supplied, matches the first identification information. Authentication device.

2. the authentication unit provides a password-based authentication means when the third identification information does not match the first identification information, and when the password-based authentication means is used, notifies a contact address registered for the user or an administrator of the authentication device. The authentication device according to claim 1 .

3. When making the request, the authentication unit notifies the terminal device of the network address by SMS (Short Message Service). The authentication device according to claim 1 .

4. When the network address notified by the SMS is selected by a tap operation, the first application program accesses the network address, and when the network address is selected by a long press operation, the second application program accesses the network address. The authentication device according to claim 3.

5. the second application program is a web browser; the second identification information of the web browser is different from the first identification information; The authentication device according to claim 4.

6. the first application program cooperates with a payment management device to provide an electronic payment service to the user; the first application program requests the payment management device to authenticate a user who logs in to the electronic payment service, and provides the electronic payment service to a user who has been successfully authenticated. The authentication device according to claim 1 .

7. the authentication unit provides a password-based authentication means when the third identification information does not match the first identification information, and when the password-based authentication means is used, restricts a part of the functions provided by the electronic payment service for the user. The authentication device according to claim 6.

8. the display information displays a QR code for authentication as a first authentication means, and displays a link for accessing the network address as a second authentication means. The authentication device according to claim 1 .

9. an authentication device that executes an authentication process for authenticating a user in response to a request from a first application program running on a terminal device of the user, an authentication method for authenticating the user when first identification information, which is identification information of the first application program and is received from the first application program at the time of the request, matches second identification information, which is identification information of a second application program that has accessed a predetermined network address notified to the terminal device at the time of the request, the network address is written in a manner that designates the first application program as an entity that accesses the network address, when the first identification information and the second identification information do not match, the authentication device supplies display information for displaying the network address to the second application program, and authenticates the user when a third identification information, which is identification information of an application program that has accessed the network address after the supply of the display information, matches the first identification information. Authentication method.

10. an authentication device that executes an authentication process for authenticating a user in response to a request from a first application program running on a terminal device of the user; a program for executing an authentication process for authenticating the user when first identification information, which is identification information of the first application program and is received from the first application program at the time of the request, matches with second identification information, which is identification information of a second application program that has accessed a predetermined network address and is notified to the terminal device at the time of the request, the network address is written in a manner that designates the first application program as an entity that accesses the network address, If the first identification information and the second identification information do not match, the authentication device providing display information to the second application program for displaying the network address; and authenticating the user when third identification information, which is identification information of an application program that has accessed the network address after the display information is provided, matches the first identification information. Program for.

Images