System and Method for Encryption Authentication

Abstract

A system and method for cryptographic authentication is provided. A transport service can establish a connection with a login device and a user is attempting to log in via a web browser. The login device can display a graphical code that encodes a unique URL provided by the transport service. The user can use an authenticator device to image the graphical code. A browser in the authenticator device is opened and the URL can be accessed. The transport service can utilize the authenticator device to perform proximity-based authentication.

Description

Technical Field

[0001] Cross - Reference to Related Applications

[0001] This application claims the priority and benefit of U.S. Provisional Patent Application No. 63 / 011,775, filed on April 17, 2020, the entire content of which is incorporated herein by reference.

Background Art

[0002] Background of the Invention

[0002] Authentication for accessing one or more online resources is important for preventing identity theft or other types of theft. Online service providers are beginning to add more security layers to examine an individual's identifier. In one example, FIDO ("Fast Identity Online") authentication can be used to authenticate an individual. Other types of proximity - based authentication can be used.

[0003]

[0003] However, certain devices may not be able to support FIDO authentication or other types of proximity - based authentication. In some examples, this type of authentication may require hardware that the device does not have. In other examples, the device may have software or other applications that can limit the use of certain components or hardware that may be required for such authentication. This can prevent a user from using a particular device to access online resources.

Summary of the Invention

Problems to be Solved by the Invention

[0004] Summary of the Invention

[0004] There is a need for an improved method for a system and method for cryptographic authentication. There is a further need for a system and method that allows a user to access online resources by means of a device, even if the device generally does not support the type of authentication (e.g., FIDO authentication, proximity - based authentication).

Means for Solving the Problem

[0005]

[0005] A system and method are provided that can enable the use of an authenticator device to perform authentication types not supported by a login device. For example, a user may desire to access online resources by a login device, but that login device may not support FIDO authentication. The user can use an authenticator device to scan a graphical code displayed on the login device. The graphical code can enable the user to open, on the authenticator device, a browser or application that can enable the authenticator device to perform authentication (e.g., FIDO authentication). The host of the resource can be provided with confirmation of the authentication, and the user may be permitted to access the resource on the login device.

[0006]

[0006] An aspect of the present invention is a method for providing authentication, which includes providing a unique URL (Uniform Resource Locator) to a login device, where the URL is configured to be encoded within a graphical code displayed on the login device, establishing a connection with an authenticator device, where the connection is provided when the authenticator device captures the graphical code displayed on the login device and accesses the URL encoded within the graphical code, and communicating with the authenticator device that performs proximity-based authentication.

[0007]

[0007] In one aspect, a method for providing authentication is provided. The method includes generating a unique URL, where the URL is encoded within a graphical code that is rendered on a login device for accessing resources provided by a service provider, establishing a network connection between the login device and the user device using the unique URL, where the network connection is established when the user device captures the graphical code displayed on the login device and accesses the URL encoded within the graphical code, and communicating with the user device to perform proximity-based authentication.

[0008]

[0008] In some embodiments, the graphical code is a QR code. In some embodiments, the unique URL is provided to the login device via a WebSocket connection. In some embodiments, the graphical code is provided to the login device via a WebSocket connection. In some embodiments, the graphical code is rendered within a native application on the login device. In some cases, the graphical code is generated by the native application.

[0009]

[0009] In some embodiments, the network connection between the login device and the user device is a WebSocket connection. In some embodiments, the proximity-based authentication includes FIDO (Fast IDentity Online) authentication. In some cases, the challenge and response for FIDO authentication are transmitted via the network connection. For example, the challenge and response are transmitted via the native browser of the user device.

[0010]

[0010] In some embodiments, the unique URL is within the network domain of the service provider. In some cases, the unique URL includes a domain name and a unique identifier.

[0011] [

[0011] ] Relatedly, in another aspect, a system for providing authentication is provided. The system is a transport service configured to generate a unique URL, the URL being encoded within a graphical code that is rendered on a login device for accessing resources provided by a service provider, the transport service, and a user device, (i) using the unique URL to establish a network connection with the login device, the network connection being established when the user device captures a graphical code displayed on the login device and accesses the URL encoded within the graphical code, (ii) performing proximity-based authentication, and configured to communicate with the login device via the network connection to transmit a response to the proximity-based authentication.

[0012] [

[0012] ] In some embodiments, the graphical code is a QR code. In some embodiments, the unique URL is provided to the login device via a WebSocket connection. In some embodiments, the graphical code is generated by the transport service and provided to the login device via a WebSocket connection. In some embodiments, the graphical code is rendered within a native application on the login device. In some cases, the graphical code is generated by the native application.

[0013] [

[0013] ] In some embodiments, the network connection between the login device and the user device is a WebSocket connection. In some embodiments, the proximity-based authentication includes FIDO authentication. In some cases, a challenge for FIDO authentication is transmitted via the network connection. For example, the challenge and response are communicated via the native browser of the user device. In some embodiments, the unique URL is within the network domain of the service provider. In some cases, the unique URL includes a domain name and a unique identifier.

[0014]

[0014] Further aspects and advantages of the present disclosure will become readily apparent to those skilled in the art from the following detailed description, which illustrates and describes only exemplary embodiments of the present disclosure. As will be understood, the present disclosure is capable of other and different embodiments, and some of the details thereof are capable of modification in various obvious respects without departing from the present disclosure. Accordingly, the drawings and description are to be regarded as illustrative in nature and not as restrictive.

[0015] Incorporation by reference

[0015] All publications, patents, and patent applications mentioned in this specification are hereby incorporated by reference into this specification to the same extent as if each individual publication, patent, or patent application was specifically and individually indicated to be incorporated by reference. To the extent that the incorporated publications and patents or patent applications conflict with the disclosure contained herein, this specification is intended to supersede and / or precede any such conflicting material.

[0016] Brief description of the drawings

[0016] The novel features of the present invention are set forth in detail in the appended claims. A more detailed understanding of the features and advantages of the present invention can be obtained by reference to the following detailed description of exemplary embodiments in which the principles of the present invention are utilized, and the accompanying drawings (also referred to herein as "drawings" and "figures").

Brief description of the drawings

[0017]

Figure 1

[0017] A diagram is shown of a user using an authenticator device to assist in logging into a login device according to an embodiment of the present invention.

Figure 2

[0018] An exemplary process for logging into a first device using a second device according to an embodiment of the present invention is shown.

Figure 3

[0019] An exemplary process for registering an account on a first device using a second device according to an embodiment of the present invention is shown.

Figure 4

[0020] A schematic diagram showing a second device capturing a graphical code during an authentication session, according to an embodiment of the present invention.

Figure 5A

[0021] An exemplary schematic diagram showing the use of a WebSocket useful for authentication, according to an embodiment of the present invention.

Figure 5B

[0022] Another exemplary schematic diagram showing the use of a WebSocket useful for authentication, according to an embodiment of the present invention.

Figure 6A

[0023] An exemplary method for authenticating a user for accessing a resource, according to an embodiment of the present invention, is shown.

Figure 6B

[0024] Another flowchart of an exemplary method for authenticating a user for accessing a resource, according to an embodiment of the present invention, is shown.

Figure 7

[0025] An exemplary network layout showing one or more authentication systems, according to an embodiment of the present invention, is shown.

Figure 8

[0026] An exemplary computer system according to an embodiment of the present invention is shown.

DETAILED DESCRIPTION OF THE INVENTION

[0018] Detailed Description

[0027] Various embodiments of the present invention are shown and described herein, but it will be apparent to those skilled in the art that such embodiments are merely illustrative. Without departing from the present invention, numerous modifications, variations, and substitutions can be envisioned by those skilled in the art. It should be understood that various alternative forms to the embodiments of the present invention described herein can be used.

[0019]

[0028] The present invention provides a system and method for encrypted authentication. Various aspects of the present invention described herein can be applied to any of the specific applications described below. The present invention can be applied as part of an online service or authentication system. It should be understood that the various aspects of the present invention can be recognized individually, collectively, or in combination with each other.

[0020]

[0029] A system and method for authentication are provided that may permit a user to access online resources on a login device that may not support the required authentication level. In some embodiments, proximity-based authentication such as FIDO authentication may be required for access to online resources, such as logging into an account or performing a specific action on an online site. In these scenarios, in conventional systems, a user may not be able to access an online system using a login device.

[0021]

[0030] In addition, conventional FIDO authentication protocols require relying parties (e.g., service providers, application servers) to use an API to interact with a user's authenticator. The relying parties are composed of a backend server and a frontend application. During authentication or registration, the application uses a client-side API to create and inspect user credentials with the authenticator. For example, this may include transmitting an encrypted challenge from the server to the authenticator and returning the authenticator's response to the server for verification. The backend server stores the user's public key credentials and account information. During authentication or registration, the server generates an encrypted challenge in response to a request from the application. The server then evaluates the response to the challenge. The FIDO authenticator generates user credentials. The user credentials have both a public key component and a private key component. The public key is shared with the application service, while the private key is kept secret by the authenticator.

[0022]

[0031] An authenticator can be part of the user's device or an external piece of hardware or software. In the conventional FIDO registration process, when a user signs up for an account on a website, the authenticator generates a new key pair that can only be used on that application service (i.e., the relying party's service). The public key and identifier for the credential information can be stored with the server. In the conventional FIDO authentication process, when a user returns to the service on a new device or after the user's session has expired, the authenticator can provide proof of the user's private key. The authenticator does this by responding to a cryptographic challenge issued by the server. To verify the user's identifier, some types of authenticators use biometrics such as fingerprints or facial recognition or a PIN. However, the pairing or binding process in the conventional FIDO protocol can be cumbersome. For example, the pairing or binding process can require USB, Near Field Communication (NFC), or Bluetooth (BLE) on the authenticator device. Furthermore, there is a lack of an omnichannel for supporting FIDO and a lack of current FIDO technology for network transport with sufficient phishing resistance.

[0023]

[0032] The systems and methods herein can provide a transport service that acts as a proxy between an authenticator device and a relying party application (e.g., a browser, an online resource), enabling a user to perform proximity-based authentication using the authenticator device, which enables the user to access an online resource on a login device upon confirmation of the authentication. The login device can display a graphical code such as a QR code. The QR code can have a unique URL encoded therein.

[0024]

[0033] The URL can be a unique URL of the relying party domain (e.g., network domain). For example, the relying party domain can be a resource at http: / / www.bank.com / login, and the unique URL can be hosted by www.bank.com / login, such as www.bank.com / login?cid=(uuid). The authenticator device can navigate to a secure login URL on the relying party domain to perform FIDO authentication. For example, FIDO authentication can be invoked on a relying party application (e.g., a web page at a unique URL within a browser, a browser running on a login device), and the challenge is transferred through an established channel to the authenticator device. The authenticator responds to the challenge, and the response is sent back to the relying party application. In this way, the FIDO response goes towards the relying party's domain. The inherited security of FIDO still exists, and although the key is unique, since the remote authentication occurs on the same domain of the relying party, the established channel effectively eliminates phishing. The URL can be generated by a transport service. The provided authentication method can be adapted to the existing FIDO architecture and existing network communication channels with improved security.

[0025]

[0034] The communication channel established between the authenticator device and the relying party application can be a two-way connection capable of transferring FIDO authentication challenges and responses. The two-way connection can use the WebSocket protocol. This protocol can enable a connection between a client and a server and continue to exist until terminated by either party (client or server). Different from HTTP which requires requests and responses for each connection, the connection established by WebSocket can enable interaction with less overhead than HTTP.

