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 Art

[0002] Conventionally, in authenticating a user who logs in to a service, in addition to the prescribed authentication means, it is confirmed whether the terminal device of the login requester is a registered terminal device. If the terminal device of the login requester is not a registered terminal device, additional authentication using a QR code (registered trademark, the same applies hereinafter) or SMS (Short Message Service) may be performed (see, for example, Patent Documents 1 and 2).

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Patent Document 2

Summary of the Invention

Problems to be Solved by the Invention

[0004] In the conventional technology, when the terminal device of the login requester is not a registered terminal device, identity verification may be performed by issuing an authentication code (hereinafter, authentication code) to the user and having the user reply. However, in this case, there is a possibility that the legitimate user's account may be misused by a third party who has illegally obtained the authentication code by means such as phishing.

[0005] One of the objects of the present invention is to provide an authentication device, an authentication method, and a program that can improve the security of an authentication method for identity verification by issuing an authentication code and replying it to the user in consideration of such circumstances.

Means for Solving the Problems

[0006] One aspect of the present invention is an authentication device that executes an authentication process for authenticating a user in response to an authentication request of a first application program operating on a user's terminal device. The authentication device includes an authentication unit that authenticates the user when first identification information, which is identification information of the first application program and is received from the first application program at the time of the authentication request, matches second identification information that is registered in advance in the authentication device for the user. When the first identification information does not match the second identification information, the authentication unit displays an authentication code screen on which a first authentication code is displayed on the first application program, and notifies access information to an authentication code input screen for receiving an input of the authentication code to a telephone number registered in advance in the authentication device for the user. The authentication unit acquires a second authentication code input on the authentication code input screen from the terminal device, and authenticates the user when the acquired second authentication code matches the first authentication code.

Effect of the Invention

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

Brief Description of the Drawings

[0008]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Embodiments for Carrying Out the Invention

[0009] Hereinafter, with reference to the drawings, embodiments of the authentication apparatus, authentication method, and program of the present invention will be described. Various apparatuses such as "server", "management apparatus", "information providing apparatus", etc. that provide services to users or perform internal analysis may be realized by a decentralized group of apparatuses, and the operators of each apparatus may be different. Also, the holder of the hardware of the apparatus (provider of the cloud server) and the operator who actually operates may be different. The application program and the payment server cooperate to provide an electronic payment service. In the following description, the application program is referred to as a payment application. The electronic payment service is a service that supports payment for the purchase of goods and services in a store. The store is, for example, a physical store (actual store) existing in the real space, but may include a virtual store for e-commerce. The virtual store may include those provided by a party different from the operator of the electronic payment service. In that case, at the time of payment for shopping in the virtual store, it is controlled to transition to the interface screen of the electronic payment service. In the electronic payment service, the store is, for example, treated as belonging to a franchise (brand), and processing such as payment when a purchase action is performed in the store is mainly performed between the user and the franchise. Instead of this, processing such as payment may be performed between the user and the store.

[0010] [Electronic Payment Service] FIG. 1 is a diagram showing an example of a configuration for realizing an electronic payment service. The electronic payment service is realized centering around a payment server 100. The payment server 100 communicates with each of, 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 a portable terminal device such as a smartphone or a tablet terminal, for example. The user terminal device 10 is a computer device having at least an optical reading function, a communication function, a display function, an input reception function, and a program execution function. In the following description, the configurations for realizing these functions are respectively referred to as a camera, a communication device, a touch panel, a CPU (Central Processing Unit), etc. In the user terminal device 10, the payment application 20 is executed by a processor such as a CPU, and it operates to provide an electronic payment service to the user in cooperation with the payment server 100. The payment application 20 is installed in the user terminal device 10 from an application store, for example, and controls a camera, a communication device, a touch panel, etc.

[0012] The first store terminal device 50 is installed in a store, for example. 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 shall apply hereinafter) printed on a paper or plastic medium. Note that the store code image 60 may be displayed by a display placed in the store (which may be a display of a terminal device such as a smartphone).

[0013] The second store terminal device 70 is used by the operator of the franchise store. The second store terminal device 70 is a smartphone, a tablet terminal, a personal computer, or the like. In the second store terminal device 70, an interface 72 for the franchise store operates. The interface 72 for the franchise store may be an application for the franchise store or a browser. The interface 72 for the franchise store accepts settings of coupons and the like by the operator of the franchise store and transmits them to the payment server 100. The second store terminal device 70 that is a smartphone has a function of displaying a code image corresponding to the store code image or reading the code image displayed by the user terminal device 10 by executing an application for the franchise store.

