Passwordless authentication for access management

Abstract

The present disclosure relates to passwordless authentication for access management. An access management system that can provide access to resources through passwordless authentication is disclosed. The access management system can provide multiple layers of security for authentication, taking into account risk factors (e.g., device, location, etc.), to ensure authentication without compromising access. Contextual details of a user of a mobile device can be used to authenticate based on possession of the device. Passwordless authentication of the user can be enabled by registering the device and / or location (e.g., geolocation) as trusted. Secure data, which is embedded with encrypted data, can be sent to a first device in order to passwordlessly authenticate the user on the device. A second device registered to the user can obtain the secure data from the first device. The second device can decrypt the data and send the decrypted data to the access management system for verification, thereby enabling passwordless authentication at the first device.

Description

[0001] This application is a divisional application of invention patent application 201680061204.3, filed on October 21, 2016, entitled “Passwordless Authentication for Access Management”.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] This PCT patent application claims the benefit of and priority to U.S. Provisional Application No. 62 / 245,891, filed October 23, 2015, entitled “PASSWORD-LESS AUTHENTICATION FOR ACCESS MANAGEMENT,” the contents of which are incorporated herein by reference in their entirety for all purposes. Technical Field

[0004] The present invention relates generally to data processing and more particularly to techniques for multi-stage authentication. Background Art

[0005] Modern businesses rely on a variety of applications and systems that control and generate information critical to business operations. Different applications often provide different services and information, and different users may require access to different levels of information within each system or application. The level of access granted to a user can depend on the user's role. For example, a manager may need access to certain information about the employees who report to them, but it may be inappropriate to allow the manager access to the same information about the people they report to.

[0006] Previously, less complex applications incorporated access management business logic directly into the application code. That is, for example, each application would require the user to have a separate account, separate policy logic, and separate permissions. Furthermore, when a user authenticated with one of these applications, that authentication remained unknown to other applications in the enterprise because the fact that authentication with the first application had occurred was not shared. As a result, there was no concept of trust between applications that used different systems for authentication and access control. Engineers quickly realized that setting up an access management system for every application in the enterprise was like having a gas station for every car, and determined that authentication and access control would be more efficiently implemented and managed as shared resources. These shared resources became known as access management systems.

[0007] Access management systems often use policies and other business logic to determine whether a particular access request should be granted to a particular resource. Upon determining that access should be granted, a token is provided to the requestor. This token is like a key that can be used to open the door protecting the restricted data. For example, a user can attempt to access a human resources database to gather information about certain employees, such as salary information. The user's web browser makes a request to the application that requires authentication. If the web browser does not have a token, then the user is asked to log in to the access management system. When the user is authenticated, the user's browser receives a cookie representing a token that can be used to access the human resources application.

[0008] In an enterprise, a user (e.g., an employee) can often have access to one or more different systems and applications. Each of these systems and applications can utilize different access control policies and require different credentials (e.g., a username and password). Single sign-on (SSO) can provide a user with access to multiple systems and applications after an initial login. For example, when a user logs in to their work computer, the user can then also have access to one or more other resources, such as systems and applications. An access management system can challenge the user to verify his / her identity to determine access to the resources. The user can be challenged for information based on a combination of "what do you have," "what do you know," and "who are you."

[0009] An access management system can utilize a graphical user interface on a client device to prompt a user to challenge user information to verify the user's credentials. Sometimes, the information requested by the user can include sensitive confidential information that, if compromised, can threaten an individual's identity and personal information (e.g., financial or account information). Thus, a user can hesitate to provide sensitive information to a system, such as a server, to gain access to a resource without being confident that the system requesting the information does in fact control access to those resources.

[0010] With the continued advancement of technology-based identity theft using techniques such as fraud and phishing, users are even less willing to provide their credentials without being confident that the recipient is an access management system. The access management system is also not confident in the authenticity of the source of the credentials. In some cases, a client system can receive a one-time code (e.g., a password) to enable a user operating the client system to access a resource via the access management system. If the client system is compromised or stolen, the user operating the client system can gain unauthorized access to the resource using the one-time code.

[0011] While passwords have been the accepted norm for authenticating users and providing access, they are fraught with problems—people forget their passwords or make them easy enough to guess. The use of layered security and multiple authentication factors is gaining momentum as a more secure authentication method for preventing fraud. Summary of the Invention

[0012] The present disclosure relates to an access management system. Certain technologies are related to enabling passwordless authentication. These technologies provide multi-layered security for authentication, taking into account various risk factors (device, location, etc.), ensuring that legitimate users have an easy way to authenticate and access the resources they need, while making it difficult for fraudsters to game the system. With the increasing use of mobile devices, the technologies disclosed herein enable mobile devices to be used as trust points for multi-factor authentication. The access management system in this disclosure can leverage user contextual details based on the device, ensuring that users are authenticated based on possession of the device.

[0013] An access management system can coordinate the registration of devices (e.g., mobile devices) and / or locations (e.g., geographic locations) associated with users. Once the devices and / or locations are registered, they can be trusted by the access management system for access by users associated with those devices and / or locations. The access management system can enable passwordless authentication of users associated with any of the trusted devices and / or locations. Using a device registered with the access management system, a user can be provided access to (one or more) resources. Devices registered with the access management system can be used for passwordless authentication to authenticate users at trusted devices and / or locations. Possession of a registered device can serve as a point of trust to ensure that the user associated with the device is legitimate as a previously authenticated user.

[0014] In at least one embodiment, device fingerprinting and geolocation techniques may be utilized to reliably identify a device or a location associated with a device as being trustworthy from which a user is requesting access. In order to register a device or location as being trustworthy, the access management system may employ one or more authentication processes (e.g., multi-factor authentication). For example, multi-factor authentication may include utilizing an out-of-band verification process utilizing a device (e.g., a mobile phone) that has been pre-registered for the user's account. Once registered, the device may be used for passwordless authentication to capture security data sent to a different device from which passwordless authentication is to be performed. Further authentication (e.g., biometric authentication) at the pre-registered device may be used to reliably identify the user before allowing the user to perform passwordless authentication. Contextual details of the user based on the mobile device may be used to authenticate the user based on possession of a device that was pre-registered with the access management system.

[0015] The access management system can perform passwordless authentication by generating security data embedded with encrypted data. The security data can be sent to the first device from which the passwordless authentication is to be performed. A second device registered with the user can obtain the security data from the first device. The second device can decrypt the data using security information (e.g., a key) provided to it by the access management system. The second device can send the decrypted data to the access management system for verification. Upon successful verification, the access management system can send a message to the first device to enable access through passwordless authentication.

[0016] The technology disclosed herein enables the use of multiple different authentication processes for passwordless authentication. Device fingerprinting and geolocation can reliably identify the device requesting access. The use of out-of-band authentication (e.g., a one-time password) can allow a user to authorize sensitive access. The security of the device owning the user can also be ensured by controlling access at the registered device using biometrics for local authentication. The use of encryption for secure data can protect communications between the device used for passwordless authentication and the device at which passwordless authentication is requested. The use of multiple authentication techniques (including the use of a registered device as an authenticator) can increase security to ensure that access via the access management system is not compromised.

[0017] In some embodiments, an access management system may include a computer system configured to implement the methods and operations disclosed herein. The computer system may include one or more processors and one or more memories accessible to the one or more processors and storing one or more instructions that, when executed by the one or more processors, cause the one or more processors to implement the methods and / or operations disclosed herein. Still other embodiments relate to systems and machine-readable tangible storage media that employ or store instructions for the methods and operations disclosed herein.

[0018] In at least one embodiment, a method includes receiving a user request from a first device to access a resource. The method may include determining, based on the request, that the first device is registered for the user, based on prior authentication of the user at the first device. The method may include generating security data used to determine the user's authentication to access the resource using the first device. The security data may include first data based on information related to the user, and wherein the first data is encrypted based on an encryption key. The method may include sending the encryption key to a second device that the user has registered with an access management system, wherein the second device is different from the first device. The second device may be a mobile device, and the first device may be a computer system. The method may include sending the security data to the first device, wherein the first device presents the security data at an interface of the first device. The method may include receiving, from the second device, second data generated by the second device based on decryption of the first data included in the security data. The decryption of the first data may be performed by the second device using the encryption key sent to the second device. The security data may be obtained by the second device from the presentation of the security data by the first device. The method may include determining whether the second data includes the information included in the first data. The method may include enabling the first device to access the resource based on determining that the second data includes the information.

[0019] In some embodiments, presenting the security data at the first device is displaying the security data at the first device. The security data may include a Quick Response (QR) code displayed at the first device for presenting security. The first data included in the security data may be embedded in the QR code.

[0020] In some embodiments, the method may include identifying the first device as registered for the user based on one or more authentication processes used to determine authentication of the user at the first device, and wherein upon identifying the second device as registered for the user, sending the encryption key to the second device. Based on authenticating the user for access at the second device, the second device may enable the user to operate the second device to obtain the security data from the presentation of the security data at the first device. Authenticating the user for access at the second device may include performing biometric authentication of the user based on a previous biometric input provided for registration of the user.

[0021] In some embodiments, the request includes information identifying the first device.The first device may be identified as registered by the first device based on authentication of a user associated with the information identifying the first device.

[0022] In some embodiments, the authentication of the user is determined based on one or more authentication processes including a first authentication process and a second authentication process. The second authentication process can be different than the first authentication process. The method can also include performing the first authentication process prior to the request. The first authentication process can include verifying credential information of the user received from the first device. The method can include sending temporary access information to the second device prior to the request and receiving the temporary access information from the first device. The method can include performing the second authentication process prior to the request. The second authentication process can include determining that the received temporary access information matches the temporary access information sent to the second device. In some embodiments, the temporary access information is a personal identification number associated with a time period for which the temporary access information is valid for the second authentication process.

[0023] In some embodiments, the method includes sending a message to the first device indicating that access to the resource is enabled. The first device can generate a graphical interface to enable access to the resource at the first device.

[0024] The foregoing summary, as well as other features and embodiments, will be more apparent from the following description, claims and drawings. BRIEF DESCRIPTION OF DRAWINGS

[0025] Illustrative embodiments of the disclosure are described in detail below with reference to the following drawings:

[0026] Figure 1 FIGURE 1 illustrates a high-level diagram of a system for enabling multi-factor authentication for access by an access management system, according to embodiments.

[0027] Figure 2A And Figure 2B FIGURE 2 illustrates a sequence diagram showing operations for enabling multi-factor authentication for access by an access management system, according to embodiments.

[0028] Figure 3-Figure 18 FIGURE 3 illustrates an interface for enabling multi-factor authentication for access by an access management system.

[0029] Figure 19 And Figure 20 FIGURE 4 illustrates an example of a flow diagram of a process for authentication, according to some embodiments.

[0030] Figure 21 A simplified diagram of a distributed system for implementing embodiments is depicted.

[0031] Figure 22 FIGURE 5 illustrates a simplified block diagram of one or more components of a system environment in which services can be offered as cloud services, in accordance with embodiments of the present disclosure.

[0032] Figure 23An exemplary computer system is illustrated that can be used to implement embodiments of the present disclosure. DETAILED DESCRIPTION

[0033] In the following description, for illustrative purposes, specific details are set forth in order to provide a thorough understanding of the embodiments of the present disclosure. However, it will be apparent that various embodiments can be practiced without these specific details. For example, circuits, systems, algorithms, structures, techniques, networks, processes, and other components may be shown as components in block diagram form to avoid obscuring the embodiments with unnecessary detail. The drawings and descriptions are not intended to be limiting.

[0034] I. High-level overview of access management systems for passwordless authentication

[0035] Some embodiments (such as systems, methods, and machine-readable media) are disclosed for multi-factor authentication using multiple clients (eg, computing device 104 and computing device 114). Figure 1 A system 100 is illustrated in which a user (e.g., user 102) can register a device as a "trusted device" to enable passwordless authentication to an access management system 140. Passwordless authentication can enable a device to be registered as a "trusted" device for authenticating the user via the access management system to gain access to resources. Trusted devices can be registered for passwordless authentication of users associated with those devices. A geographic location identified with the device can be registered as a "trusted location" that, upon detection, can be a location where passwordless authentication can be achieved after registration.

[0036] System 100 can provide single sign-on (SSO) access. After initial authentication based on authentication of credential information (e.g., username and password), an SSO session can provide a user with access to one or more systems. Access to a system can provide access to one or more resources. A resource can include any item managed and / or stored by a computing system (such as an application, document, file, electronic content, etc.). A resource can be identified by a uniform resource locator (URL) or other data indicating the source of the resource.

[0037] The client may include a computing device or an application executing on a computing device. Figure 1In particular embodiments, computing device 104 (e.g., a desktop computer system) can include an application 106 executing on computing device 104. Application 106 can be downloaded from a source such as an online application store (e.g., application store 180). Application 106 can be a web browser that provides access to an access management portal (e.g., an "OOW Access Portal") that communicates with access management system 140 to control access to resources. Computing device 114 (e.g., a mobile device) can include an application 116 executing on computing device 114. Application 116 can be downloaded from application store 180. Application 116 can be an authentication application that manages authentication with access management system 140. The application can be the Mobile Authenticator application provided by Oracle Corporation. As will be described below, applications 106, 116 can be used to register clients with access management system 140. Application 106 can provide access to resources, while application 116 enables registration and passwordless authentication of user 102 at computing device 104.

