Server, server control method, program and image formation device

Abstract

To provide a scheme to log in an image formation device using authentication like FIDO.SOLUTION: A server that is communicable with an image formation device and with a terminal includes: receiving means for receiving, from the terminal, identification information on the image formation device; verifying means for receiving, from the terminal, signature data obtained by encrypting verification data for the image formation device to perform user authentication, and for verifying the signature data; and transmitting means for transmitting, to the image formation device identified by the identification information, an instruction to execute a login process for a user authenticated by a user authentication based on the success result of the verification. The login process for the user is executed at the image formation device based on the instruction.SELECTED DRAWING: Figure 11

Description

[Technical Field]

[0001] The present invention relates to a technique for authenticating a user who uses a device. [Background technology]

[0002] In recent years, technologies such as FIDO 2.0 defined by the FIDO (Fast Identity Online) Alliance have become well known as a means of authenticating users. This technology performs biometric authentication on a device held by the user, and then verifies data signed with a private key on the device on the authentication server side.

[0003] Patent Document 1 discloses a technique for transmitting a FIDO authentication result from a server to an image forming device in order to use a network service via the image forming device. [Prior art documents] [Patent documents]

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

[0005] However, in Patent Document 1, sending a login instruction from a server to an image forming apparatus is not taken into consideration, and it is not possible to log in to an image forming apparatus using authentication such as FIDO.

[0006] The present invention aims to provide a mechanism for logging in to an image forming apparatus using authentication such as FIDO. [Means for solving the problem]

[0007] In order to achieve the above object, the server of the present invention is a server capable of communicating with an image forming device and a terminal, and comprises: a receiving means for receiving identification information of the image forming device from the terminal; a verification means for receiving signature data obtained by encrypting verification data for user authentication of the image forming device from the terminal and verifying the signature data; and a transmitting means for transmitting, based on the success of the verification, an instruction to the image forming device identified by the identification information to execute login processing for a user authenticated by the user authentication, and the login processing for the user is executed in the image forming device in accordance with the instruction. [Effects of the Invention]

[0008] According to the present invention, it is possible to provide a mechanism for logging in to an image forming apparatus using authentication such as FIDO. [Brief explanation of the drawings]

[0009] [Figure 1] FIG. 1 is a diagram illustrating a system configuration. [Figure 2] FIG. 2 is a diagram illustrating a hardware configuration. [Figure 3] FIG. 2 is a diagram illustrating a software configuration. [Figure 4] 10 is a table showing account information. [Figure 5] 10 is a table showing MFP management information. [Figure 6] FIG. 10 is a diagram showing a user interface relating to login settings for an MFP. [Figure 7] FIG. 10 is a diagram showing a user interface relating to logging in to the MFP. [Figure 8] FIG. 2 is a diagram illustrating communication between an MFP and an MFP login server. [Figure 9] 10A and 10B are diagrams illustrating an operation screen and an operation flow of a mobile terminal. [Figure 10] FIG. 10 is a sequence diagram showing a processing flow relating to passkey registration. [Figure 11]FIG. 10 is a sequence diagram showing a processing flow relating to passkey authentication. [Figure 12] FIG. 10 is a diagram illustrating an operation screen of a mobile terminal according to the second embodiment. [Figure 13] FIG. 10 is a diagram showing a user interface relating to logging in to the MFP. [Figure 14] FIG. 10 is a sequence diagram showing a processing flow relating to passkey registration and passkey authentication. [Figure 15] FIG. 10 is a diagram showing a processing flow executed by the MFP. DETAILED DESCRIPTION OF THE INVENTION

[0010] Hereinafter, embodiments of the present invention will be described with reference to the drawings.

[0011] First Embodiment As an example of an image forming apparatus to which the present invention is applied, an embodiment of the present invention will be described taking an MFP (Multifunction Peripheral) having functions such as copying, printing, and scanning as an example.

[0012] In this embodiment, a digital signature verification technology similar to that used in FIDO (Fast Identity Online) is employed as an authentication mechanism for users to use functions and services provided by an image forming apparatus. Specifically, the technology described in this embodiment relates to a mechanism for authenticating a user by performing biometric authentication on a mobile terminal (information processing device) held by the user and verifying the resulting digital signature data with a service capable of communicating with the MFP. As will be described later, one of the features of this embodiment is that digital functions corresponding to FIDO services under FIDO technology are implemented in a service capable of communicating with the MFP. While FIDO is cited as an example of such a mechanism, it should be noted in advance that the present invention is not limited to the standards defined by the FIDO Alliance. Furthermore, authentication on a mobile terminal is not limited to biometric authentication. As will be described later, authentication using a personal identification number, for example, may also be used.

[0013] <System Configuration> Refer to FIG. 1 to describe the system configuration of this embodiment. The MFP 101 is an MFP to which the present invention is applied. The mobile terminal 102 is a user terminal owned by the user of the MFP, and is a mobile terminal such as a smartphone. The mobile terminal is a terminal equipped with iOS of Apple or a terminal equipped with Android (registered trademark) of Google.

[0014] The MFP login server 105 is a cloud service having a server function accessible from the Internet. Note that the MFP login server 105 may be configured as an on-premises server connected to a LAN instead of a cloud service. The function of the MFP login server 105 may be realized not by a single server but by a plurality of servers. The present invention is not limited to cloud services, but this embodiment will be described as a cloud service.

[0015] The MFP 101 and the mobile terminal can each communicate with the MFP login server 105 via an Internet line. The MFP 101 installed in the office may be connected to the MFP login server 105 via a LAN or a proxy server constructed in the office. Also, the MFP 101 may be directly connected to the Internet line and connected to the MFP login server 105. The mobile terminal 102 used in the office may be connected to the MFP login server 105 via the wireless LAN in the office. Also, the mobile terminal 102 may be directly connected to a mobile network such as 4G or 5G and connected to the MFP login server 105. Also, although not shown, it is assumed that there are a plurality of MFPs and user mobile terminals connected to the MFP login server 105.

[0016] <Hardware Configuration of MFP 101> 2(a) is a simplified diagram showing the hardware configuration of the MFP 101. The CPU 201 is a central processing unit (processor) that controls the overall operation of the MFP 101. The RAM (Random Access Memory) 203 is a volatile memory and a work area that is used as a temporary storage area for expanding various control programs stored in the ROM 202 and HDD 204.

[0017] The ROM 202 is a nonvolatile memory that stores the boot program of the MFP 101. The HDD 204 is a nonvolatile hard disk or flash storage with a larger capacity than the RAM 203. The HDD 204 stores a program for controlling the MFP. The OS (Operating System) and application programs are also stored in the HDD 204.

[0018] When the MFP 101 starts up, the CPU 201 executes a boot program stored in the ROM 202. This boot program reads out an OS (Operating System) program stored in the HDD 204 and loads it on the RAM 203. After executing the boot program, the CPU 201 subsequently executes the OS program loaded on the RAM 203 and controls the MFP 101. The CPU 201 also stores data used for operations by the control program on the RAM 203 and reads and writes the data.