[0014] The payment server 100 realizes electronic payment based on the 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 a franchise store server. In that case, the payment information is transmitted from the POS device to the payment server 100 via the franchise store server. In the following description, without particularly distinguishing this, it is assumed that the payment information is transmitted from the first store terminal device 50.

[0015] FIG. 2 and FIG. 3 are sequence diagrams illustrating a rough flow of electronic payment. There may be two patterns, pattern 1 and pattern 2, in the electronic payment.

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

[0017] In the case of Pattern 2 shown in FIG. 3 (hereinafter referred to as store scan), when the payment application 20 is launched, when a payment operation is performed in the payment application 20, when the automatic update timing (for example, every minute) is reached, and at other timings, the payment application 20 sends a one-time code issuance request to the payment server 100 (S11). The payment server 100 generates a one-time code (S12) and sends it to the payment application 20 (S13). The payment application 20 displays a code image such as a QR code or a barcode generated based on the one-time code (S14). The user shields (presents) the display surface of the user terminal device 10 against the first store terminal device 50, and the first store terminal device 50 decodes the code image by means of an optical reading function and acquires a one-time code or the like (S15). Then, the first store terminal device 50 generates payment information including a one-time code, a payment amount, a franchise store ID, a store ID, etc., and sends it to the payment server 100 (S16). The information on the payment amount has been acquired in advance by barcode reading, manual input, or the like. The payment server 100 identifies the user corresponding to the one-time code based on the received information and performs an electronic payment (S17). Then, the payment server 100 sends a payment completion notification to the payment application 20 (S18), and the payment application 20 displays a payment completion screen (S19).

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

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

[0020] The storage unit 170 is an HDD, a flash memory, a RAM (Random Access Memory), or the like. The storage unit 170 may be a NAS (Network Attached Storage) device accessible by the settlement server 100 via a network. Information such as user information 172, settlement content information 174, and affiliated store / store information 176 is stored in the storage unit 170.

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

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

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

[0024] FIG. 5 is a diagram showing an example of the content of the user information 172. The user information 172 is an example of the user's registration information. The user information 172 includes, for example, a user URL, an account ID, a phone number, a password, as well as an email address, a user ID, name, address, date of birth, registration date, charge balance, post-payment setting, post-payment limit, post-payment usage amount, post-payment available amount, payment method setting, bank account, credit card number, charge history information, payment history information, login status information, registered terminal information, and other information that are associated with each other. The user URL is used for money transfer processing between users. When newly registering for the electronic payment service, it is mandatory to register a phone number and a password. The account ID is issued to the user by the payment server 100, and the user ID is an ID that the user can optionally set (it is not necessary to set it). Similarly, the email address, and the name, address, and date of birth are also information that the user can optionally set (it is not necessary to set it). The registration date is the date when the user registered for the electronic payment service (the date when the account was created). Hereinafter, an instance of the user (electronic payment account) in which these pieces of information are associated with each other is referred to as an account.

[0025] The remaining balance of the charge indicates the information of the remaining balance of the electronic money set by the user by remitting money to the account in advance. As means of remittance, there are remittance from an ATM (Automatic Teller Machine) of a designated business operator (bank), remittance from a registered bank account, and the like. The post-payment setting is information indicating whether or not the setting for enabling electronic payment by post-payment has been completed, and is set to either "completed" or "not completed". The post-payment limit is the limit amount of post-payment available per month, the post-payment usage amount is the amount of post-payment already used in the current month, and the post-payment available amount is the amount of post-payment available in the current month obtained by subtracting the post-payment usage amount from the post-payment limit. Although only one post-payment limit is shown in the figure, in reality, there are further upper limits per day and the like, and the lower of them may be set as the post-payment limit. Further details of the post-payment will be described later. The payment method setting is setting information indicating whether the user performs an electronic payment using the remaining balance of the charge or a payment by post-payment at that time. Each of the bank account and the credit card number is information (account number, card number) of a bank account or a credit card number that can receive deposits in the electronic payment service. The charge history information is the history of the user increasing the remaining balance of the charge by remitting money to the electronic payment service in advance. The settlement history information is information showing the breakdown of the settlements made by the user (date and time, store ID of the store where the purchase action was performed, settlement amount, settlement method, etc.) for each settlement.