[0026]

[0035] The pairing process of the provided authentication method is simplified and improved with anti-phishing features. The authenticator device can capture an image of a QR code, and the browser on the authenticator device can be directed to an encoded URL. This can be beneficially avoided by installing an additional authentication application on the authenticator device. The authenticator device can communicate with a relying party application (e.g., the browser on the login device) through a two-way connection established by a transport service that enables the authenticator device to perform proximity-based verification (e.g., FIDO authentication). When authentication is confirmed, the user may be permitted to access online resources on the login device. This form still executes the complete required authentication level, thereby advantageously enabling the user to access resources on the login device without sacrificing security and without sacrificing the desired user interface.

[0027]

[0036] FIG. 1 shows a diagram of a user 160 using an authenticator device 120 to assist in logging in to a login device 110 according to an embodiment of the present invention.

[0028]

[0037] In some embodiments, user 160 may desire to access online resources. Resources can include services (e.g., online transactions, database access, file transfer, remote access), protected data, specific computing devices, file spaces, accounts, transactions, or computing functions. Any description of resources herein can apply to any type of resource or service, and vice versa.

[0029]

[0038] Resources can be provided by an online service provider. The online service provider can manage one or more servers to provide various services to users, such as enabling users to create an online account with the online service provider. The online service provider can be a service provider having an online portal or an online web page through which users can open an online account. The term "service provider" in this specification can be used synonymously with "online service provider". The service provider can also be referred to as a "relying party", which is an entity where user transactions are attempted (e.g., a website or an online service that executes user transactions). The service provider can provide any kind of resources. For example, the online service provider can be a financial institution (e.g., a bank), a retailer (e.g., an e-retailer, an auction site, etc.), a database, an educational institution, a communication service (e.g., email, messaging), a healthcare service, a wealth management service, a file sharing network, a cloud computing service, a social media service, a streaming service, or any other kind of service.

[0030]

[0039] A user may be able to create an online account to access online resources. The online account may be a separate account that can be created online by the user. The online account may be user-specific and / or may be owned by the user. The user's online account may be associated with user-specific information (e.g., name, address, email, etc.). Thus, the online service provider can identify the user by the user's online account with respect to the online service provider. By associating user credential information such as the user's username and accompanying password with the online account and requiring the provision of the user credential information when the user requests access to the online account, access to the online account can be protected. The online account can be stored within the memory storage area of a server.

[0031]

[0040] A user may be registered with an online service provider. The user may be registered when opening an online account with respect to the online service provider. For example, a user may be registered with the online service provider when creating an online account with respect to the online service provider.

[0032]

[0041] A user may wish to open an online account with an online service provider for any number of reasons, such as maintaining and tracking the relationship between the user and the online service provider (e.g., a financial institution, an educational institution, etc.), saving frequently used user information (e.g., shipping address) or the history of user activities (e.g., order invoices) with respect to the online service provider (e.g., an online retailer), avoiding having to provide redundant information to receive the same or similar services from the online service provider, conveniently managing the services provided to the user by the online service provider (e.g., insurance claims), participating in social networking services supported by the online service provider (e.g., Facebook (registered trademark), Instagram (registered trademark)), obtaining ownership of an online identifier (e.g., an email) provided by the online service provider (e.g., Gmail (registered trademark), Outlook (registered trademark)), etc.

[0033]

[0042] In some examples, a user may be able to provide highly personal and confidential services to an online service provider (e.g., providing a credit report, bank transaction statements), and vice versa, and thus having a secure authentication system can be a good strategy for both the user and the service provider. In some examples, using a traditional password may be insufficient to protect a user account. In some examples, a traditional password alone may not be able to secure the account from hackers. Additionally, the user may have difficulty remembering or tracking a traditional password.

[0034]

[0043] In some embodiments, online resources may use proximity-based authentication to provide users with access to resources. To log in, a user may be able to receive proximity-based authentication. Any description herein of proximity-based authentication may include any authentication that utilizes the physical proximity of the user or an object carried by the user (e.g., dongle, smart card, mobile device, any short-range wireless communication device, USB, etc.) to receive authentication. In some examples, proximity-based authentication may utilize the user's biometric information (e.g., fingerprint, palmprint, eye scan, face recognition, gesture recognition, gait recognition, voice recognition, verbal passphrase or password). In some embodiments, direct communication such as Bluetooth, wireless, optical connection, cable, or any other type of direct communication may be utilized for proximity-based authentication. In some examples, dedicated hardware such as a fingerprint scanner, iris scanner, camera, microphone, wireless antenna, Bluetooth antenna, USB port, etc. may be required to perform proximity-based authentication. Any description herein of proximity-based authentication may include FIDO (Fast Identity Online) authentication, and vice versa.

[0035]

[0044] User 160 may desire to access the online resources of an online service provider at login device 110. The login device can be any type of device (e.g., mobile device (smartphone, tablet, personal digital assistant), computer (e.g., desktop computer, laptop computer, server computer), smart device / IoT (Internet of Things) device, wearable device (e.g., glasses, wristwatch, armband, headset, etc.), kiosk, ATM (automated teller machine), or any other type of device). The login device may be able to access a network 140 such as a wide area network (WAN such as the Internet), local area network (LAN), telecommunications network (e.g., 3G, 4G, 5G, LTE, etc.), or any other type of network.

[0036]

[0045] A login device may be able to support a web browser, portal, or application that enables a user to access online resources. However, in some cases, the login device may not be able to support proximity-based authentication. For example, the login device may not have the hardware necessary to complete proximity-based authentication. For example, the login device may lack a device capable of collecting the required biometric information of the user. In another example, the login device may lack an antenna or other component capable of communicating with a device carried by the user. In a further example, the login device may lack software that can enable proximity-based authentication. In some cases, software or hardware that can prevent proximity-based authentication may be provided on the login device. For example, the login device may be Bluetooth-compatible, but security software that can prevent Bluetooth from being used in a specific way may be provided on the login device. For example, the login device may not be able to perform FIDO authentication or a specific type of FIDO authentication required by an online service provider to access online resources (e.g., log in). In one example, FIDO authentication such as FIDO2.0 may require at least one of protocols such as USB, near-field communication (NFC), Bluetooth (BLE), etc. on the login device.

[0037]

[0046] In such a situation, the user may still want to use the login device to access online resources. The systems and methods shown herein may enable a user to use the login device to access online resources even if the login device does not support the required authentication process. The provided method may also enable a FIDO challenge to be performed by a security-protected omninetwork channel (e.g., a native browser application) without requiring additional hardware or software applications.

[0038]

[0047] The user may have access to the authenticator device 120. The authenticator device may be capable of performing authentication at the required level. For example, the authenticator device may be capable of performing proximity-based authentication such as FIDO authentication. The authenticator device may have the necessary hardware and / or software for performing the required authentication. For example, during registration with an online service, the authenticator device can create a new key pair, keep the private key, and register the public key with the online service. During authentication, the authenticator device proves the possession of the private key to the service by signing a challenge, and such signature includes proximity-based authentication such as providing a fingerprint, entering a PIN, taking a selfie, speaking towards a microphone, and various other things as described above. The authenticator device may not have hardware or software that prevents the required authentication from being performed.

[0039]

[0048] For example, the authenticator device may have a biometric reader that can capture any necessary biometric information of the user. For example, the authenticator device may have a fingerprint scanner, a palm scanner, an eye scanner, one or more cameras, or one or more microphones that can be used to capture any desired biometric information. The authenticator device may have an antenna or any type of communication device that can enable communication with an object carried by the user, which may be necessary for authentication.

[0040]

[0049] If a user wishes to log in to a login device but the login device does not support the required authentication (e.g., proximity-based authentication), the login device can display a graphical code. Any description of the graphical code can apply to a QR code, bar code (e.g., 1D, 2D, or 3D bar code), series of symbols, icons, images, or any other arbitrary unique or encodable image, and vice versa. The graphical code can be displayed on a screen or other type of display. The graphical code can be displayed in any other application on the login device that can be used to access a web browser, web portal, or online resource.

[0041]

[0050] In some embodiments, if it is detected that the login device does not support the required authentication (e.g., proximity-based authentication), the graphical code can be automatically displayed on the login device. For example, an online web service or application can automatically detect that the login device does not have a particular type of hardware or that the required type of hardware is unavailable. Similarly, an online web service application can automatically detect that the login device does not have the particular software that enables the required authentication or that software has been provided that disables the ability to perform the required authentication. In such situations, the graphical code can automatically pop up on the display (e.g., without requiring a request by the user for the graphical code). In some examples, instructions can be provided along with the graphical code.

[0042]

[0051] In some situations, a user may make a request to display a graphical code. For example, the user may detect that the login device does not support the required authentication (e.g., proximity-based authentication) and may request a graphical code. In response to the user's request, the graphical code may be displayed. In some examples, even if the login device supports the required level of authentication, the user may be able to request a graphical code. In an alternative embodiment, if the login device supports the required authentication level, the graphical code may not need to be requested by the user.

[0043]

[0052] A graphical code may contain encoded information. The information encoded within the graphical code may be provided by a transport service. The transport service can communicate with and / or be part of an online service provider. The transport service may be hosted by an online service provider or a separate third party. The graphical code may be generated by the transport service or the online service provider. In one example, the transport service can generate the information encoded within the graphical code (e.g., a unique URL) and generate a graphical code with the encoded information. The transport service can transmit a QR code to a login device. In another example, the transport service can provide the information encoded within the graphical code and transmit that information to the online service provider. The online service provider can create and render a graphical code with the encoded information. The login device can display the graphical code created by the online service provider. For example, the transport service may include a software development kit (SDK) or library embedded within a native application (e.g., a native browser) of a login device (e.g., an ATM), a stand-alone application callable by other applications, and / or a service callable at the operating system level. The SDK or library may enable a native application (e.g., a browser) to generate and / or render a QR code encoded with a unique URL. In some cases, the SDK may be a downloadable data object distributed or provided by the transport service. The SDK can be incorporated or compiled within an application of a service provider such as a browser. The SDK may be a framework related to application source code development, a library downloaded and included within an application of the relying party, or incorporated in any suitable manner.It is used within a third - party application instance. In some cases, functions such as generating a unique URL for the relying party domain, generating a QR code encoding the URL, or rendering a QR code can be managed within the relying party's application.

[0044]

[0053] The information to be encoded can be a URL (Uniform Resource Locator). The URL can be a substantially unique URL of the relying party domain (i.e., the online service provider). The URL can be for a site hosted by a transport service and / or an online service provider. For example, the relying party domain can be a resource at http: / / www.bank.com / login, and the unique URL can be something like www.bank.com / login?cid=(uuid) and can be hosted by www.bank.com / login. In some examples, the transport service can be part of the online service provider or can be operated by the online service provider. Alternatively, the transport service can be separate from the online service provider and / or can be operated by a third party.

[0045]

[0054] An authenticator device can be used to capture an image of the graphical code. The authenticator device can have one or more cameras capable of capturing an image of the graphical code. The one or more cameras can be integrated into the authenticator device. Alternatively, the one or more cameras can be provided as an attachment or an add - on.

[0046]