[0019] In the MFP 101, one CPU 201 executes each process performed by the MFP 101 shown in the sequence diagrams described below, but other configurations are also possible. For example, multiple CPUs or microprocessors (MPUs) can cooperate to execute each process shown in the sequence diagrams described below. Some of the processes described below can also be executed using hardware circuits such as an ASIC (Application Specific Integrated Circuit) or an FPGA (Field-Programmable Gate Array).

[0020] The operation unit 205 is a touch-operable display (touch panel). The printer 206 is a printer engine that prints print data received from the outside via a communication unit 208 and digital data acquired from a scanner 207. The scanner 207 is a scanner device that reads paper documents and converts them into digital data. The communication unit 208 is a network interface for connecting to the Internet or an office LAN (Local Area Network).

[0021] <Hardware configuration of the mobile terminal 102> 2(b) is a simplified diagram showing the hardware configuration of the mobile terminal 102. The CPU 211 is a central processing unit (processor) that controls the overall operation of the mobile terminal 102. The RAM (Random Access Memory) 213 is a volatile memory and a work area that is used as a temporary storage area for expanding various control programs stored in the ROM 212 and flash storage 214.

[0022] The ROM 212 is a nonvolatile memory that stores a boot program for the mobile terminal 102. The flash storage 214 is a nonvolatile memory storage with a larger capacity than the RAM 213. The flash storage 214 stores a control program for the mobile terminal. The flash storage 214 also stores an OS (Operating System) and application programs.

[0023] The operation panel 215 is a touch-operable display (touch panel).

[0024] The camera 216 is a camera module that can be used to take photos and videos and capture QR codes (registered trademark). The in-camera 216 is a camera that can be used to take photos of the user of the mobile terminal and for face authentication. The fingerprint sensor 218 is a sensor that can be used for fingerprint authentication. The communication unit 219 is a network interface for wireless communication.

[0025] <Hardware Configuration of MFP Login Server 105> The MFP login server 105 can be configured as a virtual server built on a general cloud infrastructure. When building it as a physical server on a LAN, it can be composed of general-purpose computers such as personal computers. It is noted that the functions of the MFP login server 105 may be realized by a plurality of servers instead of a single server.

[0026] Figure 2(c) is a schematic diagram showing the hardware configuration of a general-purpose computer.

[0027] The CPU 221 executes programs stored in the ROM 222, and programs such as an OS (operation system) and applications loaded from the external storage 230 to the RAM 223. That is, by executing the programs stored in the readable storage medium, the CPU 221 functions as each processing unit that executes the processing of each sequence described later. The RAM 223 is the main memory of the CPU 221 and functions as a work area and the like. The keyboard controller 224 controls operation inputs from the keyboard 228 and a pointing device (such as a mouse, touch pad, touch panel, trackball, etc.) not shown. The display controller 225 controls the display of the display 229. The disk controller 226 controls data access to a storage 230 such as a hard disk (HDD) and flash memory that stores various data. The communication unit 227 is connected to a network and is a network interface that executes communication control processing with other devices connected to the network. When constructing a server as a virtual server, the keyboard 228 and the display 229 are not necessarily required for remote operations. Also, instead of the storage 230, a network-compatible storage that can communicate with the communication unit 227 may be used.

[0028] <Software Configuration> FIG. 3 is a simplified diagram showing the software configuration of the MFP 101, mobile terminal 102, and MFP login server 105. The MFP 101 has an operation unit login service 301 for logging in a user who uses the MFP 101. The operation unit login service 301 has a login processing unit 302 and a cloud communication unit 303. The login processing unit 302 displays a login screen on the operation unit 205 when a user is not logged in, thereby restricting use of the operation unit. The login processing unit 302 also has a function for logging in a user and transitioning from the login screen to a menu screen. The cloud communication unit 303 has a function for communicating with the MFP login server 105. The cloud communication unit 303 establishes a WebSocket connection with the MFP login server 105 to receive messages from the MFP login server 105. The present invention is not limited to the use of WebSocket, and other technologies may be used as long as they allow messages to be sent from the MFP login server 105 to the MFP. For example, other technologies such as MQTT (Message Queue Telemetry Transport), long polling, or WebPush may be used.

[0029] The operation unit UI service 304 of the MFP 101 provides a user interface for providing functions to a user who has logged in to the operation unit. The operation unit UI service 304 includes a menu from which the user selects functions, applications, a UI platform that controls screen transitions, and the like. For example, it includes a "copy" application that provides the user with a UI for the copy function, a "print" application that provides a UI for the print function, and a "scan and send" application that provides a UI for sending scanned documents to an external device.

[0030] The printer control unit 305 is a software module that controls the printer 206, and the scanner control unit 306 is a software module that controls the scanner 207. Each software module provides an API (Application Programming Interface) for applications to operate the printer 206 or scanner 207. Although not shown, the software configuration of the MFP 101 includes an operating system and driver software for controlling various hardware.

[0031] The OS 311 of the mobile terminal 102 is an operating system. It may be a terminal equipped with Apple's iOS or Google's Android (registered trademark). The authenticator 312 is software having a FIDO authenticator function defined by the FIDO Alliance. The function of the authenticator 312 may be incorporated into the operating system (OS 311) as one of its functions. The camera application 313 is an application that controls the camera 216 and the in-camera 217 to take photos and videos. It also has a function to capture and decode QR codes. The web browser 314 is software that operates as a client function for HTTP communication. The web browser 314 may be implemented using Apple's Safari, Google's Chrome, Microsoft's Edge, or the like.

[0032] The FIDO service 321 of the MFP login server 105 has a web server function capable of communicating via HTTP (Hypertext Transfer Protocol). It also has an authentication function of WebAuthn (Web Authentication) defined by the FIDO Alliance and the World Wide Web Consortium (W3C). It also has a function as an IdP (Identify Provider) that manages the accounts of users who use the operation unit of the MFP. As an IdP, the FIDO service 321 has a website and database for registering and managing user account information. It may also be configured to manage user accounts in cooperation with an IdP provided by a third-party vendor such as Microsoft or Google. The MFP management service 322 has a website and database for registering and managing MFPs that connect to the MFP login server 105.

[0033] The MFP login server 105 may have a function for managing the MFPs and user accounts of each office on a tenant basis based on a contract with the corporate office. In this case, the MFP login server 105 is configured so that only authorized users on a tenant basis can manage the MFPs and MFP user accounts on the website of the MFP login server 105.

[0034] Furthermore, MFPs installed in public spaces such as convenience stores and individual user accounts that use the MFPs may be managed. In this case, the MFP administrator registers MFP information in the MFP management service 322. Individual users register their own accounts in the FIDO service 321 based on a contract or the like. The MFPs and MFP functions that individual users can use may be determined based on the contract or the like.

[0035] <user account> FIG. 4 is a schematic diagram illustrating account information managed by the FIDO service 321. The account information 401 records a user ID, passkey information (credential ID, public key) used for FIDO authentication, a role, an email address, etc.

[0036] The "user ID" is an identifier for identifying a user. The "role" is information indicating the usage permission of the MFP. Examples of each role and usage permission are shown in the role information table 402. In addition to the definition of the default role, the user may be able to set detailed usage permissions and create a new role.