[0026] The login status information is information representing 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 in the electronic payment service. Also, the login status information may 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 the identification information of the "registered terminal" described later. The registered terminal information is to be registered in advance by the user with the settlement server 100.

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

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

[0029] The login authentication unit 150 performs an authentication process for a user who is trying to log in to the electronic payment service in response to a request from the payment application 20. The login authentication unit 150 updates the login state of the user according to the authentication result.

[0030] [Electronic Payment] When the payment processing unit 130 acquires payment information from the user terminal device 10 or the first store terminal device 50, it refers to 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 reduces the charge balance managed in association with the user ID and increases the item value of the sales amount of the affiliated store to perform electronic payment. The item value of the sales amount of the affiliated store is not, for example, itself used as electronic money, and the amount corresponding to the item value of the sales amount is transferred to the bank account in a cycle according to the agreement between the affiliated store and the electronic payment service.

[0031] For users whose "Settings Information" is set to "Postpaid", the payment processing unit 130 performs electronic payments as follows. Postpaid is set separately from "credit payment" through 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 that do not depend on the remaining recharge amount within the scope of the postpaid limit. In addition, in order to receive the postpaid service, it may be required to obtain a credit card provided by the operator of the electronic payment service. The amount used for postpaid is settled in one lump sum on the payment date of the following month, for example, by debit from a bank account. In this case, the payment processing unit 130 performs a provisional settlement by adding the settlement amount to the postpaid usage amount and subtracting the same amount from the available postpaid amount. At the end of the month, the processing for debiting the settlement for the current month on the payment date of the following month as described above is performed, or the operator of the credit card company is requested to perform the processing. If the settlement amount exceeds the available postpaid amount at the time of provisional settlement, 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 whose login status to the electronic payment service is logged in 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 (for example, when the app is launched), the payment app 20 displays a login screen and accepts the input of authentication information (user ID and password). Based on the input authentication information, a login request is sent to the payment server 100. In response to this login request, the login authentication unit 150 in the payment server 100 executes an authentication process. When 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.

[0033] However, in the conventional login authentication method, passwords (including passcodes) may be illegally obtained by means such as phishing, and the accounts of legitimate users may be illegally used by third parties. The login authentication method in this embodiment is configured to reduce the possibility of illegal use due to such password leakage compared to the conventional method. More specifically, in the conventional login authentication, there was a concern that the password would be stolen when a user who failed device authentication migrated to one-time password authentication. This embodiment aims to reduce the possibility of illegal use by improving the one-time password authentication method that occurs due to the failure of device authentication.

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

[0035] First, the flow of FIG. 7 will be described. First, when the user of the user terminal device 10 inputs his / her own ID (for example, the above-described user ID, telephone number, account ID, etc., hereinafter referred to as "login ID") and password in the payment application 20, and performs an operation (login operation) instructing a login attempt using the login ID and password on the payment application 20. In response to this login operation, the payment application 20 generates a login request based on the input login ID and password and transmits it to the payment server 100 (S401: Login Request).

[0036] Subsequently, the payment server 100 receives 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 the authentication of the login request has failed (S403: Authentication Error) and notifies the authentication result to the payment application 20 that is the request source.

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

[0038] In S404, when the presented device ID matches the registered device ID, the payment server 100 notifies the requesting payment application 20 that the login authentication has succeeded (S405). Then, on the user terminal device 10, in response to the requesting payment application 20 receiving the notification in S405, normal authentication processing is executed (S406). The normal authentication processing is defined as the processing to be executed when the login authentication is successful. As a typical example, it is the processing to transition to the top screen of the payment application 20. Note that the normal authentication processing may be processing according to the situation where the login request is sent, in addition to the processing to transition to the top screen.

[0039] On the other hand, in S404, when the presented device ID does not match the registered device ID, the payment server 100 notifies the requesting payment application 20 of a device authentication error (S407). In response to this notification, on the user terminal device 10, the requesting payment application 20 displays an authentication code input screen (S408). For example, on the authentication code input screen, there are means for accepting an operation to request the payment server 100 to send an authentication code and means for accepting an input operation of the authentication code. When the user performs an operation to request the sending 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 registered phone number of the requesting user. If the login to the payment application 20 is by a legitimate user, usually, the destination phone number is the phone number of the requesting user terminal device 10, so the authentication code is received on the requesting user terminal device 10.