[0038] For purposes of illustration, as described herein, a "session" includes an SSO session; however, a session can include other types of sessions that enable access to a user. Access management system 140 can provide access to one or more resources. Access management system 140 can implement a login system (e.g., an SSO system) that can establish an SSO session to provide SSO access to one or more resources.

[0039] A resource can include, but is not limited to, a file, a web page, a document, web content, a computing resource, or an application. For example, system 100 can include resources such as applications 120 and / or content accessible through these applications 120. An application can be used to request and access a resource. For example, an application can request access to a web page from a resource server based on a URL that identifies the requested resource. A resource can be provided by one or more computing systems (e.g., a resource server that provides access to one or more resources upon authentication of user 102 in an SSO system).

[0040] The access management system 140 can be implemented by a computing system. The computing system can include one or more computers and / or servers (e.g., one or more access manager servers), which can be general-purpose computers, dedicated server computers (including, by way of example, PC servers, UNIX servers, mid-range servers, mainframe computers, rack-mount servers, etc.), server farms, server clusters, distributed servers, or any other suitable arrangement and / or combination thereof. The access management system 140 can run any operating system or a variety of additional server applications and / or middle-tier applications, including HTTP servers, FTP servers, CGI servers, Java servers, database servers, etc. Exemplary database servers include, but are not limited to, those commercially available from Oracle, Microsoft, etc. The access management system 140 can be implemented using hardware, firmware, software, or a combination thereof.

[0041] In some embodiments, the access management system 140 can be implemented by multiple computing devices (e.g., access manager servers) deployed as a cluster in a data center, which allows for scalability and high availability. Multiple such geographically dispersed data centers with access manager server clusters can be connected (wired or wirelessly) to form a multi-data center (MDC) system. The MDC system can meet the high availability, load distribution, and disaster recovery requirements of access servers within an enterprise computer network. The MDC system can act as a single logical access server to support SSO services for the access management system 140.

[0042] The access management system 140 may include at least one memory, one or more processing units (or processor(s)), and memory. The processing unit(s) may be suitably implemented using hardware, computer-executable instructions, firmware, or a combination thereof. In some embodiments, the access management system 140 may include several subsystems and / or modules. For example, the access management system 140 may include an access manager 142, which may be implemented using hardware, software (e.g., program code, instructions executable by a processor) executed on the hardware, or a combination thereof. In some embodiments, the software may be stored in a memory (e.g., a non-transitory computer-readable medium), on a storage device, or on some other physical storage, and may be executed by one or more processing units (e.g., one or more processors, one or more processor cores, one or more GPUs, etc.). The computer-executable instructions or firmware implementation of the processing unit(s) may include computer-executable instructions or machine-executable instructions written in any suitable programming language to perform the various operations, functions, methods, and / or processes described herein. The memory may store program instructions that may be loaded and executed on the processing unit(s), as well as data generated during the execution of these programs. The memory can be volatile (such as random access memory (RAM)) and / or non-volatile (such as read-only memory (ROM), flash memory, etc.). The memory can be implemented using any type of persistent storage device (such as a computer-readable storage medium). In some embodiments, the computer-readable storage medium can be configured to protect the computer from electronic communications containing malicious code. The computer-readable storage medium may include instructions stored thereon that, when executed on a processor, perform the operations described herein.

[0043] Each of computing devices 104, 114 can communicate with access management system 140 via one or more communication networks. Access management system 140 can communicate with computing device 104 via one or more communication networks 170. Access management system 140 can communicate with computing device 114 via one or more communication networks 130. Examples of communication networks can include mobile networks, wireless networks, cellular networks, local area networks (LANs), wide area networks (WANs), other wireless communication networks, or combinations thereof.

[0044] Figure 1An example is shown in which user 102 can engage in communication with access management system 140 to prevent his access from being denied based on his actions at a client (e.g., computing device 104). In this example, user 102 operating computing device 114 can attempt to access a resource such as application 106, for example, application 120 or any of the resources accessible through application 120. Upon successful authentication of user 102's credential information, application 120 can be accessible to user 102. User 102 can attempt to provide credential information, and after several unsuccessful attempts, user 102 can be denied access. Access can be denied based on a threshold number of attempted access attempts being met. Access management system 140 can communicate with the destination (e.g., computing device 114) to provide the user with temporary access information, which the user can provide to the access management system at computing device 104 to prevent his access from being denied.

[0045] When attempting to access an application, the user 102 may operate an application (e.g., application 106) that manages access to the user's account via the access management system 140. For example, the application 106 is an access management application that can present an interface (such as a graphical user interface (GUI)), some of which are disclosed herein. The application can be provided as a service (e.g., a cloud service) or as part of a web-based application. The application can enable a user to access and execute services provided by the access management system 140. The access management system 140 can be configured to run one or more services or software applications described in the foregoing disclosure. For example, the access management system 140 can provide many SSO services, including management of access to resources (e.g., granting / denying access), automatic login, changing and resetting application passwords, session management, application credential provisioning, and authentication of sessions. In some embodiments, the access management system 140 can provide a plurality of SSO services for the application 120 (such as an application running on or accessed from a client device). Applications, Web Applications, Applications and mainframe / terminal-based applications) provide automatic single sign-on functionality. As explained above, the access management system 140 can perform authentication of a user (e.g., user 102) operating a client device (e.g., computing device 114). Authentication is the process by which a user is verified to be who they claim to be.

[0046] The access management system 140 may also provide services or software applications, which may include non-virtualized environments and virtualized environments. In some embodiments, these services may be provided to users of the client as web-based services or cloud services or according to a software as a service (SaaS) model. The services provided by the access management system 140 may include application services. Application services may be provided by the access management system 140 via a SaaS platform. The SaaS platform may be configured to provide services that fall under the SaaS category. The SaaS platform may manage and control the underlying software and infrastructure used to provide SaaS services. By utilizing the services provided by the SaaS platform, customers may utilize applications executed in the access management system 140, which may be implemented as a cloud infrastructure system. Users may obtain application services without the need for customers to purchase separate licenses and support. A variety of different SaaS services may be provided. Users operating the client may then utilize one or more applications to interact with the access management system 140 to utilize the services provided by the subsystems and / or modules of the access management system 140.

[0047] In some embodiments, the access management system 140 may use one or more policies 160 ("policies") stored in a data repository to control access to resources. Policies 160 may include authentication policies that specify the authentication methods that will be used to authenticate users for whom access must be provided on a given resource. Policies 160 define how resource access is protected (e.g., the type of encryption, etc.). Policies 160 may include authorization policies that specify the conditions under which a user or group of users can access a resource. For example, an administrator may authorize only certain users within a group to access a particular resource. The access management system 140 may determine the authentication to use for an SSO session based on one or more of the policies 160.

[0048] The access management system 140 may also include or be coupled to additional storage, which may be implemented using any type of permanent storage device, such as a memory storage device or other non-transitory computer-readable storage medium. In some embodiments, the local storage may include or implement one or more databases (e.g., a document database, a relational database, or other type of database), one or more file repositories, one or more file systems, or a combination thereof. For example, the access management system 140 is coupled to or includes one or more data repositories for storing data such as access data 150, policies 160, application store 180, and client registration data 190 ("client registration data"). Memory and additional storage are both examples of computer-readable storage media. For example, computer-readable storage media may include volatile or non-volatile, removable or non-removable media implemented in any method or technology for storing information, such as computer-readable instructions, data structures, program modules, or other data.

[0049] The access manager 142 may handle processing to determine whether a valid session exists for the user 102 to access a resource. The access manager 142 checks for a valid session for the user 102 to access a protected requested resource. The access manager 142 may evaluate the validity of the session for the user 102 based on consideration of one or more access policies applicable to the user 102. Based on a determination that a valid session does not exist for the user 102, the access manager 142 may request credential information ("credentials") from the user 102. Successful authentication of the credential information may provide the user with access to one or more resources, which may include the requested resource. The access manager 142 may implement multi-factor authentication to determine authentication of the user. Multi-factor authentication may involve the use of a variety of different authentication techniques.

[0050] In some embodiments, the access manager 142 may register clients (such as computing devices 104) associated with the user. Figure 2A 14. The user may register using a different client (e.g., computing device 114) as described in

[15] . Information about the registered client (including geographic location information) may be stored in client registration data 190. The user's authentication credentials may be stored in access data 150. During registration, access manager 142 may generate or determine security information (e.g., one or more encryption keys) that is shared with the client (e.g., computing device 104 and computing device 114) to support registration and multi-factor authentication of the device by access management system 140. The encryption key may be stored in access data 150. Encryption performed as disclosed herein may use one or more known encryption techniques. The security data may be generated by access manager 142 or may be pre-generated by another system. The security data may be encrypted using an encryption key specified for the registered user.

[0051] User 102 may operate computing device 104 and use application 106 to access a portal (e.g., a web page) provided by access management system 140 to register a device (such as computing devices 104 or 114) as a trusted authentication device. Computing device 104 may request access management system 140 through the portal to access features for device registration. The request may be transmitted to computing device 104, and in response, computing device 104 prompts user 102 to enter user credentials to authenticate the session. The request may include information (e.g., a URL) to a web page or user interface (e.g., a web page, portal, or dashboard) for receiving credential information. Access manager 142 may perform operations to authenticate user 102's credential information. In some embodiments, upon successful authentication of the user, access manager 142 may store information about the established session. For an SSO session (e.g., an SSO authenticated session), the SSO session may be managed as an SSO session that enables access to all resources accessible to the user based on successful authentication of the user's credential information. The access manager 142 may determine protected resources and may determine the resources that are allowed and / or restricted for the session based on the authentication session.

[0052] When a device (e.g., computing device 114) is registered as trusted for use as a mobile authenticator for passwordless authentication, the device can be used to perform passwordless authentication for subsequent attempts to access resources at the portal. For example, computing device 114 can be used for passwordless authentication of a user by capturing security data presented at computing device 104. After computing device 104 is registered as a trusted device / location, access manager 142 can use passwordless authentication to determine the authentication of user 102 when there is a request to access a resource from computing device 104. Access manager 142 can generate and send security data including encrypted information to computing device 104. Computing device 104 can present the security data to user 102. Computing device 114 can obtain 190 the security data presented by computing device 104. Computing device 114 can communicate with computing device 104 to obtain the security data. Figure 2B An example of passwordless authentication when registering a device is shown. Access manager 142 can manage information about trusted devices so that access manager 142 can transmit security information (e.g., security keys) to registered devices to enable these devices to operate as authenticators for passwordless authentication. Technologies for passwordless authentication are further disclosed herein.

[0053] Communications between the computing devices 104, 114 and the access management system 140 can be received through a gateway system. The gateway system can support access management services. The gateway system can support access management services. For example, a single sign-on (SSO) gateway can implement one or more access proxies (such as a proxy (e.g., a web gate proxy)) to balance and / or handle requests from clients and the access management system 140. In some embodiments, the access management system 140 can be implemented in the system 100 according to a proxy-server model for communications between the computing devices 114, 104 and any of the access manager servers implemented for the access management system 140. The proxy-server model can include a proxy component (e.g., the gateway system) and a server component. The proxy component can be deployed on a host system and the server component can be deployed on a server (e.g., an access manager server). The computing device 114 can be a workstation, a personal computer (PC), a laptop computer, a smart phone, a wearable computer, or other networked electronic device.

[0054] The access management system 140 can present a request for authentication credentials to the user 102 in the form of a challenge (e.g., via a web browser of the user at the computing device 114). In some embodiments, the user 102 can access an SSO user interface through a client executing on the computing device 114 or through a web browser on the computing device 114. The SSO user interface can be implemented at the access management system 140. The access management system 140 can send the SSO user interface or information (e.g., a URL) that enables access to the SSO user interface.

[0055] In some embodiments, the SSO user interface can include a list of applications that the user 102 typically uses. The user 102 can manage their policies and credentials associated with the applications through the SSO user interface. When the user 102 requests access to an application (e.g., the application 140) through the SSO user interface, a request can be sent from the computing device 114 to the access management system 140 to determine a policy type for the application from one or more policies 160 that apply to the user 102. The access management system 140 can determine whether there is a valid session for the user and, if so, it can determine credential information for the user 102 based on the policy type.

[0056] In some embodiments, the request can include an authentication cookie from a previous login, which can be used to determine whether the user 102 is authorized to retrieve the credential. If authorized, the user can use the credential to log in to the application. In some embodiments, the proxy can enable the user to use SSO services provided by the access management system to access the application 120. Access can be provided directly through the web browser without first accessing an SSO user interface or using a client executing on the computing device 114. If the user 102 is not authorized, the access management system can request a credential from the user 102. The SSO user interface can present an interface to receive input including credential information. The credential information can be sent to the access management system 140 to determine authentication of the user 102.

[0057] In some embodiments, multiple credential types can be supported, such as Oracle Access Management protected resources, federated applications / resources, and form fill applications. Examples of credential types can include smart card / proximity card, token, public key infrastructure (PKI), Windows login, Lightweight Directory Access Protocol (LDAP) login, biometric input, etc. For OAM protected resources, a user request can be authenticated and then directed to a URL associated with the requested resource. For federated applications, links can be provided to federated partners and resources, including business-to-business (B2B) partner applications and SaaS applications. For form fill applications, templates can be used to identify fields of an application web page through which credentials can be submitted.

