Patent Description:
Cloud computing offers businesses cost-effective access to virtually unlimited computing power and storage, rather than the businesses purchasing and/or maintaining physical computing resources. As such, many businesses offer services that are performed at distributed and/or remote locations. Since many services include use of private information of a user, such as personal and/or financial information, security is critical for many services offered via cloud computing. However, the distributed nature of cloud computing can increase the complexity of security issues. Therefore, the increasing use of cloud computing by businesses warrants improved methods for customer protection.

Approaches to determining authentication frequency and challenge type for authenticating a user are set out in <CIT> and <CIT>.

In some cases, parentheticals are utilized after a reference number to distinguish like elements. Use of the reference number without the associated parenthetical is generic to the element.

This disclosure describes, at least in part, techniques that may be implemented by an authentication entity that is coupled to one or more user devices and one or more online services. For instance, the authentication entity may provide an interface through which a user device of a user may be authenticated for access to the online service(s). The authentication entity may help the online service(s) trust the user device of the user to allow access to the online service(s) through the use of credentials associated with the user. For example, the authentication entity may provide the user with single sign-on (SOO) authentication, where the user device of the user is authenticated using at least the credentials. In some instances, the authentication entity may further use multi-factor authentication when authenticating the user device for the online service(s). Once the authentication entity authenticates the user device, the authentication entity may provide the user with data, such as a token, that the user device is able to use to access each of the online service(s) during a session. The session may be associated with a duration for which the token is valid for accessing the online service(s). Once the duration of the token expires, the authentication entity may require that the user device be re-authenticated using at least the credential (and/or the multi-factor authentication).

For more detail, the user may use the user device to attempt to log in to an online service. To log in to the online service, the user device may receive inputs representing the credentials (e.g., a username, a password, etc.) and send the credentials to the online service. The online service may then communicate with the authentication entity to determine if the user device can be trusted. In some instances, the authentication entity uses the credentials to authenticate the user device as a trusted device for the online service. For example, the authentication entity may match the credentials to additional credentials that are stored in association with a user account. Additionally, or alternatively, in some instances, the authentication entity performs multi-factor authentication to authenticate the user device as the trusted device for the online service. For example, the authentication entity may generate an authentication request and send the authentication request to the user (e.g., via email, a message, an application, etc.). The authentication request may include, but is not limited to, a code, a question, a password, a push notification, and/or any other factor that may be used to authenticate the user device. The authentication entity may then receive, from the user device and/or another device, a response to the authentication request and authenticate the user device using the response.

After authenticating the user device, the authentication entity may generate authentication data (e.g., a token, a cookie, etc.) that the user device can use to access the online service, as well as one or more other online services, during a session. The authentication data may include at least a duration for which the authentication data is valid to access the online service(s) during the session. After generating the authentication data, the authentication entity may send the authentication data to the user device. The user device is then able to use the authentication data to access the online service(s) during the session. For example, the user device may send the authentication data to the online service(s) during the session, where the online service(s) use the authentication data to trust the user device. After trusting the user device, the user device is able to use resources provided by the online service(s). However, at the expiration of the duration, the authentication data may no longer be valid to authenticate the user device and, as such, the authentication entity may require re-authentication of the user device.

The duration that the authentication data is valid may be important for one or more reasons. For a first example, if the duration is too short, the authentication entity may require that the user device be re-authenticated multiple times while the user is accessing the online service(s) during a period of time, such as during an hour, a day, a week, and/or the like. This may cause problems, such as being burdensome to the user as well as requiring computing resources to continuously authenticate the user device. For a second example, if the duration is too long, the authentication entity may not require that the user device be re-authenticated for an extended period of time. This may also cause problems, such as the authentication data being compromised during the session (e.g., retrieved by an unauthorized device during the session) and used to gain unauthorized access to the online service(s) of the user. As such, the authentication entity described herein may use one or more techniques in order to determine the duration of the session.

For instance, the authentication entity may use a set duration if this is the first time that the user device has been authenticated for a session. The set duration may include, but is not limited to, one hour, twelve hours, one day, one week, and/or any other period of time. The authentication entity may then update the duration each time the authentication entity authenticates the user device for a new session. In some instances, the authentication entity updates the duration by increasing or decreasing a previous duration for a previous session. Additionally, or alternatively, in some instances, the authentication entity updates the duration by once again using the set duration. In either of the instances, the authentication entity may use information associated with an environment of the user device when updating the durations for the user device.

For instance, a component (e.g., an application) executing on the user device may analyze the environment in order to determine one or more characteristics associated with a state of the environment. As described herein, the characteristic(s) may include, but are not limited to, a unique device identifier associated with the user device, hardware associated with the user device (e.g., hardware installed on the user device), software installed on the user device, one or more applications that are active on the user device, central processing unit (CPU) usage associated with the user device, memory usage associated with the user device, an Internet Protocol (IP) address associated with the user device, power consumption associated with the user device, a type of network connection associated with the user device, one or more other devices for which the user device is communicating (e.g., via Bluetooth, WiFi, etc.), sensor data representing a user of the user device, and/or the like. In some instances, the information sent to the authentication entity represents the characteristic(s). Additionally, or alternatively, in some instances, the information sent to the authentication entity represents one or more transitions associated with the environment.

For example, the component may compare the characteristic(s) associated with the environment to one or more previous characteristics associated with the environment. In some instances, the component determined the previous characteristic(s) during one or more previous sessions for which the user device was authenticated. Based on the comparison, the component may identify transition(s) between a current state of the environment and state(s) of the environment during the previous session(s) when the authentication entity authenticated the user device. As described herein, the transition(s) may include, but are not limited to, a change in the unique device identifier, a change in the hardware associated with the user device, a change in the software installed on the user device, a change in the one or more applications that are active on the user device, a change in the CPU usage associated with the user device, a change in the memory usage associated with the user device, a change in the IP address associated with the user device, a change in the power consumption associated with the user device (e.g., whether the user device was continuously receiving power or whether the user device stopped receiving power for period(s) of time), a change in the type of network connection associated with the user device, a change in the user of the user device (as determined using the sensor data), and/or any other state change.

In instances where the information represents the characteristic(s) associated with the environment, the authentication entity may perform similar processes as the component in order to identify the transition(s). For example, the authentication entity may store additional information representing the previous characteristic(s) associated with the environment. In some instances, the authentication entity stores the information each time the authentication entity receives such information from the user device and/or each time the authentication entity authenticates the user device. The authentication entity may then compare the characteristic(s) associated with the environment to the previous characteristic(s) in order to identify the transition(s) between the current state of the environment and the state(s) of the environment during the previous session(s) when the authentication entity authenticated the user device.