[0040] Subsequently, by the user entering the authentication code notified by SMS into the authentication code input screen (S410), the entered authentication code is notified to the payment server 100 (S411). The payment server 100 determines whether the authentication code transmitted in S409 matches the authentication code received in S411 (S412). If they match, it notifies the requesting payment application 20 that the login authentication has succeeded (S405). If they do not match, it notifies the requesting payment application 20 that the login authentication has failed (S403: authentication error). Here, the authentication code notified to the payment server 100 via the authentication code input screen is an example of the "second authentication code".

[0041] Next, the flow of FIG. 8 will be described. The flow of FIG. 8 is basically the same as the flow of FIG. 7 with the user terminal device 10 being the user PC, but the difference lies in that the SMS notification destination of the authentication code is the user terminal device 10 having the user's registered phone number instead of the requesting user PC (S419). In this case, the user visually confirms the authentication code notified to the user terminal device 10 by SMS and enters the confirmed authentication code into the authentication code input screen displayed on the user PC. Here, the device ID provided from the application program (for example, a web browser) that transmits the login request (S401) on the user PC is an example of the "first identification information", and the registered device ID is an example of the "second identification information".

[0042] [Concerns about phishing in conventional SMS authentication] As described above, in the conventional SMS authentication, after displaying an authentication code input screen on the requesting user terminal device 10 or the user PC, the authentication code is notified by SMS. Therefore, if a malicious third party obtains the authentication code illegally by means such as phishing, logging in will succeed by entering the obtained authentication code into the authentication code input screen, and there is a possibility that the legitimate user's account will be hijacked by a third party. In order to suppress such hijacking of an account by a third party, this embodiment modifies a part of the conventional SMS authentication to perform a new SMS authentication.

[0043] [Flow of the new SMS authentication] FIG. 9 and FIG. 10 are sequence charts showing an example of the flow of a 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 the payment application 20 on the user terminal device 10 in which the 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 (for example, a PC, hereinafter referred to as "user PC") in which the 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. Subsequently, the settlement server 100 generates an authentication code and generates an authentication code screen for displaying the generated authentication code, and transmits it to the settlement application 20 of the request source (S501). The settlement application 20 of the request source displays the received authentication code screen (S502). Here, for example, on the authentication code screen, there are means for displaying the authentication code and means for accepting an operation of requesting to transmit the link URL to the authentication code input screen to the settlement server 100 by SMS. When the user performs an operation of requesting to transmit the link URL to the authentication code input screen for the displayed authentication code screen, an SMS transmission request is made to the settlement server 100 (S503). Note that the authentication code displayed on the authentication code screen is an example of the "first authentication code". Also, the link URL to the authentication code input screen is an example of the "access information" and the "network address".

[0045] When the settlement server 100 receives the request of S503, it generates a link URL to the authentication code input screen and notifies the user terminal device 10 of the request source 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. The one-time link is a URL that is valid within a predetermined period after generation. Also, for example, the link URL is created as a deep link for accessing the application program of the request source of S503. In this case, when the user performs an operation of selecting the notified link URL, the settlement application 20 of the request source requests the settlement server 100 to transmit the authentication code input screen (S505), and in response to this request, the settlement server 100 transmits the authentication code input screen to the settlement application 20 of the request source (S506).

[0046] Subsequently, 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 an input operation of the authentication code (S508). Here, the user visually confirms the authentication code displayed on the authentication code screen in S502, and inputs the authentication code into the authentication code input screen displayed in S507. The flow after S508 is the same as the flow in FIG. 7.

[0047] Next, the flow in FIG. 10 will be described. The flow from S401 to S407 is the same as that in FIG. 7. Subsequently, the payment server 100 generates an authentication code, and generates an authentication code screen for displaying the generated authentication code, and transmits it to the requesting user PC (S511). The requesting user PC displays the received authentication code screen (S512). The authentication code screen is the same as that described in FIG. 9. By the user performing an operation of requesting transmission of the link URL to the authentication code input screen with respect to the displayed authentication code screen, a SMS transmission request is made to the payment server 100 (S513).