[0058] II. Process to register a device as authenticator for passwordless authentication

[0059] Some embodiments, such as the embodiments disclosed with respect to Figure 2A , Figure 2B and Figure 3-Figure 18 may be described as processes that are depicted as flow charts, flow diagrams, data flow diagrams, structure diagrams, sequence diagrams, or block diagrams. Although a sequential process can be described, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations can be re-arranged. A process is terminated when its operations are completed, but could have additional steps not included in a figure. A process can correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination can correspond to a return of the function to the calling function or the main function.

[0060] Processes described herein, such as with respect to Figure 2A , Figure 2B and Figure 3-Figure 18The described processes) can be implemented in software (e.g., code, instructions, programs) executed by one or more processing units (e.g., processor cores), hardware, or combinations thereof. The software can be stored in a memory (e.g., on a memory device, on a non-transitory computer-readable storage medium). In some embodiments, the processes depicted in the flowcharts herein can be implemented by a computing system of an access management system (e.g., the access management system 140 of Figure 1 The particular series of processing steps in the present disclosure are not intended to be limiting. Other orders of steps can also be performed according to alternative embodiments. For example, alternative embodiments of the present disclosure can perform the steps outlined above in a different order. Also, individual steps illustrated in the figures can include multiple sub-steps that can be performed in various orders as appropriate for the individual step. Additionally, depending on the particular application, additional steps can be added or removed. One of ordinary skill in the art will recognize many variations, modifications, and alternatives.

[0061] In an aspect of some embodiments, Figure 2A , Figure 2B and Figure 3-Figure 18 Each of the processes depicted in the figures can be performed by one or more processing units. A processing unit can include one or more processors (including single core or multicore processors), one or more processor cores, or combinations thereof. In some embodiments, a processing unit can include one or more special-purpose co-processors (such as graphics processors, digital signal processors (DSPs), etc.). In some embodiments, some or all of the processing units can be implemented using custom circuitry (such as application-specific integrated circuitry (ASICs) or field-programmable gate arrays (FPGAs)).

[0062] Turning now to Figure 2A According to embodiments, an example of operations 200 that can be used to enable passwordless authentication of multi-factor authentication is shown. The operations described with reference to the access management system 140 can be implemented by the access manager 142 or multiple modules or blocks in the access management system 140.

[0063] Beginning at step 210, a user can operate a client 202 (e.g., a computing device 114) to access or download an application (e.g., a mobile authenticator application) from a source (e.g., an application store 180). The source can be part of the access management system 140. The application can be used for the client 202 to register with the access management system 140 for passwordless authentication. After registering the client 202, the application can be used for the user’s passwordless authentication.

[0064] As part of the authentication process, the user may need to register the clients 202 and 204 with the access management system 140. When using the application, the application may request the user to provide credential information to authenticate the user. At step 212, the credential information may be sent to the access management system 140. At step 214, the access management system 140 may authenticate the user and, once authenticated, may store access data indicating the user's authentication. At step 216, the access management system 140 may send security or access information (e.g., encryption keys) to the client 202. This information may include a key pair comprising a private key and a public key, thereby enabling the client 202 to encrypt communications from the access management system 140. Subsequent communications between the access management system 140 and the client 202 will be encrypted with these keys to ensure security.

[0065] At step 218, the user can operate the application to configure the application for passwordless authentication. The client 202 can be operated to register security information for multi-factor authentication. In order to use the application for passwordless authentication, the security information can be used to configure additional security. Security information (such as an access code (e.g., a 4 to 6 digit personal identification number (PIN)) and biometric data for biometric identification (e.g., fingerprint)) can be registered for accessing the application. For each subsequent use of the application, the user may have to provide security information to ensure the additional security of passwordless authentication using a trusted device.

[0066] At step 220, a user may operate a different client (client 204 (e.g., a desktop computer such as computing device 104)) to access a resource protected by access management system 140. This access may be based on authentication of the user who is to access the resource. The resource may be accessed through an interface (such as a graphical user interface) presented in an application (e.g., a browser). To determine access, the application of access management system 140 may facilitate an authentication process. Authentication may include registering other devices as trusted devices for passwordless authentication. The application may provide interactive controls to facilitate registration of devices. The registration process may include authenticating the user using single-factor or multi-factor authentication. At step 220, the user may interact with an application provided by access management system 140 for managing access to the resource. Before a resource can be accessed, the application may be presented with an interface (e.g., a portal) for access. An example of an interface is shown in FIG. Figure 3 As shown in the following example. Figure 10 The interface shown in is provided. This interface enables the user to request registration of the device for future authentication.

[0067] Client 204 can be a device that facilitates the registration of other trusted devices (such as client 202). Client 204 can provide an interface to enable clients 202, 204 to be registered for password-free authentication. At step 220, client 204 can send a request to be registered as a trusted device to access management system 140. In some embodiments, the request can include information about client 204 (such as device information or information about the application through which the resource is requested). This information can be determined based on factors such as browser version, plug-ins, etc. The request can include the user's geographic location based on the browser's IP address. This information can be determined by client 204 and / or the application. The request can indicate information about the user requesting to register the device.

[0068] In at least one embodiment, when a user requests access to register a device, access management system 140 may determine the user's authentication to register client 202 at step 222. Access management system 140 may determine whether the user is authenticated by access management system 140 and, if so, whether the permitted access includes registration of a device for passwordless authentication. In some embodiments, access management system 140 may also determine whether the device for which authentication is requested is already registered. Access management system 140 may also use information from the request at step 220 to determine whether any device corresponds to the device requested for registration. In some embodiments, access management system 140 may determine whether the location information in the request matches information about the user, such as a location associated with the user's visit. Information about the user may be obtained from an authoritative source accessible to the access management system, such as a human resources system. Access management system 140 may determine the device / geolocation of the device to be registered and verify whether it is one of the user's trusted devices / geolocations from a repository of access management system 140. If the user has previously authenticated using a device, then the device is trusted. In this example, client 204 is not trusted, so access management system 140 may determine that the device is not authenticated.

[0069] At step 224, upon determining that the user is not authenticated at the client 204, the access management system 140 may send a request for credential information ("credentials") to authenticate the user and thereby register the device. The client 204 may prompt the user at the application to request the credential information based on the request from the access management system 140. In some embodiments, the credential information may be automatically provided to the access management system 140 as part of the SSO process implemented by the access management system 140. At step 226, the user may provide the credential information to the application, which sends the credential information to the access management system 140 to authenticate the user.

[0070] At step 228, the access management system 140 may verify the credential information to determine whether it matches the credential information previously stored when creating access for the user. In some embodiments, the access management system 140 may determine whether the client 204 from which the registration request was initiated is a trusted device from which the user can register other devices. The access management system 140 may determine whether the client 204 is found in the user's trusted list based on geographic location or some other information. Upon determining that the device is found in the list, the access management system 140 may not challenge the user for credentials and may proceed to step 242. Upon determining that the client 204 is not found in the trusted list, the access management system 140 will later challenge the user for access information (e.g., a one-time PIN or password). The access information may be temporary, such that it remains valid based on one or more criteria (such as usage, time, or a combination thereof).

[0071] At step 230, the access management system 140 may request the client 204 to provide temporary access information. The request for the temporary information may be sent before or after the temporary access information is generated. At step 232, the temporary access information may be generated by the access management system 140. In some embodiments, the access management system 140 may send a request to an application at the client 204 to request that the application generate the temporary access information. In some embodiments, the temporary access information is restricted in use based on one or more criteria. The access management system 140 may request that another device (e.g., the client 202) that is registered with the access management system 140 generate the temporary access information. The access management system 140 may generate the temporary access information and then send it to the client 202 in an encrypted form that enables the client 202 to decrypt the information using security information that was previously provided when the application on the client 202 was registered.

[0072] In some embodiments, at step 230, access management system 140 may request that the application initiate authentication using temporary access information. The application at client 204 may prompt the user, using an interface, to select an option for receiving temporary access information. Step 232 may be performed based on the selected option. The application may communicate with access management system 140 to provide options for temporary access information. At step 232, temporary access information may be provided using various techniques to ensure secure access for registering the device as a trusted device. These techniques include sending the temporary access information to the user's device (e.g., client 202), the user's email account, a device associated with a phone number (e.g., a short messaging system message), or to the device via an application (such as an application downloaded at client 202). Information about the user may be obtained from an authoritative source (such as a human resources system). At step 234, client 202 may be operated to access the temporary access information. If the user is a legitimate user, they will be able to authenticate themselves to the application at client 202 using their fingerprint. The application at client 202 may provide the temporary access information. The temporary access information may be generated at client 202 or received from access management system 140. The temporary access information may be accessed via email using the client 202 or an application that provides access to the email to which the temporary access information was sent.

[0073] At step 236, the client 204 may be operable to retrieve temporary access information, which may be accessible from the client 204. An application at the client 204 may provide an interface for receiving the temporary access information. The user may operate the client 204 to provide the temporary access information requested by the access management system 140. This information may be provided along with other information identifying the client 204 as a trusted device / location from which access to the access management system 140 is permitted.

[0074] At step 238, the application on the client 204 can send the temporary access information to the access management system 140. At 240, the access management system 140 can verify the temporary access information to determine that the temporary access information is correct as generated and valid according to the criteria defined for temporary access information. If it is determined that the temporary access information does not match previously generated temporary access information, access to the registered client 204 can be denied at the application. If the temporary access information is determined to be correct, the access management system 140 can store the information about the client 204 by adding it to a trusted list. The geographic location can be saved along with the information.

[0075] In some embodiments, access management system 140 can send security information to a device associated with a user authenticated by client 204 that is registered as a new trusted device. The security information can be sent to client 202. The device associated with the user can be identified based on information about the user obtained from an authoritative source. The security information can be sent before client 204 is determined to be a trusted device.

[0076] At step 242, upon determining that the temporary access information is verified, the access management system 140 may send a message to the client 204 indicating that the user is authenticated to access the resource. The application at the client 204 may change the interface to enable the user to access the resource and register the device for passwordless authentication. The access management system 140 may send information that the user has been authenticated (such as access to the resource and other information about the device and location registered for the user).

[0077] Figure 2B An example of operations 250 for passwordless authentication is illustrated in accordance with some embodiments. Figure 2B Upon successful authentication of the user, the client 204 may provide the user with access to the application. Figure 2A The exposed operations are authenticated to access the application. Figure 2B At step 260, the client 204 may provide an interface to enable the user to log out or end the session for accessing the application. The user may interact with the interface to terminate the access session through the application. At step 262, the user may again request access to features and resources through the application. The user may interact with the application to request access. At 304, the client 204 may send a request for access. The request may include information about the client 204 (e.g., device information) and / or geographic location information. This information may be retrieved using the techniques disclosed herein (such as reference 204). Figure 2A described technique) to obtain.

[0078] At step 264, access management system 140 can determine whether the user is authenticated for access using the application. Access management system 140 can determine that client 204 is a trusted device based on the information included in the request. The information in the request can be compared with information stored by the access management system for trusted devices registered for the user. Because client 204 is registered on a trusted list based on a previous registration process by performing operation 200, the access management system can determine that client 204 is a trusted device.

[0079] At step 264, upon determining that the device is not trusted, the access management system 140 may deny access to the client 204. The access management system 140 may initiate an authentication process (such as referring to Figure 2AAuthentication process described in ). Upon determining that the client 204 is a registered trusted device, the access management system 140 may generate security data. The security data may be audio data, video data, image data, other types of data, other perceptible data that can be recognized or captured by the device, or a combination thereof. In at least one embodiment, the security data is generated as image data (e.g., a Quick Response (QR) code). The security data may be generated with information that implements a password-free authentication process. For example, the security data may be generated with security information (e.g., an encryption key) that is unique to the user being provided access. The information may be generated based on information that is unique to or relevant to the user (e.g., date of birth, phone number, personal information, etc.). The information may be a token. The information may be encrypted using security information (e.g., an encryption key). The information may be encrypted using one or more encryption techniques known in the art. The security data may include a unique request id, which will be encrypted using an encryption key previously sent to the client 202 operated by the user. The security data may be decrypted by an application on a device associated with the user that has access rights (such as the client 202). The secure data serves as a convenient way to transfer personal information about a user from one device (eg, client 204 ) to another device (eg, client 202 ).

[0080] In some embodiments, because client 204 is a trusted device (e.g., identified as a device authenticating the user based on multi-factor authentication), at step 266, the access management system may send security information to client 204 for an application at client 204 to generate security data. The security information may be sent to other devices registered with the access management system via an application (e.g., a mobile authenticator application). Upon determining that client 204 is a trusted device, the security information may be sent to client 202. A mobile device (such as client 202) may be configured to perform passwordless authentication by decrypting information within the security data using the security information. Client 202 may be associated with the user based on information obtained from an authoritative source. To prevent unauthorized access at client 204, security data may be sent along with the security information to prevent client 202 from obtaining the security information. The security information within the security data may be encrypted using an encryption key for the user. The encryption key may be sent to a device (such as client 202) registered with access management system 140 for mobile authentication via passwordless authentication. The encryption key may be used to read and / or decrypt the security information within the security data.

