JP7783243B2 - Authentication device, authentication method, and program - Google Patents

Description

The present invention relates to an authentication device, an authentication method, and a program.

In the past, when authenticating a user logging in to a service, in addition to using a specified authentication method, the system would check whether the terminal device from which the login request was made was a registered terminal device, and if the terminal device from which the login request was made was not a registered terminal device, additional authentication would be performed using a QR code (registered trademark, the same applies hereinafter) or SMS (Short Message Service) (see, for example, Patent Documents 1 and 2).

Patent No. 7247416 Patent No. 7202500

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 "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.

The present invention was made in consideration of these circumstances, and one of its objectives is to provide an authentication device, authentication method, and program that can improve the security of authentication methods that verify identity by issuing an authentication code and having the user return it.

One aspect of the present invention is an authentication device that executes authentication processing 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 for the first application program and is 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 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 in the authentication code input screen from the terminal device, and authenticates the user if the obtained second authentication code matches the first authentication code.

One aspect of the present invention provides an authentication device, authentication method, and program that can improve the security of one-time passwords provided as an additional authentication means in addition to standard authentication means.

FIG. 1 is a diagram illustrating an example of a configuration for realizing an electronic payment service. FIG. 1 is a sequence diagram (part 1) illustrating an example of the general flow of electronic payment. FIG. 2 is a sequence diagram (part 2) illustrating the general flow of electronic payment. FIG. 2 is a configuration diagram of a payment server 100 according to the first embodiment. FIG. 10 is a diagram showing an example of the contents of user information 172. FIG. 10 is a diagram showing an example of the contents of affiliated store/store information 176. 1 is a sequence chart (part 1) illustrating an example of a flow of conventional SMS authentication. 1 is a sequence chart (part 2) illustrating an example of a flow of conventional SMS authentication. 1 is a sequence chart (part 1) illustrating an example of a flow of new SMS authentication. 10 is a sequence chart (part 2) illustrating an example of the flow of new SMS authentication. FIG. 10 is a diagram showing an example of an authentication code screen in new SMS authentication. FIG. 1-1 shows an example of screen transitions during payment including new SMS authentication. FIG. 1-2 shows an example of screen transitions during payment including new SMS authentication. FIG. 2-1 shows an example of screen transitions during payment including new SMS authentication. FIG. 2-2 shows an example of screen transitions during payment including new SMS authentication.

The following describes embodiments of the authentication device, authentication method, and program of the present invention, with reference to the drawings. Various devices used to provide services to users and perform internal analysis, such as the "server," "management device," and "information provider" mentioned below, may be implemented as a distributed group of 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. The application program and payment server work together to provide electronic payment services. In the following description, the application program is referred to as a payment app. Electronic payment services are services that support payments for the purchase of goods and services at stores. A store is, for example, a physical store (brick-and-mortar store) located in the real world, but may also include virtual stores for e-commerce transactions. Virtual stores may also include those operated by entities other than the operator of the electronic payment service. In such cases, when making payments for purchases at the virtual store, the user is controlled to transition to the interface screen of the electronic payment service. In electronic payment services, stores are treated as belonging to, for example, affiliated stores (brands), and transactions such as payments when making purchases at a store are primarily conducted between the user and the affiliated store. Alternatively, payment and other transactions may be handled between the user and the store.

[Electronic payment service]
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 local area network (LAN), a wireless base station, a provider device, etc.

The user terminal device 10 is, for example, a portable terminal device such as a smartphone or tablet. The user terminal device 10 is a computer device that has 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, the components that realize these functions will be 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.

The first store terminal device 50 is installed, for example, in a store. The first store terminal device 50 is a computer device that has 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 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 also be displayed on a display placed in the store (which may be the display of a terminal device such as a smartphone).

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.

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 to the payment server 100 via the affiliated store server. In the following explanation, this distinction will not be made and payment information will be assumed to be sent from the first store terminal device 50.

Figures 2 and 3 are sequence diagrams illustrating the general flow of electronic payments. There may be two patterns for electronic payments: Pattern 1 and Pattern 2.

In the case of pattern 1 (hereinafter referred to as user scan) shown in FIG. 2, the user terminal device 10, with the payment app 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-identifying information has been added, and is associated with an affiliated store ID, store ID, etc. in the payment server 100 (described below). The payment app 20 transmits 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, obtains information on the affiliated store name and store name, and transmits this information to the payment app 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). The user terminal device 10 then generates second payment information including at least the payment amount and sends 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 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 in which the user inputs 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.

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 (S11) when the payment app 20 is launched, when a payment operation is performed in the payment app 20, when an automatic update occurs (e.g., every minute), and at other times. 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 obtained in advance by reading a barcode or manually entering it. Based on the received information, the payment server 100 identifies the user corresponding to the one-time code and performs the electronic payment (S17). The payment server 100 then sends a payment completion notification to the payment app 20 (S18), and the payment app 20 displays a payment completion screen (S19).

Note that electronic payment may be made 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 during store scanning, and the payment app 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.

[Payment server]
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 implemented by, for example, a hardware processor such as a CPU executing a program (software). Some or all of these components may be implemented 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 implemented 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.

The storage unit 170 is a hard disk drive (HDD), flash memory, RAM (Random Access Memory), etc. The storage unit 170 may also 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.

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.

The payment content providing unit 120 has, for example, the functionality of a web server, and provides the user terminal device 10 with information (payment content) for displaying a screen that provides various functions of the electronic payment service. The payment content providing unit 120 reads out the 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 app 20, and transmits the aforementioned payment information and the like to the payment server 100.

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 referencing the user information 172.

Figure 5 shows 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 settings, deferred payment limit, deferred payment usage amount, available deferred payment amount, payment method settings, 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 by the user (or does not have to be set). The email address, name, address, and date of birth are also information that can be set by the user (or do not have to be set). The registration date is the date the user registered for the electronic payment service (the date the account was created). Hereinafter, a user's instance (electronic payment account) associated with this information will be referred to as an account.

The charge balance is information indicating the balance of electronic money set by the user by transferring funds to the account in advance. Transfer methods include transfer from a designated (bank) ATM (Automatic Teller Machine) or from a registered bank account. The deferred payment setting indicates whether the settings for electronic deferred payment have 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, and 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 illustration shows only one deferred payment limit, in reality there may also be daily limits, and the lower of these may be set as the deferred payment limit. Further details on deferred payment will be provided later. The payment method setting is setting information indicating 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 about 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.).

Login status information is information that indicates the login status of each user in the electronic payment service. For example, login status information includes information on whether the user is logged in or logged out of the electronic payment service. Login status information may also include information such as the date and time the user logged in to the electronic payment service and the date and time the user logged out. Registered terminal information is identification information for the "registered terminal" described below. Registered terminal information is registered in advance by the user in the payment server 100.

Figure 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 affiliated store IDs and store IDs are associated with store URLs, a second table 176B in which affiliated store IDs are associated with affiliated store names and sales amounts (described above), and a third table 176C in which store IDs are associated with store names. In addition to this information, the affiliated store/store information 176 may also include information such as affiliated store or store categories, store locations, and payment patterns.

The information management unit 140 manages user information 172 and affiliated store/store information 176 based on information obtained from the user terminal device 10 and the second store terminal device 70. The information management unit 140 adds new records, edits, deletes, etc. for the user information 172 and affiliated store/store information 176.

In response to a request from the payment application 20, the login authentication unit 150 performs authentication processing for a user attempting to log in to the electronic payment service. The login authentication unit 150 updates the user's login status according to the authentication result.