[0048] When the payment server 100 receives the request in S513, it generates a link URL to the authentication code input screen, and transmits the link URL to the registered phone number of the user by SMS (S514). That is, here, the link URL to the authentication code input screen is received not by the user PC that is the request source in S513, but by the user terminal device 10 having the registered phone number of the user. When the user performs an operation of selecting the notified link URL, the user terminal device 10 requests the payment server 100 to transmit the 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] Subsequently, the user terminal device 10 displays the authentication code input screen received from the payment server 100 (S517) and accepts an input operation of the authentication code (S518). Here, the user visually confirms the authentication code displayed on the authentication code screen in S512 and inputs the authentication code into the authentication code input screen displayed in S517. The flow after S518 is the same as the flow in FIG. 8.

[0050] For example, in the case of FIG. 9, a third party who has illegally obtained the service ID and password of a legitimate user can succeed in password authentication (S402) by making a login request (S401) from their own user terminal device 10 (illegal terminal) using the service ID and password. However, in this case, since the device ID of the illegal terminal does not match the registered device ID, the device authentication (S404) fails, and an authentication code screen is displayed on the illegal terminal (S502). After that, a link URL to the authentication code input screen is sent by SMS from the payment server 100 (S504), but since this is notified to the user terminal device 10 having the registered phone number of the legitimate user, the third party cannot input the authentication code obtained in S502 into the authentication code input screen. Therefore, a third party who makes a login request using an illegal terminal cannot proceed to the steps after S503, and thus cannot succeed in login authentication.

[0051] Also, for example, in FIG. 10, when the user PC is assumed to be an unauthorized terminal, a third party using the user PC can illegally obtain the legitimate user's service ID and password, and can succeed in password authentication (S402) by making a login request (S401) from the user PC. However, in this case, since the device ID of the user PC does not match the registered device ID, the device authentication (S404) fails, and an authentication code screen is displayed on the user PC (S502). Then, a link URL from the settlement server 100 to the authentication code input screen is sent by SMS (S504), but since this is notified to the user terminal device 10 having the registered phone number of the legitimate user, the third party cannot input the authentication code obtained in S502 into the authentication code input screen. Therefore, in this case, the third party who made a login request using the user PC cannot proceed to the steps after S503, so the login authentication cannot be successful.

[0052] As described above, in the new SMS authentication, when the device authentication fails after password authentication, the 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. Thereby, even if the authentication code is illegally obtained by a third party, it is possible to prevent the authentication code from being input into the authentication code input screen, so that the possibility of unauthorized login can be reduced.

[0053] FIG. 11 is a diagram showing an example of an authentication code screen in the new SMS authentication. On the authentication code screen D1, an authentication code display section D11 and an input section D12 for receiving an operation of requesting the settlement server 100 to send a link URL to the authentication code input screen by SMS are arranged. The authentication code is provided with a valid time. The valid time may be displayed together with the authentication code in the display section D11.

[0054] Note that the authentication code illustrated in FIG. 11 is a combination of two alphabetic characters and four digits. Both the two alphabetic characters and the four digits may be randomly generated. In this case, the authentication code input screen may be configured to allow the user to enter the entire authentication code. Also, the authentication code input screen may be configured to allow the user to enter a part of the authentication code. For example, the authentication code input screen may be configured to pre-display the two alphabetic characters notified to the user and allow the user to enter the four digits. 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 digits after confirming that the input destination of the authentication code is correct.

[0055] As described above, the process of logging in to the electronic payment service using the new SMS authentication has been explained for the case of logging in via the payment app 20 and the case of logging in without using the payment app 20 (logging in from a web browser). However, the new SMS authentication may be applied to any login situation as long as it is a situation that requires login authentication to the electronic payment service. For example, the new SMS authentication may be applied to the authentication when the user logs in to the payment app 20. Also, for example, the new SMS authentication may be applied to the authentication of logging in to the electronic payment service required when making a payment using the electronic payment service.

[0056] Figs. 12 to 15 are diagrams showing examples of screen transitions during settlement including new SMS authentication. More specifically, both 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 the purchase screen D21 of the user PC, pass through the settlement screen of the user terminal device 10, and reach the settlement completion screen (payment completion screen) of the user PC. Also, both the screen transitions in the examples of Figs. 12 and 13 and the screen transitions in the examples of Figs. 14 and 15 show examples of screen transitions when, although successful in password authentication, authentication by the device fails and input of an authentication code is required. Figs. 12 and 13 show examples of screen transitions when using a QR code for displaying the login screen, and Figs. 14 and 15 show examples of screen transitions when not using a QR code for displaying the login screen. Here, the QR code used for displaying the login screen is an example of the "two-dimensional code displayed on the first application program".