[0055] The authenticator device may have software or an application that can recognize a graphical code. The authenticator device may be able to access the encoded information within the graphical code. In order to access the encoded information within the graphical code, the authenticator device may or may not use dedicated software or an application. The user may or may not need to open an application or software before capturing an image of the graphical code or before analyzing the image of the graphical code.

[0047]

[0056] The authenticator device can utilize the information encoded within the graphical code to perform the above authentication process. For example, the information encoded within the graphical code may enable the authenticator device to perform proximity-based authentication such as FIDO authentication with an online service provider.

[0048]

[0057] In one example, the information encoded within the graphical code may be a unique URL of an online service provider domain. The authenticator device can capture an image of the graphical code. The authenticator device may be able to extract or recognize the URL from the graphical code. The authenticator device can access the URL site through a native application such as a browser operating on the authenticator device or an operating system-level application. For example, the authenticator device can navigate to a secure login URL on the relying party domain to perform FIDO authentication. Such a login beneficially provides an omnichannel for FIDO challenges that conform to any FIDO authenticator selected by the user / provider.

[0049]

[0058] Via a URL, an authentication process can be performed using an authenticator device. For example, challenges and responses for a complete FIDO authentication can occur between the authenticator device and the like. FIDO authentication may include a registration process in which the authenticator device creates a new and unique public / private key pair used to authenticate access. The public key is then sent to the online service provider and associated with the user's account. The private key and all other confidential data related to the proximity-based authentication method (e.g., biometric prints) remain on the local device and never leave it. During the FIDO authentication challenge, the authenticator device is required to prove to the authentication-side service that it holds the private key by responding to the cryptographic challenge without problems. The private key can only be used after being successfully authenticated using the registered authenticator (e.g., by swiping a finger on a fingerprint sensor, entering a PIN, speaking towards a microphone, inserting a second-factor device, pressing a button, etc.). The authenticator device then uses the user account identifier provided by the service to select the correct key and cryptographically sign the service's challenge. The signed challenge is sent back to the online service provider, which checks it with the stored public key and logs the user in. The challenge and the signed challenge can be transmitted by a two-way connection established by the above unique URL.

[0050]

[0059] In some cases, FIDO authentication may require a second-factor device such as a dongle. The dongle 150 is for illustrative purposes only. Authentication may involve communication between the authenticator device 120 and a separate device 150. For example, the separate device can be a dongle, smart card, mobile device, or any other type of device as described elsewhere in this specification. The communication can be performed by a hardwired connection or wireless communication. The wireless communication can be direct wireless communication such as by Bluetooth, Wi-Fi, optical connection, or any other direct communication technique. The communication can be proximity-based such that the separate device needs to be within the proximity range of the authenticator device. Any other type of device can be used to assist proximity-based authentication, such as a device that can be integrated with the authenticator device. For example, a biometric reader can be integrated within the authenticator device or provided separately from the authenticator device but utilize proximity-based communication (e.g., hardwired or direct wireless communication).

[0051]

[0060] Then, the authentication can be verified. When the authentication process is complete, the online service provider can verify that the user is an authenticated individual. Optionally, the online service provider can also verify that the user is authorized to access the online resources. When it is verified that the user is authenticated and / or authorized, the user can be permitted to access the online resources by the login device.

[0052]

[0061] By establishing a network connection between an authenticator device and a native application running on a login device using a single URL, the provided method can advantageously permit a user to access online resources even when the login device does not support the authentication process required to access the online resources. This can enable the user to obtain the benefit of using the user interface of the login device while also allowing for robust authentication. For example, if the login device has a more user-friendly interface, the user may desire to access the online resources using the login device rather than the authenticator device. For example, the login device may have a larger screen, an easier-to-use keyboard, or other interactive devices (e.g., mouse, touchpad, scanner, trackball, touch screen, etc.), or may be located within a comfortable environment (e.g., seat, kiosk, pod, etc.).

[0053]

[0062] Figure 2 shows an exemplary process for logging in to a first device using a second device according to an embodiment of the present invention.

[0054]

[0063] The user may first attempt to access a resource on a site at the first device 210. The request to access the resource may include logging in to a site hosted by an online service provider. The request to log in may be a request to access resources available when the user logs in. In some examples, a request for a resource may be made even after the user has logged in. For example, when the user desires to perform a particular action, additional checks or authentication may be required.

[0055]

[0064] For example, a user may log in to a financial institution's website. The user may be able to perform certain activities on the site without the need for additional information. However, if the user wishes to engage in a large-scale financial transaction (e.g., a transaction exceeding a threshold amount), the user may require further authentication. Any description in this specification of logging in to or accessing a resource may include any type of activity by a user who may require further authentication, such as performing a large-scale transaction. In some examples, authentication may be required for various activities of a transaction or at various stages. Any description in this specification of using an authenticator device to assist with proximity-based authentication may refer to any step that may require further authentication, such as initially logging in to the site or something that may occur after the user has logged in to the site.

[0056]

[0065] In some cases, the user may attempt to access a resource by a native application such as the native browser of the login device. The login device may have a web browser that can serve as an online portal to resources provided by an online service provider. Any description in this specification regarding the browser may apply to an application that may be provided on the login device to access resources provided by an online service provider. The login device may or may not require any dedicated software or download to access resources provided by an online service provider (e.g., a website, portion, or step hosted by an online service provider).

[0057]

[0066] After a user requests access to a resource on a login device, a graphical code (e.g., a QR code) can be displayed on the login device 220. The graphical code can be displayed on a native application such as a web browser of the login device. Alternatively, the graphical code can be displayed on other applications of the login device. The graphical code can be displayed on the same application or software used to request the resource from an online service provider. For example, when a user uses a web browser to attempt to log in to a site hosted by an online service provider, the web browser can be used to display the graphical code.

[0058]

[0067] The graphical code can have embedded information. For example, a URL can be encoded within a QR code. As described above, the URL can be a unique URL of a relying party domain (e.g., an online service provider domain). The URL and the QR code can be generated by a transport service in response to a request from an online service provider. Alternatively, the QR code can be generated by an embedded SDK of a web browser for encoding a URL generated by a transport service.

[0059]

[0068] A second device can be used to image the graphical code 230. The second device can be separate from the first device. The second device can be operable independently of the first device. The second device can have a set of unique applications that can operate independently of the first device. The second device can be operable without being in proximity to the first device. In one example, the second device can be a mobile device such as a smartphone, a tablet, a laptop, or a personal digital assistant. The second device can be a wearable device such as any wearable device described elsewhere in this specification.

[0060]

[0069] In some embodiments, both the first device and the second device may be network - capable. The first device and the second device may be communicable with a wide - area network such as the Internet. The first device and / or the second device may be communicable with a telecommunications network as described elsewhere in this specification. The second device may optionally have hardware or software that enables proximity - based authentication such as FIDO authentication. The second device may be the same as the above - described authenticator device. The first device may not necessarily optionally have hardware or software that enables proximity - based authentication. In some examples, the second device does not have hardware or software that hinders proximity - based authentication. In some examples, the first device has hardware or software that hinders proximity - based authentication.

[0061]

[0070] In one example, the first device may be a kiosk, a desktop computer, a laptop computer, an automated teller machine (ATM), a vending machine, or any other device by which a user may desire to access online resources. Any description in this specification regarding the first device or the login device, without limitation, may apply to any of the described types of first devices including an ATM. The second device may be a smartphone, a tablet, a laptop, a personal digital assistant, a wearable device, or any other device that may be capable of proximity - based authentication. The second device may be smaller than, or not smaller than, or may be more or less mobile than the first device.

[0062]

[0071] The second device may be capable of decrypting information embedded within a graphical code. An image of the graphical code can be used to identify the embedded information (e.g., a URL). The second device may or may not use dedicated software or an application to identify the embedded information. In another example, identification can be performed locally using a processor mounted on the second device. Alternatively, the second device can communicate with a remote resource to identify information embedded within the graphical code.

[0063]

[0072] Identifying the embedded information can cause a browser (or other native application) that can facilitate proximity-based authentication (e.g., FIDO authentication) to be opened 240. For example, the information to be embedded can be a URL. The browser can be automatically opened within the second device and be directed to the URL encoded within the graphical code. The URL encoded within the graphical code can be hosted by a transport service and / or an online service provider. The transport service can be operated by an online service provider, and the URL can direct the user to a unique location (e.g., a unique URL of the online service provider domain) hosted or operated by the online service provider. In another example, the transport service can be operated by a third party separate from the online service provider, and the URL can direct the user to a unique location hosted or operated by a transport service separate from the online service provider.

[0064]

[0073] The URL encoded within the graphical code can be substantially unique. Any description herein of a unique URL can refer to any URL that is unique for the purpose that no other URL or any other graphical code that is substantially unique can currently embed the same URL. The unique URL can be generated using a random number generator or any other kind of algorithm or technique. The URL can be sufficiently unique so that no other user is presented with a QR code having that same URL while the code / URL is still valid. The unique URL is within the online service provider domain. For example, the URL can include a domain name and a unique identifier. For example, the relying party domain can be a resource at http: / / www.bank.com / login, and the unique URL can be hosted by www.bank.com / login, such as www.bank.com / login?cid=(uuid).

[0065]

[0074] In some examples, the code / URL may be valid within a predetermined time window or may expire after a predetermined time. In some examples, if a URL is used, that URL should not be reused again for an extended period (e.g., at least 1 hour, at least 1 day, at least 1 week, at least 1 month, etc.).

[0066]

[0075] The browser or application opened within the second device may prompt an authentication process. For example, instructions on how to proceed with authentication (e.g., respond to a FIDO challenge) can be presented to the user. If a device integrated with or connected to (or communicating with) the second device is required, such device may or may not be automatically initialized or prepared to perform its role in the authentication process.

[0067]

[0076] The user can then use the second device to undergo and complete an authentication process that uses proximity-based authentication (e.g., FIDO authentication). For example, the FIDO challenge and the signed challenge can be transmitted between the first device and the second device via a network connection between the browser application on the first device and the browser application on the second application. The signed response is sent back to the relying party application (e.g., the browser on the first device), thereby sending the FIDO response towards the relying party domain. Since the carried-over security of FIDO still exists and the keys are unique, and since FIDO authentication occurs on the same domain of the relying party, the established channel nullifies phishing. Optionally, instructions can be provided in a step-by-step manner that guides the user through the authentication process. The instructions can be displayed on the second device. The instructions can be displayed on a user interface such as the web browser of the second device. To complete the authentication process, the second device can communicate with a transport service and / or an online service provider.

[0068]

[0077] To enable a user to access resources on a first device, an online service provider can be given confirmation that authentication has been completed 260. In some cases, a transport service may assist in confirming that authentication has been completed and is being inspected. For example, the transport service may relay a challenge to the user and receive a response from a second device. The transport service can directly confirm whether it has access or whether the user is authenticated using the authentication process. Instead, the transport service may relay challenges and responses between the second device and the online service provider. In some examples, the online service provider may have information for completing the authentication process (e.g., public key, user account identifier, etc.). The transport service can simply relay information between the second device and the online service provider, and the online service provider can determine whether the user is authenticated.

[0069]

[0078] In some examples, when authentication is confirmed, a message or confirmation can be displayed on the second device. Instead, no message or confirmation is displayed on the second device. In some examples, the first device can display some form of confirmation of authentication and / or access to the requested resources (e.g., login, transaction, etc.) can be granted to the user.

[0070]