In either of the examples above, the authentication entity may use the transition(s) in order to determine the durations. For a first example, if the transition(s) indicate that the current state of the environment is similar to previous state(s) of the environment, then the authentication entity may determine the duration by increasing a previous duration associated with a previous session. In some instances, the greater the similarities between the current state of the environment and the previous state(s) of the environment, the greater the increase that the authentication entity uses when determining the duration. For a second example, if the transition(s) indicate that the current state of the environment is different than the previous state(s) of the environment, then the authentication entity may determine the duration by decreasing the previous duration associated with the previous session. In some instances, the greater the differences between the current state of the environment and the previous state(s) of the environment, the greater the decrease that the authentication entity uses when determining the duration.

In some instances, the authentication entity may determine that the transition(s) indicate that the current state of the environment is similar to the previous state(s) of the environment when there is little variance between the compared characteristic(s). For a first example, if the transition(s) only indicate a small change in the CPU usage (e.g., <NUM>%, <NUM>%, <NUM>%, etc.) and/or a small change in the memory usage (e.g., <NUM>%, <NUM>%, <NUM>%, etc.), then the authentication entity may determine that the current state of the environment is similar to the previous state(s) of the environment. For a second example, if the transition(s) only indicate that a new software application was activated on the user device, then the authentication entity may determine that the current state of the environment is still similar to the previous state(s) of the environment. However, the authentication entity may determine that the similarity in the first example is greater than the similarity in the second example and, as such, the authentication entity may increase the duration by a greater amount in the first example than in the second example.

In some instances, the authentication entity may determine that the transition(s) indicate that the current state of the environment is different to the previous state(s) of the environment when there is a large variance between the compared characteristic(s). For a first example, if the transition(s) indicate a large change in the CPU usage (e.g., <NUM>%, <NUM>%, <NUM>%, etc.) and/or a large change in the memory usage (e.g., <NUM>%, <NUM>%, <NUM>%, etc.), then the authentication entity may determine that the current state of the environment is different from the previous state(s) of the environment. For a second example, if the transition(s) indicate that the user device is using a new IP address and/or has a new unique device identifier, then the authentication entity may again determine that the current state of the environment is different from the previous state(s) of the environment. However, the authentication entity may determine that the difference in the second example is greater than the difference in the first example and, as such, the authentication entity may decrease the duration by a greater amount in the second example than in the first example.

In some instances, the authentication entity may analyze the information in order to identify "triggering events" associated with the environment of the user device. As described herein, a triggering event may include, but is not limited to, a change in the user of the user device (determined using image data, biometric data, etc.), malicious hardware/software identified on the user device (e.g., malware), a change in the unique device identifier, a change in the IP address, an unsecured network connection (e.g., the user device connected to a public and unsecured network, and/or the like. In some instances, when the authentication entity identifies a triggering event, the authentication entity may require that the user device be re-authenticated (either using the credentials and/or by performing multi-factor authentication). Additionally, or alternatively, in some instances, when the authentication entity identifies the triggering event, the authentication entity may determine the duration as the set duration and/or determine the duration by decreasing the previous duration.

In the examples above, and in some instances, the authentication entity may receive the information from the user device each time the authentication entity authenticates the user device for the online service(s). Additionally, or alternatively, in some instances, the authentication entity may receive the information at various times. For example, the authentication entity may receive the information at given time intervals during a session, continuously during a session, each time there is a period of inactivity between the user device and the online service(s), and/or at any other time. Additionally, or alternatively, in some instances, the authentication entity may receive the information based on sending, to the user device, a request for the information.

For example, after authenticating the user device for a session, the authentication entity may determine a duration (e.g., <NUM> hours) associated with the session. However, during the session (e.g., <NUM> hours into the session), the authentication entity may again perform an authentication of the user device (e.g., using the processes described herein). Based on that authentication, the authentication entity may determine whether to update the duration, such as to decrease the duration (e.g., to <NUM> hours) or increase the duration (e.g., to <NUM> hours) from the time of the original authentication. As such, the authentication may use the new duration when determining when to once again reauthenticate the user device. For example, if the authentication entity decreases the duration, then authentication entity may determine to reauthenticate the user device after <NUM> hours elapses from the original authentication. Additionally, if the authentication entity increases the duration, then authentication entity may determine to reauthenticate the user device after <NUM> hours elapses from the original authentication.

For another example, the authentication entity may again authenticate the user device for a first session that includes a first duration (e.g., <NUM> hours). However, at a time during the first session (e.g., <NUM> hours into the first session), the authentication entity may determine a second duration for a second session. If the second duration (e.g., <NUM> hours) is less than the time into the first session (e.g., <NUM> hours into the first session), then the authentication entity may determine to reauthenticate the user device immediately. However, if the second duration (e.g., <NUM> hours) is greater than the time into the first duration (e.g., <NUM> hours into the first session), then the authentication entity may determine not to reauthenticate the user device for the second duration (e.g., <NUM> hours after the start of the first duration).

Additionally, in the examples above, the component executing on the user device and/or the authentication entity may use one or more machine learned models to identify the transition(s) associated with the current state of the environment. For example, the machine learned model(s) may be configured to analyze characteristic(s) associated with the environment of the user device, such as each time the component determines the characteristic(s). Based on the analysis, the machine learned model(s) identify (e.g., learn) characteristic(s) that remain substantially constant. For example, the machine learned model(s) may identify that the user device usually uses the same IP address, usually uses the same unique device identifier, includes a CPU usage that falls within a given range, includes application(s) that are usually active on the user device, and/or the like. The component and/or the authentication entity may then compare new characteristic(s) to the learned characteristic(s) in order to identity the transition(s). When using machine learned model(s) to identify the transition(s), the transition(s) may correspond to "anomalies" with the user device. The authentication entity may thus use these anomalies when determining the durations.

For example, if the authentication entity determines that the anomalies are minor, then the authentication entity may determine a duration by increasing a previous duration associated with the user device. In some instances, the authentication entity may determine that the anomalies are minor using similar processes as described above with respect to the state changes. For instance, the authentication entity may determine that the anomalies are minor based on the anomalies indicating that the current state of the environment is similar to the previous state(s) of the environment. For another example, if the authentication entity determines that the anomalies are major, then the authentication entity may determine a duration by decreasing a previous duration associated with the user device. In some instances, the authentication entity may determine that the anomalies are major using similar processes as described above with respect to the state changes. For instance, the authentication entity may determine that the anomalies are major based on the anomalies indicating that the current state of the environment is different than the previous state(s) of the environment.

Although the examples described herein may refer to a user device and/or an authentication entity as participating in a multi-party cloud authentication system in a cloud networking environment, the techniques can generally be applied to any device or role, including an enterprise workforce scenario. Further, the techniques are generally applicable for any network of devices managed by any entity where virtual resources are provisioned. In some instances, the techniques may be performed by software-defined networking (SDN), and in other examples, various devices may be used in a system to perform the techniques described herein. The user devices by which the techniques are performed herein are a matter of implementation, and the techniques described are not limited to any specific architecture or implementation.

The techniques described herein provide various improvements and efficiencies with respect to network communications. For instance, the techniques described herein may reduce the amount of computational resource use, storage, dropped data, latency, and other issues experienced in networks due to lack of network resources, overuse of network resources, issues with timing of network communications, and/or improper routing of data. By improving network communications across a network, overall performance by servers and virtual resources may be improved.

Certain implementations and embodiments of the disclosure will now be described more fully below with reference to the accompanying figures, in which various aspects are shown. However, the various aspects may be implemented in many different forms and should not be construed as limited to the implementations set forth herein. The disclosure encompasses variations of the embodiments, as described herein.

<FIG> illustrates an example environment <NUM> in accordance with the present cloud authentication concepts. The example environment <NUM> may include a cloud computing network <NUM> (e.g., network), one or more user devices <NUM>, one or more server devices <NUM>, and/or one or more authentication devices <NUM> (e.g., an authentication entity). Parentheticals are utilized after a reference number to distinguish like elements. Use of the reference number without the associated parenthetical is generic to the element. For example, <FIG> includes two instances of a user device <NUM>, including the user device <NUM>(<NUM>), which may represent a desktop computer, and the user device <NUM>(<NUM>), which may represent a mobile phone. In some scenarios, multiple user devices <NUM> may be associated with a single user. The server device(s) <NUM> may provide a remote, online service that the user wishes to engage via at least the user device <NUM>(<NUM>). Additionally, the authentication device(s) <NUM> may perform authentication entity function(s) to authenticate the user device <NUM>(<NUM>) for the server device(s) <NUM>.

In some examples, the environment <NUM> comprises a data center or cloud-computing network comprising servers and other network components (e.g., routers, switches, etc.) stored across multiple data centers located across geographic areas. In these instances, the cloud-computing environment may be a distributed network through which users (often customers) may interact via user devices to manage or otherwise interact with service provided by the cloud computing network. The cloud computing network may provide on-demand availability of computing system resources, such as data storage, computing power (e.g., CPU, GPU, etc.), networking, databases, etc., without direct active management by users. In some examples, the cloud computing network may be managed and maintained by a service provider such that users do not have to invest in and maintain the computing infrastructure for their computing resource needs. Generally, a user may be provided access to, or allocated use of, a portion of the computing resources in the cloud computing network. The cloud computing network may scale, such as by spinning up resources or spinning down resources, based on demand for the individual users. The portions of the cloud computing network may be allocated using hardware virtualization such that portions of the cloud computing network can be configured and managed by the user (e.g., security configuration, load balancing configuration, etc.). However, the cloud computing network need not be managed by a service provider, and can be managed by any entity, including the user themselves that run the applications or services.

The user device(s) <NUM>, server device(s) <NUM>, and/or authentication device(s) <NUM> may be communicatively coupled among one another and/or to various other devices via cloud computing network <NUM>. Within the example environment <NUM>, a user device <NUM>, a server device <NUM>, an authentication device <NUM>, and/or other devices may exchange communications (e.g., packets) via a network connection(s) to cloud computing network <NUM>, indicated by double arrows <NUM>. For instance, network connections <NUM> may be transport control protocol (TCP) network connections or any network connection (e.g., information-centric networking (ICN)) that enable the devices to exchange packets with other devices via cloud computing network <NUM>. The network connections <NUM> represent, for example, a data path between a user device <NUM> and the authentication device(s) <NUM>. For example, the user device <NUM> may be a computer, laptop, mobile device, tablet, etc., while the server device(s) <NUM> and/or the authentication device(s) <NUM> may be configured to provide data and/or network services to the user device <NUM>. The server device(s) <NUM> and/or authentication device(s) <NUM> may or may not be a producer, a point of generation and/or origination of the data. For instance, the data may originate elsewhere for the server device(s) <NUM> and/or the authentication device(s) <NUM> to be able to provide to the user device <NUM>. Additionally, or alternatively, the data may pass through other network devices (e.g., router, switch) on a path from the server device(s) <NUM> and/or the authentication device(s) <NUM> to the user device <NUM>. It should be appreciated that the term "network connection" may also be referred to as a "network path. " The use of a cloud computing network in this example is not meant to be limiting. Other types of networks are contemplated in accordance with multi-party cloud authentication concepts.

At "Step <NUM>," the user device <NUM>(<NUM>) may communicate with the server device(s) <NUM>. The communication at Step <NUM> may include the user device <NUM>(<NUM>) attempting to log in to an account (e.g., email account, messaging account, ect. ) associated with the server device(s) <NUM>. For instance, the user device <NUM>(<NUM>) may receive input(s) representing credentials <NUM> associated with the account. The credentials <NUM> may include, but are not limited to, a username and password associated with the account. The user device <NUM>(<NUM>) may then send the credentials <NUM> to the server device(s) <NUM>. In some instances, based on receiving the credentials <NUM>, the server device(s) <NUM> may authenticate the user device <NUM>(<NUM>). For example, the server device(s) <NUM> may match the credentials <NUM> to additional credentials stored in association with the account. Additionally, or alternatively, in some instances, the server device(s) <NUM> may determine to use the authentication device(s) <NUM> to authenticate the user device <NUM>(<NUM>) as a trusted device.

For example, at "Step <NUM>," the server device(s) <NUM> may communicate with the authentication device(s) <NUM>. The communication at Step <NUM> may include the server device(s) <NUM> sending, to the authentication device(s) <NUM>, the credentials <NUM> and/or other data that identifies the user device <NUM>(<NUM>). In some instances, the authentication device(s) <NUM> may use the credentials <NUM> to authenticate the user device <NUM>(<NUM>), similar to the server device(s) <NUM> described above. Additionally, or alternatively, in some instances, the authentication device(s) <NUM> may determine to use multi-factor authentication in order to authenticate the user device <NUM>(<NUM>). In such instances, although not illustrated in the example of <FIG>, the authentication device(s) <NUM> may communicate with the user device <NUM>(<NUM>) in order to select how the authentication device(s) <NUM> are to provide an authentication request <NUM> associated with the multi-factor authentication. For example, the authentication device(s) <NUM> may allow the user to select either email, text message, push notification, and/or the like for sending the authentication request <NUM>.

At "Step <NUM>," the authentication device(s) <NUM> may communicate with the user device <NUM>(<NUM>). The communication at Step <NUM> may include providing the user device <NUM>(<NUM>) with the authentication request <NUM> via the selected type of communication. The user device <NUM>(<NUM>) may then receive input(s) representing a response <NUM> to the authentication request <NUM>. For a first example, if the authentication request <NUM> includes a code that is emailed to the user, then the response <NUM> may include the emailed code. For a second example, if the authentication request <NUM> includes a question for the user, then the response <NUM> may include the answer to the question. Still, for a third example, if the authentication request <NUM> includes a push notification, then the response <NUM> may include the user selecting an interface element, such as a button, associated with the push notification. In either of the examples, the user device <NUM>(<NUM>) may then send the response <NUM> back to the authentication device(s) <NUM>.

The authentication device(s) <NUM> may then use the response <NUM> to authenticate the user device <NUM>(<NUM>) via the multi-factor authentication. For example, the authentication device(s) <NUM> may determine that the response <NUM> to the authentication request <NUM> is correct. The authentication device(s) <NUM> may then generate authentication data <NUM>, such as a token, a cookie, and/or the like, that the user device <NUM>(<NUM>) may use to access the one or more services provided by the server device(s) <NUM>. As shown in the example of <FIG>, the authentication data <NUM> includes at least a duration <NUM> for which the authentication data <NUM> is valid. For example, during the duration <NUM> of the authentication data <NUM>, the user device <NUM>(<NUM>) may use the authentication data <NUM> to access the resources provided by the server device(s) <NUM>. For instance, the server device(s) <NUM> may receive the authentication data <NUM> from the user device <NUM>(<NUM>) and use the authentication data <NUM> to determine that the user device <NUM>(<NUM>) is trusted. However, at the expiration of the duration <NUM>, the user device <NUM>(<NUM>) may no longer be able to access the resources provided by the server device(s) <NUM> using the authentication data <NUM>. Rather, the user device <NUM>(<NUM>) may be required to reauthenticate with the authentication device(s) <NUM>.

To determine the duration, and at "Step <NUM>," the authentication device(s) <NUM> may communicate with the user device <NUM>(<NUM>). The communication at Step <NUM> may include the authentication device(s) <NUM> requesting information <NUM> from the user device <NUM>(<NUM>) that the authentication device(s) <NUM> use to determine the duration <NUM>. Based on the request, a state component <NUM> (e.g., an application executing on the user device <NUM>(<NUM>)) may analyze the environment in order to determine one or more characteristics <NUM> associated with a state of the environment. As described herein, the characteristic(s) <NUM> may include, but are not limited to, a unique device identifier <NUM> associated with the user device <NUM>(<NUM>), hardware <NUM> associated with the user device <NUM>(<NUM>) (e.g., hardware <NUM> installed on the user device <NUM>(<NUM>)), software <NUM> installed on the user device <NUM>(<NUM>), one or more applications <NUM> that are active on the user device <NUM>(<NUM>), central processing unit (CPU) usage associated with the user device <NUM>(<NUM>), memory <NUM> usage associated with the user device <NUM>(<NUM>), an IP address associated with the user device <NUM>(<NUM>), power consumption associated with the user device <NUM>(<NUM>), a type of network connection associated with the user device <NUM>(<NUM>), one or more other devices for which the user device <NUM>(<NUM>) is communicating (e.g., via Bluetooth, WiFi, etc.), sensor data <NUM> representing a user of the user device <NUM>(<NUM>), and/or the like. In some instances, the information <NUM> may represent the characteristic(s) <NUM> associated with the environment.

Additionally, or alternatively, in some instances, the state component <NUM> may compare the characteristic(s) <NUM> associated with the current state of the environment to one or more previous characteristics <NUM> associated with one or more previous states of the environment. In some instances, the state component <NUM> determined the previous characteristic(s) during one or more previous sessions for which the user device <NUM>(<NUM>) was authenticated. Based on the comparison, the state component <NUM> may identify one or more transitions <NUM> between the current state of the environment and the state(s) of the environment during previous session(s) when the authentication device(s) <NUM> authenticated the user device <NUM>(<NUM>), which are described above. In such instances, the information <NUM> may represent the transition(s) <NUM>.

In instances where the information <NUM> represents the characteristic(s) <NUM> associated with the environment, the authentication device(s) <NUM> may perform similar processes as the state component <NUM> in order to identify the transition(s) <NUM>. For example, the authentication device(s) <NUM> may store additional information <NUM> representing the previous characteristic(s) <NUM> associated with the environment. In some instances, the authentication device(s) <NUM> store the information <NUM> each time the authentication device(s) <NUM> receive such information <NUM> from the user device <NUM>(<NUM>) and/or each time the authentication device(s) <NUM> authenticate the user device <NUM>(<NUM>). The authentication device(s) <NUM> may then compare the characteristic(s) <NUM> associated with the current state of the environment, as represented by the received information <NUM>, to the previous characteristic(s) <NUM> associated with the previous state(s) of the environment, as represented by previous information <NUM>, in order to identify the transition(s) <NUM> between the current state of the environment and the previous state(s) of the environment.

The authentication device(s) <NUM> may then use the transition(s) <NUM> to determine the duration <NUM>. For example, the authentication device(s) <NUM> may use a set duration <NUM> if this is the first time that the user device <NUM>(<NUM>) has been authenticated for a session. As described above, the set duration <NUM> may include, but is not limited to, one hour, twelve hours, one day, one week, and/or any other period of time. The authentication device(s) <NUM> may then update the duration <NUM> each time the authentication device(s) <NUM> authenticate the user device <NUM>(<NUM>) for a new session. In some instances, the authentication device(s) <NUM> updates the duration <NUM> by increasing or decreasing a previous duration <NUM> for a previous session.

For example, if the transition(s) <NUM> indicate that the current state of the environment is similar to the previous state(s) of the environment, then the authentication device(s) <NUM> may determine the duration <NUM> by increasing a previous duration <NUM> associated with a previous session. In some instances, the greater the similarities between the current state of the environment and the previous state(s) of the environment, the greater the increase that the authentication device(s) <NUM> use when determining the duration <NUM>. For another example, if the transition(s) <NUM> indicate that the current state of the environment is different than the previous state(s) of the environment, then the authentication device(s) <NUM> may determine the duration <NUM> by decreasing the previous duration <NUM> associated with the previous session. In some instances, the greater the differences between the current state of the environment and the previous state(s) of the environment, the greater the decrease that the authentication device(s) <NUM> use when determining the duration <NUM>.

In some instances, the authentication device(s) <NUM> may analyze the information <NUM> and/or the transition(s) <NUM> in order to identify "triggering events" associated with the environment of the user device <NUM>(<NUM>). As described herein, a triggering event may include, but is not limited to, a change in the user of the user device (determined using image data, biometric data, etc.), malicious hardware/software identified on the user device (e.g., malware), a change in the unique device identifier, a change in the IP address, and/or the like. In some instances, when the authentication device(s) <NUM> identify a triggering event, the authentication device(s) <NUM> may require that the user device <NUM>(<NUM>) be re-authenticated (either using the credentials and/or by performing multi-factor authentication). Additionally, or alternatively, in some instances, when the authentication device(s) <NUM> identify the triggering event, the authentication device(s) <NUM> may determine the duration <NUM> as the set duration <NUM> and/or determine the duration <NUM> by decreasing the previous duration <NUM>.

Additionally, in the examples above, the state component <NUM> and/or the authentication device(s) <NUM> may use one or more machine learned models to identify the transition(s) <NUM> associated with the current state of the environment. For example, the machine learned model(s) may be configured to analyze characteristic(s) <NUM> associated with the environment of the user device <NUM>(<NUM>), such as each time the state component <NUM>(<NUM>) determines the characteristic(s) <NUM>. Based on the analysis, the machine learned model(s) identify (e.g., learn) characteristic(s) <NUM> that remain substantially constant. For example, the machine learned model(s) may identify that the user device <NUM>(<NUM>) usually uses the same IP address, usually uses the same unique device identifier, includes a CPU usage that falls within a given range, includes application(s) that are usually active on the user device <NUM>(<NUM>), and/or the like. The state component <NUM> and/or the authentication device(s) <NUM> may then compare new characteristic(s) <NUM> to the learned characteristic(s) <NUM> in order to identity the transition(s) <NUM>.

In the example of <FIG>, and in some instances, after generating the authentication data <NUM>, the authentication device(s) <NUM> may send the authentication data <NUM> to the user device <NUM>(<NUM>). Additionally, or alternatively, in some instances, after generating the authentication data <NUM>, the authentication device(s) <NUM> may send the authentication data <NUM> to the server device(s) <NUM>, which may then send the authentication data <NUM> to the user device <NUM>(<NUM>). In either of the instances, the user device <NUM>(<NUM>) may then use the authentication data <NUM> to access services provided by the server device(s) <NUM> during the duration <NUM>.

As further illustrated in the example of <FIG>, the user device <NUM>(<NUM>) includes processor(s) <NUM> and the memory <NUM>, the authentication device(s) <NUM> include processor(s) <NUM> and memory <NUM>, and the user device <NUM>(<NUM>) includes processor(s) <NUM> and memory <NUM>. As used herein, a processor may include multiple processors and/or a processor having multiple cores. Further, the processors may comprise one or more cores of different types. For example, the processors may include application processor units, graphic processing units, and so forth. In one instance, the processor may comprise a microcontroller and/or a microprocessor. The processor(s) may include a graphics processing unit (GPU), a microprocessor, a digital signal processor or other processing units or components known in the art. Alternatively, or in addition, the functionally described herein can be performed, at least in part, by one or more hardware logic components. For example, and without limitation, illustrative types of hardware logic components that can be used include field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip systems (SOCs), complex programmable logic devices (CPLDs), etc. Additionally, processor(s) may possess its own local memory, which also may store program components, program data, and/or one or more operating systems.

Memory may include volatile and nonvolatile memory, removable and non-removable media implemented in any method or technology for storage of information, such as computer-readable instructions, data structures, program component, or other data. The memory includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, RAID storage systems, or any other medium which can be used to store the desired information and which can be accessed by a computing device. The memory may be implemented as computer-readable storage media ("CRSM"), which may be any available physical media accessible by the processor(s) to execute instructions stored on the memory. In one basic instance, CRSM may include random access memory ("RAM") and Flash memory. In other instances, CRSM may include, but is not limited to, read-only memory ("ROM"), electrically erasable programmable read-only memory ("EEPROM"), or any other tangible medium which can be used to store the desired information and which can be accessed by the processor(s).

<FIG> illustrate an example of updating durations of sessions using information associated with an environment of the user device <NUM>(<NUM>), in accordance with the present concepts. For example, and for a first session <NUM>, the authentication device(s) <NUM> may receive first information <NUM>(<NUM>) from the user device <NUM>(<NUM>). As shown, the first information <NUM>(<NUM>) indicates that a first state of the environment includes a CPU usage of 100MB, a memory usage of 100MB, a unique device identifier of Identifier <NUM>, an IP address of Address <NUM>, and three active software applications (e.g., Software <NUM>-<NUM>). In the example of <FIG>, the first session <NUM> may correspond to the first time that the authentication device(s) <NUM> have authenticated the device <NUM>(<NUM>) for a session. As such, the authentication device(s) <NUM> may determine that there are no first transition(s) <NUM>(<NUM>) associated with the environment. As such, the authentication device(s) <NUM> may determine to use a set duration as a first duration <NUM>(<NUM>) for the first session <NUM> which, in the example of <FIG>, includes <NUM> hours.

At a second session <NUM>, the authentication device(s) <NUM> may receive second information <NUM>(<NUM>) from the user device <NUM>(<NUM>). As shown, the second information <NUM>(<NUM>) indicates that a second state of the environment includes a CPU usage of 110MB, a memory usage of 90MB, a unique device identifier of Identifier <NUM>, an IP address of Address <NUM>, and three active software applications (e.g., Software <NUM>-<NUM>). As such, the authentication device(s) <NUM> may compare the second information <NUM>(<NUM>) to the first information <NUM>(<NUM>) in order to identify second transitions <NUM>(<NUM>). The second transitions <NUM>(<NUM>) may include a CPU usage increase of 10MB and a memory usage decrease of 10MB. As such, the authentication device(s) <NUM> may determine that the second state of the environment is similar to the first state of the environment. Therefore, the authentication device(s) <NUM> may determine a second duration <NUM>(<NUM>) by increasing the first duration <NUM>(<NUM>). As shown in the example of <FIG>, the second duration <NUM>(<NUM>) includes <NUM> hours.

At a third session <NUM>, the authentication device(s) <NUM> may receive third information <NUM>(<NUM>) from the user device <NUM>(<NUM>). As shown, the third information <NUM>(<NUM>) indicates that a third state of the environment includes a CPU usage of 170MB, a memory usage of 120MB, a unique device identifier of Identifier <NUM>, an IP address of Address <NUM>, and three active software applications (e.g., Software <NUM>-<NUM>). As such, the authentication device(s) <NUM> may compare the third information <NUM>(<NUM>) to the second information <NUM>(<NUM>) in order to identify third transitions <NUM>(<NUM>). The third transitions <NUM>(<NUM>) may include a CPU usage increase of 60MB and a memory usage increase of 120MB. As such, the authentication device(s) <NUM> may determine that the third state of the environment is similar to the second state of the environment. Therefore, the authentication device(s) <NUM> may determine a third duration <NUM>(<NUM>) by increasing the second duration <NUM>(<NUM>). However, since the third state of the environment is less similar to the second state of the environment than the second state of the environment was to the first state of the environment, the authentication device(s) <NUM> may determine to increase the third duration <NUM>(<NUM>) by a smaller amount. As shown in the example of <FIG>, the third duration <NUM>(<NUM>) includes <NUM> hours.

At a fourth session <NUM>, the authentication device(s) <NUM> may receive fourth information <NUM>(<NUM>) from the user device <NUM>(<NUM>). As shown, the fourth information <NUM>(<NUM>) indicates that a fourth state of the environment includes a CPU usage of 300MB, a memory usage of 400MB, a unique device identifier of Identifier <NUM>, an IP address of Address <NUM>, and four active software applications (e.g., Software <NUM>-<NUM>). As such, the authentication device(s) <NUM> may compare the fourth information <NUM>(<NUM>) to the third information <NUM>(<NUM>) in order to identify fourth transitions <NUM>(<NUM>). The fourth transitions <NUM>(<NUM>) may include a CPU usage increase of 130MB, a memory usage increase of 280MB, and new activate software (e.g., Software <NUM>). As such, the authentication device(s) <NUM> may determine that the fourth state of the environment is different than the third state of the environment. Therefore, the authentication device(s) <NUM> may determine a fourth duration <NUM>(<NUM>) by decreasing the third duration <NUM>(<NUM>). As shown in the example of <FIG>, the fourth duration <NUM>(<NUM>) includes <NUM> hours.

Finally, at a fifth session <NUM>, the authentication device(s) <NUM> may receive fifth information <NUM>(<NUM>) from the user device <NUM>(<NUM>). As shown, the fifth information <NUM>(<NUM>) indicates that a fifth state of the environment includes a CPU usage of 310MB, a memory usage of 410MB, a unique device identifier of Identifier <NUM>, an IP address of Address <NUM>, and four active software applications (e.g., Software <NUM>-<NUM>). As such, the authentication device(s) <NUM> may compare the fifth information <NUM>(<NUM>) to the fourth information <NUM>(<NUM>) in order to identify fifth transitions <NUM>(<NUM>). The fifth transitions <NUM>(<NUM>) may include a CPU usage increase of 10MB, a memory usage increase of 10MB, a new unique device identifier (e.g., Identifier <NUM>), and a new IP address (e.g., IP address <NUM>). As such, the authentication device(s) <NUM> may determine that a triggering event has occurred and determine to once again use the set duration <NUM> for the fifth session <NUM>. As shown in the example of <FIG>, the fifth duration <NUM>(<NUM>) includes <NUM> hours.

It should be noted that while the example of <FIG> describes the authentication device(s) <NUM> as receiving the information <NUM> and using the information <NUM> to determine the transitions <NUM>, in other examples, the state component <NUM> of the user device <NUM>(<NUM>) may initially use the information <NUM> to determine the transitions <NUM>. In such examples, the information <NUM> that the user device <NUM>(<NUM>) sends to the authentication device(s) <NUM> may represent the transitions <NUM>.

<FIG> illustrates a flow diagram of a first example method <NUM> for determining a duration associated with authenticating a user device during a session. An operation <NUM> represents determining a first duration associated with authenticating a user device during a first session. For instance, authentication device(s) <NUM> may determine the first duration for the user device. In some instances, the authentication device(s) <NUM> may determine the first duration as a set duration that the authentication device(s) <NUM> initially use when new devices are authenticated. In some instances, the authentication device(s) <NUM> determine the first duration using information representing an environment of the user device. For instance, the authentication device(s) <NUM> may use the information to determine the first duration by increasing or decreasing a previous duration associated with a previous session.

An operation <NUM> represents receiving credentials associated with a user account and an operation <NUM> represents authenticating the user device for a second session based at least in part on the credentials. For instance, the authentication device(s) <NUM> may use the credentials to authenticate the user device for the second session. In some instances, the authentication device(s) <NUM> may provide the user device with single sign-on authentication. Additionally, in some instances, the authentication device(s) <NUM> may perform a multi-factor authentication in order to authenticate the user device.

An operation <NUM> represents receiving information associated with an environment of the user device. For instance, the authentication device(s) <NUM> may receive the information from the user device. In some instances, the information may represent one or more characteristics associated with the current state of the environment of the user device. Additionally, or alternatively, in some instances, the information may represent one or more transitions between the current state of the environment and one or more previous states associated with the environment.

An operation <NUM> represents determining, based at least in part on the first duration and the information, a second duration for authenticating the user device during the second session. For instance, the authentication device(s) <NUM> may use the information and the first duration in order to determine the second duration. In some instances, the authentication device(s) <NUM> initially identify one or more transition(s) between the current state of the environment and the previous state(s) of the environment. The authentication device(s) <NUM> then use the transition(s) to determine the second duration. For instance, if the transition(s) indicate that the current state of the environment is similar to the previous state(s) of the environment, then the authentication device(s) <NUM> may determine the second duration by increasing the first duration. Alternatively, if the transition(s) indicate that the current state of the environment is different than the previous state(s) of the environment, then the authentication device(s) <NUM> may determine the second duration by decreasing the first duration.

An operation <NUM> represents generating data representing at least the second duration and an operation <NUM> represents sending the data. For instance, the authentication device(s) <NUM> may generate the data (e.g., a token, a cookie, etc.) that represents at least the second duration. In some instances, the authentication device(s) <NUM> then send the data to the user device. Additionally, or alternatively, in some instances, the authentication device(s) <NUM> send the data to one or more service devices. In either of the instances, the user device uses the data to gain access to services provided by the service device(s). For instance, the service device(s) may use the data to determine that the user device includes a trusted device during the second duration.

<FIG> illustrates a flow diagram of a second example method <NUM> for determining a duration associated with authenticating a user device during a session. An operation <NUM> represents storing first information associated with an environment of a user device during a first session. For instance, the authentication device(s) <NUM> may have previously authenticated the user device for the first session. During and/or after authenticating the user device, the authentication device(s) <NUM> may have received the first information associated with the state of the environment of the user device during the first session. The authentication device(s) <NUM> may have then used the first information to determine a duration for the first session. Also, the authentication device(s) <NUM> may have stored the first information for later determining durations for later sessions associated with the user device.

An operation <NUM> represents receiving second information associated with the environment of the user device. For instance, the authentication device(s) <NUM> may receive the information from the user device for the second session. In some instances, the second information may represent one or more characteristics associated with the current state of the environment of the user device.

An operation <NUM> represents determining, based at least in part on the first information and the second information, a duration for authenticating the user device during the second session. For instance, the authentication device(s) <NUM> may use at least the first information and the second information in order to determine the duration. In some instances, the authentication device(s) <NUM> initially identify one or more transitions between the current state of the environment, as represented by the second information, and a previous state of the environment, as represented by the first information. The authentication device(s) <NUM> then use the transition(s) to determine the duration. For instance, if the transition(s) indicate that the current state of the environment is similar to the previous state(s) of the environment, then the authentication device(s) <NUM> may determine the duration by increasing a previous duration. Alternatively, if the transition(s) indicate that the current state of the environment is different than the previous state(s) of the environment, then the authentication device(s) <NUM> may determine the duration by decreasing the previous duration.

An operation <NUM> represents generating data representing at least the duration and an operation <NUM> represents sending the data. For instance, the authentication device(s) <NUM> may generate the data (e.g., a token, a cookie, etc.) that represents at least the duration. In some instances, the authentication device(s) <NUM> then send the data to the user device. Additionally, or alternatively, in some instances, the authentication device(s) <NUM> send the data to one or more service devices. In either of the instances, the user device uses the data to gain access to services provided by the service device(s). For instance, the service device(s) may use the data to determine that the user device includes a trusted device during the duration.

<FIG> illustrates a flow diagram of a third example method <NUM> for determining a duration associated with authenticating a user device during a session. An operation <NUM> represents determining first information representing a first state of an environment of a user device. For instance, the authentication device(s) <NUM> may have previously authenticated the user device for the first session. Based at least in part on authenticating the user device, the authentication device(s) <NUM> may receive the first information representing the first state of the environment of the user device during the first session. The authentication device(s) <NUM> may have then used the first information to determine a first duration for the first session.

An operation <NUM> represents receiving second information representing a second state of the environment of the user device. For instance, the authentication device(s) <NUM> may be authenticating the user device for a second session. Based at least in part on authenticating the user device, the authentication device(s) <NUM> may receive the second information representing the second state of the environment of the user device during the second session.

An operation <NUM> represents determining one or more transitions between the second state of the environment and the first state of the environment. For instance, the authentication device(s) <NUM> may analyze the first information with respect to the second information in order to determine the transition(s). As described herein, the transition(s) may include, but are not limited to, a change in the unique device identifier, a change in the hardware associated with the user device, a change in the software installed on the user device, a change in the one or more applications that are active on the user device, a change in the CPU usage associated with the user device, a change in the memory usage associated with the user device, a change in the IP address associated with the user device, a change in the power consumption associated with the user device (e.g., whether the user device was continuously receiving power or whether the user device stopped receiving power for period(s) of time), a change in the type of network connection associated with the user device, or a change in the user of the user device (as determined using the sensor data).

An operation <NUM> represents determining whether the one or more transitions indicate that the second state is similar to the first state. For instance, the authentication device(s) <NUM> may analyze the transition(s) in order to determine whether the second state of the environment is similar to the first state of the environment. In some instances, the authentication device(s) <NUM> may determine that the second state is similar to the first state when the transition(s) represent small changes between the states, such as small changes in the CPU usage, memory usage, and/or the like. Additionally, in some instances, the authentication device(s) <NUM> may determine that the second state is not similar to the first state when the transition(s) represent large changes between the states, such as a change in the unique device identifier, a change in the IP address, a change in the user, and/or the like.

It, at <NUM>, it is determined that the one or more transitions indicate that the second state is similar to the first state, then an operation <NUM> represents determining a duration by increasing a previous duration. For instance, if the authentication device(s) <NUM> determine that the second state is similar to the first state, then the authentication device(s) <NUM> may determine the duration by increasing the previous duration. In some instances, the authentication device(s) <NUM> may increase the previous duration by a greater amount the more similar the second state is to the first state.

However, if, at <NUM>, it is determined that the one or more transitions indicate that the second state is not similar to the first state, then an operation <NUM> represents determining the duration by decreasing the previous duration. For instance, if the authentication device(s) <NUM> determine that the second state is not similar to the first state, then the authentication device(s) <NUM> may determine the duration by decreasing the previous duration. In some instances, the authentication device(s) <NUM> may decrease the previous duration by a greater amount the more dissimilar the second state is to the first state.

It should be noted that, while the example of <FIG> describe the authentication device(s) <NUM> as performing <NUM>-<NUM>, in other examples, the user device may perform <NUM>-<NUM>. In such instances, the authentication device(s) <NUM> may then receive, from the user device, information representing the transition(s).

<FIG> is a computing system diagram illustrating a configuration for a data center <NUM> that can be utilized to implement aspects of the technologies disclosed herein. The example data center <NUM> shown in <FIG> includes several computers 602A-602F (which might be referred to herein singularly as "a computer <NUM>" or in the plural as "the computers <NUM>") for providing computing resources. In some examples, the resources and/or computers <NUM> may include, or correspond to, any type of networked device described herein, such as the server device(s) <NUM> and/or the authentication device(s) <NUM>. Although, computers <NUM> may comprise any type of networked device, such as servers, switches, routers, hubs, bridges, gateways, modems, repeaters, access points, hosts, etc..

The computers <NUM> can be standard tower, rack-mount, or blade server computers configured appropriately for providing computing resources. In some examples, the computers <NUM> may provide computing resources <NUM> including data processing resources such as virtual machine (VM) instances or hardware computing systems, database clusters, computing clusters, storage clusters, data storage resources, database resources, networking resources, and others. Some of the computers <NUM> can also be configured to execute a resource manager <NUM> capable of instantiating and/or managing the computing resources. In the case of VM instances, for example, the resource manager <NUM> can be a hypervisor or another type of program configured to enable the execution of multiple VM instances on a single computer <NUM>. Computers <NUM> in the data center <NUM> can also be configured to provide network services and other types of services.

In the example data center <NUM> shown in <FIG>, an appropriate local area network (LAN) <NUM> is also utilized to interconnect the computers 602A-602F. It should be appreciated that the configuration and network topology described herein has been greatly simplified and that many more computing systems, software components, networks, and networking devices can be utilized to interconnect the various computing systems disclosed herein and to provide the functionality described above. Appropriate load balancing devices or other types of network infrastructure components can also be utilized for balancing a load between data centers <NUM>, between each of the computers 602A-602F in each data center <NUM>, and, potentially, between computing resources in each of the computers <NUM>. It should be merely illustrative and that other implementations can be utilized.

In some examples, the computers <NUM> may each execute one or more application containers and/or virtual machines to perform techniques described herein. For instance, the containers and/or virtual machines may serve as server devices, user devices, and/or routers in the cloud computing network <NUM>.

In some instances, the data center <NUM> may provide computing resources, like application containers, VM instances, and storage, on a permanent or an as-needed basis. Among other types of functionality, the computing resources provided by a cloud computing network may be utilized to implement the various services and techniques described above. The computing resources <NUM> provided by the cloud computing network can include various types of computing resources, such as data processing resources like application containers and VM instances, data storage resources, networking resources, data communication resources, network services, and the like.

Each type of computing resource <NUM> provided by the cloud computing network can be general-purpose or can be available in a number of specific configurations. For example, data processing resources can be available as physical computers or VM instances in a number of different configurations. The VM instances can be configured to execute applications, including web servers, application servers, media servers, database servers, some or all of the network services described above, and/or other types of programs. Data storage resources can include file storage devices, block storage devices, and the like. The cloud computing network can also be configured to provide other types of computing resources <NUM> not mentioned specifically herein.

The computing resources <NUM> provided by a cloud computing network may be enabled in one embodiment by one or more data centers <NUM> (which might be referred to herein singularly as "a data center <NUM>" or in the plural as "the data centers <NUM>"). The data centers <NUM> are facilities utilized to house and operate computer systems and associated components. The data centers <NUM> typically include redundant and backup power, communications, cooling, and security systems. The data centers <NUM> can also be located in geographically disparate locations. One illustrative embodiment for a data center <NUM> that can be utilized to implement the technologies disclosed herein will be described below with regard to <FIG>.

<FIG> is a computer architecture diagram showing an illustrative computer hardware architecture for implementing a server computing device <NUM> that can be utilized to implement aspects of the various technologies presented herein. The server device(s) <NUM> and/or the authentication device(s) <NUM>, discussed above, may include some or all of the components discussed below with reference to the server computing device <NUM>.

To begin, the server computer <NUM> can be standard tower, rack-mount, or blade server computers configured appropriately for providing the computing resources described herein. As mentioned above, the computing resources provided by a cloud computing network, data center, or the like can be data processing resources such as VM instances or hardware computing systems, database clusters, computing clusters, storage clusters, data storage resources, database resources, networking resources, and others. Some of the servers <NUM> can also be configured to execute a resource manager capable of instantiating and/or managing the computing resources. In the case of VM instances, for example, the resource manager can be a hypervisor or another type of program configured to enable the execution of multiple VM instances on a single server computer <NUM>. Server computers <NUM> in a data center can also be configured to provide network services and other types of services.

The server computer <NUM> includes a baseboard <NUM>, or "motherboard," which is a printed circuit board to which a multitude of components or devices can be connected by way of a system bus or other electrical communication paths. In one illustrative configuration, one or more central processing units (CPUs) <NUM> operate in conjunction with a chipset <NUM>. The CPUs <NUM> can be standard programmable processors that perform arithmetic and logical operations necessary for the operation of the computer <NUM>.

The chipset <NUM> provides an interface between the CPUs <NUM> and the remainder of the components and devices on the baseboard <NUM>. The chipset <NUM> can provide an interface to a RAM <NUM>, used as the main memory in the computer <NUM>. The chipset <NUM> can further provide an interface to a computer-readable storage medium such as a read-only memory (ROM) <NUM> or non-volatile RAM (NVRAM) for storing basic routines that help to startup the computer <NUM> and to transfer information between the various components and devices. The ROM <NUM> or NVRAM can also store other software components necessary for the operation of the computer <NUM> in accordance with the configurations described herein.

The computer <NUM> can operate in a networked environment using logical connections to remote computing devices and computer systems through a network, such as a local area network <NUM>. The chipset <NUM> can include functionality for providing network connectivity through a Network Interface Card (NIC) <NUM>, such as a gigabit Ethernet adapter. The NIC <NUM> is capable of connecting the computer <NUM> to other computing devices over the network. It should be appreciated that multiple NICs <NUM> can be present in the computer <NUM>, connecting the computer to other types of networks and remote computer systems.

The computer <NUM> can be connected to a storage device <NUM> that provides non-volatile storage for the computer. The storage device <NUM> can store an operating system <NUM>, programs <NUM>, and data, which have been described in greater detail herein. The storage device <NUM> can be connected to the computer <NUM> through a storage controller <NUM> connected to the chipset <NUM>. The storage device <NUM> can consist of one or more physical storage units. The storage controller <NUM> can interface with the physical storage units through a serial attached SCSI (SAS) interface, a serial advanced technology attachment (SATA) interface, an FC interface, or other type of interface for physically connecting and transferring data between computers and physical storage units.

The computer <NUM> can store data on the storage device <NUM> by transforming the physical state of the physical storage units to reflect the information being stored. The specific transformation of physical state can depend on various factors, in different embodiments of this description. Examples of such factors can include, but are not limited to, the technology used to implement the physical storage units, whether the storage device <NUM> is characterized as primary or secondary storage, and the like.

For example, the computer <NUM> can store information to the storage device <NUM> by issuing instructions through the storage controller <NUM> to alter the magnetic characteristics of a particular location within a magnetic disk drive unit, the reflective or refractive characteristics of a particular location in an optical storage unit, or the electrical characteristics of a particular capacitor, transistor, or other discrete component in a solid-state storage unit.

The computer <NUM> can further read information from the storage device <NUM> by detecting the physical states or characteristics of one or more particular locations within the physical storage units.

In addition to the mass storage device <NUM> described above, the computer <NUM> can have access to other computer-readable storage media to store and retrieve information, such as program modules, data structures, or other data. It should be appreciated by those skilled in the art that computer-readable storage media is any available media that provides for the non-transitory storage of data and that can be accessed by the computer <NUM>. In some examples, the operations performed by the computer <NUM>, and or any components included therein, may be supported by one or more devices similar to computer <NUM>.

By way of example, and not limitation, computer-readable storage media can include volatile and non-volatile, removable and non-removable media implemented in any method or technology. Computer-readable storage media includes, but is not limited to, RAM, ROM, erasable programmable ROM (EPROM), electrically-erasable programmable ROM (EEPROM), flash memory or other solid-state memory technology, compact disc ROM (CD-ROM), digital versatile disk (DVD), high definition DVD (HD-DVD), BLU-RAY, or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information in a non-transitory fashion.

As mentioned briefly above, the storage device <NUM> can store an operating system <NUM> utilized to control the operation of the computer <NUM>. According to one embodiment, the operating system comprises the LINUX operating system. According to another embodiment, the operating system comprises the WINDOWS● SERVER operating system from MICROSOFT Corporation of Redmond, Washington. According to further embodiments, the operating system can comprise the UNIX operating system or one of its variants. It should be appreciated that other operating systems can also be utilized. The storage device <NUM> can store other system or application programs and data utilized by the computer <NUM>.

In one embodiment, the storage device <NUM> or other computer-readable storage media is encoded with computer-executable instructions which, when loaded into the computer <NUM>, transform the computer from a general-purpose computing system into a special-purpose computer capable of implementing the embodiments described herein. These computer-executable instructions transform the computer <NUM> by specifying how the CPUs <NUM> transition between states, as described above. According to one embodiment, the computer <NUM> has access to computer-readable storage media storing computer-executable instructions which, when executed by the computer <NUM>, perform the various processes described above with regard to <FIG>. The computer <NUM> can also include computer-readable storage media having instructions stored thereupon for performing any of the other computer-implemented operations described herein.

The server computer <NUM> may also store, in the storage device <NUM>, the authentication request <NUM>, the authentication data <NUM>, the information <NUM>, and the transition(s) <NUM>, described above.

In summary, this disclosure describes techniques for authenticating a user device for a session. For instance, an authentication entity may authenticate a user device using single sign-on authentication and/or multi-factor authentication. The authentication entity may then determine a duration for which the user device is authenticated for the session. For example, the authentication entity may receive information representing a state of an environment of the user device. The authentication entity may then use the information to identify one or more transitions associated with the environment between the session and a previous session. Using the one or more transitions, the authentication entity may determine the duration for the session by increasing or decreasing a previous duration associated with the previous session.

While the invention is described with respect to the specific examples, it is to be understood that the scope of the invention is not limited to these specific examples. Since other modifications and changes varied to fit particular operating requirements and environments will be apparent to those skilled in the art, the invention is not considered limited to the example chosen for purposes of disclosure.

Claim 1:
A method performed at an authentication device (<NUM>) comprising:
storing first information (<NUM>(<NUM>)) associated with an environment of a user device (<NUM>) during a first session (<NUM>), the first session associated with a first duration (<NUM>(<NUM>));
receiving credentials associated with a user account;
authenticating the user device for a second session (<NUM>) based at least in part on the credentials;
receiving second information (<NUM>(<NUM>)) associated with the environment of the user device for the second session;
analyzing the first information with respect to the second information to determine one or more transitions (<NUM>(<NUM>)) associated with the environment between the first session and the second session;
determining a second duration (<NUM>(<NUM>)) associated with authenticating the user device during the second session, the determining comprising increasing or decreasing the first duration based at least in part on the one or more transitions;
generating data (<NUM>) representing at least the second duration; and
sending the data to the user device.