CN110869928A

CN110869928A - Authentication system and method

Info

Publication number: CN110869928A
Application number: CN201780091059.8A
Authority: CN
Inventors: M.K.贝纳耶德
Original assignee: Barclays Services Corp
Current assignee: Barclays Services Corp
Priority date: 2017-05-25
Filing date: 2017-05-25
Publication date: 2020-03-06
Also published as: EP3631662A4; WO2018217204A1; EP3631662A1

Abstract

Receiving at a processing component from a requesting device operated by an end user: the data describes a request for access to a computer program. The processing component determines whether there is an existing authentication session for the end user. Upon a determination that there is no existing authentication session for the end user, prompting the end user to authenticate to the processing component. The risk assessment is performed based on a determination that there is an existing authentication session for the end user. Risk assessment includes consideration of one or both of the following: (i) one or more request characteristics associated with a request for access to a computer program, and (ii) one or more computer program access criteria. Access to the computer program is provided to the requesting device based on a positive determination that the risk assessment is positive. Upon a determination that the risk assessment is negative, the end user is prompted to perform an authentication activity. In response to receiving data indicating that the authentication activity was performed for the end user and that the authentication activity was successful, a new authentication session is established for the end user and access to the computer program is provided to the requesting device.

Description

Authentication system and method

Technical Field

The present invention relates generally to authenticating end-user access to a computer program across multiple devices using single sign-on techniques.

Disclosure of Invention

In one embodiment, there is a system and method for performing enhanced authentication.

Receiving at a processing component from a requesting device operated by an end user: the data describes a request for access to a computer program. The processing component determines whether there is an existing authentication session for the end user. Upon a determination that an existing authentication session for the end user does not exist, prompting the end user to authenticate to the processing component. The risk assessment is performed based on a determination that an existing authentication session exists for the end user. Risk assessment includes consideration of one or both of the following: (i) one or more request characteristics associated with a request for access to a computer program, and (ii) one or more computer program access criteria. Access to the computer program is provided to the requesting device based on a positive determination that the risk assessment is positive. Upon a determination that the risk assessment is negative, the end user is prompted to perform an authentication activity. In response to receiving data indicating that an authentication activity was performed on the end user and that the authentication activity was successful, a new authentication session is established for the end user and access to the computer program is provided to the requesting device.

The data indicating that the end user performed the authentication activity may include biometric data of the end user; a password selected by the end user; and/or a one-time password provided by the processing component after receiving a request for access from a requesting device.

In some embodiments, the processing component receives a registration request from an end user. The processing component creates a unique registration token (token). The processing component creates a database record that includes an identifier for the end user and a unique registration token. The processing component provides a mechanism for an access authentication application to a registration device for initiating registration of the registration device. The identifier for the end user and the unique registration token are received from the end user by the authentication application. Identifiers associated with registered devices are collected. A public key is received from a registration device. The public key forms part of a cryptographic key pair that is created when the end user authenticates to the registered device. The registration device stores a private key of the cryptographic key pair. The processing component calculates device authentication weights that are stored in a database along with the public key.

In some embodiments, a registration device is used to establish an authentication session for an end user prior to receiving a request to access a computer program.

In some embodiments, the requesting device is a registered device, and in other embodiments is a different device.

In some embodiments, consideration of computer program access criteria indicates a determination that the risk assessment is negative regardless of consideration of the request characteristics.

In some embodiments, consideration of the request characteristics indicates a determination that the risk assessment is negative regardless of consideration of the computer program access criteria.

The computer program access criteria may include a minimum authentication weight associated with the computer program, which may be determined based on a criticality of the computer application.

The request characteristics may include one or more of the following: a device authentication weight; the location of the requesting device; time that has elapsed since the existing authentication session was established; and whether the registered device is the same device used to make the access request.

The device authentication weights may be calculated based on the modality through which the end user authenticates with the registered device and/or the security rating of the registered device.

In some embodiments, the processing component receives a public key associated with an end user performing an authentication activity.

In some embodiments, a request to access a resource within a computer program is received at a processing component, and it is determined whether one or more request characteristics satisfy one or more computer program resource access criteria. The one or more computer program resource access criteria include a minimum authentication weight associated with the resource.

In some embodiments, an existing authentication session is established in connection with an end user accessing another computer program that is not the subject of the requested access. In such embodiments, the one or more request characteristics may include the following modalities: an existing authentication session related to accessing another computer program is established in the modality.

In some embodiments, the computer program may be a native application; web-based applications; or the operating system of the requesting device.