[0079] If a user undergoes an authentication process but is not authenticated (e.g., the fingerprints do not match, the dongle cannot be read, or an inappropriate match is suspected, etc.), the user can be prompted to retry. The user can be guided through the steps to attempt to log in again or can be given troubleshooting hints. In some examples, the user can be instructed to use a different device (e.g., a second device or a device different from the first device) to be authenticated. In some examples, if the number of attempts exceeds a predetermined threshold, the user can be locked out for a certain period. The number of attempts or the suggestions to the user can be determined by an online service provider and can optionally vary based on the service provider.

[0071]

[0080] FIG. 3 shows an exemplary process for registering an account in a first device using a second device according to an embodiment of the present invention.

[0072]

[0081] The user can first attempt to access 310 in the first device to register an account for an online service provider. The request to register can include creating a new account at a site hosted by the online service provider. The request to register an account can create a new account for the user to log in and enable access to the desired resources available when the user logs in. In some examples, even after the user creates an account, a request can be made for resources that may require registering an authentication device or collecting information about the user or the user device. For example, when the user desires to perform a specific action, additional confirmation or authentication may be required. Even if the user has already created an account, if the user has not yet performed the step of requesting additional inspection, that user can be required to register for the additional inspection.

[0073]

[0082] For example, a user may wish to create an account for a financial institution's website. To log in to the site, the user may need to undergo a proximity-based authentication process (e.g., FIDO authentication). As part of the registration process, the user may need to provide proximity-based information to enable subsequent proximity-based authentication. For example, if the user needs to provide biometric information to log in, the user may be required to provide a set of initial biometric information that can be used as a comparison point when the user logs in. For example, if authentication requires face recognition, the user may be required to take one or more photos of themselves to provide a baseline for subsequent authentication. In another example, if the user has a dongle or other short-range wireless communication device, the user may need to register or initially link the device to enable subsequent authentication. As described above, the authenticator device can create a new key pair during registration with an online service provider and keep the private key, while the public key is registered with the online service provider. In some cases, during registration, the online service provider can accept or select an authentication mechanism such as being locally available. For example, the user can register their mobile device and select its embedded fingerprint sensor as the local authentication means to use to authenticate themselves to the online service. Other authentication mechanisms can also be selected, including looking at the camera, speaking towards the microphone, or entering a PIN. Once registered and accepted by the online service, the user can authenticate to the online service using the registered local authentication action and respond to the FIDO challenge using the private key.

[0074]

[0083] In another example, a user may already have an account on a financial institution's website. The user may be able to perform certain activities on the site without the need for additional information. However, if the user wishes to engage in a large-scale financial transaction (e.g., a transaction exceeding a threshold amount), the user may require further authentication. Any description herein of logging in or accessing resources may include any type of activity by a user who may require further authentication, such as performing a large-scale transaction. In some examples, authentication may be required for various activities of a transaction or at various stages. If the user has not previously registered or provided the information necessary to receive proximity-based authentication, the user may be required to perform such registration or provide such information before performing activities that require additional information. Any description herein of using an authenticator device to assist in registering for proximity-based authentication may refer to any step that may occur after creating an account for the site or after the user logs in to a site that may require further authentication.

[0075]

[0084] Further, the user may attempt to register for an account and / or an authentication process via a browser on a first device. The first device may have a web browser that can serve as an online portal to resources provided by an online service provider. Any description herein of a browser may apply to an application that may be provided on a login device to access resources provided by an online service provider and / or to register an account with the online service provider. The first device may or may not require any dedicated software or download to access resources (e.g., a website, portion, or step hosted by an online service provider) provided by an online service provider and / or to register an account with the online service provider.

[0076]

[0085] After a user requests to open an account, a graphical code (e.g., a QR code) can be displayed on a first device 320. The graphical code can be displayed on a web browser of the first device. Alternatively, the graphical code can be displayed on another application of the first device. The graphical code can be displayed on the same application or software used to request resources from an online service provider. For example, when a user attempts to log in to a site hosted by an online service provider using a web browser, the web browser can be used to display the graphical code.

[0077]

[0086] The graphical code can have embedded information. For example, as described above, a URL can be encoded within a QR code.

[0078]

[0087] A second device can be used to image the graphical code 330. The second device can be separate from the first device. The second device can be operable independently of the first device. The second device can have a set of its own applications that can operate independently of the first device. The second device can be operable without the need to be in proximity to the first device. In one example, the second device can be a mobile device such as a smartphone, tablet, laptop, or personal digital assistant. The second device can be a wearable device such as any wearable device described elsewhere in this specification.

[0079]

[0088] In some embodiments, both the first device and the second device may be network-enabled. The first device and the second device may be communicable with a wide area network such as the Internet. The first device and / or the second device may be communicable with a telecommunications network as described elsewhere herein. The second device may optionally have hardware or software that enables proximity-based authentication such as FIDO authentication. The first device may not necessarily optionally have hardware or software that enables proximity-based authentication. In some examples, the second device does not have hardware or software that impedes proximity-based authentication. In some examples, the first device has hardware or software that impedes proximity-based authentication.

[0080]

[0089] In one example, the first device may be a kiosk, desktop computer, laptop computer, ATM, or other device by which a user may desire to access online resources. The second device may be a smartphone, tablet, laptop, personal digital assistant, wearable device, or other device by which proximity-based authentication may be possible. The second device may be smaller than, or not smaller than, or may be more or less mobile than the first device.

[0081]

[0090] The second device may be able to identify information embedded within a graphical code. An image of the graphical code can be used to identify the embedded information (e.g., URL). The second device may or may not use dedicated software or an application to identify the embedded information. In another example, identification can be performed locally using a processor mounted on the second device. Instead, the second device may be able to communicate with a remote resource to identify information embedded within the graphical code.

[0082]

[0091] Identifying the embedded information can cause a browser (or other application) that can facilitate registration for proximity-based authentication (e.g., FIDO authentication) to open 340. For example, the information to be embedded can be a URL. The browser can be automatically opened within the second device and be directed to a URL encoded within the graphical code. The URL encoded within the graphical code can be hosted by a transport service and / or an online service provider. The URL can have the same domain as the transport service and / or the online service provider. In some cases, the URL can be a unique URL of the relying party domain. For example, the relying party domain can be a resource at http: / / www.bank.com / login, and the unique URL can be hosted by www.bank.com / login, such as www.bank.com / login?cid=(uuid). The transport service can be operated by an online service provider, and the URL can direct the user to a unique location hosted or operated by the online service provider. In another example, the transport service can be operated by a third party separate from the online service provider, and the URL can direct the user to a unique location hosted or operated by a transport service separate from the online service provider.

[0083]

[0092] The URL encoded within the graphical code can be substantially unique. Any description in this specification regarding a unique URL can refer to any URL that is substantially unique or any other graphical code that is unique for the purpose of not being able to currently embed the same URL. A unique URL can be generated using a random number generator or any other type of algorithm or technique. The URL can be sufficiently unique such that while the code / URL remains valid, no other user is presented with a QR code having the same URL. In some examples, the code / URL can expire after a predetermined time. In some examples, once a URL has been used, that URL should not be reused for an extended period (e.g., at least 1 hour, at least 1 day, at least 1 week, at least 1 month, 1 year, etc.).

[0084]

[0093] The browser or application opened within the second device can prompt for a registration process. For example, instructions on how to proceed with the registration can be presented to the user. If a device integrated with or connected to (or communicating with) the second device is required, such a device may or may not be automatically initialized or prepared to perform its role in the registration process.

[0085]

[0094] The user can then use the second device to undergo and complete a registration process for proximity-based authentication (e.g., FIDO authentication). Optionally, instructions can be provided in a step-by-step manner that guides the user through the registration process. The instructions can be displayed on the second device. The instructions can be displayed on a user interface such as a web browser of the second device. To complete the registration process, the second device can communicate with a transport service and / or an online service provider.

[0086]

[0095] 360. The user can provide the online service provider with confirmation of successful registration in order to enable the user to complete the creation of an account for the site on the first device. In some examples, completing the registration may allow the user to complete the creation of the account and be permitted to log in to the account. In some embodiments, the transport service may confirm that the registration is complete. For example, the transport service may provide a challenge to the user and receive a response from the second device. The transport service can have access or directly confirm that the user has completed the registration and provide sufficient proximity-based information required for subsequent proximity-based authentication (e.g., FIDO authentication). Alternatively, the transport service may relay the communication between the second device and the online service provider. In some examples, the online service provider may have information to complete the registration process. The transport service can simply relay information between the second device and the online service provider, and the online service provider can determine whether the registration for proximity-based authentication is complete.

[0087]

[0096] In some examples, when the registration is confirmed, a message or confirmation can be displayed on the second device. Alternatively, no message or confirmation is displayed on the second device. In some examples, the first device can display some form of confirmation of the registration and / or an account can be granted to the user.

[0088]

[0097] The user undergoes a registration process, and if an error occurs (for example, the fingerprint is not clear, the dongle is not registered or is in an unexpected format, etc.), the user can be prompted to retry. The user can be guided through the steps to attempt registration again or can be given troubleshooting hints. In some examples, the user can be instructed to use a different device (e.g., a second device or a device different from the first device) to register. In some examples, if the number of attempts exceeds a predetermined threshold, the user can be locked out for a certain period. The number of attempts or the suggestions to the user can be determined by an online service provider and can optionally vary based on the service provider.

[0089]

[0098] Any description in this specification regarding the authentication process can apply to the registration process. For example, any description in this specification regarding how to perform the authentication process using a second device can also apply to a registration system that utilizes the second device for proximity-based authentication. Any details in this specification regarding how the authentication process can be performed can similarly apply to the registration process.

[0090]

[0099] FIG. 4 shows a schematic diagram of a second device 404 capturing a graphical code during an authentication session according to an embodiment of the present invention.

[0091]

[0100] The authentication session is hosted by a server on one or more interactive web pages and can be accessed by one or more users. A second device 404 (e.g., an authenticator device) can be used to scan a visual graphical code such as a QR code displayed on a first device 401 (e.g., a login device). The QR code or any other graphical code can be provided to the first device by a transport system 402.

[0092]

[0101] The second device 404 and the first device 401 can be separate devices. The second device and the first device can operate independently of each other. Alternatively, the second device 404 and the first device 401 can be the same device. In some examples, the first device and the second device can communicate with each other independently over a network. The first device or the second device may or may not be registered with the transport system. In some examples, the systems and methods provided herein may be functional without registering the first device and the second device. The first device and the second device can communicate with the transport system over a network.

[0093]

[0102] The second device 404 can be a mobile device (e.g., smartphone, tablet, pager, personal digital assistant (PDA)), a computer (e.g., laptop computer, desktop computer, server) or a wearable device (e.g., smartwatch) or any other device described elsewhere in this specification. The second device can also include any other media content player, such as a set-top box, a television receiver, a video game console or any electronic device capable of providing or rendering data. The second device can optionally be portable. The second device can be handheld. The second device can be a network device connectable to a network such as a local area network (LAN), a wide area network (WAN) such as the Internet, a telecommunications network, a data network or any other type of network.

[0094]

[0103] The second device 404 may include a memory storage unit that may include a non-transitory computer-readable medium containing code, logic, or instructions for performing one or more steps. The second device may also locally store the public / private key and / or other authentication information (e.g., biometric data) generated during registration. The user device may include, for example, one or more processors capable of performing one or more steps by means of a non-transitory computer-readable medium. The second device may include a display presenting a graphical user interface. The second device may be capable of receiving input by means of a user interaction device. Examples of such user interaction devices may include a keyboard, buttons, a mouse, a touch screen, a touch pad, a joystick, a trackball, a camera, a microphone, a motion sensor, a thermal sensor, an inertial sensor, or any other kind of user interaction device. The second device may be capable of executing software or an application provided by one or more authentication systems. The one or more applications may or may not be related to reading code such as graphical code.

[0095]

[0104] In some examples, the software and / or application may enable a user to scan a graphical authentication mark, such as a QR code, that is displayed on another device or the same device during an authentication session and transmit authentication data between the second device 404 and the transport system 402. The software and / or application may be registered with the transport system by the user. Optionally, the software and / or application may not be registered with the transport system, and only the authenticator device or the login device may be registered with the transport system. Optionally, both the software and the authenticator device or the login device may be registered with the transport system. Optionally, the software and / or application may be configured to collect authentication data (e.g., image capture characteristics, capture time, etc.), encrypt the data, and then transmit the data to the transport server during the authentication session. As described above, in some examples, a device or software application may not be required to be pre-registered with the transport service.

[0096]

[0105] The second device 404 can be, for example, one or more computing devices configured to perform one or more operations consistent with the disclosed embodiments. For example, the second device can be useful for proximity-based authentication and / or registration. The second device can optically detect one or more visual elements such as visual codes. The user device can utilize an optical detection device. The optical detection device can optically read or scan the visual element. In some embodiments, the user device can include an imaging device 403 configured to capture visual graphical elements such as QR codes, text, photos, sequences thereof, or other arbitrary forms of graphical authentication marks displayed on the first device 401. The imaging device can include hardware and / or software elements. In some embodiments, the imaging device can be a hardware camera sensor operably coupled to the user device. For example, the camera sensor can be embedded in the second device. Alternatively, the imaging device can be located outside the second device to be connected by cable or wirelessly, and the image data of the graphical element can be transmitted to the second device by the communication means described elsewhere in this specification. The imaging device can be controlled by an application and / or software configured to scan the visual graphical code. For example, the camera can be configured to scan a QR code. Optionally, the software and / or application can be configured to activate the camera on the second device to scan the code. In some examples, the camera can be controlled by a processor natively embedded within the second device. Optionally, when the first device 401 and the second device 404 are the same device, the imaging device can include screen capture software (e.g., screenshot) configured to capture and / or scan the QR code on the screen of the second device 104.

[0097]

[0106] The first device 401 may be configured to display a visual graphical code (e.g., a QR code) to a user. In some embodiments, the QR code may be displayed by an interface such as a web page, an application, a program, or any suitable software. The first device 401 may be a monitor, a computer (e.g., a laptop computer, a desktop computer), a mobile device (e.g., a smartphone, a tablet, a pager, a personal digital assistant (PDA)), a kiosk, an ATM, a smart device, or a vending machine. In some examples, the first device may include one or more processors that are natively embedded within the first device. The first device may optionally be portable. The first device may be handheld.

[0098]

[0107] In some examples, the visual graphical code that is displayed on the display device 101 and subsequently scanned by the imaging device 103 can be a QR code. A QR code is a two-dimensional barcode that encodes data by using dark and light modules arranged in a square or rectangular shape. A QR code can be optically captured and read by a machine. The barcode can define elements such as the barcode version, format, position, alignment, and timing to enable barcode reading and decoding. The remaining part of the barcode can encode various types of information in any suitable format such as binary information or alphanumeric information. As long as the imaging device can scan the QR code from a proper distance, the QR code can have various symbol sizes. The QR code can be in any image file format (e.g., EPS or SVG vector graph, PNG, TIF, GIF, or JPEG raster graphics format). The QR code can be based on any of several standards. In some examples, the QR code can comply with a known standard that can be read by a standard QR reader. The information encoded by the QR code can be composed of data of four standardized types ("modes") (numeric, alphanumeric, byte / binary, kanji) or by supported extensions, substantially all types of data. In some examples, the QR code may be under exclusive rights, and thus can only be read by an authenticated application provided by an authentication system running on a user device. In some examples, only the authentication system or the authenticated application can encrypt or decrypt the QR code.

[0099]

[0108] Information may be embedded in a QR code. In some examples, dedicated software or an application may be required to access the embedded information. Alternatively, dedicated software or an application may not be required to access the embedded information. A second device may be able to access and interpret the embedded information. The second device may be able to access and interpret the information without requiring network connectivity. The second device may be able to access and interpret the information locally. Alternatively, the second device may be able to utilize one or more remote resources to access and interpret the embedded information. The second device may require network connectivity to access and be able to interpret the encoded information.

[0100]

[0109] The information embedded in the QR code may include a URL. The URL may be hosted by a transport service. The transport service may utilize a website by an online service provider for the URL or a website by a third party for the URL. The URL may be substantially unique. To ensure being substantially unique, the URL may be created using a random number generator or any other kind of algorithm.

[0101]

[0110] The URL may be encoded within the QR code using any technique known or developed later.

[0102]

[0111] Scanning the QR code may cause the second device to be automatically directed to the site defined by the URL. The second device may automatically open the local browser of the second device and be directed to the URL. Alternatively, the second device may automatically open an application on the second device and be directed to the URL. The user may or may not be prompted to continue to access the URL.

[0103]

[0112] FIG. 5A shows an exemplary schematic diagram illustrating the use of a WebSocket useful for authentication, according to an embodiment of the present invention.

[0104]

[0113] The web browser 510 can operate on the login device. The web browser can operate on a network-enabled device. The web browser can establish a WebSocket connection with the authenticator 520 via the transport service 530. Any description herein of a WebSocket connection can apply to any type of two-way communication channel. In some embodiments, the connection can provide a full-duplex communication channel. Such a communication channel can be provided over a single TCP (Transmission Control Protocol) connection. In some embodiments, this connection can be HTTP-compliant or can utilize an HTTP-compliant initial handshake. This connection can enable interaction between the web browser and one or more servers of the transport service with low overhead. A WebSocket is a stateful protocol meaning that the connection between the client and the server persists until terminated by either party (client or server). Unlike HTTP which requires a request and a response for each connection, the connection established by a WebSocket can enable interaction with less overhead than HTTP. This beneficially enables fast communication for challenges and responses during FIDO authentication. Any description herein of a WebSocket connection can apply to a connection having any of these characteristics. Any description herein of a WebSocket can apply to any communication that enables two-way communication between the web browser and the transport service.

[0105]

[0114] A WebSocket connection between a web browser and a transport service may enable the web browser to request a unique URL. In some embodiments, when a user attempts to log in to or access any other type of resource, the web browser can automatically generate a request for a URL. In some embodiments, when it is detected that a login device is unable to perform the required authentication (e.g., proximity-based authentication such as FIDO authentication), the web browser can automatically generate a request for a URL. Optionally, the web browser can generate a request for a URL in response to a user input requesting a URL.

[0106]

[0115] The transport service can generate a unique URL. The unique URL can be substantially unique and can be hosted by the transport service. The transport service can be operated by an online service provider. For example, if a user is attempting to access a resource at http: / / www.bank.com, the transport service can optionally provide a URL hosted by www.bank.com / . In other embodiments, the transport service can be owned and operated independently of an online service provider. For example, if a user is attempting to access a resource at http: / / www.bank.com, the transport service can optionally provide a URL hosted by www.transportservice.com / .

[0107]

[0116] A URL may include the domain name and unique identifier of the relying party. The transport service can generate the unique identifier within the URL in a randomized manner. The transport service can generate the URL using one or more algorithms. The URL can be a series of random or pseudo-random character strings. The URL can be at least 10, 15, 20, 30, 40, or 50 characters in length. After generating the random URL, the transport service can perform a check to ensure that the same URL is not currently active or has not been generated or activated within a predetermined period in the past (e.g., within the past 1 hour, 1 day, 1 week, 1 month, 1 year, etc.).

[0108]

[0117] When the URL is generated by the transport service, the URL can be sent to a web browser. The web browser can generate a graphical code such as a QR code that encodes the URL. In other examples, the transport service can generate a QR code in which the URL is encoded. The QR code can be sent to the web browser. The QR code can be displayed on the web browser.

[0109]

[0118] The authenticator 520 can scan the QR code. The authenticator can be any device as described elsewhere in this specification. The authenticator can have an imaging device that can capture an image of the QR code. The authenticator can be able to access the encoded URL from the QR code. The authenticator may or may not use dedicated software or an application to access the URL from the QR code. The authenticator can utilize a network connection to communicate with a remote device that can access the URL from the QR code.

[0110]

[0119] Accessing the URL can cause a new browser to open within the authenticator. The browser installed in the authenticator may operate separately or independently from the web browser in the login device. Any description in this specification regarding the browser on the authenticator may apply to the applications that can be opened on the authenticator. The new browser can automatically open the URL. In some embodiments, the new browser can be automatically opened and directed to the URL without requiring user input when capturing an image of the QR code. Alternatively, the user may be prompted to take one or more actions or to approve opening the URL.

[0111]

[0120] A WebSocket connection can be established between the authenticator 520 and the transport service 530. The WebSocket connection can be established using a unique URL such that the transport service 530 functions as a proxy for establishing the WebSocket between the web browser 510 and the authenticator 520. As described above, any description in this specification regarding the WebSocket connection may apply to any type of bidirectional communication channel. In some embodiments, the connection can provide a full-duplex communication channel. Such a communication channel can be provided over a single TCP (Transmission Control Protocol) connection. In some embodiments, this connection can be HTTP compliant or can utilize an HTTP-compliant initial handshake. This connection can enable interaction between the browser of the authenticator and one or more servers of the transport service with low overhead. In some embodiments, this connection can enable interaction with less overhead than HTTP. Any description in this specification regarding the WebSocket connection may apply to a connection having any of these characteristics. Any description in this specification regarding the WebSocket may apply to any communication that enables bidirectional communication between the browser of the authenticator and the transport service.

[0112]

[0121] A connection of the same type as the web browser 510 and the transport service 530 can be established between the authenticator 520 and the transport service 530. In some embodiments, with respect to the systems and methods provided herein, any type of two-way communication between the transport service and both the web browser and the authenticator may be sufficient. In some embodiments, the systems and methods provided herein may be operable as long as the web browser and the authenticator have some type of network connectivity (e.g., the Internet, a telecommunications network, a data network, etc.).

[0113]

[0122] The URL can be used to create a web socket connection between the authenticator and the transport service. Thereafter, the user may be able to perform the required complete authentication process on the authenticator. The challenges and responses required to perform the required complete authentication can be transferred between the transport service and the authenticator. The required authentication can be proximity-based authentication such as FIDO authentication. Any of the authentication techniques described elsewhere in this specification can be performed using the authenticator.

[0114]

[0123] Once the authentication is confirmed, the user may be able to access the requested resource (e.g., log in to a website) in the original web browser 510. The transport service can communicate the confirmation of the authentication to the online service provider, and the online service provider may grant access to the resource. Thereafter, the user can interact with the original web browser on the login device in a standard operation.

[0115]

[0124] The systems and methods provided herein may advantageously enable a web browser on a device that may not support a required authentication (e.g., proximity-based authentication) to interact with a user. The user may use an authenticator device to perform the authentication and, if the authentication is confirmed, be able to interact with the original web browser. This form may provide an improvement in flexibility for a user to access resources in various devices that may typically not support the required authentication.

[0116]

[0125] FIG. 5B shows another exemplary schematic diagram illustrating the use of a web socket useful for authentication according to an embodiment of the present invention. Any of the characteristics or steps described elsewhere herein may apply.

[0117]

[0126] A web socket connection is established between a web browser 510 on a login device and a transport service 530. A unique URL may be received by the web browser, and a graphical code such as an encoded QR code may be displayed on the web browser. An authenticator 520 such as a mobile device may capture an image of the graphical code. The mobile device may scan the graphical code and open the URL. The authenticator may use the unique URL to establish a web socket connection.

[0118]

[0127] A FIDO challenge may be provided to the web browser by a response unit 540. The transport service may transfer the challenge and response for FIDO authentication to the authenticator. The web browser may then convey the FIDO response to the relying party for the challenge.

[0119]

[0128] FIG. 6A shows an exemplary method for authenticating a user to access a resource according to an embodiment of the present invention. In some embodiments, a login device 601, an authenticator device 602, a service provider server 603, a transport service 604, and a proximity-based authenticator 605 may be provided.

[0120]

[0129] The service provider server and the transport service can be provided as the same server or as separate servers. The transport service can be part of the overall service provider system or can be separate from the service provider system. Any description in this specification of steps that can be performed by the service provider or the transport system can be performed by the same entity.

[0121]

[0130] Similarly, the proximity-based authenticator can be illustrated as a dongle, but can apply to any hardware or software or user presence necessary for performing proximity-based authentication. For example, the authenticator device can have local hardware such as a biometric reader, a camera, a microphone, a temperature sensor, a pressure sensor, an ultrasonic sensor, an antenna, or other types of hardware that can enable proximity-based authentication. Similarly, the authenticator can have dedicated software that can be useful for proximity-based authentication. In some examples, an external device (e.g., a dongle, a smart card, a mobile device, etc.) may be required for proximity-based authentication. In some examples, the physical presence of the user (e.g., for biometric reading) may be required for proximity-based authentication.

[0122]

[0131] A user may wish to access online resources. The user can interact with the login device 601. The user can interact with the browser of the login device. The login device (e.g., the browser of the login device) can request 610 access to the resource. This request can be provided to the service provider server 603.

[0123]

[0132] In some embodiments, it may be determined that proximity-based authentication is disabled on the login device. In some examples, the user may provide an input indicating that proximity-based authentication is not enabled on the login device. Alternatively, no indication that proximity-based authentication is disabled on the login device may be required.

[0124]

[0133] A transport service and a WebSocket connection can be established 612. The login device can request a QR code for the session. The transport service can generate a QR code 613 in which a unique URL is encoded. As described above, the unique URL is within the domain of the relying party. Alternatively, the transport service can generate only the unique URL.

[0125]

[0134] In some embodiments, the transport service can provide a QR code to the login device 614. Alternatively, the transport service can provide a URL to the login device, and the login device can generate a QR code in which the URL is encoded.

[0126]

[0135] The login device can display the QR code 615. The QR code can be displayed on the web browser of the login device.

[0127]

[0136] The authenticator device 602 can scan the QR code 616. The authenticator device can have one or more cameras that can capture an image of the QR code. In some embodiments, the imaging device can capture an image of the QR code with sufficient clarity for the encoded information to be readable. If the captured image is not sufficiently clear, the authenticator can be prompted to take another photo.

[0128]

[0137] The authenticator device can open the URL encoded in the QR code within the local browser of the authenticator device 617. Alternatively or in addition, an application can be opened based on the scanned QR code.

[0129]

[0138] A WebSocket connection can be established between an authenticator and a transport service using a URL 618. The URL can be substantially unique. Even if other devices are using the transport service for various login sessions, their communications and authentications can remain separated based on the unique URL.

[0130]

[0139] The transport service can notify the login device regarding the scanning of a QR code 6181. The login device can request a FIDO challenge from the service provider 6182. The login device can also send a FIDO challenge 6183.

[0131]

[0140] The transport service can transfer a challenge for FIDO authentication to the authenticator 619. The authenticator can make a request to collect FIDO information 620. This request can include a request to the user to provide biometric information, can be a request to the user to enter input at the authenticator or a remote device, can include a request to a remote device such as a dongle or smart card, or can include other types of requests that may be necessary to complete ping or proximity-based authentication.

[0132]

[0141] The requested information can be provided 621. For example, the remote device can respond to the request made by the authenticator. In some embodiments, direct wireless communication (e.g., Bluetooth, wireless, optical, infrared, etc.) or wired communication can occur between the remote device and the authenticator. The remote device can be a short-range wireless communication device or any type of device that may need to be in proximity to the authenticator to perform authentication. In another example, the user can respond to the request to provide biometric information.

[0133]

[0142] The authenticator can transfer the response for FIDO authentication to the transport service 622. The transport service can convey the FIDO authentication response to the login device 623. The login device can convey the FIDO authentication response to the service provider server 6231. The service provider can determine the user's approval 624. The service provider can determine whether the user is approved to access the requested resource.

[0134]

[0143] If the user is determined to be approved to access the requested resource, access to the resource can be granted to the user 625. The service provider can provide an update that can allow the browser on the login device to permit the user to access the resource.

[0135]

[0144] FIG. 6B shows another exemplary method for authenticating a user to access a resource according to an embodiment of the present invention. Any of the features, characteristics, or steps described elsewhere in this specification may be applicable. For example, a user may wish to access an online resource by interacting with a login device (e.g., an ATM). The user can interact with the native browser of the ATM. The login device (e.g., the browser of the ATM) can request access to a resource (e.g., https: / / bank.com / login). The request can be provided to the relying party. To establish a WebSocket connection, the login device (e.g., the ATM) can send the request to the transport service.

[0136]

[0145] In response to the request, the transport service can generate a unique URL (https: / / bank.com / login?cid=(uuid)) for the relying party domain. For example, the URL includes the domain name bank.com and the unique identifier uuid.

[0137]

[0146] Upon receiving a URL, the native browser of the ATM can generate and render a QR code encoded with the URL using a software development kit (SDK) incorporated into the browser. For example, the transport service may include a software development kit (SDK) or library embedded within the native application of the device, a stand-alone application callable by other applications, and / or a service callable at the operating system level. The SDK or library may enable the ATM browser to generate a QR code encoded with a unique URL.

[0138]

[0147] The user can scan the QR code using the user device, and the user device can be navigated to the URL. For example, the native browser on the user device can be directed to a unique URL hosted by the relying party. At the same time, the user device can establish a WebSocket connection with the transport service using the unique identifier within the URL. Thereby, a two-way WebSocket connection between the user device and the ATM via the transport service is established. Upon receiving a notification from the transport service indicating that a WebSocket connection with the user device has been established, the ATM can notify the relying party, and the relying party can send a FIDO authentication request to the native browser of the ATM. Subsequently, the native browser of the ATM can transfer the FIDO authentication request to the native browser of the user device via the WebSocket connection.

[0139]

[0148] Next, the user can be prompted to locally perform FIDO authentication on the user device with an authenticator, etc. (e.g., proximity-based authentication). Once authenticated, the authenticator can sign the challenge request, and the native browser of the user device can send a response back to the native browser of the ATM via the WebSocket connection. The relying party can be informed of the authentication result.

[0140]

[0149] During the above authentication process, FIDO challenges and responses are transmitted within the relying party's domain, which beneficially enhances the security of network transfer. Pairing between the ATM and the user device is also simplified by using QR codes and activating the native browser application.

[0141]

[0150] FIG. 7 shows an exemplary network layout illustrating one or more authentication systems according to an embodiment of the present invention. In one aspect, the network layout can include a plurality of authenticator devices 702, one or more servers 704, a network 706, one or more databases 712, a plurality of login devices 714, a plurality of transport servers 708, and one or more transport systems 710. Each of the components 702, 704, 708, 710, and 714 can be operably connected to each other by the network 706 or any other kind of communication link that enables the transmission of data from one component to another.

[0142]

[0151] The authenticator device 702 described earlier in this specification can be, for example, one or more computing devices configured to perform one or more operations consistent with the disclosed embodiments. For example, the authenticator device can be a computing device capable of executing software or an application including proximity-based authentication. In some embodiments, the software and / or application can enable a user to scan a QR code or any other kind of graphical code displayed on another device during an authentication session, process the QR code, and transmit authentication data between the authenticator device and the transport system. The software and / or application may or may not be registered with the transport system by the user. Optionally, the software and / or application may not be registered with the transport system. In some embodiments, the application can be configured to collect authentication data (e.g., capture of an image, capture time, etc.) during an authentication session, encrypt the data, and then transmit it to the transport server. The authentication session can be hosted by the service provider server 704 on one or more interactive web pages and can be accessed by one or more users.

[0143]

[0152] As described earlier, the authenticator device 702 can include an imaging device such as a camera and / or imaging software. The camera and / or imaging software can be configured to be capable of capturing a QR code or a visual graphical barcode.

[0144]

[0153] In some examples, the network 706 can include multiple authenticator devices 702. Each authenticator device may or may not be associated with one or more users. The one or more users can be geographically in the same location, for example, users working in the same office or the same geographical location. In some examples, some or all of the users and authenticator devices can be in remote geographical locations (e.g., different cities, countries, etc.), but this is not a limitation of the present invention.

[0145]

[0154] A network layout may include a plurality of nodes. A node may be part of a telecommunications network. A node can receive and / or relay information. A node can generate information that can be relayed. Each authenticator device 702 in the network can correspond to a node. In FIG. 7, when a number or character follows "authenticator device 702", it means that "authenticator device 702" can correspond to the node and other components corresponding to the node that share the same number or character. For example, as shown in FIG. 7, the authenticator device 702-1 can correspond to node 1 associated with user 1, login device 714-1, and server 704-1, the authenticator device 702-2 can correspond to node 2 associated with user 2, login device 714-2, and server 704-2, and the authenticator device 702-k can correspond to node k associated with user k, authenticator device 714-k, and server 704-k, where k can be any positive integer.

[0146]

[0155] A node can be a logically independent entity within a network layout. Thus, a plurality of nodes within a network layout can represent various entities. For example, each node can be associated with a user, a group of users, or a plurality of groups of users. For example, a node can correspond to an individual entity (e.g., an individual). In another example, a node can correspond to a plurality of entities (e.g., a group of individuals).

[0147]

[0156] Any number of authentication sessions can be performed simultaneously or sequentially. In some embodiments, multiple individuals may attempt to log in to a website hosted by the same service provider or multiple service providers simultaneously. As shown, in some examples, the transport service can communicate with or support multiple servers of various service providers. In another example, each server or online service provider may have its own transport service that supports that particular online service provider. The transport service can operate on the service provider's server, and a separate transport service / transport server may not be required.

[0148]

[0157] A user can be registered or associated with the authentication system. For example, a user can be a registered user of an entity (e.g., a company, an organization, an individual, etc.) that provides and / or manages one or more of the service provider servers 704. One user can be associated with one or more authenticator devices 702 or can use such authenticator devices 702. One online service provider can be associated with one or more servers 704. The disclosed embodiments are not limited to any particular relationship or partnership between the user and the online service provider or server 704, database 712, transport service 708, and transport system 710.