[0081] At step 268, the client 204 may present the security data at the client 204. The security data may be presented in an application that provides an interface to the access management system 140. For example, an application provided by the access management system 140 may display the security data at the client 204. The security data may be presented based on one or more criteria. The criteria may be configurable to limit the security data to be displayed for a temporary time period (such as 60-90 seconds) within which a legitimate (e.g., authorized) user may be expected to complete a passwordless authentication. This reduces the time available for a fraudster to access security data codes intended for authorized users. The secure presentation may prompt the user to operate another device (e.g., client 202) registered with the access management as a trusted device for passwordless authentication.

[0082] At step 270, the access management system may send security data to client 202. Client 202 may be a device registered with the access management system as a user's device. The device may include an application for enabling passwordless authentication. The security data may be different from the security data sent at step 266. The security data may include security information to enable client 202 to read (e.g., decrypt) the security data presented at client 204.

[0083] At step 272, the user can operate the client 202 to obtain access to the client 202. One or more authentication technologies can be used to control access. Multi-factor authentication can be used to improve the security of using the client 202 for passwordless authentication. These authentication technologies can include biometric authentication and other input-driven authentication technologies. The client 202 can include an application provided by the access management system 140 for authenticating via the access management system 140. The application can use one or more authentication technologies to enable access to the application. The user authenticates himself locally in the application, and then enables the features of the application to read the security data sent to the client 204. The application can be configured to utilize one or more functions on the device (e.g., camera, microphone or video recorder) to capture the security data provided at the client. In some embodiments, the security data sent at step 270 can be sent when the user obtains access to the application at step 272. The application can communicate with the access management system 140 to authenticate the user. Upon successful authentication, the access management system 140 can send the security data.

[0084] Upon obtaining access rights at the client 202, the user operates the client 202 (specifically, the application) at step 274. The client 202 may be operated to use one of its functions (e.g., a camera) to read or capture the security data displayed at step 268. For example, the client 202 may be operated to use its camera to capture security data (e.g., a QR code) encrypted using security information provided to the client 204 by the access management system 140.

[0085] At step 276, client 202 is operated to process the security data obtained at step 274. In at least one embodiment, the application on client 202 can be operated to capture the security data presented by client 204 at step 268. If client 202 is registered with access management system 140 for the user, it can read the security information in the captured security data. Client 202 may have the security data obtained from access management system 140. The application can use this security data to read the security information from the security data captured at step 274. Because the application will be able to decrypt the security data using the security data it obtained from access management system 140, the application can display the request details to the user within the application and present one or more interactive elements for confirming receipt of the security data. Upon user confirmation, the application can send a secure communication back to access management system 140 at step 278.

[0086] At step 276, the application may perform operations to obtain data from the secure data captured from the client 204. The data may be obtained by decrypting the secure data provided by the access management system. In some embodiments, the secure data obtained from the client 204 may be sent to the access management system 140 for decryption.

[0087] At step 278, the application on client 202 may communicate with access management system 140. The secure communication may be sent along with information about the security data captured from client 204. The information may include the security data obtained from client 204. For example, the application may send security information determined by decrypting the security data obtained from client 204. The communication may include authentication information of the user. If it is determined that the application has authenticated the user to access management system 140, the secure communication may not include authentication information.

[0088] At step 280, the access management system 140 can verify access based on the communication received from the client 202. The access management system can verify that the information received from the client 202 (e.g., the request identifier or the security key), as obtained from the security data captured by the client 204, matches the information in the security data sent to the client 204 at step 266. The information can be compared to determine whether they match. The information can be a decrypted form of the information included in the security data. The decrypted form of the information can be compared to the information decrypted from the information encrypted in the security data. The information can be associated with criteria for the security data generated by the access management system 140, so that the criteria are evaluated to determine whether the security information was received from the client 202 that meets the criteria (e.g., time).

[0089] At step 280, upon determining that the information received from client 202 at step 278 does not match the information in the previously generated security data, access management system 140 may deny access to client 204. The user may operate client 202 to request that access management system 140 send new security data to client 202. Denied access may include access to a resource. Access management system 140 may communicate with client 204 to send the new security data. The operations disclosed herein may be repeated to enable another attempt at passwordless authentication. The number of attempts as a criterion for a desired level of secure access may be configurable.

[0090] Upon determining that the information received from the client 202 at step 278 matches information in the previously generated security data, the access management system 140 may grant access to the client 204 .

[0091] At step 282, access management system 140 can communicate with client 202 to send information about whether user access is allowed based on the communication sent at step 278. The information can be a notification about whether the user is allowed access. At step 284, client 202 can provide the information.

[0092] At step 286, the access management system 140 may communicate with the client 204 to enable access to the resource. The access management system 140 may send information to notify the application on the client 204 to enable access to the resource. The information may include information about accessible resources or information for displaying options to enable access. At step 288, the application on the client 204 may enable access to the resource. For example, the application may provide an interface (e.g., a portal) for accessing different resources. The resources may be provided by one or more resource management systems.

[0093] As mentioned above, reference Figure 2A and Figure 2B The disclosed operations enable passwordless authentication when registering a device as trusted with the access management system 140. A user can authenticate at a trusted device by providing authentication at a mobile device (e.g., client 202) and use the mobile device to capture information from the trusted device. If a registered user is unable to capture security data within a configurable time period, the access management system 140 can generate new security data upon request from the client 202. However, the access management system 140 also maintains a retry counter. If a user attempts to make more than a maximum number of configured retry attempts to generate security data, the access management system 140 can lock or prevent the user's access to prevent fraud.

[0094] Alternatively, the access management system 140 can be configured to challenge the user at the mobile device (e.g., client 202) using multi-factor authentication. This can allow three factors—something the user possesses (his smartphone), something the user has (e.g., a fingerprint), and something the user knows (e.g., a personal access code)—to provide authentication. While the user may have to remember the security information, the security information does not need to be as strong as a password because it is used in conjunction with other factors at the mobile device and the mobile device is used to capture information from a trusted device.

[0095] Since password-free authentication based on secure data can be implemented from the legitimate user's trusted device, the fraudster cannot use it from any other device or location. If the fraudster manages to access resources from the legitimate user's device and location, he will likely not be able to capture secure data using the application in client 202 because the application may not have the security information to decrypt the secure data intended for the legitimate user. If the fraudster manages to access resources from the legitimate user's device and location and also steals the legitimate user's smartphone, he will still not be able to continue because the application on client 204 may require the legitimate user's fingerprint to continue capturing secure data.

[0096] III. Interface for passwordless authentication

[0097] Figure 3-Figure 18 An interface, such as a graphical user interface (GUI), for multi-factor authentication in an access management system is illustrated according to an embodiment. Figure 3-Figure 18 The GUI in can be displayed as part of an access portal (such as a website or application). Figure 3-Figure 18 Each GUI in can be displayed in an application on the device. Figure 3-Figure 18 Each GUI in can be displayed by an access management application that manages access to one or more resources. Each GUI can be accessed from the access management system 140 or can be part of an application installed on a client for communicating with the access management system 140.

[0098] Now turn Figure 3 , Figure 3 3 is a GUI for receiving credential information (eg, a username and password). The GUI 300 may be presented at a computing device 104 or client 204 operated by a user. The GUI 300 may be presented in an application (eg, a browser).

[0099] GUI 300 may be presented when a user first operates a client device to obtain access to a resource by authenticating through access management system 140. GUI 300 may be presented when a user requests access to a resource. GUI 300 may be presented as part of an application (e.g., an "OOW access portal") that supports access management system 140, such as an access portal application or website. GUI 300 may be presented as part of one or more authentication processes for registering a client device for a user. Any type of authentication process may be implemented in GUI 300.

[0100] GUI 300 may include one or more interactive elements to provide input (e.g., credential information) for the authentication process. Interactive element 302 in GUI 300 may receive input for user identification (e.g., "username"). Interactive element 304 in GUI 300 may receive input for credentials (e.g., "password"). Interactive element 306 in the GUI may be interactive to submit a request for authentication using the input received in the interactive element.

[0101] When interacting with interactive element 306, credential information entered into GUI 300 may be sent from computing device 104 to access management system 140 for authentication. This credential information may be credential information that the user has previously provided to register with access management system 140.

[0102] Figure 4 and Figure 5 Illustrated is a GUI for an authentication process for multi-factor authentication of a user, for registering a device as a trusted device for passwordless authentication. Figure 4 GUI 400 or Figure 5Each of the GUIs 500 may present one or more interactive elements for selecting an option to receive security information. The security information may be associated with one or more criteria, such that the security information is temporarily available for authentication. The GUI 400 may display an interactive area 402 having one or more interactive elements. In an application at a mobile device (e.g., a mobile authenticator application), the interactive element 402 may enable a user to select an option for a device (e.g., computing device 104 or client 204) to receive security information (e.g., a one-time password) at a mobile device (e.g., device 114 or client 202). Interaction with the interactive element 406 may cause the device to request the access management system 140 to request the mobile device to provide the security information. The GUI 500 may display an interactive area 502 having one or more interactive elements (e.g., interactive elements 510, 512, 514) for selecting different options for obtaining security information. The interactive element 510 may correspond to an option for receiving security information at an application on the mobile device. Interactive element 512 may correspond to an option to receive security information at a mobile device using a short message service (SMS) (such as a text message) and a location associated with the user (e.g., a phone number or email address). Interactive element 514 may correspond to an option to receive security information at an email address associated with the user. Interaction with interactive element 516 may cause the device to request security information corresponding to the selected option. By sending the security information to another device or location associated with the user, secure access information is protected from unauthorized users.

[0103] Figure 6 An example of a device 602 (e.g., computing device 114 or client 202) that enables another device (e.g., computing device 104 or client 204) to be registered as a trusted device is illustrated. Device 602 is shown as having a different GUI of an application (e.g., a mobile authenticator application) for access management system 140. The application can be used to register the device (e.g., client 204) as a trusted device and / or can be used for passwordless authentication of a user at the trusted device after registration. Device 602 can provide one or more authentication processes to access features of the application. The authentication process can include multi-factor authentication, which can utilize the authentication process on device 602. For example, device 602 can provide an interface with prompt 604 that requests biometric (e.g., fingerprint) input for authentication. Interactive element 606 can be used to provide biometric input.

[0104] Device 602 may provide an interface having element 622 that provides security information for registering different devices with access management system 140. As disclosed herein, security information may be provided by the access management system or may be generated by an application at device 602. Security information may be displayed based on one or more criteria (e.g., time) for using the security information. Interactive element 624 may enable a user to request operation of device 602 to capture security data displayed at a device to be registered with access management system 140.