In some embodiments, consideration of the request characteristics and the computer program access criteria indicates that: the risk assessment is a negative determination when the device authentication weight does not exceed a minimum authentication weight associated with the computer program.

In some embodiments, consideration of the request characteristics and the computer program access criteria indicates that: the risk assessment is a negative determination when a distance between a first location of a requesting device at the time the access request is sent and a second location of another device at the time the existing authentication session is created exceeds a distance threshold.

In some embodiments, consideration of the request characteristics and the computer program access criteria indicates that: the risk assessment is a negative determination when a time period between a first time at which the access request is sent and a second time at which an existing authentication session is created exceeds a time period threshold.

Drawings

The foregoing summary, as well as the following detailed description of embodiments of the present invention, will be better understood when read in conjunction with the appended drawings of exemplary embodiments. It should be understood, however, that the invention is not limited to the precise arrangements and instrumentalities shown.

In the drawings:

FIG. 1 is a diagram illustrating exemplary hardware and software components that may be used in conjunction with exemplary embodiments of the present invention;

FIG. 2A is a diagram illustrating the communication and data flow between and among devices and other computer system components associated with an exemplary registration process of the present invention;

FIG. 2B is a diagram illustrating the communication and data flow between and among devices and other computer system components associated with an exemplary authentication process of the present invention; and is

FIG. 3 is a diagram illustrating an exemplary computer system architecture that may be used in accordance with the present invention.

Detailed Description

Organizations and end users face a number of challenges in authenticating spaces. Users are required to remember multiple passwords for accessing computer programs (e.g., applications, operating systems of devices, etc.) that they use on a daily basis. This burden is compounded by the extent to which users need to access multiple computer programs on multiple devices (e.g., via mobile devices when traveling, and via their desktop machines when arriving at work or other destinations). As a result, password resets are on the rise, which is costly to implement and maintain for an organization. In addition, mobile applications are proliferating within the organization. This further increases the complexity of password resetting and the significant risk that an organization faces if a single application or system is compromised. In view of the foregoing, there is a need in the art for a system that: the system provides end users with convenience and flexibility in accessing computer programs and provides organizations with the required security.

Embodiments of the present invention provide novel improvements in the field of authentication technology and are particularly useful in identification and access management systems. More particularly, embodiments of the present invention provide a platform that allows a user to log onto any of a number of different clients (e.g., mobile, desktop, services/capabilities) and access computer programs (e.g., native mobile applications, desktop applications, web/cloud-based applications, authentication settings, operating systems, services, or capabilities) using a single sign-on functionality (i.e., a single sign-on (e.g., username/password, touch identification)). In an exemplary embodiment, the present invention uses biometrics (although biometrics need not be used in all embodiments of the present invention), authentication and password components to enable the following capabilities: where the user's identity (e.g., biometric identity), or signature, remains anonymous while the cryptographic key relationship is used to authenticate the user. A risk engine is also provided in the preferred embodiment to control the single sign-on function based on various risk factors, such as time, number of devices, and/or geographic location, as examples.

A detailed description of exemplary embodiments of the invention will now be described. FIG. 1 is a diagram of a system 100 illustrating exemplary hardware and software components that may be used in conjunction with embodiments of the present invention. Device 10 is any device seeking access to a computer program. The device(s) 15 comprise devices that register with the processing component 20. The illustrated network is a communication network that allows the components of the system 100 to communicate and exchange data. The processing component 20 performs the authentication activities described herein. The processing component 20 may be a computer server in an exemplary embodiment, and thus, is also referred to herein as an authentication server 20. The risk engine 30 includes a computer processor programmed to perform the risk assessment activities described herein. The rules/weights store 45 includes a data storage/retrieval mechanism for rules and weights used by the risk engine 30. The cryptographic storage 40 stores data associated with cryptographic keys used in connection with the present invention.