[0037] 403 is a table showing the association between a user and the MFPs available to the user.

[0038] <MFP Management Information> FIG. 5 is a schematic diagram illustrating MFP management information managed by the MFP management service 322. The "MFP-ID" is an identifier for uniquely identifying an MFP. That is, it is the identification information of the MFP. Anything is acceptable as long as it does not overlap with the IDs of other MFPs. For example, the manufacturing number of the MFP, a host name in the FQDN format, etc. can be used. Also, when communicating with the MFP using MQTT, the client ID used for MQTT communication may be used as the MFP-ID. Also, the MFP management service 322 may issue an MFP-ID at the time of MFP registration and register the MFP-ID in the MFP. The "online status" indicates the connection status with each MFP. For example, when a WebSocket connection is established between the MFP and the MFP login server 105, it is considered online, and when the connection is not established, it is considered offline.

[0039] The "operation panel status" indicates the usage status of the operation panel of the MFP. When no one is logged in, it is set to ready. When someone is logged in and using it, it is set to logged in.

[0040] <MFP Login Settings> Next, the cooperative operation between the MFP 101 and the MFP login server 105 will be described with reference to FIGS.

[0041] 6 and 7 are simplified diagrams showing examples of user interfaces displayed on the operation unit 205 of the MFP 101. FIG. 8 is a simplified diagram showing communication between the MFP 101 and the MFP login service 103.

[0042] Before login settings are made, a menu screen 601 is displayed on the operation unit 205.

[0043] When the menu screen 601 detects that a management setting button has been pressed, the operation unit 205 displays a management setting screen 602. Although not shown, when the management setting button is pressed, an authentication screen for entering a user name and password may be displayed to authenticate the administrator. The management setting screen 602 is a portal screen for management settings. The administrator of the MFP 101 can configure various settings related to the MFP 101, such as "network settings," "function settings," and "login settings." Pressing the "login settings" button on the management setting screen 602 displays a login setting screen 603. The login setting screen 603 is for enabling the login function of the MFP 101. For example, the administrator of the MFP 101 enters the "server address of the MFP login server" and "MFP-ID" on the login setting screen 603 to enable the function of linking with the MFP login server. Furthermore, the login setting screen 603 provides the following functions for handling a client certificate for verifying the identity of the MFP.

[0044] ·Generating a key pair Create a Certificate Signing Request for a client certificate (public key certificate). The client certificate includes the MFP-ID.

[0045] Import a client certificate issued by a CA (Certificate Authority) from an external memory media, etc.

[0046] <Connection between MFP and MFP Login Server> The MFP 101 with the function enabled to cooperate with the MFP Login Server attempts to connect to the MFP Login Server 105 using the WebSocket protocol.

[0047] Specifically, in S801 shown in FIG. 8, the cloud communication unit 303 of the MFP 101 transmits a WebSocket connection request to the MFP Login Server 105. At this time, a TLS handshake is performed and the MFP 101 transmits a client certificate and a digital signature to the MFP Login Server 105.

[0048] In S802, in order to prevent impersonation of the MFP, the MFP Login Server 105 verifies the received client certificate and digital signature and authenticates the MFP. Also, in order to confirm that it is the MFP managed by the MFP management information 403, it is confirmed that the MFP-ID obtained from the client certificate is registered in the MFP management information 501.

[0049] When the authentication of the device is successful, in S803, the MFP Login Server 105 returns a WebSocket connection response to the MFP 101. Thereafter, it becomes possible to transmit messages bidirectionally between the MFP 101 and the MFP Login Server 105 using the WebSocket connection. Detecting that the connection to the MFP has been established, the MFP Login Server 105 changes the "online status" in the MFP management information 501 from offline to online. When the authentication of the device fails, the MFP Login Server 105 can reject the WebSocket connection request from the MFP 101.

[0050] The MFP 101 that has received the WebSocket connection response displays the login screen shown in 701 of FIG. 7 on the operation unit 205 in S804 and restricts the use of the operation unit 205 so that the menu screen and various functions cannot be used without logging in.

[0051] <Login Instruction from MFP Login Server> The user's login is performed by the cooperation of the operation unit login service 301, the mobile terminal 102, and the MFP login server 105. The MFP login server 105 authenticates the user using a technology based on PKI (Public Key Infrastructure) defined by FIDO called a passkey. Details regarding the registration of the passkey and the authentication sequence using the passkey will be described later. In this embodiment, the authentication of the user by the MFP login server 105 using a technology based on PKI defined by FIDO is referred to as user authentication. That is, user authentication refers to authenticating the user using the result of verifying the signature data obtained by encrypting the challenge with the private key using the public key. In this embodiment, separately from this user authentication, authentication for authenticating the owner of the mobile terminal is performed on the mobile terminal. This is the authentication in S1019 and S1114 described later. Thus, in this embodiment, there are multiple types of authentication.

[0052] When the user authentication in the MFP login server 105 is successful, at S805, the MFP login server 105 transmits the user information of the account for logging in to the MFP to the MFP 101. The user information includes information such as the user ID, email address, role, and authority stored in the account information 401. These user information can be transmitted and received in a text format such as JSON.

[0053] At S806, the cloud communication unit 303 of the MFP 101 transmits the received user information to the login processing unit 302 to perform login processing.

[0054] After the login processing is completed, at S807, the cloud communication unit 303 of the MFP 101 notifies the MFP login server 105 of the login completion. The MFP login server 105 changes the operation unit status of the MFP management information 501 from "ready" to "logging in".

[0055] If the login is successful, the operation unit UI service 304, which has detected the user's login, displays a menu screen 702 on the operation unit 205. The operation unit UI service 304 then provides functions that require user authentication. Buttons for functions that the user does not have permission to use are grayed out to prevent them from being used.

[0056] An example of a function that requires user authentication is a printing function using predetermined print settings on the printer 206. When a user assigned the role of Administrator or GeneralUser is authenticated, printing with color print settings is possible. When a user assigned the role of LimitedUser is authenticated, printing with black and white print settings is permitted only. For example, when a user with the role of GeneralUser logs in, the "Administration Settings" button in menu 702 is grayed out. Furthermore, when a user without the authority to use the address book logs in, the address book reference button in Scan and Send 703 is grayed out.

[0057] Another function that requires user authentication is the function of transmitting image data obtained by scanning with the scanner 207 to an external device. This function is provided when a user assigned the role of Administrator or GeneralUser is authenticated.

[0058] Furthermore, a function that requires user authentication is the function of using an address book when specifying the destination of image data obtained by scanning with Scan 207. The address book is a list in which information about one or more destinations is registered. A user assigned the role of GeneralUser can select a destination from the address book and specify the destination of image data. A user assigned the role of Administrator can not only select a destination from the address book, but also register a new destination in the address book and edit the address book.