[0149]

[0158] The authenticator device 702 may be configured to receive input from one or more users. The user may provide input to the user device using, for example, an input device such as a keyboard, mouse, touch screen panel, voice recognition, and / or dictation software or any combination of the foregoing. Examples of other user interaction devices may include buttons, touch pads, joysticks, trackballs, cameras, microphones, motion sensors, thermal sensors, inertial sensors, or any other type of user interaction device. The input may include the user performing various virtual actions during or prior to an authentication session. The input may include biometric information for authenticating the user, such as, for example, fingerprints, hand scans, iris scans, face recognition, gestures, walking, voice, or any other characteristic. The input may include activation or proximity of an object carried or worn by the user.

[0150]

[0159] In the explanatory diagram of FIG. 7, a two-way data transfer function may be provided between any two components including, for example, the transport server 708 and each authenticator device 702, the service provider server 704 and each authenticator device 702, the authentication server 708 and each service provider server 704, the service provider server 704 and each login device 714, the transport server 708 and each login device 714, and the like.

[0151]

[0160] The transport server 708 can include one or more server computers configured to perform one or more operations consistent with the disclosed embodiments. In one aspect, the transport can be implemented as a single computer, and the authenticator device 702 and / or the login device 714 can communicate with other components of the network 706 via that computer. In some examples, the authenticator device can communicate with the transport server via the network. In other examples, the transport server can communicate with one or more transport systems 710 or databases 712 via the network, instead of the authenticator device and / or the login device. In one aspect, the transport server can embody the functionality of one or more transport systems. In another aspect, one or more transport systems can be implemented inside and / or outside of the service provider server. Any server can be a server within a data network (e.g., a cloud computing network).

[0152]

[0161] In some examples, the authenticator device and / or the login device can be directly connected to the transport server via separate links. They can be directly connected by a web socket. In a particular example, the transport server can be configured to operate as a front-end device configured to provide access to one or more transport systems that conform to the particular embodiments disclosed. In some examples, for authentication purposes and for the purpose of inputting user information, to compare and match authentication data (e.g., a timestamp, a verification ID, etc.) and user information request data, the transport server can process data (e.g., FIDO authentication data) provided by the authenticator device using one or more transport systems. The transport server can be configured to store authentication data, user information data regarding the user, and user information request data regarding the online service provider in one or more databases 712. The transport server can also be configured to search for, obtain, and analyze (e.g., decrypt, decode, compare, etc.) authentication data stored in one or more databases. The transport server can also be configured to search for, obtain, and store user information data and user information request data in one or more databases. As described above, the transport service may operate on one or more service providers, and any description of the transport server in this specification may apply to any individual service provider server.

[0153]

[0162] In some examples, the authenticator device 702 and / or the login device 714 can be directly connected to the server 704 of the online service provider to open or access such an online account. In some examples, the server can include a web server, an enterprise server, or any other type of computer server, and can be computer-programmed to receive requests (e.g., HTTP or other protocols that can initiate data transmission) from computing devices (e.g., user devices, publicly shared devices) and provide the requested data to the computing devices. Additionally, the server can be a broadcast facility such as FTA (free-to-air), cable, satellite, or other broadcast facilities for delivering data. The server can also be a server within a data network (e.g., a cloud computing network).

[0154]

[0163] Server 704 may include known computing components such as one or more processors, one or more memory devices that store software instructions and data executed by the processors, etc. The server may have at least one memory for storing one or more processors and program instructions. The one or more processors may be a single or multiple microprocessors, a field programmable gate array (FPGA), or a digital signal processor (DSP) capable of executing a specific set of instructions. Computer-readable instructions may be stored on a tangible non-transitory computer-readable medium such as a flexible disk, hard disk, CD-ROM (compact disc read-only memory), MO (magneto-optical), DVD-ROM (digital versatile disc read-only memory), DVD RAM (digital versatile disc random access memory), or semiconductor memory. Alternatively, the methods disclosed herein may be implemented by hardware components such as, for example, an ASIC (application specific integrated circuit), a dedicated computer, or a general-purpose computer, or a combination of hardware and software. In FIG. 7, the transport server 708 is shown as a single server, but in some embodiments, the functions associated with the transport server may be implemented by multiple devices, or the functions of the transport server may be executed by the service provider server 714.

[0155]

[0164] Network 706 can be configured to provide communication between various components of a network layout. The network can include one or more networks that connect devices and / or components within the network layout to enable communication between those devices and / or components. For example, the network can be implemented as the Internet, a wireless network, a wired network, a local area network (LAN), a wide area network (WAN), Bluetooth, near field communication (NFC), or any other type of network that provides communication between one or more components of the network layout. In some embodiments, the network can be implemented using a cellular and / or pager network, a satellite, a licensed wireless, or a combination of licensed wireless and unlicensed wireless. The network can be wireless, wired (e.g., Ethernet), or a combination thereof.

[0156]

[0165] One or more transport systems 710 can be implemented as one or more computers that, when executed by one or more processors, each store instructions that can generate, upon request, a plurality of unique URLs and / or visual graphical codes (e.g., QR codes) associated with a particular session (e.g., verification ID, session ID, etc.), and provide the code or locator of the code to server 704. A user can scan the code with authenticator device 702 and send the scan data back to the one or more transport systems. For one-way authentication or mutual authentication, the one or more transport systems can provide user authentication to an online service provider based on the code and / or scan data, and / or provide online service provider authentication to the user. The one or more transport systems can simply convey information to an online service provider that can make a determination regarding user authentication. When inspected, the transport system can provide confirmation to the online service provider, which may enable the user to access the requested resources on the login device. In some examples, the server can include a computer on which one or more transport systems and / or authentication systems are implemented. Alternatively, the transport server can include a computer on which one or more authentication systems are implemented. Alternatively, the one or more transport systems can be implemented on separate computers.

[0157]

[0166] The server can access one or more authentication systems to execute one or more processes that conform to the disclosed embodiments, and can execute such authentication systems. In a particular configuration, the one or more authentication systems can be software stored in memory accessible by the server (e.g., in local memory for the server or in remote memory accessible on a communication link such as a network). Thus, in a particular aspect, the one or more authentication systems can be implemented as one or more computers, as software stored on a memory device accessible by the server, or as a combination thereof. For example, one authentication system can be computer hardware that executes one or more authentication techniques, and another authentication system can be software that executes one or more authentication techniques when executed by the server.

[0158]

[0167] The one or more authentication systems can be used to authenticate users in a variety of different ways. For example, the one or more authentication systems can store and / or execute software that executes an algorithm for authenticating a user based on FIDO authentication collected using an authenticator device. The one or more transport systems can also store and / or execute software that executes an algorithm for generating a unique URL and / or a visual graphical code (e.g., a QR code) having a specific verification ID. The transport system can communicate with the one or more authentication systems and can further store and / or execute software that executes an algorithm for searching, obtaining, and storing user information regarding the user and user information request data regarding the online service provider.

[0159]

[0168] The disclosed embodiments can be configured to implement one or more authentication systems such that various algorithms can be executed to perform one or more authentication techniques and authentication sequences, including providing required user information after authentication is completed. Although multiple authentication systems for executing the above algorithms have been described, it should be noted that some or all of the algorithms can be executed using a single authentication system that is consistent with the disclosed embodiments.

[0160]

[0169] The authenticator device 702, the transport server 708, the service provider server 704, and one or more transport systems 710 can be connected to or interconnected with one or more databases 712. The one or more databases can be one or more memory devices configured to store data (e.g., QR codes, FIDO authentication information, user identifiers, user device identifiers, service provider identifiers, server identifiers, transaction / verification IDs, user information, user information requests, etc.). Additionally, in some embodiments, the one or more databases can also be implemented as a computer system having a storage device. In one aspect, the one or more databases can be used by components of the network layout to perform one or more operations consistent with the disclosed embodiments. In certain embodiments, the one or more databases can be co-located with a server or with an authentication server and / or can be co-located with each other on the network. Those skilled in the art will recognize that the disclosed embodiments are not limited to this configuration and / or arrangement of the one or more databases.

[0161]

[0170] The login device 712 can be an unauthenticated device in that the identifier of the device is not registered with the transport or authentication system and does not necessarily need to be registered. In some embodiments, this device is used by a user to open an online account with an online service provider or to access a web portal or website provided by the service provider server 704 in order to access such an online account. The login device can be a publicly shared device whose identifier is not known to the authentication system. As described above, the login device can be configured to display a visual graphical code (e.g., a QR code) and / or a user interface (e.g., a web portal, a website) to the user. A visual graphical code or a locator of the code can be transmitted from the transport server to the display device. In some embodiments, when a locator (e.g., a URL) is provided, the QR code can be displayed by an interface such as a web page or any software. To establish communication between the user and the transport server, the interface can be linked to the server by a locator (e.g., a URL). The login device can be a computer (e.g., a laptop computer, a desktop computer), a mobile device (e.g., a smartphone, a tablet, a pager, a personal digital assistant (PDA)), a kiosk, an ATM, a smart appliance, a vending machine, etc. that requires user authentication or verification to open an online account (e.g., with an online service provider) or to access such an online account. The login device can optionally be portable. The login device can be handheld.

[0162]

[0171] In some embodiments, any of the authenticator device 702, the login device 714, the server 704, the one or more databases 712, and / or the one or more transport systems 710 can be implemented as a computer system. Additionally, in FIG. 7, the network is shown as a “central” point for communication between the components of the network layout, but the disclosed embodiments are not limited thereto. For example, one or more components of the network layout can be interconnected in various ways, and in some embodiments, as would be understood by those skilled in the art, they may be directly connected to each other, co-located, or separated. Additionally, some of the disclosed embodiments can be implemented on a server, but the disclosed embodiments are not limited thereto. For example, in some embodiments, other devices (such as one or more authenticator or login devices) can be configured to perform one or more of the processes and functions consistent with the disclosed embodiments, including those described with respect to the server and the authentication system.

[0163]

[0172] Although a particular computing device has been illustrated and the network has been described, it should be recognized and understood that other computing devices and networks can be utilized without departing from the spirit and scope of the embodiments described herein. Additionally, as would be recognized by those skilled in the art, one or more components of the network layout can be interconnected in various ways, and in some embodiments, they may be directly connected to each other, co-located, or separated.

[0164] Computer control system

[0173] The present disclosure provides a computer control system programmed to implement the methods of the present disclosure. FIG. 8 shows a computer system 801 programmed or otherwise configured to assist in authenticating a user attempting to access an online resource. This computer system can enable a user of FIDO authentication. This computer system can be part of a login device, an authenticator device, a transport service, or a provider service. This computer system can be a user's electronic device or a computer system located remotely from the electronic device. The electronic device can be a mobile electronic device.

[0165]

[0174] The computer system 801 can include a central processing unit (CPU, also referred to herein as a "processor" and a "computer processor") that can be a single-core processor, a multi-core processor, or multiple processors for parallel processing. The computer system also includes a memory or memory location 810 (e.g., random access memory, read-only memory, flash memory), an electronic storage unit 815 (e.g., hard disk), a communication interface 820 (e.g., network adapter) for communicating with one or more other systems, and peripheral devices 825 such as a cache, other memory, data storage areas, and / or an electronic display adapter. The memory 810, storage unit 815, interface 820, and peripheral devices 825 communicate with the CPU 805 via a communication bus (solid lines) such as a motherboard. The storage unit 815 can be a data storage unit (or data repository) for storing data. The computer system 801 can be operably coupled to a computer network ("network") 830 using the communication interface 820. The network 830 can be the Internet, the Internet and / or an extranet, or an intranet and / or an extranet that communicates with the Internet.