Referring to fig. 2A, an exemplary method 200 is depicted by which an end user may register with the system, including registering his device(s) 15 with the system, through the exemplary method 200. In step 201, a user initiates a registration from a secure client device. More particularly, the user may initiate registration from a trusted working desktop or other authenticated environment, utilizing an existing authentication session (i.e., from a trusted device that has been registered and into which the user is logged, or from an authorized desktop into which the user is logged). In step 202, the authentication server 20 receives a request for starting a registration and creates a unique and sometimes limited registration token (e.g. a one-time pin (personal identification number) or password, or a QR code, as examples). Authentication server 20 creates a database record including, for example: an identifier for the user, such as the user's email address, and a unique, time-limited registration code. In step 203, the authentication server 20 sends an electronic message to the user, for example using a secure electronic mailbox address, including a link for downloading the application and initiating the registration process. As described more fully herein, the application acts as an authentication agent and is protected, for example, using biometrics, to unlock access to the private key. Alternatively, a link for downloading the application may be displayed on the screen to the user within the secure session. Thus, the user is provided access to the application in any number of ways so he can install it on the device. Thus, in step 204, using the link, the user installs the application and is prompted by the application to register his device. In step 205, the user enters an identifier for the user, e.g. his email address, and a unique, time-limited registration code. Additional data may be collected, such as an identifier of the device performing the registration and the location of such device at the time of registration. At this point, the authenticity and ownership of the device 15 that the user seeks to register with is confirmed, as well as the association of the user with the authenticated session on the device with which the user is registering his device. In step 206, the user registers the authentication factor on the device 15, for example by entering a password created by the user or using biometric features. In step 207, a cryptographic key pair is created within a secure container of the device. The private key of the key pair is stored in a secure area of the device and is not revealed during the authentication process described with reference to fig. 2A. The public key comprises a device ID, a key ID, and in some embodiments data describing the location of the device 15 at the time of registration.

In connection with the registration process, the application installed on the device 15 calculates device authentication weights in conjunction with the risk engine 30 in step 208. In a preferred embodiment, the device authentication weight may be calculated based on several factors.

One factor relates to location, which uses parameters (e.g., geographic location, time) obtained by the application at registration time, for example. The location of both the device performing the registration process and the device to be registered is relevant to the process. For example, the system will consider whether the user should be permitted to register devices that are not within reasonable proximity to the device the user is using to perform the registration. In a particular example, if a user logs on to his laptop in new york when he seeks to register his mobile phone, registration may be denied if the same user attempts to download an application from a location in europe and register his mobile phone within a few minutes after his new york laptop logs in, as this would indicate an impossible speed (i.e., travel from new york to europe within a few minutes).

Regarding another factor, the more secure the authentication capabilities of the device sought to be registered, the higher the weight assigned. For example, the risk engine 30 assigns weights based on authentication factors provided, e.g., biometric factors based on hardware and supported with a key stored in a secure container of the device will be considered more trusted than the password. The biometric factors may be weighted based on established industry ratings, among other things: for example, an iris scanner has fewer false positives than a vein scanner and will therefore be given a higher weight. Thus, in an exemplary embodiment, the high-to-low weighting order is an iris scanner, a vein scanner, a touch identification, a pass phrase, and then a password.

Another factor relates to how secure the device is with respect to storing the private key, and whether there are any known leaks or vulnerabilities. Thus, for example, the touch identity sensor has an operating system and hardware support to ensure that private keys are never accessed by software and that they are stored and function entirely within the hardware. On the other hand, some iris scanner implementations may have a higher perceived security rating, but the key management used in connection with such implementations is entirely software-based, and thus, the private key is exposed to software before being submitted to storage. An iris scanner implementation that utilizes hardware security may have a higher security rating than a touch identification.

It should be noted that the device sought to be registered need not be an integrated device. For example, users may utilize externally available devices for biometric authentication that connect to their devices directly or via wireless capability and using known interfaces.

In an exemplary embodiment, the registration process for the device is then completed, and the device sends the following data elements to the authentication server 20: a user identifier, e.g. his email address; a unique registration code; a public key; and a device authentication weight. In step 209, the user/device record is updated in the database 40.

The user may register more than one device 15 according to the registration procedure described above. Each device 15 is associated with its own unique public/private key relationship and a unique key ID. With respect to registration of multiple devices, the authentication weights are based on the login context and are device specific. More particularly, devices that are at rest (e.g., registered devices that are offline or online but not being used) do not contribute to the weight logic. The user may initiate a login via the first device and assign an authentication weight to the particular transaction based on the usage of the first device. If the user seeks to log in from the second device, an authentication weight is calculated based on the new authentication request from the second device (e.g., based on location, time, and other factors previously described).

Referring to FIG. 2B, an exemplary method 210 is illustrated in which the system of the present invention processes a login request. The process begins when a user attempts to use a device to access a desired computer program. The user may seek access to: a native or web application on the mobile device; a native or web application on a desktop computer; a server application or service; or an operating system, such as, for example, an operating system of a smart device.