[0059] In addition, as a function premised on user authentication, there is a function for setting the MFP101. The settings of the MFP101 include, as displayed on the management setting screen 504, settings for the login method of the local UI, settings related to each user account, device settings, and network settings. When a user assigned the role of Administrator is authenticated, these setting functions are provided and the settings of the MFP101 can be made. The device settings include settings related to printing and scanning jobs, such as whether to display the history recorded during the execution of a job on the operation unit 205. Also, the network settings include settings such as whether to permit the use of each printing protocol during printing.

[0060] When the operation unit 205 detects a user logout operation, at S808, the login processing unit of the MFP101 performs a logout process and displays the login screen 701 again.

[0061] After the logout process, at S809, the cloud communication unit 303 of the MFP101 notifies the MFP login server 105 of the logout. The MFP login server 105 changes the operation unit status of the MFP management information 501 from "logged in" to "ready".

[0062] <FIDO service function> The FIDO service 321 has a web server function capable of communicating via HTTP (Hypertext Transfer Protocol). It also has an authentication function for WebAuthn defined by the FIDO Alliance and the W3C.

[0063] The FIDO service 321 is accessed via HTTPS communication from the web browser 314 of the mobile terminal 102 that has photographed the QR code displayed on the login screen 701 or the passkey registration screen 706. The FIDO service 321 provides access and functions to URLs 1 to 6, for example, as a web server.

[0064] <url1> https: / / mfplogin.service.com / registration URL1 returns an HTML screen for obtaining the user ID, an HTML screen for verifying the user's identity using a passcode, and an HTML screen for registering a passkey.

[0065] The HTML for passkey registration returned at URL1 includes JavaScript for accessing the REST (Representational State Transfer) API at the following URL2 and URL3. It also includes the following WebAuthn JavaScript specified in FIDO2.0.

[0066] <WebAuthnのJavaScript> outputJSONData = await navigator.credentials.create(inputJSONData); <url2> https: / / mfplogin.service.com / registration / challenge URL2 is the URL of the REST API that responds with input JSON data to be input to the above API "navigator.credentials.create()". The input JSON data includes challenge data issued by the FIDO service 321. The challenge is a random number, and is verification data used for verification when registering a passkey.

[0067] <url3> https: / / mfplogin.service.com / registration / verification URL3 is the URL of the REST API that receives information for registering a passkey. It receives the output JSON data output by the API "navigator.credentials.create()" above. The output JSON data includes the credential ID, challenge, public key, digital signature, etc. issued by the mobile terminal 102.

[0068] <url4> https: / / mfplogin.service.com / authentication?random=RandomNumber&MFP-ID=MFP101 URL4 is a URL that responds with HTML for passkey authentication. URL4 allows a random number or MFP-ID to be specified as a URL parameter. The random number is a character string such as "b15dee080a1a549be6e3c74e6b59f5c5", for example. The random number matches the character string embedded in the QR code on the login screen 701. The MFP-ID indicates the MFP to log in to if passkey authentication is successful.

[0069] The HTML for passkey authentication returned by URL4 includes JavaScript for accessing the REST APIs at URL5 and URL6. It also includes the following WebAuthn JavaScript specified in FIDO2.0.

[0070] <WebAuthnのJavaScript> outputJSONData = await navigator.credentials.get(inputJSONData); <url5> https: / / mfplogin.service.com / authentication / challenge URL5 is the URL of the REST API that responds with input JSON data to be input to the above "navigator.credentials.get()". The input JSON data includes a challenge issued by the FIDO service 321. The challenge is a random number, and is verification data used for verification of user authentication using a passkey.

[0071] <url6> https: / / mfplogin.service.com / authentication / verification URL6 is the URL of the REST API that receives information for passkey authentication. It receives the output JSON data output by the API "navigator.credentials.get()". The output JSON data includes the passkey credential ID used for the digital signature, the challenge, the digital signature, etc.

[0072] 15 is a flowchart showing the processing flow executed by CPU 201 of MFP 101 in the above-described cooperative operation between MFP 101 and MFP login server 105. The operation executed by CPU 201 of MFP 101 will be described with reference to FIG.

[0073] In step S1501, if the function for linking with the MFP login server is enabled, the CPU 201 transmits a WebSocket connection request to the MFP login server 105.

[0074] In step S1502, the CPU 201 receives a response to the WebSocket connection from the MFP login server 105 and establishes a WebSocket connection with the MFP login server 105.

[0075] In S1503, the CPU 201 displays the login screen 701 and waits for a login request transmitted from the MFP login server 105. That is, the CPU 201 performs display control to display a QR code for verification in the FIDO service 321.

[0076] In step S1504 , the CPU 201 receives the login request sent from the MFP login server 105 .

[0077] In S1505, the CPU 201 analyzes the received data.

[0078] In S1506, if the analysis of the received data is successful and necessary user information (such as user ID, email address, role, and authority) can be acquired, the CPU 201 determines that the analysis is successful. If the analysis of the received data fails and necessary user information cannot be acquired, the CPU 201 determines that the analysis is unsuccessful.

[0079] If the analysis is successful, in step S1507, the CPU 201 performs a login process to allow the user identified by the acquired user information to log in to the MFP.

[0080] In step S1508, the CPU 201 transitions the screen from the login screen to a menu screen, and ends the login process.

[0081] If the analysis fails in S1506, the CPU 201 displays a message on the UI in S1509 indicating that an error has occurred, and returns to S1503 to display the login screen again.

[0082] <Passkey registration sequence> The process flow for registering a passkey will be described with reference to FIGS.

[0083] Fig. 9 is a diagram showing an example of an operation screen and an operation flow of the mobile terminal 102. Fig. 10 is a sequence diagram showing a processing flow relating to passkey registration.

[0084] In this embodiment, the processes executed by the MFP 101 are recorded in software programs such as an operation unit login service 301 and a FIDO service 321. The software programs are stored in non-volatile storage such as the ROM 202 and the HDD 204, loaded into the RAM 203, and executed by the CPU 201.

[0085] The processes executed by the mobile terminal 301 are recorded in software programs such as a web browser 314 and an authenticator 312. The software programs are stored in non-volatile storage such as a ROM 212 or a flash storage 214, loaded into a RAM 213, and executed by a CPU 211.

[0086] The processes executed by the MFP login server 105 are recorded in software programs such as the FIDO service 321 and the MFP management service 322. The software programs are stored in non-volatile storage such as the ROM 222 and the storage 230, loaded into the RAM 223, and executed by the CPU 221.

[0087] In S1001, the operation unit login service 301 detects that the user has pressed the passkey registration button 705 on the login screen 701.

[0088] In S1002, the operation unit login service 301 displays the QR code on the passkey registration screen 706. The QR code has URL1 information embedded therein.

[0089] Next, in S1003 , the user starts the camera application 313 from the mobile terminal 102 that the user owns, and captures a picture of the QR code displayed on the operation unit 205 .

[0090] Next, in S1004, the camera application 313 reads URL1 from the QR code and starts the web browser 314.

[0091] In S1005, the web browser 314 accesses the address of URL1.

[0092] In S1006, the FIDO service 321 of the MFP login server 105 returns the HTML of the screen 901 for inputting the user ID. The header of the communication packet in S1006 includes a session ID to be saved in a cookie of the web browser 314. The session ID is used to confirm that subsequent communications are being performed in the same session. If subsequent communications are performed without the session ID in the cookie, an error response can be returned as unauthorized access that does not follow the required procedures.

[0093] In S1007, the web browser 314 displays the screen 901 to prompt the user to input a user ID. The user inputs the user ID and presses the "Next" button.

[0094] When the input of the user ID is detected, in S1008, the web browser 314 sends the user ID to the FIDO service 321.

[0095] In S1009, the FIDO service 321 checks whether the acquired user ID is registered in the account information 401. If it is registered, a passcode for identity verification is issued and sent to an email address stored in association with the acquired user ID. Instead of email, the phone number of the mobile terminal 102 may be registered in advance, and the passcode may be sent by short message. If the user ID is not registered in the account information 401, an error is returned (not shown). A message prompting the user to register a new account may also be returned.

[0096] After confirming the registration of the account information, the FIDO service 321 returns the HTML of the screen 902 for entering a passcode in S1010.

[0097] In S1011, the web browser 314 displays a screen 902 to prompt the user to enter a passcode. The user enters the passcode obtained from the email or short message and presses the "Next" button.

[0098] When the input of the passcode is detected, in S1012, the web browser 314 sends the passcode to the FIDO service 321.

[0099] In S1013, the FIDO service 321 verifies that the received passcode matches the passcode it issued. If the passcodes match, it can be determined that the owner of the mobile terminal 102 and the owner of the email address and phone number registered in the account information 401 are the same person, thereby preventing impersonation by a third party. If the passcodes do not match, an error is returned (not shown).

[0100] After confirming that the passcodes match, the FIDO service 321 responds in S1014 with the HTML of the screen 903 for registering a passkey. The HTML of the screen 903 includes JavaScript for accessing the REST (Representational State Transfer) API of URL2 or URL3. It also includes the following WebAuthn JavaScript defined in FIDO 2.0:

[0101] <WebAuthnのJavaScript> outputJSONData = await navigator.credentials.create(inputJSONData); Web browser 314 receives the HTML in S1014, and in S1015 executes JavaScript to access URL2. At this time, it is preferable to automatically execute JavaScript to access URL2 without the user operating the web browser. JavaScript can be executed automatically by utilizing the onload event of JavaScript, which is called when the HTML of HTML screen 903 has been fully loaded into web browser 314. Alternatively, a "Register Passkey" button (not shown) may be displayed on HTML screen 903, and JavaScript may be executed to access URL2 upon detecting that the user has pressed the "Register Passkey" button.

[0102] Upon receiving the access to URL2, the FIDO service 321 generates a challenge in S1016. The challenge is a random number.

[0103] In S1017, the input JSON data including the generated challenge is returned as a response. The input JSON data also includes information about the FIDO service 321 (for example, an address such as mfplogin.service.com), a user ID, and the like.

[0104] Next, in S1018, the web browser 314 executes the following JavaScript of WebAuthn using the received input JSON data and launches the authenticator 312.

[0105] <WebAuthnのJavaScript> outputJSONData = await navigator.credentials.create(inputJSONData); Next, in S1019, the authenticator 312 authenticates the owner of the mobile terminal 102 by any of the following means: authentication using biometric information such as face authentication or fingerprint authentication, authentication using a personal identification number, or pattern authentication.

[0106] Next, in S1020, the authenticator 312 generates a key pair (PKI private key and public key) called a passkey and a credential ID for identifying the passkey, and stores the generated passkey in a tamper-resistant storage area in association with information about the FIDO service 321 (e.g., mfplogin.service.com) and the user ID.

[0107] Next, in S1021, the authenticator 312 uses the generated private key to digitally sign the data, including the challenge data, received in S1017. The authenticator 312 returns output JSON data to the web browser. The output JSON data includes the generated public key, credential ID, digital signature, etc.

[0108] Next, in S1022, the web browser 314 accesses URL3 and sends output JSON data including the public key, credential ID, and digital signature to the FIDO service 321.

[0109] Next, in S1023, the FIDO service 321 verifies the received digital signature. Specifically, the FIDO service 321 verifies whether the digital signature is identical to the challenge issued by the FIDO service 321 by decrypting the digital signature using the received public key. If they are identical, the FIDO service 321 determines that the digital signature verification was successful, and if they are not identical, the FIDO service 321 determines that the verification was unsuccessful. If the digital signature verification was successful, in S1024, the FIDO service 321 associates the passkey information (public key and credential ID) with the user ID and stores them in the account information 401.

[0110] Next, in S1025, the FIDO service 321 responds to the web browser 314 with information such as whether the passkey registration was successful. If the passkey registration was successful, the FIDO service 321 responds with, for example, the HTML of screen 905.

[0111] In the above flow of passkey registration, an example was shown in which the mobile terminal 102 obtains URL1 by reading a QR code displayed on the operation unit 205 of the MFP 101, but other methods may be used to notify URL1. For example, URL1 may be notified from the MFP 101 to the mobile terminal 102 using short-range wireless communication such as Bluetooth or NFC. Alternatively, URL1 may be notified to each user by email from the MFP login server 105. The user does not need to be in front of the MFP when registering the passkey. Furthermore, if an error occurs in the sequence related to passkey authentication described below, it may be determined that the access is from a mobile terminal for which a passkey is not registered, and the user may be prompted to access URL1 to register the passkey.

[0112] <Passkey authentication sequence> The process flow for registering a passkey will be described with reference to Figures 7, 9, and 11. Figure 11 is a sequence diagram showing the process flow for passkey authentication.

[0113] In step S1101, if a user is not logged in, the operation unit login service 301 starts displaying the login screen 701. For example, when a logged-in user logs out, the login screen 701 is displayed. Also, when the MFP 101 is powered on, the login screen 701 is displayed as the initial screen.

[0114] In S1102, the operation unit login service 301 generates a random number. The random number is, for example, a character string such as "b15dee080a1a549be6e3c74e6b59f5c5".

[0115] Next, in S1103, the generated random number is sent to the FIDO service 321 of the MFP login server 105 and shared. The random number may be generated not by the operation unit login service 301 but by the FIDO service 321 or another module and shared with the operation unit login service 301. In addition to the random number, the FIDO service 321 may generate the QR code itself and share it with the operation unit login service 301.

[0116] Next, in step S1104, the operation unit login service 301 displays the QR code on the login screen 701. The QR code has embedded therein data for URL4, which includes the random number and the MFP-ID of the MFP 101 as URL parameters. The random number is information known only to the person who photographed the QR code, and is intended to confirm that the user accessing URL4 is in front of the operation unit.

[0117] Next, in step S1105 , the user starts the camera application 313 from the mobile terminal 102 that the user owns, and captures a picture of the QR code displayed on the operation unit 205 .

[0118] Next, in S1106, the camera application 313 reads the URL 4 from the QR code and starts the web browser 314.

[0119] Next, in S1107, the web browser 314 accesses the address of URL4.