[0166]

[0175] In some cases, network 830 is a telecommunications network and / or a data network. The network may include one or more computer servers that enable distributed computing such as cloud computing. For example, one or more computer servers may perform various aspects of the analysis, calculation, and generation of the present disclosure, such as capturing the configuration of one or more experimental environments, storing the experimental environment in a registry at each of one or more time points, performing one or more experimental runs that utilize the experimental environment, providing the output of the experimental runs that utilize the environment, generating a plurality of links between the experimental environment and the experimental runs, and generating one or more execution states corresponding to the experimental environment at one or more time points, etc., to enable cloud computing (the "cloud") on the network. Such cloud computing may be provided by cloud computing platforms such as Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform, and IBM cloud. In some cases, the network can implement a peer-to-peer network using computer system 801, and the peer-to-peer network can enable devices coupled to the computer system to act as clients or servers.

[0167]

[0176] CPU 805 can execute a series of machine-readable instructions that can be embodied by a program or software. The instructions can be stored within a memory location such as memory 810. The instructions can be directed to the CPU and then the CPU can be programmed or otherwise configured to implement the methods of the present disclosure. Examples of operations performed by the CPU can include fetch, decode, execute, and write-back.

[0168]

[0177] CPU 805 can be part of a circuit such as an integrated circuit. One or more other components of the system may be included within the circuit. In some cases, the circuit is an application specific integrated circuit (ASIC).

[0169]

[0178] The memory unit 815 can store files such as drivers, libraries, and saved programs. The memory unit can store user data, such as user basic settings and user programs. In some cases, the computer system 801 can include one or more additional data storage units external to the computer system, such as located on a remote server that communicates with the computer system via an intranet or the Internet.

[0170]

[0179] The computer system 801 can communicate with one or more remote computer systems via the network 830. For example, the computer system can communicate with a remote computer system of a user (e.g., a user in an experimental environment). Examples of remote computer systems include personal computers (e.g., portable PCs), slates or tablet PCs (e.g., Apple® iPad, Samsung® Galaxy Tab), telephones, smartphones (e.g., Apple® iPhone, Android-compatible devices, Blackberry®), or portable information terminals. The user can access the computer system via the network.

[0171]

[0180] The methods described herein can be implemented by machine (e.g., computer processor) executable code stored on an electronic memory location of the computer system 801, such as, for example, in the memory 810 or the electronic memory unit 815. The machine executable or machine readable code can be provided in software form. In use, the code can be executed by the processor 805. In some cases, the code can be retrieved from the memory unit for rapid access by the processor and stored on the memory. In some situations, the electronic memory unit can be excluded and the machine executable instructions can be stored on the memory.

[0172]

[0181] The code can be pre-compiled and configured for use with a machine having a processor adapted to execute the code, or can be compiled during run-time. The code can be provided by a programming language that can be selected to enable the code to be executed in a pre-compiled or just-in-time compiled fashion.

[0173]

[0182] Programming. Various aspects of the present technology can typically be considered as a “product” or “manufactured article” in the form of machine (or processor) executable code and / or associated data that is carried on or embodied within a machine-readable medium. The machine executable code can be stored on an electronic storage unit such as a memory (e.g., read-only memory, random access memory, flash memory) or a hard disk. A “storage” type medium can include any or all of the tangible memories of various semiconductor memories, tape drives, disk drives, etc., computers, processors, etc. or their associated modules that can provide non-transitory storage at any point in time for software programming. All or part of the software can sometimes be transmitted by the Internet or other various electrical communication networks. Such communication can enable, for example, loading software from one computer or processor into another computer or processor, e.g., from an administrative server or host computer into the computer platform of an application server. Accordingly, another type of medium that can carry software elements can include light waves, radio waves, and electromagnetic waves such as those used across local device interfaces, through wired and optical line networks, and over various air links. Physical elements that carry such waves, such as wired links or wireless links, optical links, etc., can also be regarded as media that carry software. As used herein, unless limited to non-transitory tangible “storage” media, terms such as computer or machine “readable media” refer to any medium involved in providing instructions to a processor for execution.

[0174]

[0183] Accordingly, machine-readable media such as computer-executable code can take many forms including, but not limited to, tangible storage media, carrier wave media, or physical transmission media. Non-volatile storage media includes, for example, optical disks or magnetic disks such as any of the storage devices in the illustrated computers that can be used to implement a database, etc. Volatile storage media includes dynamic memory such as the main memory of such a computer platform. Tangible transmission media includes coaxial cables, copper wire, and fiber optics including the wiring that includes a bus within a computer system. Carrier wave transmission media can take the form of electrical signals or electromagnetic signals or acoustic or light waves such as generated during radio frequency (RF) and infrared (IR) data communications. Accordingly, common forms of computer-readable media include, for example, floppy disks, flexible disks, hard disks, magnetic tape, any other magnetic media, CD-ROM, DVD or DVD-ROM, any other optical media, punched cards, paper tape, any other physical storage media with patterns of holes, RAM, ROM, PROM, and EPROM, FLASH-EPROM, any other memory chip or cartridge, carrier waves that transfer data or instructions, cables or links that transfer such carrier waves, or any other media that a computer can read programming code and / or data from. Many of these forms of computer-readable media can be involved in carrying one or more sequences of one or more instructions to a processor for execution.

[0175]

[0184] Computer system 801 can include, for example, an electronic display 103 that includes a user interface (UI) 840 for providing, among other things, a selection of an environment, components of an environment, or a point in time of an environment, or can communicate with such an electronic display 103. Examples of UIs include, without limitation, graphical user interfaces (GUIs) and web-based user interfaces.

[0176]

[0185] The methods and systems of the present disclosure can be implemented by one or more algorithms. The algorithms can be implemented by software when executed by a central processing unit 805. The algorithms can, for example, capture the configuration of one or more experimental environments, store the experimental environments in a registry at each of one or more time points, perform one or more experimental runs that utilize the experimental environments, provide the outputs of the experimental runs that utilize the environments, generate a plurality of links between the experimental environments and the experimental runs, and generate one or more execution states corresponding to the experimental environments at one or more time points.

[0177]

[0186] The systems and methods shown herein can provide one or more advantages that lead to an improvement in flexibility when providing users with access to online resources while maintaining security. The systems and methods shown herein utilize existing (e.g., web) communication channels without requiring a dedicated protocol such as USB, NFC, or BLE. This leads to an improvement in the flexibility of the types of login devices that can be used to access a particular resource. For example, it is even possible to use an ATM to access a login resource without requiring a dedicated protocol. The systems and methods shown herein support the concept of physical proximity of FIDO and can advantageously conform to existing FIDO architectures.

[0178]

[0187] The systems and methods shown herein lead to an improvement in usefulness along with quick and easy pairing. The systems and methods shown herein can lead to omnichannel use of mobile platform "built-in" applications. The present systems and methods may be capable of providing an improvement in usefulness without compromising security. Web sockets protected by TLS 1.2 can be used. The systems and methods shown herein can be decentralized

[0179]

[0188] Although specific implementations have been illustrated and described, various modifications to those implementations can be made, and it should be understood from the foregoing what is contemplated herein. Further, the present invention is not intended to be limited by the specific examples given herein. Although the present invention has been described with respect to the foregoing specification, the description and figures of the preferred embodiments herein are not intended to be construed in a limiting sense. Further, it should be understood that all aspects of the present invention are not limited to the specific depictions, configurations or relative ratios described herein, which depend on various conditions and variables. Various modifications in the form and details of the embodiments of the present invention will become apparent to those skilled in the art. Accordingly, the present invention is considered to include any such modifications, variations and equivalents thereof.

Claims

1. A method executed by a computer system for providing authentication to access resources provided by a service provider via a login device, comprising: generating a unique Uniform Resource Locator (URL) within a network domain of the network of the service provider, the URL including the name of the network domain of the service provider, the URL being encoded within a graphical code rendered on the login device for accessing the resources provided by the service provider; establishing a network connection between the login device and the user device using the unique URL, the network connection being established when the user device captures the graphical code displayed on the login device and accesses the URL encoded within the graphical code; performing an authentication for accessing the resources via the login device by executing an encrypted challenge and an encrypted response between the user device and the service provider via the network connection using an encryption key, the encrypted response being signed and transmitted to the network domain of the network of the service provider; A method including the above steps.

2. The method according to claim 1, wherein the graphical code is a QR code.

3. The method according to claim 1, wherein the unique URL is provided to the login device via a WebSocket connection.

4. The method according to claim 1, wherein the graphical code is provided to the login device via a WebSocket connection.

5. The method according to claim 1, wherein the graphical code is rendered within a native application on the login device.

6. The method according to claim 5, wherein the graphical code is generated by the native application.

7. The method according to claim 1, wherein the network connection between the login device and the user device is a WebSocket connection.

8. The method according to claim 1, wherein the encrypted challenge and the encrypted response include FIDO (Fast IDentity Online) authentication.

9. The method according to claim 8, wherein the cryptographic challenge and the cryptographic response for the FIDO authentication are signed using the encryption key.

10. The method according to claim 9, wherein the cryptographic challenge and the cryptographic response are transmitted via the native browser of the user device.

11. The method according to claim 1, wherein the unique URL includes a series of random or pseudo-random character strings.

12. The method according to claim 11, wherein the unique URL further includes a unique identifier.

13. A system for providing authentication for accessing resources provided by a service provider via a login device, a transport service configured to generate a unique Uniform Resource Locator (URL) within the network domain of the network of the service provider, the URL including the name of the network domain of the service provider, the URL being encoded within a graphical code rendered on the login device for accessing the resources provided by the service provider, a transport service; a user device, (i) establishing a network connection with the login device using the unique URL, the network connection being established when the user device captures the graphical code displayed on the login device and accesses the unique URL encoded within the graphical code; (ii) performing a cryptographic challenge and a cryptographic response with the login device via the network connection using an encryption key, and performing authentication for accessing the resources via the login device, the cryptographic response being signed and transmitted to the network domain of the network of the service provider; a user device configured to perform; a system including.

14. The system according to claim 13, wherein the graphical code is a QR code.

15. The system according to claim 13, wherein the unique URL is provided to the login device via a WebSocket connection.

16. The system according to claim 13, wherein the graphical code is generated by the transport service and provided to the login device via a WebSocket connection.

17. The system according to claim 13, wherein the graphical code is rendered within a native application on the login device.

18. The system according to claim 17, wherein the graphical code is generated by the native application.

19. The system according to claim 13, wherein the network connection between the login device and the user device is a WebSocket connection.

20. The system according to claim 13, wherein the cryptographic challenge and the cryptographic response include FIDO authentication.

21. The system according to claim 20, wherein the cryptographic challenge and the cryptographic response for the FIDO authentication are signed using the encryption key.

22. The system according to claim 21, wherein the cryptographic challenge and the cryptographic response are transmitted via the native browser of the user device.

23. The system according to claim 13, wherein the unique URL includes a series of random or pseudo-random character strings.

24. The system according to claim 23, wherein the unique URL further includes a unique identifier.

Images