In some embodiments, each computer program that would benefit from the authentication techniques of the present invention needs to include an authentication module that launches when an end user requests access to an application, and in some instances when the end user seeks to perform an activity (e.g., access a resource) within the application. More particularly, for each class of device and computer program (e.g., mobile native application; mobile web application; desktop native application; desktop web application; desktop plug-in; and access to a server and/or operating system), an entry point is created that translates the user interface/access control of the device/application into the ability to communicate with the authentication server 20. This allows a single login to all such computer programs across all platforms/devices/services.

In the case where the creator of the computer program is also the originator of the authentication technique, the authentication module may be written in code associated with logging into the computer program. However, for third party computer programs (i.e. those not created by the originator of the authentication technology, such as native applications of the mobile device), an entry point for encoding the authentication module is required. Such a third party may allow a user of the computer program to customize the landing page of the computer program (e.g., allow for customized branding). Such access may be used as an opening for including code (e.g., HTML or JavaScript code) that implements an authentication module that is then launched when a user requests access to the computer program.

Referring now to the steps of the exemplary method illustrated with reference to fig. 2B, in step 211, when a user requests access to a computer program, identifies himself to the computer program by, for example, entering his username, the authentication module launches and causes the device to initiate an authentication request. In step 212, the authentication request is passed to the authentication server 20. In step 213, the authentication server 20 determines whether the user must authenticate or can trust the previous authentication. More particularly, the authentication server 20 determines whether there is an authentication session for the user (i.e., an existing session that has not expired or been purged). As an example, assume that a user employing a first device is logged into a computer program. The authentication server 20 maintains a record of the user's login into the computer program using the first device at a particular location. The record remains valid for the duration of the maximum session length as configured by the administrator and will be automatically cleared if the maximum session length is exceeded or cleared at the next login. At the next login, it is assumed that the user logs in from a different device, such that a device identifier for the second device, the location of the second device and the identity of the target computer program are available. The authentication server 20 uses data from previous logins as well as from current login attempts to perform speed calculations and apply risk scores and can determine whether the user should be permitted to login or whether additional authentication is required.

If a session does not exist, one must be established. The procedure for establishing a session is described in more detail with reference to steps 215 through 219.

However, even if an authentication session exists, the risk associated with the newly requested access is assessed in step 214 (e.g., because the existing authentication session may require fewer security requirements than the application currently seeking access would require), as will follow.

The risk engine first considers the minimum authentication weights associated with: a computer program seeking access, or a resource within a computer program seeking access, or an activity to be performed in relation to a computer program. The risk engine 30 consults the rules/weights database 45 for this purpose. For example, a critical computer program/application may be associated with a higher minimum authentication weight than a non-critical computer program/application. As a further example, a request to log into a computer program/application may be associated with a lower minimum authentication weight than a request to complete a transaction using the application or a request to access a resource within the application.

If the device authentication weight assigned during the registration process is below the minimum authentication weight, then the risk engine 30 requires an authentication step.

If the device authentication weight assigned during the enrollment process is the same as or higher than the minimum authentication weight, risk engine 30 considers: a location of a device seeking access to an application; time that has elapsed since the last authentication; and/or the device that is used to seek access to the application (e.g., is the same device that was used during the registration process).

Thus, the risk engine 30 may consider whether to use the device within a trusted proximity of a location (e.g., at a home or office, at a hotel, at a convention center associated with a company or entity hosting the application, or at a public location within a country where companies and users typically reside). The risk engine 30 may further consider whether the user is located in a foreign country where the company does business or is otherwise located. In one exemplary embodiment, the user may inform the risk engine 30 of the expected location and obtain pre-approval accordingly to reduce the impact on the weights.

In some embodiments, the speed at which the user moves is considered. For example, assume that the user successfully logged into the application from New York City and that the session is permitted. It is estimated that it will take at least 6 hours to travel to the uk; thus, if a user attempts to log in from london 30 minutes after a new york city login, the score will decrease due to the impossible speed. In an exemplary embodiment, the risk engine 30 assigns a default user maximum speed of 600 miles per hour. With this model, a speed of 700 miles per hour is possible, but less likely. A speed of 800 miles per hour would even further reduce the score, and a speed of 1200 miles per hour would render the score zero and would result in an immediate login failure.

In another example, in one embodiment, the fact that the device being used is different from the device that was first logged into the application is a negative factor in the weighting calculation.

Based on these considerations, risk engine 30 determines a risk score accordingly and indicates to authentication server 20 whether the user should be granted access to the application or whether another authentication step is required.