[0120] In S1108, the FIDO service 321 of the MFP 101 verifies whether the random number included in the parameter of URL4 accessed in S1107 matches the random number acquired in S1103. If the random numbers do not match or are not included, an error such as HTTP 404 Not Found is returned to the web browser 314. If a match between the random numbers is confirmed, the MFP-ID included in the parameter of URL4 is associated with the session ID and temporarily stored in the RAM 223.

[0121] In S1109, the HTML of the HTML screen 910 for passkey authentication is responded. The HTML for passkey authentication includes JavaScript for accessing the REST (Representational State Transfer) API of URL5 or URL6. It also includes the following WebAuthn JavaScript specified in FIDO2.0.

[0122] <WebAuthnのJavaScript> outputJSONData = await navigator.credentials.get(inputJSONData); Additionally, the header of the communication packet in S1109 includes a session ID to be saved in the cookie of the web browser 314. The session ID is used to confirm that subsequent accesses are made in the same session. If URL5 or URL6 is accessed directly without a session ID in the cookie, it is determined to be unauthorized access that does not follow the required procedures, and the FIDO service 321 can return an error without processing the request.

[0123] Upon receiving the packet in S1109, the web browser 314 may automatically execute JavaScript in S1110 to access URL 5 without any user operation on the web browser. JavaScript can be executed automatically by utilizing the onload event of JavaScript, which is called when the HTML of HTML screen 910 has been completely loaded into the web browser 314.

[0124] Alternatively, a "passkey authentication" button (not shown) may be displayed on HTML screen 910, and upon detecting that the user has pressed the "passkey authentication" button, JavaScript may be executed to access URL 5.

[0125] Upon receiving the access to URL5, the FIDO service 321 generates a challenge in S1111. The challenge is a random number.

[0126] Next, in S1112, input JSON data including the generated challenge is returned as a response. The input JSON data also includes information about the FIDO service 321 (for example, an address such as mfplogin.service.com).

[0127] Next, in S1113, the web browser 314 uses the received input JSON data to execute the following JavaScript of WebAuthn and launch the authenticator 312. If the authenticator 312 manages multiple passkeys in association with information on the FIDO service 321, it may display a screen for selecting one passkey from the multiple passkeys.

[0128] <WebAuthnのJavaScript> outputJSONData = await navigator.credentials.create(inputJSONData); Next, in S1114, the authenticator 312 authenticates the owner of the mobile terminal 102 by any means such as face authentication, fingerprint authentication, personal identification number, or pattern authentication.

[0129] Next, in S1115, the authenticator 312 obtains the passkey (PKI private key) stored in association with information about the FIDO service 321 (for example, mfplogin.service.com). Then, the authenticator 312 generates a digital signature using the private key for the data including the challenge received in S1112. The authenticator 312 returns output JSON data to the web browser. The output JSON data includes the digital signature, the credential ID of the passkey used for the digital signature, and the like.

[0130] Next, in S1116, the web browser 314 accesses URL 6 and sends output JSON data including the public key, credential ID, and digital signature to the FIDO service 321.

[0131] Next, in S1117, the FIDO service 321 refers to the account information 401 to obtain the user ID and public key of the account associated with the received credential ID.

[0132] Next, in S1118, the received digital signature is verified. Specifically, the FIDO service 321 verifies whether the digital signature is the same as the challenge it issued by decrypting the digital signature using the public key. If they are the same and the digital signature verification is successful, it is determined that authentication is successful. If the verification is unsuccessful, it is determined that authentication is unsuccessful.

[0133] Next, in S1119, it is determined whether the user having the MFP-ID stored in association with the session ID is permitted to log in to MFP 101. Specifically, table 403 is referenced to determine whether the user having the user ID who was successfully authenticated in S1118 is permitted to use MFP 101. MFP management information 501 is also referenced to confirm whether MFP 101 is online and in a ready state. If the user having the user ID is permitted to use MFP 101 and MFP 101 is online and in a ready state, it is determined that login is permitted.

[0134] In S1120, the FIDO service 321 responds with HTML including a message indicating the authentication result of S1118 and the determination of whether login is permitted or not of S1119. For example, if it is determined that the authentication is successful and login is permitted, the HTML of screen 912 is responded. If the user with the user ID is not permitted to use the MFP 101, the HTML of screen 913 is responded.

[0135] If the authentication is successful and it is determined that login is permitted, in S1121 the MFP login server 105 transmits user information of the account used to log in to the MFP to the cloud communication unit 303 of the MFP 101. The user information includes information such as the user ID, email address, role, and authority stored in the user account information 401.

[0136] In step S1122, the cloud communication unit 303 of the MFP 101 transmits the received user information to the login processing unit 302 to perform login processing. The login processing unit 302 notifies the operation unit UI service 304 of a login occurrence event. The login event includes information about the user who is to log in.

[0137] When the login process is complete, in step S1123, the login screen 701 is closed and the operation unit UI service 304 displays the menu screen 702. The operation unit UI service 304 then provides functions according to the user's authority. For example, it grays out buttons for functions that the user does not have authority to use, making them unavailable.

[0138] If the verification is not successful in S1118 or if it is determined in S1119 that login is not possible, the MFP login server 105 notifies the cloud communication unit 303 of the MFP 101 of the failure. For example, the reasons for this include "user ID not registered," "passkey public key not registered in association with the user ID," "digital signature verification failed," and "no authority to log in to the MFP 101." The operation unit login service 301 may display a message indicating authentication failure, as shown on screen 704.

[0139] Furthermore, it is advisable to update the random number stored in the QR code on the login screen 701 to a new random number when a notification of authentication success or failure is received. Even if there is no notification of authentication success or failure, it is safer to update it periodically and shorten the lifetime of the random number.

[0140] In the above passkey authentication flow, an example has been shown in which the mobile terminal 102 acquires the URL 4 and the random number by reading the QR code displayed on the operation unit 205 of the MFP 101, but the means for notifying the URL 4 may be other methods. For example, the MFP 101 may notify the mobile terminal 102 of the URL 4 and the random number using short-range wireless communication such as Bluetooth or NFC.

[0141] <Effects> As described above, the present invention can provide a mechanism for authenticating a user using an external server equipped with signature verification technology and granting permission to use the operation unit of an image forming apparatus.

[0142] Users can log in to the operation unit using the biometric authentication function of their mobile device, so password-less login can be provided without the additional cost of an IC card reader or the like.

[0143] With conventional technology, encrypted passwords could be sent over the network, posing a risk of being leaked if the encryption is broken. This invention uses digital signature verification technology, which is also used in FIDO. Passwords are not sent over the network, and are therefore safe because they cannot be leaked by third parties due to eavesdropping.

[0144] An external server equipped with signature verification technology can collectively manage multiple users, public keys registered from each user's mobile terminal, and multiple MFPs.

[0145] A user can conveniently log in to multiple image forming apparatuses by registering a public key from a mobile terminal only once on an external server equipped with signature verification technology.

[0146] The administrator can manage users and image forming devices using an external server equipped with signature verification technology, which provides good manageability.