[0057] First, the user operates the web browser of the user PC to access, for example, the online store of a franchise store and performs a product purchase operation on the online store, whereby the purchase screen D21 is displayed on the user PC. For example, the purchase screen D21 includes information such as the product amount and a QR code or link for displaying the login screen. Here, it is assumed that the user reads the QR code with the camera of the user terminal device 10A or 10B, and the login screen D22 is displayed on the user terminal device 10A or 10B. Also, here, the user terminal device 10A is a user terminal device 10 in which the settlement application 20 is not installed and which does not have a registered phone number. On the other hand, the user terminal device 10B is a user terminal device 10 in which the settlement application 20 is not installed and which has a registered phone number.

[0058] For example, the login screen D22 includes an input box for the user ID and an input box for the password. The user inputs the user ID and password and sends them to the payment server 100. As described above, here, after the password authentication is successful (with the correct user ID and password entered), the device authentication fails, so the login screen D22 transitions to the authentication code screen D23. As described above, the authentication code screen D23 includes the display of the authentication code and a link URL to the authentication code input screen. By performing an operation of selecting the link URL by the user, a message with the link URL is sent by SMS from the payment server 100 to the user terminal device 10B having the registered phone number. The user causes the SMS message D24 notified to the user terminal device 10B to be displayed and performs an operation of selecting the link URL described in the message, whereby the authentication code input screen D25 is displayed on the user terminal device 10B. By the user inputting the authentication code displayed on the authentication code screen D23 into the authentication code input screen D25 and sending it to the payment server 100, the authentication code input screen D25 transitions to the payment screen D26. By the user confirming the payment amount displayed on the payment screen D26 and inputting a payment execution operation, the payment process is executed on the payment server 100, and the payment completion notification is returned 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, causes the purchase screen D21 to transition to the payment completion screen D27.

[0059] Next, the screen transition examples in FIGS. 14 and 15 will be described. First, similar to the cases of FIGS. 12 and 13, the user operates the web browser on the user PC to display the purchase screen D21. Here, instead of reading the QR code, it is assumed that the user performs an operation of selecting the link for displaying the login screen shown on the purchase screen D21, and thereby the login screen D22 is displayed on the user PC. Similar to the cases of FIGS. 12 and 13, it is assumed that the correct user ID and password are input here. In this case, after the password authentication is successful, the device authentication fails, so the login screen D22 transitions to the authentication code screen D23.

[0060] Subsequently, when the user performs an operation of selecting the link URL to the authentication code input screen shown on the authentication code screen D23, a message containing the link URL is sent by SMS from the settlement server 100 to the user terminal device 10B having the registered phone number. The user displays the SMS message D24 notified to the user terminal device 10B and performs an operation of selecting the link URL described in the message, whereby the authentication code input screen D25 is displayed on the user terminal device 10B. When the user inputs the authentication code shown on the authentication code screen D23 into the authentication code input screen D25 and sends it to the settlement server 100, the authentication code input screen D25 transitions to the settlement screen D26. When the user confirms the settlement amount shown on the settlement screen D26 and inputs a settlement execution operation, the settlement process is executed by the settlement server 100, and the settlement completion notification is returned to the user PC. On the user PC, the web browser maintains a session with the settlement server 100, and upon receiving the above settlement completion notification, transitions the authentication code screen D23 to the settlement completion screen D27.

[0061] In FIGS. 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. On the purchase screen D21, the expiration time, the countdown of the expiration time, etc. may be displayed. Also, here, the case where the user inputs the issued authentication code into the authentication code input screen for authentication has been described. However, when the user possesses the user terminal device 10 on which the payment application 20 is installed, the user can also authenticate by inputting the authentication code into the payment application 20. That is, the payment application 20 has a function of displaying an authentication code input screen for logged-in users. In this case, the payment application 20 may be configured to send the input authentication code to the payment server 100 and, when the authentication is successful, display the payment screen D26.

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

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

[0064] According to the embodiment described above, the security of the authentication method for performing identity verification by issuing an authentication code and sending it back to the user can be improved.