If the risk assessment indicates that the authentication should be re-verified despite the existence of the existing authentication session, the process continues as described in steps 215 through 219. In some embodiments, the user is provided with a one-time password that is used in conjunction with additional authentication steps, as described in more detail below.

In the event that authentication is required, all devices 15 that are registered with the system (e.g., through the process described with reference to fig. 2A) receive an authentication request from the authentication server 20 in step 215. For example, all registered devices 15 receive notifications as supported by a particular device platform. When the user activates a notification from one of the devices that has received the notification, only that device may be used to fulfill the authentication request using the authentication module. The authentication request includes a cryptographic random number (nonce). Device(s) 15 perform an authentication challenge (e.g., fingerprint scan or entry password) in step 216 and the end user enters a one-time password. In step 217, if the authentication challenge is successful, the cryptographic random number is signed using the private key and sent to the authentication server 20. In step 218, the authentication server 20 verifies the signature using the public key stored in the cryptographic key storage 40. In step 219, the authentication session context is returned to the requesting computer program/application at device 10 (or device 15 if the requesting device is a registered device). The user employing device 10 (or device 15) may then be redirected/given access to the desired computer program/application.

In some instances, the user has successfully logged into the application, and once within the application, the user desires to access a resource within the application, such as to perform some activity within the application. The framework of the present invention can be used to assess whether a resource can be accessed within an existing authentication session or whether the risk associated with the requested resource requires additional authentication. For example, a user may have been permitted to log in to an application using an existing authentication session (e.g., due to the low risk nature of the application at login), but now seeks to complete a transaction that may be associated with more risk. The risk engine 30 may be used to determine whether a desired activity (e.g., a transaction) may be permitted or whether further verification of the certificate is required. To accomplish this, the functionality of the risk engine 30 is extended to the active portion of the application such that the risk engine will be employed to assess the risk associated with the desired activity. In one embodiment, the functionality of the risk engine may be made available to the application as an Application Programming Interface (API). When a user indicates a desire within an application to perform a particular activity, the application calls an authenticator API that invokes the authentication server 20, thereby invoking the functionality of the risk engine 30 to assess the risk associated with the transaction. More particularly, the authentication server 20 identifies the end user, creates a one-time password, and sends it back to the API where the application displays the one-time password via the accessing application. In parallel, the authentication server 20 initiates a notification to the registered device(s) 15 of the end user. Any registered devices 15 that are online receive and display the notification. The user selects one device and initiates authentication (by using the touch identification, e.g. plus verifying a previously provided one-time password). Authentication server 20 receives the registered device decision (i.e., yes or no), adds the decision of risk engine 30 to it, and then responds back to the API with a signed session token, either authorizing the request or denying it. The API responds to the application accordingly. As described above, different types of transactions desired by the user may be assigned different weights, and those weights used in conjunction with risk assessment.

Embodiments of the present invention are directed to improvements over existing systems and address several technical problems existing in the prior art. For example, in existing solutions that provide a single sign-on between, for example, a native application and a Web application, if there is a shared session context, it is reused. In connection with the present invention, the risk engine determines whether a new authentication session is required before providing access. This improves the operation of computer technology as it allows a user to enter a previous authentication event with a new authentication event in a continuous manner as the user moves from one application to another and from one device to another. Further, upon completion of any successful authentication events, an industry standard security token (e.g., a SAML or OAUTH token) is generated for each single sign-on request. These tokens are accepted by most applications, their contents are signed, and they are only single use. The present invention does not rely on a pre-existing authenticated key that continues to be shared. All end users have their own keyset that is established through the registration process as previously described. This improves the operation of computer technology because it uses hardware-stored passwords to assert user identity across multiple devices in an unobtrusive manner. Still further, embodiments of the present invention represent an improvement over the prior art in that the present invention does not involve a mere binary decision as to whether to grant access based on the session context. In connection with embodiments of the invention, the context of the access rights is considered simultaneously with the authentication or even after the authentication, e.g. at the time of the access request. This represents a significant improvement over the prior art, as continued consideration of factors such as device type, location and application context awareness increases the usefulness of the platform, as it allows the platform architect to easily combine applications of different risk levels without compromising security.

The solution allows cryptographic trust of the user identity without hosting any user biometrics or other identity information on the backend. It also allows for single sign-ins of multiple applications across multiple devices (including mobile devices), applications, and services while controlling and managing the associated risks.

An exemplary use case of the present invention is described below.

Receiving at a processing component from a requesting device operated by an end user: the data describes a request for access to a computer program. The requesting device may be a registered device or may be another device.