[0147] By using the present invention, there is no need for direct communication between a mobile terminal and an image forming device, and no pre-settings or infrastructure (LAN or direct communication) are required for direct communication between the mobile terminal and the image forming device. This reduces the hassle of pre-settings. The present invention can also be applied to image forming devices installed in places where an unspecified number of users use them, such as offices or convenience stores without a LAN.

[0148] Furthermore, by using the present invention, it is not necessary to install a FIDO client function or authenticator in the image forming device. Therefore, there is no need for development costs to implement the client function or authenticator in the image forming device. If a QR code is used as in this embodiment, there is no need for a short-range wireless device such as Bluetooth or NFC. By using the present invention, a secure login method can be provided even in a relatively inexpensive image forming device.

[0149] Mobile devices have the ability to photograph a QR code with the mobile camera, launch a standard browser, and access the URL embedded in the QR code. This means that there is no need to install a dedicated mobile app; users can use this function with just the standard camera and browser on their mobile device.

[0150] <Second embodiment> In the first embodiment, an example in which a standard camera and browser provided in a mobile terminal are used has been described.

[0151] In another embodiment, an application for the MFP may be used instead of using the standard web browser and camera application of the mobile terminal 102. Specifically, a vendor may provide an application for the MFP that can be installed on the mobile terminal 102, and this application may be used to log in to the MFP.

[0152] The advantage of using an MFP application is that it allows for faster access to the MFP login server 105 and authentication than launching a standard camera application and capturing a QR code. Also, since the MFP application has functions for generating a key pair and creating a digital signature, the present invention can be used even on a web browser or a mobile terminal that does not support WebAuthn or FIDO. Furthermore, the MFP application does not need to comply with the FIDO standard.

[0153] FIG. 12 shows an example of the operation screen of the mobile terminal 102 when the MFP application 901 is used.

[0154] When the MFP application is started, it communicates with the MFP login server 105, acquires information about the MFPs registered in the MFP login server 105, and displays a list of MFPs on the operation panel 215 of the mobile terminal as shown in 1201. The MFPs that the user normally uses may be pre-registered as favorite MFPs, and the favorite MFPs may be displayed preferentially.

[0155] When it is detected that the user has selected the MFP, a screen 1202 for entering a PIN code is displayed. The PIN code is displayed on the MFP login screen instead of a QR code. The user visually checks the PIN code displayed on the MFP login screen and enters it on screen 1202. The entered PIN code is sent to the MFP login server, which then checks that it matches the PIN code displayed on the MFP login screen. This makes it possible to confirm that the user is in front of the MFP.

[0156] Next, the MFP application uses an API provided by the mobile device's OS to activate the biometric authentication function and authenticate the user.

[0157] If biometric authentication is successful, the MFP application adds a digital signature to the challenge obtained from the MFP login server and sends it to the MFP login server. If biometric authentication fails, the MFP application does not send the digital signature. This mechanism ensures that biometric authentication has been performed on the mobile terminal beforehand when the MFP application sends the digital signature.

[0158] The MFP login server verifies the received digital signature and can confirm that the MFP application on the mobile terminal is a legitimate mobile terminal that possesses the private key that pairs with the pre-registered public key.

[0159] The PIN code confirmation function described above may be omitted. In this case, since it is not possible to confirm whether the user performing the mobile operation is in front of the MFP, the configuration allows the user to log in to the MFP's operation unit from a remote location. There is no benefit for a legitimate user to log in to the MFP's operation unit from a remote location, so there are no major security concerns. Considering cases where a user accidentally logs in to the MFP, it is recommended to configure the system so that the user can log out from the MFP's operation unit using an MFP application in the same way as logging in.

[0160] <Third embodiment> In the first embodiment, an example has been shown in which the user ID is not particularly handled on the login screen of the operation unit of the MFP, and the user who performs passkey registration and passkey authentication is identified through communication between the mobile terminal and the MFP login server.

[0161] In the third embodiment, referring to Figures 13 and 14, an example is shown in which communication between a mobile terminal and an MFP login server is started after a user who performs passkey registration or passkey authentication is identified on the login screen of the MFP's operation unit.

[0162] FIG. 13 is a diagram showing an example of a user interface displayed on the operation unit of the MFP in the third embodiment.

[0163] FIG. 14 is a sequence diagram showing the process flow of passkey registration and passkey authentication in the third embodiment.

[0164] Before displaying the login screen, the MFP 101 requests a list of users who can use the MFP 101 from the MFP login server 105 in step S1401.

[0165] In S1402, the MFP login server 105 refers to the user account information 401 and a table 403 that indicates the association of MFPs that can be used by the users, and responds with a list of users who can use the MFP 101. The user list should preferably include information on whether or not a passkey has been registered.

[0166] Next, in step S1403, the MFP 101 displays a login screen 1301. A list of users who can use the MFP 101 is displayed in the form of buttons on the login screen 1301. The buttons may display a "user ID," a "display name associated with the user ID," an "icon image associated with the user ID," or the like.

[0167] In S1404, pressing of a user button displayed on the login screen 1301 is detected, and the user ID associated with the user button is identified.

[0168] The MFP 101 determines whether the pressed button belongs to a user whose passkey has been registered.

[0169] If the button is for a user for whom a passkey has not been registered, in S1405, the passkey registration screen 1302 is displayed. The passkey registration screen 1302 displays a QR code that stores URL1 including the specified user ID in the URL parameter as follows:

[0170] https: / / mfplogin.service.com / registration?uid=Alice Next, in S1406 , the user starts the camera application 313 from the mobile terminal 102 that the user owns, and captures a picture of the QR code displayed on the operation unit 205 .

[0171] Next, in S1407, the camera application 313 reads URL1 from the QR code and starts the web browser 314.

[0172] In S1408, the web browser 314 accesses the address of URL 1. Unlike the first embodiment, the user ID read from the QR code is included in the URL parameters when URL 1 is accessed for the first time.

[0173] In S1409, the MFP login server transmits the passcode to the email address stored in association with the acquired user ID. Instead of an email, the phone number of the mobile terminal 102 may be registered in advance, and the passcode may be transmitted by short message.

[0174] In S1410, the FIDO service 321 returns the HTML of the screen 902 for entering a passcode along with the issued session ID.

[0175] The subsequent processing is the same as S1011 to S1025 described in the first embodiment.

[0176] If the pressed button is a button of a user for whom a passkey has been registered in S1404, the MFP 101 transmits the identified user ID to the MFP login server 105 in S1411.

[0177] In step S1412, the MFP login server 105 temporarily stores the received user ID in the RAM 223.

[0178] In step S1413, the MFP 101 displays the passkey authentication screen 1302 on the operation unit 205. The passkey authentication screen 1302 displays a QR code that stores URL4 including the specified user ID and MFP-ID in the URL parameters as follows:

[0179] https: / / mfplogin.service.com / authentication?uid=Alice&MFP-ID=MFP101 Next, in S1414 , the user starts the camera application 313 from the mobile terminal 102 that the user owns, and captures a picture of the QR code displayed on the operation unit 205 .

[0180] Next, in S1415, the camera application 313 reads the URL4 from the QR code and starts the web browser 314.