[0065] <Modification Example> In the above embodiment, the case where the payment server 100 determines that the login authentication is successful when the authentication code matches after failing the device authentication in the new SMS authentication has been described. However, when the authentication code matches, the payment server 100 may be configured to further perform device authentication. For example, in addition to the authentication code matching, the payment server 100 may be configured to determine that the login authentication is successful when the device ID (an example of the third identification information) of the application program that sent the SMS transmission request (S503 in FIGS. 9 and 10) in the new SMS authentication matches the device ID (an example of the fourth identification information) of the application program (an example of the 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. However, the authentication device may be configured as a separate device that is separated from the function of the electronic payment service that the payment server 100 has. 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. Further, in this case, part or all of the information necessary for login authentication among the information stored in the storage unit 170 of the payment server 100 may be held in the storage unit of the authentication device.

[0067] As described above, the embodiments for implementing the present invention have been described using the embodiments. However, the present invention is not limited to such embodiments, and various modifications and substitutions can be made without departing from the gist of the present invention.

Explanation of Reference Numerals

[0068] 10 User terminal device 20 Payment application 50 First store terminal device 60 Store code image 70 Second store terminal device 72 Interface for franchisees 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 Franchise / store information

Claims

1. An authentication device that executes an authentication process for authenticating a user in response to an authentication request of a first application program operating on a user's terminal device, comprising an authentication unit that authenticates the user when first identification information, which is identification information of the first application program and is received from the first application program at the time of the authentication request, matches second identification information that is registered in advance in the authentication device for the user, wherein when 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 on which a first authentication code is displayed, and notifies access information to an authentication code input screen for receiving an input of the authentication code to a telephone number registered in advance in the authentication device for the user, acquires a second authentication code input on the authentication code input screen from the terminal device, and authenticates the user when the acquired second authentication code matches the first authentication code, Authentication device.

2. A settlement processing unit that executes a settlement process for providing an electronic payment service to the user in cooperation with the first application program, and causes the first application program to display a settlement screen that displays the details of the settlement using the electronic payment service and receives an execution instruction for the settlement, and a settlement completion screen for notifying the completion of the settlement, wherein the authentication request requests authentication for logging in to the electronic payment service, which may be requested when the user makes an electronic payment using the electronic payment service, and when the second authentication code matches the first authentication code, the authentication unit causes the settlement screen to be displayed on the terminal device having the telephone number, The authentication device according to claim 1.

3. The settlement processing unit completes the settlement in response to an input of the execution instruction for the settlement to the settlement screen, and causes the first application program to display the settlement completion screen related to the settlement, The authentication device according to claim 2.

4. The authentication request is performed via a two-dimensional code displayed on the first application program or a login screen specified by a link, The login screen is displayed on the device that has read the two-dimensional code or the first application program that has received the selection operation of the link. The authentication device according to claim 1.

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

6. The authentication unit receives a transmission request for the access information via the authentication code screen. In addition to the second authentication code matching the first authentication code, the third identification information received from the first application program at the time of the transmission request is the second application program that accessed the authentication code input screen related to the access information. The user is authenticated when it matches the fourth identification information obtained from the program. 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 of a first application program operating on a user's terminal device. An authentication method for authenticating a user when the first identification information, which is the identification information of the first application program and is received from the first application program at the time of the authentication request, matches the second identification information previously registered in the authentication device for the user. When the first identification information does not match the second identification information, a authentication code screen on which a first authentication code is displayed is displayed on the first application program, and access information to an authentication code input screen for receiving input of the authentication code is sent to the user. Notify the phone number registered in the authentication device in advance, obtain the second authentication code input on the authentication code input screen from the terminal device, and authenticate the user when the obtained second authentication code matches the first authentication code. Authentication method.

8. In an authentication device that executes an authentication process for authenticating a user in response to an authentication request of a first application program operating on a user's terminal device. A program for authenticating a user when first identification information received from a first application program at the time of the authentication request, which is identification information of the first application program, matches second identification information registered in advance in the authentication device for the user, when the first identification information does not match the second identification information, cause the authentication device to execute a process of causing the first application program to display an authentication code screen on which a first authentication code is displayed, notify access information to an authentication code input screen for accepting input of an authentication code to a telephone number registered in advance in the authentication device for the user, cause the terminal device to acquire a second authentication code input on the authentication code input screen, and authenticate the user when the acquired second authentication code matches the first authentication code. A program for this purpose.

Images