The processing component determines whether there is an existing authentication session for the end user. The existing authentication session may have been previously established in one of several different ways.

For example, the end user may authenticate (e.g., using a biometric feature or password) to the registered device prior to or at the beginning of the end user's work day (e.g., at home before he leaves the office or during his commute). After having done so, the end user may be able to seamlessly and automatically access all applications needed throughout his workday without having to log in/authenticate again, assuming that the risk engine makes this determination based on its assessment (e.g., the end user's location when authenticating to his registered device is within a reasonable distance from his office; the time of authentication is within the same workday; and the applications sought to be accessed by the end user throughout the end user's workday are not highly sensitive/critical from a security perspective).

In another example, an existing authentication session may be established by: the end user logs into the computer application in a typical manner (e.g., username and password) or the end user authenticates to the registered device in a previous session in response to a prompt from the authentication server 20. In each such case, in conjunction with determining whether a new authentication is required for the current access request, the existing authentication is rated in terms of how it is established as described in more detail herein (e.g., the modality of the authentication, including the device used for authentication; the location and time of the authentication, and the computer program being rated).

Returning now to the flow, the end user is prompted for authentication based on a determination that an existing authentication session for the end user does not exist. This may be accomplished in the manner described herein, in the typical manner in which end users access computer programs (e.g., via a username and password), or by using a registered device 15.

In accordance with a determination that an existing authentication session exists for the end user, it is determined whether one or more request characteristics satisfy one or more computer program access criteria.

The request characteristics may include device authentication weights. The device authentication weights may be calculated based on the modality through which the end user authenticates with the registered device (e.g., biometric feature or password) and/or the security rating of the registered device (e.g., how secure the device is generally). Thus, for example, if the device is generally secure (e.g., no known leaks or access holes) and the end user authenticated the device using biometric features during enrollment, the device authentication weight will be higher. Thus, for example, if an existing authentication session is created when a device with a higher authentication weight is employed, it may be more likely that re-authentication is not required for the currently requested access to the computer program.

The request characteristics may also include the location of the requesting device. For example, it may be considered whether the end user makes a request from a location reasonably and realistically in close proximity to a previously logged-on/established location of an existing authentication session. The request characteristics may also include a rating of the time that has elapsed between the establishment of the existing authentication session and the current access request (e.g., whether too much time has elapsed).

The computer program access criteria may include a minimum authentication weight associated with the computer program seeking access, which may be determined based on the criticality of the computer application (e.g., computer applications that are more sensitive or critical from a security perspective will be weighted higher and thus have stricter authentication requirements).

Access to the computer program is provided to the requesting device in accordance with a determination that the one or more request characteristics satisfy the one or more computer program access criteria. From the end user's perspective, access is provided seamlessly and automatically without further authentication of the end user.

In accordance with a determination that the one or more request characteristics do not satisfy the one or more computer program access criteria, prompting the end user to perform an authentication activity. In response to receiving data indicative of the end user having performed an authentication activity (e.g., biometric data of the end user or a password selected by the end user; and in some instances a one-time password provided by the processing component after receiving a request for access from the requesting device), a new authentication session is established for the end user and access to the computer program is provided to the requesting device.

In one example, consideration of the request characteristics and the computer program access criteria indicates that: the risk assessment is a negative determination when the device authentication weight does not exceed a minimum authentication weight associated with the computer program (e.g., the manner in which the registered device is authenticated and/or the registered device itself is not sufficiently secure).

In another example, consideration of the request characteristics and the computer program access criteria indicates that: the risk rating is a negative determination when a distance between a first location of a requesting device at the time the access request is sent and a second location of another device at the time the existing authentication session is created exceeds a distance threshold (e.g., the end user cannot travel the distance between the location where the existing authentication session was created and the location where the access request was made within an elapsed period of time).

In some embodiments, consideration of the request characteristics and the computer program access criteria indicates that: the risk assessment is a negative determination when a time period between a first time when the access request is sent and a second time when an existing authentication session is created exceeds a time period threshold (e.g., too much time has passed between when the authentication session was created by the end user and when the end user requested access to the computer program).

The exemplary method of embodiments of the present invention may be implemented by a system comprising: the system employs a client/server architecture, such as, for example, the collection of components illustrated and described with reference to fig. 1. Such an exemplary embodiment is described in more detail below with reference to fig. 3. Data that may be used as input to the system, as well as output from the system, may be stored in one or more databases 301 (e.g., rules/weights store 45 or password store 40). Database server(s) 302 may include database service management application 303, which manages the storage and retrieval of data from database(s) 301. Database 301 may be a relational database; however, other data organization structures may be used without departing from the scope of the invention.