[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; rather, an 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.

The payment processing unit 130 performs electronic payments as follows for users whose "setting information" is set to "deferred payment." 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, allowing electronic payments that are not dependent on the charge balance within the deferred payment limit. 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 in full for one month on the payment date of the following month, 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 payment date of the following month, 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.

[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 are logged in to the electronic payment service and not to provide payment content to users who are 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's user terminal device 10.

However, with conventional login authentication methods, passwords (including passcodes) can be illegally obtained through phishing or other methods, resulting in the unauthorized use of legitimate users' accounts by third parties. The login authentication method of this embodiment is designed to reduce the likelihood of unauthorized use due to such password leaks compared to conventional methods. More specifically, with conventional login authentication, there was a concern that a user who failed device authentication could have their password stolen when switching 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 when device authentication fails.

[Conventional SMS authentication flow]
Figures 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"). Figure 7 shows the flow when logging in to an electronic payment service using payment app 20 on user terminal device 10 on which payment app 20 is installed. On the other hand, Figure 8 shows the flow when logging in to an electronic payment service using, for example, a web browser on a user terminal device (e.g., a PC, hereinafter referred to as "user PC") on which payment app 20 is not installed. Here, payment app 20 in the case of Figure 7 and the web browser in the case of Figure 8 are examples of a "first application program."

First, the flow in Figure 7 will be explained. First, the user of the user terminal device 10 inputs their own ID for the electronic payment service (for example, the above-mentioned user ID, telephone number, account ID, etc., hereinafter referred to as the "login ID") and password into the payment app 20, and performs an operation (login operation) on the payment app 20 to instruct the payment app 20 to attempt to log in using the login ID and password. In response to this login operation, the payment app 20 generates a login request based on the input login ID and password and sends it to the payment server 100 (S401: Login request).

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 app 20 of the authentication result.

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 requesting payment app 20 (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 app 20 presents its own device ID when interacting with the payment server 100, and device authentication is an authentication method that authenticates the requesting payment app 20 when the presented device ID matches a registered device ID. Here, the device ID provided by the payment app 20 is an example of "first identification information," and the registered device ID is an example of "second identification information."

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

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 app 20 of a device authentication error (S407). In response to this notification, the requesting payment app 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 an authentication code. When the user requests the transmission of an 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 app 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.

Next, the user enters the authentication code notified by SMS into the authentication code input screen (S410), and the entered authentication code is notified to the payment server 100 (S411). The payment server 100 determines whether the authentication code sent in S409 matches the authentication code received in S411 (S412), and if they match, notifies the requesting payment app 20 that login authentication was successful (S405). If they do not match, it notifies the requesting payment app 20 that login authentication failed (S403: authentication error). Here, the authentication code notified to the payment server 100 via the authentication code input screen is an example of a "second authentication code."

Next, the flow in Figure 8 will be explained. The flow in Figure 8 is basically the same as the flow in Figure 7, except that the user terminal device 10 in the flow is replaced with a user PC. However, it differs in that the authentication code is not sent via SMS to the requesting user PC, but to the user terminal device 10 with the user's registered phone number (S419). In this case, the user visually confirms the authentication code sent to the user terminal device 10 via SMS and enters the confirmed 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."

[Concerns about phishing with conventional SMS authentication]
As described above, in conventional SMS authentication, an authentication code is notified via SMS after an authentication code input screen is displayed on the requesting user terminal device 10 or user PC. Therefore, if a malicious third party were to obtain an authentication code illegally through phishing or other methods, they could successfully log in by entering the obtained authentication code into the authentication code input 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.

[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 app 20 on user terminal device 10 on which payment app 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 (e.g., a PC, hereinafter referred to as "user PC") on which payment app 20 is not installed (corresponding to Fig. 8).

First, the flow of Figure 9 will be described. The flow from S401 to S407 is the same as in Figure 7. Next, the payment server 100 generates an authentication code and generates an authentication code screen for displaying the generated authentication code and sends it to the requesting payment application 20 (S501). The requesting payment application 20 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 the payment server 100 to send a link URL to the authentication code input screen via SMS. When the user operates the displayed authentication code screen to request the transmission of the link URL to the authentication code input screen, an SMS transmission request is made to the 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."

When the payment server 100 receives the request of S503, it generates a link URL to the authentication code input screen and notifies the requesting user terminal device 10 of the link URL via 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 specified period of time after its generation. Also, for example, the link URL is created as a deep link for accessing the application program that made the request in S503. In this case, when the user performs an operation to select the notified link URL, the requesting payment app 20 requests the payment server 100 to send an authentication code input screen (S505), and in response to this request, the payment server 100 sends the authentication code input screen to the requesting payment app 20 (S506).

Next, on 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 then enters that 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.

Next, the flow in Figure 10 will be described. The flow from S401 to S407 is the same as in Figure 7. Next, the payment server 100 generates an authentication code and 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 Figure 9. When the user performs an operation on the displayed authentication code screen to request transmission of a link URL to the authentication code input screen, an SMS transmission request is made to the payment server 100 (S513).

When the payment server 100 receives the request of S513, it generates a link URL to the authentication code input screen and sends the link URL via SMS to the user's registered phone number (S514). In other words, 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 phone number. When the user performs an operation to select the notified link URL, the user terminal device 10 requests the payment server 100 to send an authentication code input screen (S515), and in response to this request, the payment server 100 sends the authentication code input screen to the requesting user terminal device 10 (S516).

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

For example, in the example shown in Figure 9, a third party who has illegally obtained a legitimate user's service ID and password can successfully complete password authentication (S402) by using that service ID and password to make a login request (S401) from their own user terminal device 10 (unauthorized terminal). 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). The payment server 100 then sends a link URL to the authentication code input screen via SMS (S504). However, this 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, a third party who makes a login request using an unauthorized terminal cannot proceed to steps S503 and beyond, and therefore cannot successfully complete login authentication.

Also, for example, in Figure 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). The payment server 100 then sends a link URL to the authentication code input screen via SMS (S504). However, this 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.

In this way, with the new SMS authentication, if device authentication fails after password authentication, the authentication code screen is displayed before the authentication code input screen is displayed on the user's side (user terminal device 10, user PC), and the authentication code input screen is displayed on the user's 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 fraudulently obtained by a third party, thereby reducing the possibility of fraudulent logins occurring.

Figure 11 shows an example of an authentication code screen for 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 via SMS. The authentication code has an expiration time. The display section D11 may display the expiration time along with the authentication code.

The authentication code illustrated in FIG. 11 is a combination of two letters and a four-digit number. Both the two letters 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 enter the entire authentication code. Alternatively, the authentication code input screen may be configured to prompt the user to enter part of the authentication code. For example, the authentication code input screen may be configured to pre-display the two letters notified to the user and prompt the user to enter the four-digit number. In this case, the user can visually confirm that the two letters displayed on the authentication code screen match the two letters displayed on the authentication code input screen, and then enter the four-digit number after confirming that the authentication code has been entered correctly.

The flow of logging in to an electronic payment service using the new SMS authentication has been explained 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.

Figures 12 to 15 show examples of screen transitions during payment, including new SMS authentication. More specifically, the screen transitions in the examples of Figures 12 and 13 and the screen transitions in the examples of Figures 14 and 15 both start from the purchase screen D21 on the user PC, go through the payment screen on the user terminal device 10, and then reach the payment completion screen (payment completion screen) on the user PC. Furthermore, the screen transitions in the examples of Figures 12 and 13 and the screen transitions in the examples of Figures 14 and 15 both show examples of screen transitions when password authentication is successful but device authentication fails, requiring input of an authentication code. Figures 12 and 13 show examples of screen transitions when a QR code is used to display the login screen, while Figures 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 the first application program."

First, a user operates the web browser on their user PC to access, for example, an affiliated store's online shop and purchase a product from that online shop, which causes a purchase screen D21 to be displayed on the user PC. For example, purchase screen D21 includes information such as the product price and a QR code or link for displaying a login screen. Here, the user reads the QR code with the camera on user terminal device 10A or 10B, which causes login screen D22 to be displayed on user terminal device 10A or 10B. 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 does have a registered phone number.

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 sends 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 the login screen D22 transitions to the authentication code screen D23. As described above, the authentication code screen D23 includes an authentication code display and a link URL to the authentication code input screen, and 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 with 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 the 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 sends it to the payment server 100, the authentication code input screen D25 transitions to the payment screen D26. When the user checks 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 the payment completion screen D27.

Next, we will explain the screen transition examples in Figures 14 and 15. First, as in Figures 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 the login screen displayed on the purchase screen D21, which causes the login screen D22 to be displayed on the user's PC. As in Figures 12 and 13, we assume 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.

Next, the user selects the 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 with 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, causing the authentication code input screen D25 to be 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, causing the authentication code input screen D25 to transition to the payment screen D26. The user confirms the payment amount displayed on the payment screen D26 and enters the payment execution operation, causing the payment server 100 to execute the payment process, and a payment completion notification is sent back 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 authentication code screen D23 to the payment completion screen D27.

In Figures 12 to 15, an expiration time is set for the QR code on the purchase screen D21 for security reasons. In the examples of Figures 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, etc. Also, while the case where the user performs authentication by entering the issued authentication code into an authentication code input screen has been described here, if the user has a user terminal device 10 with the payment app 20 installed, authentication can also be performed by entering the authentication code into the payment app 20. In other words, the payment app 20 has the function of displaying an authentication code input screen for users who have already logged in. In this case, the payment app 20 may be configured to send the entered authentication code to the payment server 100 and, if authentication is successful, display the payment screen D26.

Furthermore, in the screen transitions shown in Figures 12 to 15, if the user PC displaying the purchase screen D21 does not belong to the legitimate user, device authentication fails and new SMS authentication is performed, as described above. In new SMS authentication, as described above, an SMS notification (a link URL to the authentication code input screen) is sent to the user terminal device 10 with the registered phone number, and the user's operation is temporarily transferred to the user terminal device 10 after this SMS notification. That is, in this case, the user's operation is temporarily transferred from the terminal device (user PC) of the third party attempting fraudulent use to the legitimate user's user terminal device 10 (with the 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 legitimate user's user terminal device 10. For example, in the screen transition examples shown in Figures 12 to 15, a message warning of the possibility of fraudulent use may be displayed in the SMS message D24, the authentication code input screen D25, or the payment screen D26.

In addition, in the above description, the user PC represents a terminal device that does not have a registered phone number and does not have the payment app 20 installed, and the terminal type is not limited to a so-called PC. The user PC may be a terminal device in a type other than a so-called PC, as long as it does not have a registered phone number and does not have the 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 the payment app 20 installed.

The embodiment described above improves the security of authentication methods that verify identity by issuing an authentication code and having the user return it.

<Modification>
In the above embodiment, the case has been described in which the payment server 100 determines that login authentication is successful if 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 if the authentication codes match. For example, the payment server 100 may be configured to determine that login authentication is successful if, 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 transmission 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 ).

In the above embodiment, the authentication device of the present invention is configured as the payment server 100, but the authentication device may also be configured as a separate device that is separate from the electronic payment service functions 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 through communication with the payment server 100. Also, in this case, some or all of the information necessary for login authentication, among the information stored in the memory unit 170 by the payment server 100, may be held in the memory unit of the authentication device.

The above describes the form for carrying out the present invention using an embodiment, but the present invention is in no way limited to such an embodiment, and various modifications and substitutions can be made without departing from the spirit of the present invention.

10 User terminal device 20 Payment application 50 First store terminal device 60 Store code image 70 Second store terminal device 72 Interface for affiliated stores 100 Payment server 110 Communication unit 120 Payment content providing unit 130 Payment processing unit 140 Information management unit 150 Login authentication unit 170 Storage unit 172 User information 174 Payment content information 176 Affiliated store/store information

Claims (8)

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. 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 . the payment content providing unit further provides content for displaying a payment completion screen for notifying the 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 . 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 . 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 . 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 . 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. 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 .