[0181] In S1416, the web browser 314 accesses the address of URL 4. Unlike the first embodiment, the user ID read from the QR code is included in the URL parameters when URL 4 is accessed for the first time.

[0182] In S1417, the FIDO service 321 of the MFP 101 verifies whether the user ID included in the parameter of URL 4 accessed in S1107 matches the user ID temporarily stored in S1412. If the user IDs do not match or if the user ID is not included, an error is returned to the web browser 314.

[0183] If a match between the user IDs is confirmed, the MFP-ID included in the parameters of URL4 is associated with the session ID and temporarily stored in RAM 223.

[0184] In S1418, the HTML of the HTML screen 910 for passkey authentication is responded. The HTML for passkey authentication includes JavaScript for accessing the REST (Representational State Transfer) API of URL5 or URL6. It also includes JavaScript for WebAuthn defined in FIDO2.0.

[0185] The header of the communication packet in S1418 also includes a session ID to be saved in a cookie of the web browser 314. The session ID is used to confirm that subsequent accesses are being made in the same session.

[0186] Upon receiving the packet in S1418, the web browser 314 executes JavaScript and accesses URL5 in S1419.

[0187] Upon receiving the access to URL 5, the FIDO service 321 generates a challenge in S1420. The challenge is a random number.

[0188] Next, in S1421, input JSON data including the generated challenge is returned as a response. The input JSON data also includes information about the FIDO service 321 (for example, an address such as mfplogin.service.com). Furthermore, the input JSON data also includes a credential ID associated with the user ID temporarily stored in S1412.

[0189] Next, in S1422, the web browser 314 executes the following JavaScript of WebAuthn using the received input JSON data and starts the authenticator 312. The authenticator 312 generates a digital signature using the private key corresponding to the credential ID included in the input JSON data. If there is no private key corresponding to the credential ID, an error is returned.

[0190] The subsequent processing is the same as S1114 to S1123 in the first embodiment, except that in S1412, control is exercised so that authentication other than that of the temporarily stored user ID is not accepted.

[0191] In the process of acquiring the public key in S1117, if the credential ID included in S1116 is not the credential ID corresponding to the temporarily stored user ID, the public key is not acquired and an error occurs. In other words, control is exercised so that authentication of users other than the user pressed in S1404 is not accepted.

[0192] When the cancel button is pressed on the passkey authentication screen 1303 or when a timeout occurs, the MFP 101 returns the screen on the operation unit to the login screen 1301 and notifies the MFP login server 301 of the cancellation.

[0193] With the above configuration, the user can be selected and a passkey can be registered on the operation unit of the MFP, so the user does not have to go through the trouble of inputting a user ID, which is convenient.

[0194] Furthermore, only users who have been enabled to select a user on the operation unit of the MFP can perform passkey authentication and log in to the operation unit of the MFP, which prevents unauthorized login requests to the operation unit of the MFP from remote locations, making it safe.

[0195] Furthermore, if used in conjunction with the MFP application on the mobile terminal shown in the second embodiment, capturing a QR code is not essential. After selecting a user by pressing the user button on the operation unit of the MFP, it is possible to select the MFP to log in to from the MFP application on the mobile terminal and start passkey authentication. If it is confirmed that the credential ID of the passkey of the user selected on the operation unit of the MFP matches the credential ID of the passkey used to generate the digital signature on the mobile terminal, the user may be permitted to log in to the operation unit of the MFP.

[0196] <Other embodiments> The MFP operation unit login service may be equipped with a WebView (a UI component with web browser functionality). Then, a login screen created in HTML obtained from the MFP login server through HTTPS communication may be displayed as the login screen of the MFP operation unit. In this case, the MFP login server provides HTML for screens equivalent to login screen 701, passkey registration screen 706, login screen 1301, passkey registration screen 1302, and passkey authentication screen 1303. This allows the MFP login server to detect the status of the operation unit of each MFP and user operations in real time.

[0197] The present invention can also be realized by supplying a program that realizes one or more functions of each of the above-described embodiments to a system or device via a network or a storage medium, and having one or more processors in the computer of the system or device read and execute the program. It can also be realized by a circuit (e.g., ASIC or FPGA) that realizes one or more functions. [Explanation of symbols]

[0198] 101 MFP 102 Mobile Devices 103 MFP login server 205 Operation section 301 Operation unit login service 321 FIDO Services 312 Authenticator 314 Web Browser 701 Login Screen

Claims

1. A server capable of communicating with an image forming apparatus and a terminal, a receiving unit for receiving identification information of the image forming apparatus from the terminal; a verification unit that receives, from the terminal, signature data obtained by encrypting verification data for user authentication of the image forming apparatus, and verifies the signature data; a transmitting means for transmitting, based on the success of the verification, to the image forming apparatus identified by the identification information, an instruction to execute a login process for the user authenticated by the user authentication; and In accordance with the instruction, the image forming apparatus executes a login process for the user. A server characterized by:

2. The image forming apparatus is an image forming apparatus including a printer, Once the login process is completed, printing with the printer using the specified print settings becomes possible. The server according to claim 1 .

3. The image forming apparatus is an image forming apparatus equipped with a scanner, When the login process is executed, it becomes possible to transmit image data obtained by scanning with the scanner to an external device. The server according to claim 1 .

4. a first management means for managing the user's identification information and the public key acquired from the terminal in association with each other; and The verification means verifies the signature data using the public key. The server according to claim 1 .

5. a second management means for managing the user's identification information and the identification information of the image forming device available to the user in association with each other; and The transmitting unit transmits the instruction to the image forming apparatus identified by the received identification information associated with the identification information of the user authenticated by the user authentication. The server according to claim 1 .

6. The signature data is obtained by encrypting the verification data using a private key based on authentication performed by a function for authenticating biometric information in the terminal. The server according to claim 1 .

7. A method for controlling a server capable of communicating with an image forming apparatus and a terminal, comprising: a receiving step of receiving identification information of the image forming apparatus from the terminal; a verification step of receiving signature data obtained by encrypting verification data for user authentication of the image forming apparatus from the terminal and verifying the signature data; a transmitting step of transmitting, based on the success of the verification, an instruction to the image forming apparatus identified by the identification information to execute a login process for the user authenticated by the user authentication; and In accordance with the instruction, the image forming apparatus executes a login process for the user. A control method comprising:

8. A server that can communicate with the image forming apparatus and the terminal, a receiving unit for receiving identification information of the image forming apparatus from the terminal; a verification unit that receives, from the terminal, signature data obtained by encrypting verification data for user authentication of the image forming apparatus, and verifies the signature data; a transmitting means for transmitting, based on the success of the verification, to the image forming apparatus identified by the identification information, an instruction to execute a login process for the user authenticated by the user authentication; A program for functioning as In accordance with the instruction, the image forming apparatus executes a login process for the user. A program characterized by:

9. An image forming apparatus, a display control means for displaying a code for verifying a user's login process in the image forming apparatus; a receiving means for receiving an instruction transmitted when the verification of the signature data based on the authentication at the terminal that reads the code is successful; an execution means for executing a login process for the user in accordance with the instruction; An image forming apparatus having the same.

Images