One or more application servers 304 (e.g., authentication server 20 and/or risk engine 30) are in communication with database server 302. Application server 304 transmits a request for data to database server 302. Database server 302 retrieves the requested data. Application server 304 may also send data to database server 302 for storage in database(s) 301. The application server 304 includes one or more processors 305, a non-transitory computer-readable storage medium 307 storing programs (computer-readable instructions) for execution by the processor(s), and an interface 306 between the processor(s) 305 and the computer-readable storage medium 307. The application server 304 may store the computer programs mentioned herein.

To the extent that data and information are communicated over a network (e.g., the Internet or an intranet), one or more web servers 308 can be employed. The network server 308 also includes one or more processors 309, a computer-readable storage medium 311 storing a program (computer-readable instructions) for execution by the processor(s), and an interface 310 between the processor(s) 309 and the computer-readable storage medium 311. Web server 308 is employed to deliver content that may be accessed over communication network 312, for example, by an end user employing computing device 313 (e.g., device(s) 10, 15). When data is requested through an application, such as an internet browser, the web server 308 receives and processes the request. The web server 308 transmits the requested data or application along with user interface instructions for displaying a user interface on the device 313 (e.g., device(s) 10, 15).

The computers referred to herein are specifically programmed to perform the functionality described herein.

Non-transitory computer-readable storage media (e.g., 307 or 311) storing a program (i.e., a software module including computer-readable instructions) may include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules or other data. Computer-readable storage media may include, but are not limited to, RAM, ROM, erasable programmable ROM (eprom), electrically erasable programmable ROM (eeprom), flash memory or other solid state memory technology, CD-ROM, Digital Versatile Disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed and processed by a computer system.

In at least one embodiment, one or more computers are included having one or more processors and memory (e.g., one or more non-volatile storage devices). In some embodiments, memory or a computer-readable storage medium of memory stores programs, modules and data structures, or a subset thereof, for use by a processor in controlling and executing the various systems and methods disclosed herein. In one embodiment, a non-transitory computer-readable storage medium has stored thereon computer-executable instructions that, when executed by a processor, perform one or more methods disclosed herein.

It will be appreciated by those skilled in the art that changes could be made to the exemplary embodiments shown and described above without departing from the broad inventive concept thereof. It is understood, therefore, that this invention is not limited to the exemplary embodiments shown and described, but it is intended to cover modifications within the spirit and scope of the present invention as defined by the appended claims. For example, particular features of the exemplary embodiments may or may not be part of the claimed invention, and features of the disclosed embodiments may be combined. Unless specifically set forth herein, "a," an, "and" the "are not limited to one element, but instead should be understood to mean" at least one.

It is to be understood that at least some of the figures and descriptions of the present invention have been simplified to focus on elements that are relevant for a clear understanding of the present invention, while eliminating, for purposes of clarity, other elements that those of ordinary skill in the art will appreciate may also form part of the present invention. However, because such elements are well known in the art, and because they do not necessarily facilitate a better understanding of the invention, a description of such elements is not provided herein.

Furthermore, to the extent that the method does not rely on the particular order of steps set forth herein, the particular order of steps should not be construed as limitations on the claims. The claims directed to the method of the present invention should not be limited to the performance of their steps in the order written, and one skilled in the art can readily appreciate that the steps may be varied and still remain within the spirit and scope of the present invention.

Claims

1. A computerized method comprising:

receiving at a processing component from a requesting device operated by an end user: the data describing a request for access to a computer program;

determining, by a processing component, whether an existing authentication session exists for an end user;

prompting the end user to authenticate to the processing component based on a determination that there is no existing authentication session for the end user;

performing a risk assessment based on a determination that there is an existing authentication session for the end user, the risk assessment including consideration of one or both of: (i) one or more request characteristics associated with a request for access to a computer program, and (ii) one or more computer program access criteria;

providing access to the computer program to the requesting device in accordance with a determination that the risk assessment is positive;

in response to receiving data indicating that the end user performed the authentication activity and that the authentication activity was successful, establishing a new authentication session for the end user and providing access to the computer program to the requesting device.

2. The computerized method of claim 1, wherein the data indicative of the end user performing the authentication activity comprises biometric data of the end user.