[0105] Figure 7 and Figure 8 An example of a device 700 for providing an application (e.g., providing a mobile authenticator application for authenticating a user to access an application's GUI) is illustrated. Figure 6 , the application may support one or more authentication processes, such as entry of credential information (e.g., a code or personal identification number) and / or biometric input. The authentication process may be determined based on information provided to the access management system 140 for registering the user for authentication with the application. The credential information and biometric input may have been previously registered for the application. The application may provide an interactive element 702 for receiving entry of credential information. The application may provide an interactive element 704 for receiving biometric input. The application may determine authentication based on the input. Figure 7 The example in shows successful authentication 706 based on input to either of the interactive elements 702 , 704 . Figure 8 The example in shows an unsuccessful authentication 806 based on user input to either of the interactive elements 702, 704. In some embodiments, the authentication process may prevent the application from being used for passwordless authentication if it determines that the authentication was unsuccessful. Figure 8 A notification is shown that the user cannot continue to capture secure data using device 700.

[0106] Figure 9 GUIs on multiple devices are shown (a device (e.g., client 204) presenting GUI 900 to be registered as a trusted device, and a device 950 to be used as a mobile authenticator for registering the device). GUI 900 may include an interactive area 902 for assisting with the authentication process for a multi-factor authentication process. For example, Figure 3 GUI 900 is displayed for assisting the authentication process after the initial authentication process shown in FIG. Interactive area 902 may include interactive elements for assisting the authentication process of a registered device (e.g., client 204). Interactive element 904 may be interactive to receive security information (such as a Figure 4 or Figure 5 Enter a one-time password) by selecting one of the options provided in . Figure 9As shown in FIG, security information can be received as an option at an application (e.g., a mobile authenticator application) at device 950. Device 950 shows something similar to Figure 6 . The device 950 may provide a GUI having an interactive element 952 indicating security information. The GUI may provide an interactive element 954 for requesting the capture of security data from the GUI 900. The interactive element 906 in the GUI 900 may be interactive to enable a user to specify whether the device / location is to be registered as a trusted device / location. Interactive elements 908 and 910 may receive input for configuring information (e.g., name and location) for the trusted device / location. Interactive element 912 may receive input for requesting authentication of the secondary authentication process. Interactive element 914 may receive input for changing the GUI to present a Figure 4 and Figure 5 Input of options for assisting authentication disclosed in the GUI in .

[0107] Figure 10 1000 is illustrated for an application that provides access to one or more resources when a user is authenticated with an access management system 140. The authentication may be performed as a multi-factor authentication process for registering a client device as a trusted device / location. The GUI 1000 may provide interactive elements 1010, 1012, 1014, 1016, 1018 for each resource that may be accessed upon successful authentication. The GUI 1000 may include an interactive element 1002 that controls one or more settings for access management. Interaction with the interactive element 1002 may enable the user to: Figure 11 and Figure 12 Any GUI among the GUIs is rendered at the device.

[0108] Figure 11GUI 1100 is illustrated that displays information about trusted devices and trusted locations verified by access management system 140. GUI 1100 may include interactive elements for configuring these locations and / or devices. GUI 1100 may include an interactive element for each device and each location registered with the access management system as trusted. For example, for each respective different device registered with access management system 140, device 1 (e.g., "My Desktop - Firefox"), device 2 (e.g., "My Work iPhone"), and device 3 (e.g., "Work Desktop"), GUI 1100 may include interactive elements 1102, 1104, and 1106. Each of these devices may be associated with one or more trusted locations. GUI 1100 may include interactive elements 1108, 1110, and 1112 for each respective location (e.g., "Acme - London"), location (e.g., "Home"), and location (e.g., "Acme - HQ"). Each interactive element may be interactive so that an interactive GUI (e.g., "Acme - London") is displayed. Figure 12 1100 to configure settings for trusted devices and / or locations. The GUI 1100 may include an interactive element 1120 (“Save”) to configure saving settings using the GUI 1100.

[0109] Figure 12 1 illustrates a GUI 1200 that displays information about trusted devices and trusted locations verified by the access management system 140. Figure 11 , the GUI 1200 may include one or more interactive elements 1202 for configuring being registered as a trusted device. The GUI 1200 may include one or more interactive elements 1204 for configuring being registered as a trusted location. In some embodiments, the GUI 1200 may include one or more interactive elements 1206 to configure settings for managing access to trusted devices and locations. These settings may include one or more properties (such as challenge questions and answers). The GUI 1200 may include one or more interactive elements 1208 to configure settings for one or more authentication processes (such as second factor authentication). Settings for secondary factor authentication may include preferences for receiving security information (e.g., a one-time password) and criteria associated with these preferences.

[0110] When a user is authenticated at a device or location (such as any registered device or location), the Figure 11 and Figure 12 The device or location shown in .

[0111] Figure 13The GUI 1300 is shown as a device that can be displayed on a device that is registered as trusted. The GUI 1300 can be displayed when a user requests to terminate (eg, log out or exit) a service session after authentication. The GUI 1300 can be displayed on a device that is registered as trusted. Figure 10-12 13. The GUI 1300 may include an interactive element 1302 requesting access management to terminate the access session after authentication. The GUI 1300 may display an indication 1304 upon successful completion of the termination of the access session.

[0112] Figure 14 GUI 1400 is illustrated at a device registered as a trusted device with the access management system 140. After a user terminates an access session (such as Figure 13 ), the user may be presented with an option to perform a passwordless authentication from the same device that was registered during a previous authentication. When the device is determined by the access management system 140 to be registered as a trusted device or to be located in a trusted location, the GUI 1400 may be presented in an application at the device. The GUI 1400 may provide security data for passwordless authentication. As explained above, the security data may include security information. Security data 1402 (e.g., a QR code) may be presented at the device to enable another registered device (e.g., mobile device 1450) to be used for passwordless authentication. The device 1450 may be used to capture the security data.

[0113] Device 1450 can be registered with access management system 140. An application on device 1450 (e.g., a mobile authenticator application) can request that the user authenticate to use the application. This authentication can include techniques disclosed herein, such as those described in

[1450] . Figure 7 For example, device 1450 may provide an interface for authentication, including an interactive element 1452 for receiving input (e.g., a personal identification code) and an interactive element 1454 for receiving biometric input. Authentication may include communication with access management system 140. This authentication provides an additional level of security for passwordless authentication.

[0114] Upon successful authentication of the user, the application may be used to capture security data 1402, which is presented in the GUI 1400. For example, the application may enable operation of a camera of the device 1450 to capture the security data.

[0115] Figure 15 GUI 1500, Figure 16 GUI 1600 and Figure 17 GUI 1700 is similar to GUI 1400, presenting security data 1502, 1602, 1702 at a device that has been registered as a trusted device. Figure 15 Equipment 1550, Figure 16 Device 1650 and Figure 17 The device 1750 may be a device similar to the device 1450 used as a mobile authenticator for passwordless authentication. Figure 15 , an application on device 1550 (e.g., device 1450) may change its display to show captured security data 1552 and status information about the processing of the security data to determine whether the security data can be accessed by a user authenticated at device 1450. As disclosed herein, a mobile device (such as device 1550) may operate as an authenticator to process security data to determine whether an application can decrypt information in the security data. Device 1550 may decrypt the security data using security information (e.g., an encryption key) provided by access management system 140. The device may send the decrypted security data to access management system 140 for verification that it matches security information included in security data previously generated by access management system 140. Device 1550 may display a notification 1554 ("Scan Successful") when it determines that the security data was successfully decrypted (e.g., upon receiving notification thereof from access management system 140).

[0116] exist Figure 16 In another example, device 1650 may display a notification 1652 that the secure data was successfully read and decrypted. The notification may indicate that a trusted device presenting the secure data may be enabled to access the resource. Figure 17 In another example, upon determining that the security data captured from the GUI 1700 cannot be decrypted, the device 1750 may display a notification 1752 ("Invalid QR Code") that the security data cannot be decrypted.

[0117] Figure 18 An example of a device 1800 used as a mobile authenticator for passwordless authentication is illustrated. An interface 1802 can be presented as part of an application (e.g., a mobile authenticator application). When the access management system 140 receives a request from a trusted device to access a resource based on passwordless authentication, the interface 1802 can indicate a notification. The interface 1802 can include an interactive element 1804 that allows the request and can include an interactive element 1806 that denies the request. Interaction with these interactive elements can enable the application to determine whether the user wants to participate in passwordless authentication. The interface for the mobile authentication application on the mobile device disclosed herein can be presented after the user "allows" the request for passwordless authentication.

[0118] Figure 19 A flowchart 1900 is shown for a process for passwordless authentication. The process may be performed by Figure 1 This can be accomplished by the access management system 140 of the . This process can include registering the device / location as trusted before enabling password-free authentication.

[0119] Flowchart 1900 may begin at step 1902 by receiving a request for access (e.g., a first request) from a user on a device (e.g., a first device). The request may be for access to a resource or may be an explicit request to register the first device for passwordless authentication. Access may be based on authentication of the user at the device using one or more authentication processes (such as multi-factor authentication). If this is the first time the user is requesting access from the first device, then the user may be determined to be authenticated.

[0120] At step 1904, a determination is made as to whether the user is authenticated for the request. The request may include information about the first device and / or geographic location information about the first device. This information may be used to determine whether the user associated with the first device is authenticated. At step 1906, a determination of user authentication is made for the user at the first device. The authentication may be determined based on a previous authentication, and if there is no previous authentication, one or more authentication processes may be performed for the user at the first device. The access management system 140 may send information to the first device to cause the application to prompt the user for input corresponding to each of the one or more authentication processes. Determining authentication may include an authentication process whereby security information (e.g., a one-time password) associated with a criterion (e.g., time) is sent to one of a plurality of options for receiving security information. Determining authentication may include receiving credential information or other information (e.g., security information) for verification to determine authentication. Determining authentication may include communicating with a second device operated by the user as a mobile authenticator, which may provide security information.

[0121] Access may be permitted based on a determination that the user is authenticated according to one or more authentication processes. Access may be terminated. Access may be terminated upon receiving a request from the first device to terminate (e.g., log out) a session established to enable the user to access one or more resources. Access may be terminated upon satisfying one or more criteria defining access.

[0122] At step 1908, the first device is identified as a trusted device or associated with a trusted location. Upon determining that the user is authenticated at the first device, information about the first device and / or its location may be obtained from the first device during communication with the first device for use in determining authentication. This information may be associated with the user requesting access managed by the access management system. The first device and / or its location may be identified as a trusted source for access, thereby allowing passwordless authentication upon subsequent requests from that device / location.

[0123] At step 1910, a request for access by a user (e.g., a second request) can be received from the first device. The second request can be received after the user has previously authenticated with the access management system. For example, the second request can be received after the access session has terminated. The request can include information about the first device or its location.

[0124] At step 1912, a determination is made that the first device is a trusted device or location based on the information about the device and / or its location. The information can be identified as being associated with the previous user’s authentication. As such, the access management system can determine that the user is requesting access from a trusted device / location.

[0125] At step 1914, security data (e.g., a QR code) for enabling passwordless authentication is generated due to the request being from a trusted device or location. The security data can be generated to include information. The information can be information specific to the user (such as identifying information about the user). The security data can have encrypted data (such as encrypted information) embedded with it. The data can be encrypted using one or more known encryption techniques. The data can be encrypted using an encryption key. The security data can be associated with one or more criteria (e.g., a time period) to further ensure secure use according to the criteria.

[0126] At step 1916, the encrypted information (e.g., the encryption key) can be sent to a second device of the user that is registered with the access management system. The second device is different from the first device. The second device can be a mobile device. The user can have authenticated with the access management system using an application (e.g., a mobile authenticator application) on the second device. Information about the second device can be associated with the user. The second device can use the encryption key to decrypt the information embedded in the security data.

[0127] At step 1918, the security data can be sent to the first device. The first device can present (e.g., display) the security data at the first device. The security data can be presented in a manner sufficient for the user to perceive the security data based on the type of data.

[0128] At step 1920, data can be received from the second device. The second device can capture the security data presented by the first device. The second device can use the encryption key to decrypt the security information in the security data captured from the first device. The decrypted security information can be the data received from the second device.

[0129] At step 1922, a determination is made as to whether the data received from the second device matches the data in unencrypted form embedded in the security data generated at step 1914. The determination may include determining whether the data includes information (e.g., related to the user) included in the data embedded in the security data. Upon determining that the data received from the second device matches the data embedded in the generated security data, the user may be authenticated for access. The data may match when the data includes information that was originally included in the encrypted data in the security data. Upon determining that the data received from the second device does not match the data embedded in the generated security data, the user may not be authenticated for access. Upon determining that the data includes information (e.g., related to the user) included in the data embedded in the security data, access to the resource may be enabled by the access management system.

[0130] At step 1924, based on the authentication determined for the user at step 1922, a notification is sent to the first device indicating whether the user is allowed access. The notification can be sent along with other information about available resources, or separately. If the user is authenticated to access those resources, then the information can be used by the first device to access the resources. An application at the first device (e.g., a portal on a website) can allow the user to access resources through the application at the first device.

[0131] At step 1926, a notification is sent to the second device indicating whether the user is allowed access based on the authentication determined for the user at step 1922. An application on the second device may present the notification to enable the user to determine whether passwordless authentication allows user access.

[0132] Flowchart 1900 may end at step 1928 .

[0133] Figure 20 A flowchart 2000 is shown illustrating a process for passwordless authentication. The process may be performed by a device that is registered as a trusted device or associated with a trusted location (e.g., Figure 1 The process may include registering the device / location as trusted before enabling passwordless authentication.

[0134] At step 2002, a request for access from a user is received at a first device. The request may be received through an interface of an application at the first device. The interface may be provided by the access management system 140 as part of a portal or application. The request may be for access to a resource or for registering the first device as a trusted device.

[0135] At step 2004, authentication of the user is determined based on one or more authentication processes defined by the access management system for the access. The authentication process may be a reference to Figure 3-Figure 9 Disclosed authentication process. The authentication process may include a user providing input (such as authentication credentials) and security information provided by the access management system. The authentication process(es) may be implemented with the aid of a second device (such as a mobile device having an application (e.g., a mobile authenticator application) that provides information for facilitating the authentication process(es). The authentication process(es) may include receiving input at the first device via an interface and communicating with the access management system 140 to verify the input for the authentication process. The authentication process may be implemented to register the first device as a trusted device or at a trusted location.

[0136] At step 2006, the first device is allowed access as a trusted device or trusted location. The first device may receive information from the access management system indicating that the first device is trusted based on the user's authentication at step 2004. As such, the first device may allow the user to access the resource based on the information received from the access management system 140.

[0137] At step 2008, the first device receives a second request from the user to access the first device. The second request may be received after the user has previously authenticated to the access management system. For example, the second request may be received after the access session has been terminated.

[0138] At step 2010, the first device may send a request to the access management system after determining that the user has authenticated as a trusted device for access. In some embodiments, the first device may send a second request, and the access management system 140 may send information indicating whether the first device is a trusted device and whether passwordless authentication allows access. The request may include information about the first device or its location.

[0139] At step 2012, security data is received from the access management system. The access management system may generate the security data upon determining that the first device is a trusted device or is at a trusted location. The security data may be generated by the first device upon receiving information (e.g., security information). The security data may be embedded with encrypted data, which is encrypted based on information accessible to the access management system 140.

[0140] At step 2014, the security data is presented in the format in which the security data was generated or received. The security data can be captured by another device, such as a second device registered with the access management system 140 for the user. The second device can include an application (e.g., a mobile authenticator application) that can capture the security data presented at the first device. The second device can capture the security data, or a portion thereof, and then send the data to the access management system. Data can be obtained from the captured security data. The data can be generated based on decryption of encrypted data in the security data. The access management system can process the data received from the second device to determine whether the data received from the second device matches the data embedded in the security data received by the first device from the access management system 140.

[0141] At step 2016, the first device may receive a notification from the access management system. The notification may indicate whether the user is allowed access based on the authentication determined for the user. The notification may be sent along with other information about accessible resources, or separately therefrom. If the user is authenticated to access the resources, then the information may be used by the first device to access the resources. An application at the first device (e.g., a portal on a website) may allow the user to access the resources through the application at the first device. Based on the security data captured by the second device and the data transmitted to the access management system for the access management system to determine for the user whether to allow the first device to access, the user may be allowed access through passwordless authentication.

[0142] At step 2018, the first device may generate an interface (e.g., a GUI) for displaying information about the notification. The information may indicate whether the user is allowed access based on the authentication determined for the user. The interface may be Figure 10 , is used to enable access to a resource when the user is allowed access. When the notification indicates that access is not allowed, the interface may indicate a message that access is not allowed.

[0143] Flowchart 2000 may end at step 2020 .

[0144] Figure 21 A simplified diagram of a distributed system 2100 for implementing an embodiment is depicted. In the illustrated embodiment, the distributed system 2100 includes one or more client computing devices 2102, 2104, 2106, and 2108 configured to execute and operate client applications (such as web browsers, proprietary clients (e.g., Oracle Forms), etc.) over a network(s) 2110. A server 2112 can be communicatively coupled to the remote client computing devices 2102, 2104, 2106, and 2108 via the network 2110.

[0145] In various embodiments, server 2112 can be adapted to run one or more services or software applications. In certain embodiments, server 2112 can also provide other services, or the software application can include a non-virtualized environment and a virtualized environment. In some embodiments, these services can be provided to users of client computing devices 2102, 2104, 2106, and / or 2108 as web-based services or cloud services or under a software-as-a-service (SaaS) model. Users operating client computing devices 2102, 2104, 2106, and / or 2108 can then utilize one or more client applications to interact with server 2112 to utilize the services provided by these components.

[0146] exist Figure 21 In the depicted configuration, the software components 2118, 2120, and 2122 of the system 2100 are shown as being implemented on the server 2112. In other embodiments, one or more components of the system 2100 and / or the services provided by these components may also be implemented by one or more of the client computing devices 2102, 2104, 2106, and / or 2108. A user operating a client computing device may then utilize one or more client applications to use the services provided by these components. These components may be implemented in hardware, firmware, software, or a combination thereof. It should be understood that a variety of different system configurations are possible that may differ from the distributed system 2100. Thus, Figure 21 The embodiment shown in is one example of a distributed system for implementing an embodiment system and is not intended to be limiting.

[0147] Client computing devices 2102, 2104, 2106, and / or 2108 may include various types of computing systems. For example, a client computing device may include a portable handheld device (e.g., Cellular phones, computing tablets, personal digital assistants (PDAs), or wearable devices (e.g., Google head-mounted display) that runs a computer such as Microsoft Windows The client computing device may also include general-purpose personal computers, such as, for example, Microsoft Windows Phone, BlackBerry 10, and various mobile operating systems such as iOS, Windows Phone, Android, BlackBerry 10, and Palm OS. The device may support various applications (such as various Internet-related applications, email, and short message service (SMS) applications) and may use various other communication protocols. Apple The client computing device can be a personal computer and / or laptop computer running any of a variety of commercial or a workstation computer running a UNIX-like operating system (including but not limited to various GNU / Linux operating systems such as, for example, Google Chrome OS). Client computing devices may also include electronic devices capable of communicating over the network(s) 2110 (such as thin client computers, Internet-enabled gaming systems (e.g., with or without Microsoft Gesture Input Devices gaming console) and / or personal messaging device).

[0148] Although Figure 21 The distributed system 2100 in FIG. 2 is shown as having four client computing devices, but any number of client computing devices can be supported. Other devices (such as devices with sensors, etc.) can interact with the server 2112.

[0149] The network(s) 2110 in the distributed system 2100 may be any type of network familiar to those skilled in the art that can support data communications using any of a variety of available protocols, including but not limited to TCP / IP (Transmission Control Protocol / Internet Protocol), SNA (Systems Network Architecture), IPX (Internetwork Packet Exchange), AppleTalk, etc. By way of example only, the network(s) 2110 may be a local area network (LAN), an Ethernet-based network, a token ring, a wide area network, the Internet, a virtual network, a virtual private network (VPN), an intranet, an extranet, a public switched telephone network (PSTN), an infrared network, a wireless network (e.g., in any of the Institute of Electrical and Electronics Engineers (IEEE) 1002.11 protocol suites, and / or any other wireless protocol operating under) and / or any combination of these networks and / or other networks.

[0150] The server 2112 may be composed of one or more general-purpose computers, dedicated server computers (including, for example, PC (personal computer) servers, The server 2112 may be a server, a mid-range server, a mainframe computer, a rack-mounted server, etc.), a server farm, a server cluster, or any other suitable arrangement and / or combination. The server 2112 may include one or more virtual machines running a virtual operating system, or other computing architecture involving virtualization. One or more flexible logical storage device pools may be virtualized to maintain virtual storage devices for the server. The virtual network may be controlled by the server 2112 using software-defined networking. In various embodiments, the server 2112 may be suitable for running one or more services or software applications described in the foregoing disclosure. For example, the server 2112 may correspond to a server for performing the processing described above according to an embodiment of the present disclosure.

[0151] The server 2112 can run an operating system including any of the operating systems discussed above, as well as any commercially available server operating system. The server 2112 can also run any of a variety of additional server applications and / or middle-tier applications, including HTTP (Hypertext Transfer Protocol) servers, FTP (File Transfer Protocol) servers, CGI (Common Gateway Interface) servers, Servers, database servers, etc. Exemplary database servers include, but are not limited to, database servers commercially available from Oracle, Microsoft, Sybase, IBM (International Business Machines), etc.

[0152] In some implementations, the server 2112 may include one or more applications to analyze and integrate data feeds and / or event updates received from users of the client computing devices 2102, 2104, 2106, and 2108. As examples, the data feeds and / or event updates may include, but are not limited to, data received from one or more third-party information sources and continuous data streams. feed, The continuous data stream may include real-time events related to sensor data applications, financial quote machines, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, automobile traffic monitoring, etc. The server 2112 may also include one or more applications that display the data feeds and / or real-time events via one or more display devices of the client computing devices 2102, 2104, 2106, and 2108.

[0153] Distributed system 2100 may also include one or more databases 2114 and 2116. These databases may provide a mechanism for storing information (such as user interaction information, usage pattern information, adaptive rule information, and other information used by embodiments of the present disclosure). Databases 2114 and 2116 may reside in various locations. As an example, one or more of databases 2114 and 2116 may reside on a non-transient storage medium local to (and / or residing therein) on server 2112. Alternatively, databases 2114 and 2116 may be remote from server 2112 and communicate with server 2112 via a network-based connection or a dedicated connection. In one embodiment, databases 2114 and 2116 may reside in a storage area network (SAN). Similarly, any necessary files for executing the functions that server 2112 has may be appropriately stored locally on server 2112 and / or stored remotely. In one set of embodiments, databases 2114 and 2116 may comprise relational databases (such as those provided by Oracle) adapted to store, update, and retrieve data in response to SQL-formatted commands.

[0154] In some embodiments, a cloud environment may provide one or more services. Figure 22 1 is a simplified block diagram illustrating one or more components of a system environment 2200 in which services may be provided as cloud services according to an embodiment of the present disclosure. Figure 22 In the illustrated embodiment, the system environment 2200 includes one or more client computing devices 2204, 2206, and 2208, which can be used by users to interact with a cloud infrastructure system 2202 that provides cloud services. The cloud infrastructure system 2202 can include one or more computers and / or servers, which can include those described above for the server 2112.

[0155] It should be recognized that Figure 22 The cloud infrastructure system 2202 depicted in FIG may have other components in addition to those depicted. Additionally, Figure 22 The embodiment shown in is only one example of a cloud infrastructure system that can incorporate embodiments of the present disclosure. In some other embodiments, the cloud infrastructure system 2202 can have more or fewer components than shown in the figure, can combine two or more components, or can have a different configuration or arrangement of components.

[0156] The client computing devices 2204, 2206, and 2208 can be devices similar to those described above for the client computing devices 2102, 2104, 2106, and 2108. The client computing devices 2204, 2206, and 2208 can be configured to operate client applications (such as web browsers, proprietary client applications (e.g., Oracle Forms), or some other application that can be used by users of the client computing devices to interact with the cloud infrastructure system 1302 to use services provided by the cloud infrastructure system 2202). Although the exemplary system environment 2200 is shown with three client computing devices, any number of client computing devices can be supported. Other devices (such as devices with sensors, etc.) can interact with the cloud infrastructure system 2202.

[0157] The network(s) 2210 can facilitate data communication and exchange between the client computing devices 2204, 2206, and 2208 and the cloud infrastructure system 2202. Each network can be any type of network familiar to those skilled in the art that can support data communication using any of a variety of commercially available protocols, including those described above for the network(s) 2110.

[0158] In certain embodiments, the services provided by the cloud infrastructure system 2202 may include a range of services available on-demand to users of the cloud infrastructure system. A variety of other services may also be provided, including but not limited to online data storage and backup solutions, web-based email services, hosted office suites and document collaboration services, database processing, managed technical support services, etc. The services provided by the cloud infrastructure system can be dynamically scalable to meet the needs of its users.

[0159] In certain embodiments, a specific instantiation of a service provided by the cloud infrastructure system 2202 may be referred to herein as a "service instance." Generally speaking, any service made available to a user from a cloud service provider's system via a communications network (such as the Internet) is referred to as a "cloud service." Typically, in a public cloud environment, the servers and systems that make up the cloud service provider's system are distinct from the customer's own on-premises servers and systems. For example, the cloud service provider's system may host an application, and a user may subscribe to and use the application on demand via a communications network such as the Internet.

[0160] In some examples, services in a computer network cloud infrastructure may include protected computer network access to storage, hosted databases, hosted web servers, software applications, or other services provided by the cloud provider to users or as otherwise known in the art. For example, a service may include password-protected access to remote storage on the cloud via the Internet. As another example, a service may include a hosted relational database and scripting language middleware engine based on web services for specialized use by networked developers. As another example, a service may include access to an email software application hosted on the cloud provider's website.

[0161] In certain embodiments, the cloud infrastructure system 2202 may include application suites, middleware, and database service offerings delivered to customers in a self-service, subscription-based, elastically scalable, reliable, highly available, and secure manner. An example of such a cloud infrastructure system is the Oracle Public Cloud provided by the assignee.

[0162] The cloud infrastructure system 2202 can also provide computing and analytical services related to "big data." The term "big data" is generally used to refer to extremely large data sets that can be stored and manipulated by analysts and researchers to visualize large amounts of data, detect trends, and / or otherwise interact with the data. This big data and related applications can be hosted and / or manipulated by the infrastructure system at many levels and different scales. Dozens, hundreds, or thousands of processors linked in parallel can act on this data to present it or simulate external forces on the data or the content represented by the data. These data sets can involve structured data (such as data organized in a database or otherwise organized according to a structured model) and / or unstructured data (e.g., emails, images, data blobs (binary large objects), web pages, complex event processing). By leveraging the ability of embodiments to relatively quickly focus more (or fewer) computing resources on a target, the cloud infrastructure system can be better used to implement tasks on large data sets based on needs from enterprises, government agencies, research organizations, private individuals, groups of like-minded individuals or organizations, or other entities.

[0163] In various embodiments, the cloud infrastructure system 2202 can be adapted to automatically provision, manage, and track customer subscriptions to services provided by the cloud infrastructure system 2202. The cloud infrastructure system 2202 can provide cloud services via different deployment models. For example, services can be provided under a public cloud model, where the cloud infrastructure system 2202 is owned by an organization that sells cloud services (e.g., owned by Oracle Corporation) and makes the services available to the general public or different industrial enterprises. As another example, services can be provided under a private cloud model, where the cloud infrastructure system 2202 operates only for a single organization and can provide services to one or more entities within the organization. Cloud services can also be provided under a community cloud model, where the cloud infrastructure system 2202 and the services provided by the cloud infrastructure system 2202 are shared by several organizations in a related community. Cloud services can also be provided under a hybrid cloud model, which is a combination of two or more different models.

[0164] In some embodiments, the services provided by cloud infrastructure system 2202 may include one or more services provided under the Software as a Service (SaaS) category, the Platform as a Service (PaaS) category, the Infrastructure as a Service (IaaS) category, or other service categories including hybrid services. A customer may subscribe to one or more services provided by cloud infrastructure system 2202 via a subscription order. Cloud infrastructure system 2202 then performs processing to provide the services in the customer's subscription order.

[0165] In some embodiments, the services provided by the cloud infrastructure system 2202 may include, but are not limited to, application services, platform services, and infrastructure services. In some examples, application services may be provided by the cloud infrastructure system via a SaaS platform. The SaaS platform may be configured to provide cloud services that fall into the SaaS category. For example, a SaaS platform may provide the ability to build and deliver on-demand application suites on an integrated development and deployment platform. The SaaS platform may manage and control the underlying software and infrastructure used to provide SaaS services. By utilizing the services provided by the SaaS platform, customers can utilize applications executed on the cloud infrastructure system. Customers can obtain application services without the need for customers to purchase separate licenses and support. A variety of different SaaS services may be provided. Examples include, but are not limited to, services that provide solutions for sales performance management, enterprise integration, and business flexibility to large organizations.

[0166] In some embodiments, platform services can be provided by the cloud infrastructure system 2202 via a PaaS platform. The PaaS platform can be configured to provide cloud services belonging to the PaaS category. Examples of platform services may include, but are not limited to, services that enable organizations (such as Oracle) to integrate existing applications on a shared public architecture, and the ability to build new applications using the shared services provided by the platform. The PaaS platform can manage and control the underlying software and infrastructure for providing PaaS services. Customers can obtain the PaaS services provided by the cloud infrastructure system 2202 without the need for customers to purchase separate licenses and support. Examples of platform services include, but are not limited to, Oracle Java Cloud Service (JCS), Oracle Database Cloud Service (DBCS), and others.

[0167] By utilizing the services provided by the PaaS platform, customers can adopt programming languages ​​and tools supported by the cloud infrastructure system and also control the deployed services. In some embodiments, the platform services provided by the cloud infrastructure system may include database cloud services, middleware cloud services (e.g., Oracle Fusion Middleware services), and Java cloud services. In one embodiment, the database cloud service may support a shared service deployment model, which enables organizations to pool database resources and provide database as a service to customers in the form of a database cloud. In the cloud infrastructure system, the middleware cloud service can provide customers with a platform for developing and deploying various business applications, and the Java cloud service can provide customers with a platform for deploying Java applications.

[0168] A variety of infrastructure services can be provided by IaaS platforms in cloud infrastructure systems. Infrastructure services facilitate the management and control of underlying computing resources (such as storage, network, and other basic computing resources) so that customers can utilize the services provided by SaaS and PaaS platforms.

[0169] In certain embodiments, the cloud infrastructure system 2202 may also include infrastructure resources 2230 for providing resources for providing various services to customers of the cloud infrastructure system. In one embodiment, the infrastructure resources 2230 may include a pre-integrated and optimized combination of hardware (such as servers, storage devices, and networking resources) for executing services provided by the PaaS platform and the SaaS platform, as well as other resources.

[0170] In some embodiments, resources in the cloud infrastructure system 2202 can be shared by multiple users and dynamically reallocated as needed. Furthermore, resources can be allocated to users in different time zones. For example, the cloud infrastructure system 2202 can enable a first set of users in a first time zone to utilize the cloud infrastructure system's resources for a specified number of hours, and then enable the reallocation of the same resources to another set of users in a different time zone, thereby maximizing resource utilization.

[0171] In certain embodiments, a number of internal shared services 2232 may be provided that are shared by different components or modules of the cloud infrastructure system 2202 to enable provisioning of services by the cloud infrastructure system 2202. These internal shared services may include, but are not limited to, security and identity services, integration services, enterprise repository services, enterprise manager services, virus scanning and whitelisting services, high availability, backup and recovery services, services for enabling cloud support, email services, notification services, file transfer services, and the like.

[0172] In certain embodiments, the cloud infrastructure system 2202 can provide comprehensive management of cloud services (e.g., SaaS, PaaS, and IaaS services) in the cloud infrastructure system. In one embodiment, the cloud management functionality can include the ability to provision, manage, and track customer subscriptions received by the cloud infrastructure system 2202 or the like.

[0173] In one embodiment, Figure 22 , cloud management functionality may be provided by one or more modules such as an order management module 2220, an order orchestration module 2222, an order provisioning module 2224, an order management and monitoring module 2226, and an identity management module 2228. These modules may include, or may be provided using, one or more computers and / or servers, which may be general purpose computers, dedicated server computers, server farms, server clusters, or any other suitable arrangement and / or combination.

[0174] In exemplary operation, at step 2234, a customer using a client device (such as client computing device 2204, 2206, or 2208) may interact with cloud infrastructure system 2202 by requesting one or more services provided by cloud infrastructure system 2202 and placing an order for a subscription to the one or more services provided by cloud infrastructure system 2202. In certain embodiments, the customer may access a cloud user interface (UI) such as cloud UI 2212, cloud UI 2214, and / or cloud UI 2216 and place a subscription order via these UIs. Order information received by cloud infrastructure system 2202 in response to the customer placing the order may include information identifying the customer and the one or more services provided by cloud infrastructure system 2202 to which the customer intends to subscribe.

[0175] At step 2236, the order information received from the customer can be stored in the order database 2218. If this is a new order, a new record can be created for the order. In one embodiment, the order database 2218 can be one of several databases operated by the cloud infrastructure system 2218 and operated in conjunction with other system components.

[0176] At step 2238, the order information may be forwarded to the order management module 2220, which may be configured to perform billing and accounting functions related to the order, such as validating the order and booking the order upon validation.

[0177] At step 2240, information about the order may be communicated to order orchestration module 2222, which is configured to orchestrate the provisioning of services and resources for the order placed by the customer. In some cases, order orchestration module 2222 may utilize the services of order provisioning module 2224 for provisioning. In certain embodiments, order orchestration module 2222 enables management of the business processes associated with each order and applies business logic to determine whether the order should proceed with provisioning.

[0178] like Figure 22 As shown in the embodiment depicted in FIG, at step 2242, upon receiving an order for a new subscription, order orchestration module 2222 sends a request to order provisioning module 2224 to allocate resources and configure the resources needed to fulfill the subscription order. Order provisioning module 2224 enables the allocation of resources for the services ordered by the customer. Order provisioning module 2224 provides a level of abstraction between the cloud services provided by cloud infrastructure system 2202 and the physical implementation layer used to provision the resources for providing the requested services. This enables order orchestration module 2222 to be isolated from implementation details, such as whether services and resources are actually provisioned in real time or pre-provisioned and allocated / specified only upon request.

[0179] Once the services and resources are provisioned, a notification indicating that the requested services are now ready for use may be sent to the subscribing client at step 2244. In some cases, information (e.g., a link) may be sent to the client enabling the client to begin using the requested services.

[0180] At step 2246, the customer's subscription order may be managed and tracked by the order management and monitoring module 2226. In some cases, the order management and monitoring module 2226 may be configured to collect usage statistics regarding the customer's use of the subscribed service. For example, statistics may be collected regarding the amount of storage used, the amount of data transferred, the number of users, the amount of system uptime, and the amount of system downtime.

[0181] In certain embodiments, the cloud infrastructure system 2200 may include an identity management module 2228 configured to provide identity services, such as access management and authorization services within the cloud infrastructure system 2200. In some embodiments, the identity management module 2228 may control information about clients that wish to utilize services provided by the cloud infrastructure system 2202. This information may include information authenticating the identities of these clients and information describing the actions that these clients are authorized to perform with respect to various system resources (e.g., files, directories, applications, communication ports, memory segments, etc.). The identity management module 2228 may also include descriptive information about each client and management of how and by whom this descriptive information may be accessed and modified.

[0182] Figure 23 2 shows an exemplary computer system 2300 that can be used to implement embodiments of the present disclosure according to some exemplary embodiments. In some embodiments, the computer system 2300 can be used to implement any of the various servers and computer systems described above. Figure 23 As shown, computer system 2300 includes various subsystems, including a processing unit 2304 that communicates with a number of peripheral subsystems via a bus subsystem 2302. These peripheral subsystems may include a processing acceleration unit 2306, an I / O subsystem 2308, a storage subsystem 2318, and a communication subsystem 2324. The storage subsystem 2318 may include tangible computer-readable storage media 2322 and a system memory 2310.

[0183] The bus subsystem 2302 provides a mechanism for allowing the various components and subsystems of the computer system 2300 to communicate with each other as desired. Although the bus subsystem 2302 is schematically shown as a single bus, the alternative embodiment of the bus subsystem can utilize multiple buses. The bus subsystem 2302 can be any of several types of bus structures, including a memory bus or a memory controller, a peripheral bus, and a local bus utilizing any various bus architectures. For example, such architectures can include an industry standard architecture (ISA) bus, a microchannel architecture (MCA) bus, an enhanced ISA (EISA) bus, a video electronics standards association (VESA) local bus, and a peripheral component interconnect (PCI) bus, which can be implemented as a mezzanine bus manufactured according to the IEEE P1386.1 standard, or the like.

[0184] The processing subsystem 2304 controls the operation of the computer system 2300 and may include one or more processing units 2332, 2334, etc. The processing units may include one or more processors, including single-core or multi-core processors, one or more cores of a processor, or a combination thereof. In some embodiments, the processing subsystem 2304 may include one or more specialized coprocessors, such as a graphics processor, a digital signal processor (DSP), etc. In some embodiments, some or all of the processing units of the processing subsystem 2304 may be implemented using custom circuits, such as application-specific integrated circuits (ASICs) or field-programmable gate arrays (FPGAs).

[0185] In some embodiments, the processing unit in the processing subsystem 2304 can execute instructions stored in the system memory 2310 or on the computer-readable storage medium 2322. In various embodiments, the processing unit can execute various programs or code instructions and can maintain multiple concurrently executing programs or processes. At any given time, some or all of the program code to be executed can reside in the system memory 2310 and / or on the computer-readable storage medium 2322, potentially including on one or more storage devices. Through appropriate programming, the processing subsystem 2304 can provide a variety of functions.

[0186] In certain embodiments, a processing acceleration unit 2306 may be provided for performing customized processing or for offloading some of the processing performed by the processing subsystem 2304 in order to speed up the overall processing performed by the computer system 2300 .

[0187] I / O subsystem 2308 can include devices and mechanisms for inputting information to computer system 2300 and / or for outputting information from or via computer system 2300. In general, use of the term "input device" is intended to include all possible types of devices and mechanisms for inputting information to computer system 2300. User interface input devices can include, for example, a keyboard, a pointing device such as a mouse or trackball, a touch panel or touch screen incorporated into the display, a scroll wheel, a click wheel, a dial, a button, a switch, a keypad, audio input devices with speech command recognition systems, microphones, and other types of input devices. User interface input devices can also include motion sensor gesture recognition devices, Microsoft Kinect® motion sensing and / or gesture recognition devices, Microsoft 360 game controllers, devices that provide an interface for receiving input utilizing gestures and spoken commands. User interface input devices can also include eye gesture recognition devices, such as Google Goggles®, that detect eye activity such as "blinking" of the user's eye(s) and convert the eye gestures to input for the input device (e.g., Google Blink® detector). Additionally, user interface input devices can include voice recognition sensing devices that allow the user to interact with the voice recognition system with voice commands (e.g., Siri®).

[0188] Other examples of user interface input devices include, without limitation, three dimensional (3D) mice, joysticks or pointing sticks, gamepads and graphic tablets, and audio / visual input devices such as speakers, digital cameras, digital camcorders, portable media players, webcams, image scanners, fingerprint scanners, barcode reader 3D scanners, 3D printers, laser rangefinders, and eye gaze tracking devices. Additionally, user interface input devices can include, for example, medical imaging input devices such as computerized tomography, magnetic resonance imaging, position emission tomography, medical ultrasonography devices. User interface input devices can also include, for example, audio input devices such as MIDI keyboards, digital musical instruments and the like.

[0189] ​User interface output devices may include a display subsystem, indicator lights, or non-visual displays such as audio output devices. The display subsystem may be a cathode ray tube (CRT), a flat panel device such as one utilizing a liquid crystal display (LCD) or plasma display, a projection device, a touch screen, or the like. In general, the use of the term "output device" is intended to include all possible types of devices and mechanisms for outputting information from the computer system 2300 to a user or other computers. For example, user interface output devices may include, but are not limited to, various display devices that visually convey text, graphics, and audio / video information, such as monitors, printers, speakers, headphones, car navigation systems, plotters, voice output devices, and modems.

[0190] The storage subsystem 2318 provides a repository or data storage for storing information used by the computer system 2300. The storage subsystem 2318 provides a tangible, non-transitory, computer-readable storage medium for storing the basic programming and data structures that provide the functionality of some embodiments. The software (programs, code modules, instructions) that provide the above functionality when executed by the processing subsystem 2304 can be stored in the storage subsystem 2318. The software can be executed by one or more processing units of the processing subsystem 2304. The storage subsystem 2318 can also provide a repository for storing data used in accordance with the present disclosure.

[0191] The storage subsystem 2318 may include one or more non-transitory memory devices, including volatile and non-volatile memory devices. Figure 23 As shown, the storage subsystem 2318 includes system memory 2310 and computer-readable storage media 2322. The system memory 2310 can include multiple memories, including volatile main random access memory (RAM) for storing instructions and data during program execution and non-volatile read-only memory (ROM) or flash memory in which fixed instructions are stored. In some implementations, the basic input / output system (BIOS), which contains basic routines that help transfer information between elements within the computer system 2300, such as during startup, can typically be stored in ROM. RAM typically contains data and / or program modules currently being operated on and executed by the processing subsystem 2304. In some implementations, the system memory 2310 can include multiple different types of memory, such as static random access memory (SRAM) or dynamic random access memory (DRAM).

[0192] By way of example and not limitation, Figure 23As depicted in FIG, system memory 2310 may store application programs 2312, which may include client applications, web browsers, middle-tier applications, relational database management systems (RDBMS), etc., program data 2314, and an operating system 2316. As an example, operating system 2316 may include various versions of Microsoft Apple and / or Linux operating system, various commercial or UNIX-like operating systems (including but not limited to various GNU / Linux operating systems, Google OS, etc.) and / or such as iOS, Phone, OS, 10OS and OS operating system mobile operating system.

[0193] Computer-readable storage media 2322 may store programming and data structures that provide the functionality of some embodiments. Software (programs, code modules, instructions) that, when executed by processing subsystem 2304, cause the processor to provide the functionality described above may be stored in storage subsystem 2318. As an example, computer-readable storage media 2322 may include non-volatile memory, such as a hard drive, a disk drive, a hard drive such as a CD ROM, a DVD, a Blu-ray player, or a similar device. (Blu-ray) disc or other optical media. Computer readable storage media 2322 may include, but is not limited to, Drive, flash memory card, universal serial bus (USB) flash drive, secure digital (SD) card, DVD disk, digital video tape, etc. The computer readable storage medium 2322 may also include a solid-state drive (SSD) based on non-volatile memory (such as an SSD based on flash memory, an enterprise flash drive, a solid-state ROM, etc.), an SSD based on volatile memory (such as an SSD based on solid-state RAM, dynamic RAM, static RAM, DRAM, a magnetoresistive RAM (MRAM) SSD), and a hybrid SSD using a combination of DRAM-based and flash memory-based SSDs. The computer readable medium 2322 can provide storage for computer readable instructions, data structures, program modules, and other data for the computer system 2300.

[0194] In some embodiments, the storage subsystem 2300 may also include a computer-readable storage media reader 2320, which may be further connected to a computer-readable storage medium 2322. The computer-readable storage medium 2322, together with and optionally in combination with the system memory 2310, may comprehensively represent remote, local, fixed, and / or removable storage devices plus storage media for storing computer-readable information.

[0195] In certain embodiments, the computer system 2300 can provide support for executing one or more virtual machines. The computer system 2300 can execute programs such as a hypervisor to facilitate the configuration and management of the virtual machines. Each virtual machine can be allocated memory resources, computing resources (e.g., processors, cores), I / O resources, and networking resources. Each virtual machine typically runs its own operating system, which may be the same or different from the operating system executed by other virtual machines executed by the computer system 2300. Accordingly, multiple operating systems can potentially be run concurrently by the computer system 2300. Each virtual machine generally runs independently of other virtual machines.

[0196] The communication subsystem 2324 provides an interface to other computer systems and networks. The communication subsystem 2324 serves as an interface for receiving data from and sending data to other systems of the computer system 2300. For example, the communication subsystem 2324 may enable the computer system 2300 to establish a communication channel to one or more client computing devices via the Internet for receiving information from and sending information to the client computing devices.

[0197] The communication subsystem 2324 can support both wired and / or wireless communication protocols. For example, in some embodiments, the communication subsystem 2324 can include a radio frequency (RF) transceiver component, a global positioning system (GPS) receiver component, and / or other components for accessing a wireless voice and / or data network (e.g., using cellular telephone technology, advanced data network technology (such as 3G, 4G or EDGE (Enhanced Data Rates for Global Evolution), WiFi (IEEE 802.11 family of standards), or other mobile communication technologies, or any combination thereof). In some embodiments, the communication subsystem 2324 can provide a wired network connection (e.g., Ethernet) in addition to or in lieu of a wireless interface.

[0198] The communication subsystem 2324 can receive and send data in various forms. For example, in some embodiments, the communication subsystem 2324 can receive incoming communications in the form of structured and / or unstructured data feeds 2326, event streams 2328, event updates 2330, etc. For example, the communication subsystem 2324 can be configured to receive (or send) data feeds 2326 (such as WhatsApp, Facebook, or other social media network users) in real time from users of social media networks and / or other communication services. feed, Updates, web feeds such as Rich Site Summary (RSS) feeds), and / or real-time updates from one or more third-party information sources.

[0199] In certain embodiments, the communication subsystem 2324 may be configured to receive data in the form of a continuous data stream, which may be continuous or unbounded in nature with no clear end, wherein the continuous data stream may include an event stream 2328 of real-time events and / or event updates 2330. Examples of applications that generate continuous data may include, for example, sensor data applications, financial quote machines, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, automotive traffic monitoring, etc.

[0200] The communication subsystem 2324 can also be configured to output structured and / or unstructured data feeds 2326, event streams 2328, event updates 2330, etc. to one or more databases, wherein the one or more databases can communicate with one or more stream data source computers coupled to the computer system 2300.

[0201] Computer system 2300 can be of various types, including a handheld portable device (e.g., Cellular phones, computing tablets, PDAs), wearable devices (e.g., Google head-mounted display), personal computer, workstation, mainframe, kiosk, server rack, or any other data processing system.

[0202] Due to the ever-changing nature of computers and networks, Figure 23 The description of the computer system 2300 depicted in FIG is intended to be a specific example only. Figure 23 Many other configurations of more or fewer components of the system depicted are possible. Based on the disclosure and teachings provided herein, one of ordinary skill in the art will appreciate other ways and / or methods to implement the various embodiments.

[0203] Although specific embodiments of the present disclosure have been described, various modifications, changes, alternative constructions, and equivalents are also included within the scope of the present disclosure. These modifications include any relevant combination of the disclosed features. The embodiments of the present disclosure are not limited to operations within certain specific data processing environments, but can be freely operated within multiple data processing environments. In addition, although the embodiments of the present disclosure have been described using a specific series of transactions and steps, it should be clear to those skilled in the art that the scope of the present disclosure is not limited to the described series of transactions and steps. The various features and aspects of the above-described embodiments can be used alone or in combination.

[0204] In addition, although embodiments of the present invention have been described using specific combinations of hardware and software, it will be appreciated that other combinations of hardware and software are also within the scope of this disclosure. Some of the embodiments of the present disclosure can be implemented using only hardware, or only software, or a combination thereof. The various processes described herein can be implemented on the same processor or on different processors in any combination. Accordingly, where a component or module is described as being configured to perform certain operations, such configuration can be implemented, for example, by designing an electronic circuit to perform the operation, by programming a programmable electronic circuit (such as a microprocessor) to perform the operation, or by any combination thereof. Processes can communicate using various techniques, including but not limited to conventional techniques for inter-process communication, and different pairs of processes can use different techniques, or the same pair of processes can use different techniques at different times.

[0205] The specification and drawings are therefore to be considered in an illustrative rather than a restrictive sense. However, it will be apparent that additions, subtractions, deletions, and other modifications and changes may be made thereto without departing from the broader spirit and scope set forth in the claims. Therefore, while specific embodiments have been described, these are not intended to be limiting. Various modifications and equivalents are within the scope of the following claims.

Claims

1. A method for access management, comprising: Receiving, by the access management system AMS, an access request from a first computer device of a user; In response to the access request, determining, by the AMS, that the first computer device has been registered as a trusted device of the user; Based on determining that the first computer device has been registered as a trusted device of the user, sending first security data from the AMS to the first computer device, wherein the first security data is sent encrypted; receiving, by the AMS, second security data from a second computer device that is separate from the first computer device and that received the first security data from the first computer device, the second security data being generated by the second computer device upon successful authentication of the user based on user input provided to the second computer device and by decrypting the first security data using an encryption key sent from the AMS to the second computer device; determining, by the AMS, that the second security data matches the first security data, and Based on determining that the second security data matches the first security data, the first computer device is enabled to access the resource identified in the access request.

2. The method according to claim 1, wherein The first security data is sent to the first computer device as a Quick Response code, and wherein the second computer device captures the first security data by scanning the Quick Response code on a display of the first computer device.

3. The method of claim 1 , further comprising: Before the first computer device generates the access request, the first computer device is registered as a trusted device using the AMS, the registration comprising: generating temporary access information by the AMS, the temporary access information including a one-time code valid for a specific time period; sending the temporary access information to the second computer device based on the AMS determining that the second computer device has been registered as a trusted device of the user; Receiving, by the AMS, the temporary access information from the first computer device; determining, by the AMS, that the received temporary access information matches the temporary access information sent to the second computer device; and In response to determining that the received temporary access information matches the temporary access information sent to the second computer device, information identifying the first computer device as a trusted device is stored by the AMS.

4. The method according to claim 3, wherein: The storage of information identifying the first computer device as an authentic device is conditional upon receipt of the temporary access information from the first computer device within the specific time period during which the one-time code is valid.

5. The method according to claim 3, wherein: The information used to identify the first computer device as a trusted device includes a geographic location of the first computer device.

6. The method according to claim 5, wherein: Determining that the first computer device has been registered as a trusted device of the user includes determining that a geographic location of the first computer device when the AMS receives the access request corresponds to a geographic location in the stored information.

7. The method of claim 1, wherein: The authentication of the user is based on user entry of a personal identification number.

8. The method of claim 1, wherein: The authentication of the user is based on user input of biometric data.

9. The method of claim 1 , further comprising: The encryption key is sent from the AMS to the second computer device based on the AMS determining that the second computer device has been registered as a trusted device of the user.

10. A computer system comprising: one or more processors; as well as a memory accessible to the one or more processors, the memory storing instructions that, when executed by the one or more processors, cause the one or more processors to: receiving an access request from a first computer device of a user; In response to the access request, determining that the first computer device has been registered as a trusted device of the user; Based on determining that the first computer device has been registered as a trusted device of the user, sending first security data to the first computer device, wherein the first security data is sent encrypted; receiving, from a second computer device that is separate from the first computer device and that received the first security data from the first computer device, second security data generated by the second computer device upon successful authentication of the user based on user input provided to the second computer device and by decrypting the first security data using an encryption key sent from the computer system to the second computer device; determining that the second security data matches the first security data, and Based on determining that the second security data matches the first security data, the first computer device is enabled to access the resource identified in the access request.

11. The computer system of claim 10, wherein: The first security data is sent to the first computer device as a Quick Response code, and wherein the second computer device captures the first security data by scanning the Quick Response code on a display of the first computer device.

12. The computer system of claim 10, wherein: The instructions further cause the one or more processors to: Before the first computer device generates the access request, registering the first computer device as a trusted device, the registration comprising: generating temporary access information comprising a one-time code valid for a specific time period; sending the temporary access information to the second computer device based on determining that the second computer device has been registered as a trusted device of the user; receiving the temporary access information from the first computer device; determining that the received temporary access information matches the temporary access information sent to the second computer device; and In response to determining that the received temporary access information matches the temporary access information sent to the second computer device, information identifying the first computer device as a trusted device is stored.

13. The computer system of claim 12, wherein: The information used to identify the first computer device as a trusted device includes a geographic location of the first computer device.

14. The computer system of claim 13, wherein: Determining that the first computer device has been registered as a trusted device of the user includes determining that a geographic location of the first computer device when the access request is received by the computer system corresponds to a geographic location in the stored information.

15. The computer system of claim 10, wherein: The instructions further cause the one or more processors to: Based on determining that the second computer device has been registered as a trusted device of the user, the encryption key is sent to the second computer device.

16. A non-transitory computer-readable medium storing instructions that, when executed by one or more processors of a computer system, cause the one or more processors to perform a process comprising: receiving an access request from a first computer device of a user; In response to the access request, determining that the first computer device has been registered as a trusted device of the user; Based on determining that the first computer device has been registered as a trusted device of the user, sending first security data to the first computer device, wherein the first security data is sent encrypted; receiving, from a second computer device that is separate from the first computer device and that received the first security data from the first computer device, second security data generated by the second computer device upon successful authentication of the user based on user input provided to the second computer device and by decrypting the first security data using an encryption key sent from the computer system to the second computer device; determining that the second security data matches the first security data, and Based on determining that the second security data matches the first security data, the first computer device is enabled to access the resource identified in the access request.

17. The non-transitory computer readable medium of claim 16, wherein: The first security data is sent to the first computer device as a Quick Response code, and wherein the second computer device captures the first security data by scanning the Quick Response code on a display of the first computer device.

18. The non-transitory computer readable medium of claim 16, wherein: The instructions further cause the one or more processors to perform a process comprising: Before the first computer device generates the access request, registering the first computer device as a trusted device, the registration comprising: generating temporary access information comprising a one-time code valid for a specific time period; sending the temporary access information to the second computer device based on determining that the second computer device has been registered as a trusted device of the user; receiving the temporary access information from the first computer device; determining that the received temporary access information matches the temporary access information sent to the second computer device; and In response to determining that the received temporary access information matches the temporary access information sent to the second computer device, information identifying the first computer device as a trusted device is stored.

19. The non-transitory computer readable medium of claim 18, wherein: The information used to identify the first computer device as a trusted device includes a geographic location of the first computer device.

20. The non-transitory computer readable medium of claim 19, wherein: Determining that the first computer device has been registered as a trusted device of the user includes determining that a geographic location of the first computer device when the access request is received by the computer system corresponds to a geographic location in the stored information.

Images