Authentication device, authentication method, and program

Abstract

To improve security of an authentication method that verifies user identity by issuing an authentication code and having a user respond thereto.SOLUTION: An authentication device for executing authentication processing for a user in response to an authentication request from a program running on a terminal device of the user, comprises an authentication unit for authenticating the user when first identification information, which is identification information of the program and is received from the program at the time of the authentication request, matches second identification information registered in the authentication device. When the first identification information does not match the second identification information, the authentication unit causes the program to display an authentication code screen displaying a first authentication code, notifies a telephone number of the user registered in the authentication device of access information to an authentication code input screen that accepts input of an authentication code, obtains a second authentication code entered into the authentication code input screen from the terminal device, and authenticates the user when the obtained second authentication code matches the first authentication code.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 specified authentication means, it has been possible to check whether the terminal device from which the login request was made is a registered terminal device, and if the terminal device from which the login request was made 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) (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, if the terminal device making the login request was not a registered terminal device, the user's identity could be verified by issuing an authentication code (hereinafter referred to as the authentication code) and having it return it. However, in this case, there was a risk that a legitimate user's account could be misused by a third party who had illegally obtained the authentication code through phishing or other methods.

[0005] The present invention has been made in consideration of the above circumstances, and one of its objects is to provide an authentication device, an authentication method, and a program that can improve the security of an authentication method that verifies the identity of a user by issuing an authentication code and having the user return it. [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 an authentication request from a first application program running on the user's terminal device, and includes an authentication unit that authenticates the user if 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 authentication request, matches second identification information that has been pre-registered in the authentication device for the user.If the first identification information does not match the second identification information, the authentication unit causes the first application program to display an authentication code screen displaying a first authentication code, notifies a telephone number pre-registered in the authentication device for the user of access information to an authentication code input screen that accepts input of the authentication code, obtains the second authentication code entered into the authentication code input screen from the terminal device, and authenticates the user if the obtained second authentication code matches the first authentication code. [Effects 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 explanation of the drawings]

[0008] [Figure 1] FIG. 1 is a diagram illustrating an example of a configuration for realizing an electronic payment service. [Figure 2] This is a sequence diagram (part 1) illustrating the general flow of electronic payment. [Figure 3] This is a sequence diagram (part 2) illustrating the general flow of electronic payment. [Figure 4] FIG. 2 is a configuration diagram of a payment server 100 according to the first embodiment. [Figure 5] FIG. 10 is a diagram showing an example of the contents of user information 172. [Figure 6]FIG. 10 is a diagram showing an example of the contents of affiliated store / store information 176. [Figure 7] 1 is a sequence chart (part 1) showing an example of a flow of conventional SMS authentication. [Figure 8] 1 is a sequence chart (part 2) illustrating an example of a flow of conventional SMS authentication. [Figure 9] 1 is a sequence chart (part 1) showing an example of the flow of the new SMS authentication. [Figure 10] 10 is a sequence chart (part 2) showing an example of the flow of the new SMS authentication. [Figure 11] FIG. 10 is a diagram showing an example of an authentication code screen in new SMS authentication. [Figure 12] This is a diagram (part 1-1) showing an example of screen transitions during payment including new SMS authentication. [Figure 13] This is a diagram (part 1-2) showing an example of screen transitions during payment including new SMS authentication. [Figure 14] This is a diagram (part 2-1) showing an example of screen transitions during payment including new SMS authentication. [Figure 15] This is a diagram (part 2-2) showing an example of screen transitions during payment including new SMS authentication. DETAILED DESCRIPTION OF THE INVENTION

[0009] Hereinafter, with reference to the drawings, embodiments of an authentication device, an authentication method, and a program according to the present invention will be described. Various devices, such as a "server," a "management device," and an "information providing device," that provide services to users and perform internal analysis, may be implemented as a group of distributed devices, and each device may be operated by a different business. Furthermore, the hardware owner (the cloud server provider) 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 app." An electronic payment service is a service that supports payments for the purchase of goods and services at a store. A store is, for example, a physical store (real-world store) existing in the real world, but may also include a virtual store for e-commerce transactions. A virtual store may also include a store operated by an entity other than the operator of the electronic payment service. In such a case, when making a payment for a purchase at the virtual store, the user is controlled to transition to the interface screen of the electronic payment service. In an electronic payment service, a store is treated as belonging to, for example, a member store (brand), and processing such as payment when a purchase is made at the store is primarily conducted between the user and the member store. Alternatively, processing such as payment may be carried out between the user and the store.

[0010] [Electronic payment service] Figure 1 shows 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, etc.

[0011] The user terminal device 10 is, for example, a portable terminal device such as a smartphone or 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 acceptance 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 app 20, which operates in cooperation with the payment server 100 to provide electronic payment services to users. The payment app 20 is installed on 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, the same applies below) printed on a paper or plastic medium. The store code image 60 may be displayed on a display placed in the store (or on 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, tablet terminal, personal computer, etc. An interface for affiliated stores 72 runs on the second store terminal device 70. The interface for affiliated stores 72 may be an app for affiliated stores or a browser. The interface for affiliated stores 72 accepts coupon settings and the like from 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 the 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 payment information is sent from the POS device via the affiliated store server to the payment server 100. In the following explanation, this distinction will not be made and it is assumed that 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 for 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 running, decodes the store code image 60 using its optical reading function (S1). The store code image 60 includes store URL (Uniform Resource Locator) information. This store URL is the domain of the electronic payment service to which store identification information has been added, and is associated with an affiliated store ID, store ID, etc. in the payment server 100 (described below). The payment application 20 sends first payment information including the store URL and account ID to the payment server 100 (S2). The payment server 100 searches for store information (described below) using the affiliated store ID and store ID corresponding to the store URL, acquires the affiliated store name and store name information (S3), and sends this to the payment application 20 (S4). The user enters the payment amount into the user terminal device 10 on the screen displaying the affiliated store name and store name (S5). Then, the user terminal device 10 generates second payment information including at least the payment amount and sends it to the payment server 100 (S6). The payment server 100 makes the electronic payment based on the received second payment information (S7). The payment server 100 then sends a payment completion notice (information for displaying a payment completion screen) to the payment app 20 (S8), and the payment app 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 information on the payment amount in addition to the store URL. In this case, the step of the user inputting the payment amount is omitted, and the payment amount information is included in the first payment information and sent to the payment server 100. Information on the affiliated store name and store name may be included and displayed on the payment completion screen.

[0017] In the case of pattern 2 (hereinafter referred to as store scan) shown in FIG. 3, the payment app 20 sends a request to issue a one-time code to the payment server 100 when the payment app 20 is launched, when a payment operation is performed in the payment app 20, at the automatic update timing (e.g., every minute), and at other timings (S11). The payment server 100 generates a one-time code (S12) and sends it to the payment app 20 (S13). The payment app 20 displays a code image, such as a QR code or 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 in-store terminal device 50, and the first in-store terminal device 50 decodes the code image using its optical reading function and obtains the one-time code, etc. (S15). The first in-store terminal device 50 then generates payment information including the one-time code, payment amount, affiliated store ID, store ID, etc., and sends it to the payment server 100 (S16). The payment amount information is acquired in advance by reading a barcode, manually entering it, etc. Based on the received information, the payment server 100 identifies the user corresponding to the one-time code and performs electronic payment (S17). Then, the payment server 100 sends 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, issuing a one-time code may be omitted in store scanning, 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 a combination of software and hardware. The program may be stored in advance in a storage device such as an HDD (Hard Disk Drive) or flash memory (a storage device with a non-transitory storage medium), or may be stored in a removable storage medium (a non-transitory 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, flash memory, 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, and is, for example, a network interface card.

[0022] The payment content providing unit 120 has, for example, a web server function, and provides information (payment content) for displaying a screen that provides various functions of the electronic payment service to the user terminal device 10. The payment content providing unit 120 reads out necessary content from the payment content information 174 as appropriate, and provides it to the user terminal device 10. The user terminal device 10 accepts various inputs from the user while 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 user information 172. User information 172 is an example of user registration information. User information 172 includes, for example, a user URL, account ID, telephone number, and password, as well as associated information such as email address, user ID, name, address, date of birth, registration date, charge balance, deferred payment setting, deferred payment limit, deferred payment usage amount, available deferred payment amount, payment method setting, bank account, credit card number, charge history information, payment history information, login status information, and registered terminal information. The user URL is used for remittance processing between users. When registering for the electronic payment service, registration of a phone number and password is required. The account ID is issued to the user by the payment server 100, and the user ID can be set arbitrarily by the user (or does not have to be set). Similarly, the email address, name, address, and date of birth are also information that can be set arbitrarily by the user (or do 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 indicates the balance of electronic money set by the user by transferring funds to the account in advance. Transfer methods include transfers from a designated service provider (bank) ATM (Automatic Teller Machine) or from a registered bank account. The deferred payment setting indicates whether the setting for deferred payment electronic payments has been completed and is set to either "completed" or "not completed." The deferred payment limit is the monthly deferred payment limit. The deferred payment usage amount is the amount of deferred payment already used in the current month. The available deferred payment amount is the amount of deferred payment available in the current month, calculated by subtracting the deferred payment usage amount from the deferred payment limit. While the figure shows only one deferred payment limit, in reality, there may also be daily upper limits, and the lower of these may be set as the deferred payment limit. Further details on deferred payment will be discussed later. The payment method setting indicates whether the user will make electronic payments using the charge balance or by deferred payment at that time. The bank account and credit card number are information on the bank account or credit card number (account number, card number) that can be used to deposit funds into the electronic payment service. The charge history information is a history of the user's previous transfers to the electronic payment service to increase the charge balance. The payment history information is information that shows the breakdown 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 status information is information that indicates the login status of each user in the electronic payment service. For example, the login status information includes information on whether the user is logged in or logged out of the electronic payment service. The login status 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 the "registered terminal" described below. The registered terminal information is registered in advance by the user in the payment server 100.

[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 ID is associated with an affiliated store name and sales amount (described above), 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 store's location, and payment patterns.

[0028] The information management unit 140 manages the user information 172 and the 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, deletes, etc. the user information 172 and the affiliated store / store information 176.

[0029] Login authentication unit 150 performs authentication processing for a user attempting to log in to the 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 references the user information 172 to acquire the "payment method setting" of the user. For users 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 proceeds. The item value of the affiliated store's sales proceeds is not itself used as electronic money, for example, but rather the amount corresponding to the item value of the sales proceeds 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 payments for users whose "setting information" is set to "deferred payment" as follows. Deferred payment is set separately from "credit card payment," which is set in cooperation with a credit card company, which is a separate entity from the operator of the electronic payment service. The operator of the electronic payment service acts as the creditor, and allows electronic payments within the deferred payment limit, independent of the remaining balance. To receive the deferred payment service, a user may be required to obtain a credit card provided by the operator of the electronic payment service. The amount used for deferred payment is settled in full on the following month's payment date, for example, by debit from a bank account. In this case, the payment processing unit 130 makes a provisional payment by adding the payment amount to the deferred payment amount and subtracting the same amount from the available deferred payment balance. On the closing date, the payment processing unit 130 performs the process described above to debit the current month's payment on the following month's payment date, or requests the credit card operator to perform this process. If the payment amount exceeds the available deferred payment balance at the time of provisional payment, an error notification is returned to the payment app 20.

[0032] [Login to electronic payment service] In this embodiment, various functions of the electronic payment service are provided to users who have logged in to the electronic payment service. More specifically, the payment content providing unit 120 is configured to provide payment content to users who have logged in to the electronic payment service, and not to provide payment content to users who have not logged in. For example, when a user is not logged in to the electronic payment service (e.g., when the app is launched), the payment app 20 displays a login screen and accepts input of authentication information (user ID and password), and sends 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 successfully authenticates the user, it changes the user's login status from not logged in to logged in. After the user's login status is changed to logged in, the payment content providing unit 120 provides payment content to the user terminal device 10 of the user.

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

[0034] [Conventional SMS authentication process] 7 and 8 are sequence charts showing an example of the flow of conventional login authentication using SMS (Short Message Service) (hereinafter referred to as "SMS authentication"). FIG. 7 shows the flow when logging in to an electronic payment service using payment application 20 on user terminal device 10 on which payment application 20 is installed. On the other hand, FIG. 8 shows the flow when logging in to an electronic payment service using, for example, a web browser on a user terminal device (such as a PC, hereinafter referred to as "user PC") on which payment application 20 is not installed. Here, payment application 20 in the case of FIG. 7 and the web browser in the case of FIG. 8 are examples of a "first application program."

[0035] First, the flow of Fig. 7 will be described. First, the user of user terminal device 10 inputs his / her own ID (such as the above-mentioned user ID, phone number, or account ID, hereinafter referred to as "login ID") and password for the electronic payment service into payment application 20, and performs an operation (login operation) to instruct payment application 20 to attempt to log in using the login ID and password. In response to this login operation, payment application 20 generates a login request based on the input login ID and password and sends it to payment server 100 (S401: Login request).

[0036] Next, the payment server 100 accepts the login request of S401 and determines whether the presented login ID and password match the registered login ID and password (S402). If the presented login ID and password do not match the registered login ID and password, the payment server 100 determines that authentication of the login request has failed (S403: authentication error) and notifies the requesting payment application 20 of the authentication result.

[0037] On the other hand, if the presented login ID and password match the registered login ID and password in S402, the payment server 100 then performs device authentication based on the device ID of the payment application 20 that made the request (S404). Here, the device ID is an identifier for uniquely identifying the user terminal device 10 or an application program running on the user terminal device 10. The payment application 20 presents its own device ID in interactions with the payment server 100, and device authentication is an authentication method for authenticating the requesting payment application 20 when the presented device ID matches a registered device ID. Here, the device ID provided by the payment application 20 is an example of "first identification information," and the registered device ID is an example of "second identification information."

[0038] If the presented device ID matches the registered device ID in S404, the payment server 100 notifies the requesting payment application 20 that the login authentication was successful (S405). Then, in the user terminal device 10, in response to the requesting payment application 20 receiving the notification of S405, the user terminal device 10 executes a normal authentication process (S406). The normal authentication process is a process defined to be executed when the login authentication is successful, and a typical example is a process of transitioning to the top screen of the payment application 20. Note that the normal authentication process may be a process of transitioning to the top screen or a process depending on the situation when the login request was sent.

[0039] On the other hand, if the presented device ID does not match the registered device ID in S404, the payment server 100 notifies the requesting payment application 20 of a device authentication error (S407). In response to this notification, the requesting payment application 20 displays an authentication code input screen on the user terminal device 10 (S408). For example, the authentication code input screen may include a means for accepting an operation to request the payment server 100 to send an authentication code and a means for accepting an operation to input the authentication code. When the user requests the transmission of the authentication code on the displayed authentication code input screen, the payment server 100 sends the authentication code by SMS (S409). At this time, the payment server 100 sends the authentication code to the telephone number registered for the requesting user. If the login to the payment application 20 is by a legitimate user, the destination telephone number is usually the telephone number of the requesting user terminal device 10, and the authentication code is received by the requesting user terminal device 10.

[0040] Next, the user inputs the authentication code notified by SMS into the authentication code input screen (S410), and the input authentication code is notified to payment server 100 (S411). Payment server 100 determines whether the authentication code sent in S409 matches the authentication code received in S411 (S412), and if they match, notifies payment application 20 of the request source that login authentication has been successful (S405), and if they do not match, notifies payment application 20 of the request source that login authentication has failed (S403: authentication error). Here, the authentication code notified to payment server 100 via the authentication code input screen is an example of a "second authentication code."

[0041] Next, the flow of Figure 8 will be described. The flow of Figure 8 is basically the same as the flow of Figure 7, except that the user terminal device 10 in the flow of Figure 7 is replaced with a user PC, except that the destination of the SMS notification of the authentication code is the user terminal device 10 that has the user's registered telephone number (S419), rather than the user PC that sent the request. In this case, the user visually checks the authentication code notified to the user terminal device 10 by SMS and enters the checked authentication code into the authentication code input screen displayed on the user PC. Here, the device ID provided by the application program (e.g., a web browser) that sends the login request (S401) on the user PC is an example of "first identification information," and the registered device ID is an example of "second identification information."

[0042] [Phishing Concerns with Traditional SMS Authentication] As described above, in conventional SMS authentication, an authentication code entry screen is displayed on the requesting user terminal device 10 or user PC, and then the authentication code is notified via SMS. Therefore, if a malicious third party were to obtain an authentication code illegally by phishing or other means, they could successfully log in by entering the obtained authentication code into the authentication code entry screen, potentially resulting in the legitimate user's account being taken over by the third party. In this embodiment, in order to prevent such account takeover by a third party, a part of the conventional SMS authentication is modified to perform a new SMS authentication.

[0043] [New SMS authentication process] 9 and 10 are sequence charts showing an example of the flow of new login authentication using SMS (hereinafter referred to as "new SMS authentication"). FIG. 9 shows the flow when logging in to an electronic payment service using payment application 20 on user terminal device 10 on which payment application 20 is installed (corresponding to FIG. 7). On the other hand, FIG. 10 shows the flow when logging in to an electronic payment service using, for example, a web browser on a user terminal device (such as a PC, hereinafter referred to as "user PC") on which payment application 20 is not installed (corresponding to FIG. 8).

[0044] First, the flow of FIG. 9 will be described. The flow from S401 to S407 is the same as that of FIG. 7. Next, payment server 100 generates an authentication code, and generates an authentication code screen for displaying the generated authentication code and sends it to payment application 20 that is the requestor (S501). Payment application 20 that is the requestor displays the received authentication code screen (S502). Here, for example, the authentication code screen may include a means for displaying the authentication code and a means for accepting an operation to request payment server 100 to send a link URL to an authentication code input screen by SMS. When the user operates the displayed authentication code screen to request transmission of the link URL to the authentication code input screen, an SMS transmission request is made to payment server 100 (S503). Note that the authentication code displayed on the authentication code screen is an example of a "first authentication code." Furthermore, the link URL to the authentication code input screen is an example of "access information" and "network address."

[0045] Upon receiving the request of S503, the payment server 100 generates a link URL to an authentication code input screen and notifies the requesting user terminal device 10 of the link URL by SMS (S504). For example, the link URL to the authentication code input screen is generated as a one-time link. A one-time link is a URL that is valid for a predetermined period after its generation. Furthermore, for example, the link URL is created as a deep link for accessing the application program that is the requesting source of S503. In this case, when the user performs an operation to select the notified link URL, the requesting payment application 20 requests the payment server 100 to transmit an authentication code input screen (S505), and in response to this request, the payment server 100 transmits the authentication code input screen to the requesting payment application 20 (S506).

[0046] Next, in the user terminal device 10, the payment application 20 displays the authentication code input screen received from the payment server 100 (S507) and accepts the input operation of the authentication code (S508). Here, the user visually checks the authentication code displayed on the authentication code screen in S502, and enters the authentication code into the authentication code input screen displayed in S507. The flow from S508 onwards is the same as the flow in Figure 7.

[0047] Next, the flow of Fig. 10 will be described. The flow from S401 to S407 is the same as in Fig. 7. Next, the payment server 100 generates an authentication code, and also generates an authentication code screen for displaying the generated authentication code, and sends it to the requesting user's PC (S511). The requesting user's PC displays the received authentication code screen (S512). The authentication code screen is the same as that described in Fig. 9. When the user performs an operation on the displayed authentication code screen to request transmission of a link URL to an authentication code input screen, an SMS transmission request is made to the payment server 100 (S513).

[0048] Upon receiving the request of S513, the payment server 100 generates a link URL to the authentication code input screen and transmits the link URL by SMS to the user's registered telephone number (S514). That is, in this case, the link URL to the authentication code input screen is received not by the user PC that made the request in S513, but by the user terminal device 10 that has the user's registered telephone number. When the user performs an operation to select the notified link URL, the user terminal device 10 requests the payment server 100 to transmit an authentication code input screen (S515), and in response to this request, the payment server 100 transmits the authentication code input screen to the requesting user terminal device 10 (S516).

[0049] Next, the user terminal device 10 displays the authentication code input screen received from the payment server 100 (S517) and accepts the input operation of the authentication code (S518). Here, the user visually checks the authentication code displayed on the authentication code screen in S512, and enters the authentication code into the authentication code input screen displayed in S517. The flow from S518 onwards is the same as the flow in Figure 8.

[0050] For example, in the example shown in FIG. 9, a third party who has illegally obtained a legitimate user's service ID and password can successfully complete password authentication (S402) by issuing a login request (S401) from their own user terminal device 10 (unauthorized terminal) using the service ID and password. However, in this case, the device ID of the unauthorized terminal does not match the registered device ID, so device authentication (S404) fails, and an authentication code screen is displayed on the unauthorized terminal (S502). Subsequently, the payment server 100 sends a link URL to an authentication code input screen via SMS (S504). However, this link URL is notified to the user terminal device 10 that has the legitimate user's registered phone number, so the third party cannot enter the authentication code acquired in S502 into the authentication code input screen. Therefore, the third party who issued the login request using the unauthorized terminal cannot proceed to steps S503 and beyond, and therefore cannot successfully complete login authentication.

[0051] Also, for example, in FIG. 10 , if the user PC is assumed to be an unauthorized terminal, a third party using the user PC could illegally obtain the service ID and password of a legitimate user and make a login request (S401) from the user PC, thereby successfully completing password authentication (S402). However, in this case, the device ID of the user PC does not match the registered device ID, so device authentication (S404) fails, and an authentication code screen is displayed on the user PC (S502). Thereafter, the payment server 100 sends a link URL to an authentication code input screen via SMS (S504). However, this link URL is notified to the user terminal device 10 that has the legitimate user's registered phone number, so the third party cannot enter the authentication code obtained in S502 into the authentication code input screen. Therefore, in this case, the third party who made the login request using the user PC cannot proceed to steps S503 and beyond, and therefore cannot successfully complete login authentication.

[0052] In this way, with the new SMS authentication, if device authentication after password authentication fails, an authentication code screen is displayed before the authentication code input screen is displayed on the user side (user terminal device 10, user PC), and the authentication code input screen is displayed on the user side based on the information notified by SMS. This prevents the authentication code from being entered on the authentication code input screen even if the authentication code is illegally obtained by a third party, thereby reducing the possibility of an unauthorized login occurring.

[0053] 11 is a diagram showing an example of an authentication code screen in new SMS authentication. The authentication code screen D1 has an authentication code display section D11 and an input section D12 that accepts an operation to request the payment server 100 to send a link URL to an authentication code input screen by SMS. The authentication code has an expiration time. The display section D11 may display the expiration time together with the authentication code.

[0054] The authentication code illustrated in FIG. 11 is a combination of two alphabetic characters and a four-digit number. Both the two alphabetic characters and the four-digit number may be randomly generated. In this case, the authentication code input screen may be configured to prompt the user to input the entire authentication code. Alternatively, the authentication code input screen may be configured to prompt the user to input a portion of the authentication code. For example, the authentication code input screen may be configured to display the two alphabetic characters notified to the user in advance and prompt the user to input the four-digit number. In this case, the user can visually confirm that the two alphabetic characters displayed on the authentication code screen match the two alphabetic characters displayed on the authentication code input screen, and then enter the four-digit number after confirming that the authentication code input destination is correct.

[0055] The flow of logging in to an electronic payment service using the new SMS authentication has been described above for both logging in via payment app 20 and logging in without using payment app 20 (logging in from a web browser). However, the new SMS authentication may be applied to any login situation that requires login authentication to an electronic payment service. For example, the new SMS authentication may be applied to authentication when a user logs in to payment app 20. Furthermore, for example, the new SMS authentication may be applied to authentication for logging in to an electronic payment service that is required when making a payment using the electronic payment service.

[0056] 12 to 15 are diagrams showing examples of screen transitions during payment including new SMS authentication. More specifically, the screen transitions in the examples of FIGS. 12 and 13 and the screen transitions in the examples of FIGS. 14 and 15 start from a purchase screen D21 on the user's PC, go through a payment screen on the user terminal device 10, and then reach a payment completion screen (payment completion screen) on the user's PC. The screen transitions in the examples of FIGS. 12 and 13 and the screen transitions in the examples of FIGS. 14 and 15 are both examples of screen transitions that occur when password authentication is successful but device authentication fails, requiring input of an authentication code. FIGS. 12 and 13 show examples of screen transitions when a QR code is used to display the login screen, while FIGS. 14 and 15 show examples of screen transitions when a QR code is not used to display the login screen. Here, the QR code used to display the login screen is an example of a "two-dimensional code displayed in a first application program."

[0057] First, a user operates a web browser on the user's PC to access, for example, an online shop of an affiliated store and purchase a product from the online shop, which causes a purchase screen D21 to be displayed on the user's PC. For example, the purchase screen D21 includes information such as the product price and a QR code or link for displaying a login screen. Here, it is assumed that the user reads the QR code with the camera of user terminal device 10A or 10B, causing a login screen D22 to be displayed on user terminal device 10A or 10B. Here, user terminal device 10A is a user terminal device 10 that does not have the payment app 20 installed and does not have a registered phone number. On the other hand, user terminal device 10B is a user terminal device 10 that does not have the payment app 20 installed and has a registered phone number.

[0058] For example, the login screen D22 includes an input box for a user ID and an input box for a password, and the user enters the user ID and password and transmits them to the payment server 100. As described above, in this case, after password authentication is successful (the correct user ID and password are entered), device authentication fails, and therefore the login screen D22 transitions to the authentication code screen D23. As described above, the authentication code screen D23 displays an authentication code and a link URL to the authentication code input screen. When the user performs an operation to select the link URL, a message containing the link URL is sent by SMS from the payment server 100 to the user terminal device 10B that has the registered phone number. The user displays the SMS message D24 notified to the user terminal device 10B and performs an operation to select the link URL described in the message, and an authentication code input screen D25 is displayed on the user terminal device 10B. When the user enters the authentication code displayed on the authentication code screen D23 into the authentication code input screen D25 and transmits it to the payment server 100, the authentication code input screen D25 transitions to the payment screen D26. When the user confirms the payment amount displayed on the payment screen D26 and inputs the payment execution operation, the payment server 100 executes the payment process and returns a payment completion notification to the user PC. On the user PC, the web browser maintains a session with the payment server 100, and upon receiving the payment completion notification, transitions the purchase screen D21 to a payment completion screen D27.

[0059] Next, an example of screen transitions in FIGS. 14 and 15 will be described. First, as in the cases of FIGS. 12 and 13, the user operates the web browser on the user's PC to display the purchase screen D21. Here, instead of reading a QR code, the user selects a link for displaying a login screen displayed on the purchase screen D21, which causes the login screen D22 to be displayed on the user's PC. As in the cases of FIGS. 12 and 13, it is assumed that the correct user ID and password are entered. In this case, after password authentication is successful, device authentication fails, so the login screen D22 transitions to the authentication code screen D23.

[0060] Next, the user selects a link URL to the authentication code input screen displayed on the authentication code screen D23, and a message containing the link URL is sent by SMS from the payment server 100 to the user terminal device 10B that has the registered phone number. The user displays the SMS message D24 notified to the user terminal device 10B and selects the link URL described in the message, and an authentication code input screen D25 is displayed on the user terminal device 10B. The user enters the authentication code displayed on the authentication code screen D23 into the authentication code input screen D25 and sends it to the payment server 100, and the authentication code input screen D25 transitions to a payment screen D26. The user confirms the payment amount displayed on the payment screen D26 and inputs a payment execution operation, and the payment server 100 executes the payment process, and a payment completion notification is returned to the user PC. The web browser on the user PC maintains a session with the payment server 100, and upon receiving the payment completion notification, transitions the authentication code screen D23 to a payment completion screen D27.

[0061] 12 to 15, an expiration time is set for the QR code on the purchase screen D21 from a security perspective. In the examples of FIGS. 12 to 15, the expiration time is 15 seconds. The purchase screen D21 may also display the expiration time, a countdown of the expiration time, or the like. Here, the case where the user performs authentication by inputting the issued authentication code into the authentication code input screen has been described. However, if the user has a user terminal device 10 on which the payment app 20 is installed, the user can also be authenticated by inputting the authentication code into the payment app 20. That is, the payment app 20 has a function to display an authentication code input screen for a user who has already logged in. In this case, the payment app 20 may be configured to send the input authentication code to the payment server 100 and, if authentication is successful, to display the payment screen D26.

[0062] 12 to 15, if the user PC displaying the purchase screen D21 does not belong to a legitimate user, device authentication fails and new SMS authentication is performed, as described above. In the new SMS authentication, as described above, an SMS notification (a link URL to an authentication code input screen) is sent to the user terminal device 10 having the registered phone number, and the user's operation is temporarily shifted to the user terminal device 10 after this SMS notification. That is, in this case, the user's operation is temporarily shifted from the terminal device (user PC) of a third party attempting fraudulent use to the user terminal device 10 of the legitimate user (having a registered phone number). Therefore, the payment server 100 may be configured to notify the legitimate user of the possibility of fraudulent use on a screen displayed on the user terminal device 10. For example, in the example of the screen transitions in FIGS. 12 to 15, a message alerting the user to the possibility of fraudulent use may be displayed in the SMS message D24, the authentication code input screen D25, or the payment screen D26.

[0063] In the above description, the user PC represents a terminal device that does not have a registered phone number and does not have payment app 20 installed, and is not limited to a PC. The user PC may be a terminal device in a form other than a PC, as long as it does not have a registered phone number and does not have payment app 20 installed. For example, the user PC may be a tablet, a smartphone, or a user terminal device 10 that does not have a registered phone number and does not have payment app 20 installed.

[0064] According to the embodiment described above, it is possible to improve the security of an authentication method in which an authentication code is issued and returned by the user to verify the user's identity.

[0065] <Modification> In the above embodiment, the case has been described in which the payment server 100 determines that login authentication is successful when the authentication codes match through new SMS authentication after device authentication has failed, but the payment server 100 may be configured to further perform device authentication when the authentication codes match. For example, the payment server 100 may be configured to determine that login authentication is successful when, in addition to the authentication codes matching, in the new SMS authentication, the device ID (an example of third identification information) of the application program that sent the SMS sending request (S503 in FIGS. 9 and 10) matches the device ID (an example of fourth identification information) of the application program (an example of second application program) that accessed the authentication code input screen (S505 in FIGS. 9 and 10).

[0066] In the above embodiment, the case where the authentication device of the present invention is configured as the payment server 100 has been described, but 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 needed by communicating with the payment server 100. In this case, part or all of the information necessary for login authentication, which the payment server 100 stores in the storage unit 170, may be held in the storage unit of the authentication device.

[0067] 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]

[0068] 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 Department 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 including an authentication unit that executes authentication processing for authenticating a user in response to an authentication request from a first application program running on a first terminal device of the user, The authentication unit authenticating the user when the login ID and password of the user acquired via the login screen displayed on the first terminal device match a registered login ID and password, and when the identification information of the first application program provided to the authentication device in the exchange with the authentication device, which is first identification information received from the first application program at the time of the authentication request, matches second identification information pre-registered in the authentication device for the user; If the login ID and password of the user acquired from the first terminal device match a registered login ID and password and the first identification information does not match the second identification information, the method causes the first application program to display an authentication code screen displaying a first authentication code, notifies a telephone number pre-registered in the authentication device for the user corresponding to the login ID and the password of access information to an authentication code input screen that accepts input of an authentication code, acquires a second authentication code input on the authentication code input screen from a device that accessed the authentication code input screen, and authenticates the user if the acquired second authentication code matches the first authentication code. Authentication device.

2. a payment processing unit that executes payment processing in cooperation with the first application program to provide the user with an electronic payment service; a payment content providing unit that provides content for displaying a payment screen that displays details of a payment using the electronic payment service and accepts an instruction to execute the payment; Furthermore, the authentication request is a request for authentication regarding login to the electronic payment service, which may be required when the user makes an electronic payment using the electronic payment service; when the authentication unit determines that the second authentication code matches the first authentication code, the payment content providing unit causes the terminal device having the telephone number to display the payment screen. The authentication device according to claim 1 .

3. The payment content providing unit further provides content for displaying a payment completion screen for notifying completion of the payment, When the login screen is displayed based on a purchase screen displayed on a second terminal device different from the first terminal device, the payment processing unit completes the payment in response to an instruction to execute the payment being input to the payment screen, and the payment content providing unit displays the payment completion screen related to the payment on the second terminal device. The authentication device according to claim 2 .

4. the authentication request is made via the login screen identified by a two-dimensional code or a link displayed on the first application program, the login screen is displayed on a device that reads the two-dimensional code or on the first application program that accepts the link selection operation. The authentication device according to claim 1 .

5. the access information is information indicating a network address of the authentication code input screen, The network address is a one-time link with an expiration date. The authentication device according to claim 1 .

6. the authentication unit accepts a request to transmit the access information via the authentication code screen, and authenticates the user when the second authentication code matches the first authentication code and when third identification information received from the first application program at the time of the transmission request matches fourth identification information acquired from a second application program that accessed the authentication code input screen related to the access information. The authentication device according to claim 1 .

7. an authentication device that executes an authentication process for authenticating a user in response to an authentication request from a first application program running on a first terminal device of the user, authenticating the user when the login ID and password of the user acquired from the first terminal device match a registered login ID and password, and when identification information of the first application program provided to the authentication device in exchange with the authentication device, which is first identification information received from the first application program at the time of the authentication request, matches second identification information pre-registered in the authentication device for the user; If the login ID and password of the user acquired from the first terminal device match a registered login ID and password and the first identification information does not match the second identification information, the method causes the first application program to display an authentication code screen displaying a first authentication code, notifies a telephone number pre-registered in the authentication device for the user corresponding to the login ID and the password of access information to an authentication code input screen that accepts input of an authentication code, acquires a second authentication code input on the authentication code input screen from a device that accessed the authentication code input screen, and authenticates the user if the acquired second authentication code matches the first authentication code. Authentication method.

8. an authentication device that executes authentication processing for authenticating a user in response to an authentication request from a first application program running on a first terminal device of the user; authenticate the user if the login ID and password of the user acquired from the first terminal device match a registered login ID and password, and if the identification information of the first application program provided to the authentication device in the exchange with the authentication device matches first identification information received from the first application program at the time of the authentication request and second identification information pre-registered in the authentication device for the user; If the login ID and password of the user acquired from the first terminal device match the registered login ID and password, and the first identification information does not match the second identification information, a process of displaying an authentication code screen on which a first authentication code is displayed in the first application program; a process of notifying access information to an authentication code input screen that accepts input of an authentication code to a telephone number that is pre-registered in the authentication device for the user that corresponds to the login ID and the password; a process of acquiring the second authentication code input on the authentication code input screen from a terminal device that has accessed the authentication code input screen; a process of authenticating the user when the acquired second authentication code matches the first authentication code; A program to execute.

Images