3. The computerized method of claim 1, wherein the data indicating that the end user performed the authentication activity comprises a password selected by the end user.

4. The computerized method of claim 1, wherein the data indicating that the end user performed the authentication activity comprises a one-time password provided by the processing component after receiving the access request from the requesting device.

5. The computerized method of claim 1, further comprising:

receiving a registration request from an end user at a processing component;

creating, by a processing component, a unique registration token;

creating, by a processing component, a database record comprising an identifier for an end user and a unique registration token;

providing, by a processing component, to a registration device a mechanism for accessing an authentication application for initiating registration of the registration device;

receiving, from an end user through an authentication application, an identifier for the end user and a unique registration token;

collecting identifiers associated with registered devices;

receiving a public key from a registration device, the public key forming part of a cryptographic key pair, the cryptographic key pair being created upon authentication of an end user with the registration device, wherein the registration device stores a private key of the cryptographic key pair;

calculating, by a processing component, a device authentication weight;

the public key and the device authentication weight are stored in a database by the processing component.

6. A computerized method according to claim 5 wherein prior to the step of receiving data describing a request for access to a computer program, an existing authentication session for the end user is established using the registration device.

7. The computerized method of claim 5, wherein the requesting device comprises a registered device.

8. The computerized method of claim 5, wherein the requesting device comprises a device other than a registered device.

9. The computerized method of claim 1, wherein consideration of the one or more computer program access criteria indicates a determination that a risk assessment is negative regardless of consideration of the one or more request characteristics.

10. The computerized method of claim 1, wherein consideration of the one or more request characteristics indicates a determination that a risk assessment is negative regardless of consideration of the one or more computer program access criteria.

11. The computerized method of claim 1, wherein the one or more computer program access criteria comprise a minimum authentication weight associated with a computer program.

12. The computerized method of claim 5, wherein the one or more request characteristics include a device authentication weight.

13. The computerized method of claim 1, wherein the one or more request characteristics include a location of a requesting device.

14. The computerized method of claim 1, wherein the one or more request characteristics include a time that has elapsed since an existing authentication session was established.

15. The computerized method of claim 5, wherein the one or more requesting characteristics include whether a requesting device is a registered device.

16. The computerized method of claim 5, wherein the device authentication weight is calculated based on a modality by which an end user authenticates with a registered device.

17. The computerized method of claim 5, wherein the device authentication weight is calculated based on a security assessment of a registered device.

18. The computerized method of claim 11, wherein the minimum authentication weight is determined based on a criticality of the computer program.

19. The computerized method of claim 5, wherein the processing component receives a public key associated with an end user performing an authentication activity.

20. The computerized method of claim 1, further comprising:

receiving at a processing component from a requesting device: the data describes a request for access to a resource within a computer program; and

determining whether one or more request characteristics satisfy one or more computer program resource access criteria, wherein the one or more computer program resource access criteria include a minimum authentication weight associated with a resource.

21. The computerized method of claim 1, wherein the existing authentication session is established in connection with an end user accessing another computer program that is not the subject of the access request.

22. The computerized method of claim 20, wherein the one or more request characteristics include a modality in which an existing authentication session related to accessing another computer program is established.

23. The computerized method of claim 1, wherein the computer program is a native application.

24. The computerized method of claim 1, wherein the computer program is a web-based application.

25. The computerized method of claim 1, wherein the computer program is an operating system of a requesting device.

26. The computerized method of claim 5, wherein consideration of the one or more request characteristics and computer program access criteria indicates that: the risk assessment is a negative determination when the device authentication weight does not exceed a minimum authentication weight associated with the computer program.

27. The computerized method of claim 1, wherein consideration of the one or more request characteristics and computer program access criteria indicates that: the risk assessment is a negative determination when a distance between a first location of the requesting device at the time the access request is sent and a second location of another device at the time an existing authentication session is created exceeds a distance threshold.

28. The computerized method of claim 1, wherein consideration of the one or more request characteristics and computer program access criteria indicates that: the risk assessment is a negative determination when a time period between a first time at which the access request is sent and a second time at which an existing authentication session is created exceeds a time period threshold.

29. A system, comprising:

a processing component configured to:

receiving the following data from a requesting device operated by an end user: the data describing a request for access to a computer program;

determining whether an existing authentication session exists for the end user;

a risk engine configured to:

performing a risk assessment based on a determination that there is an existing authentication session for the end user, the risk assessment including consideration of one or both of: (i) one or more request characteristics, and (ii) one or more computer program access criteria;

the processing component is further configured to: