Patent Description:
Further, computing system functionality can be enhanced by a computing systems' ability to be interconnected to other computing systems via network connections. Network connections may include, but are not limited to, connections via wired or wireless Ethernet, cellular connections, or even computer to computer connections through serial, parallel, USB, or other connections. The connections allow a computing system to access services at other computing systems and to quickly and efficiently receive application data from other computing systems.

This interconnection has facilitated the proliferation of so-called web applications. In particular, a user can use a web application where the majority of the computational activities are performed on a remote server while the user interacts with a small local client (in terms of processing power, storage, or other resources). For example, a user may access an email or word processing application implemented at an online server through a simple browser interface. In this example, the browser performs a minimal amount of computing while the online server performs the majority of the computing processes required to implement the email application or word processing application. Thus, many users use web applications.

When web applications were originally developed, there was a problem identified whereby the web applications had difficulty in maintaining context for user actions while simultaneously enforcing id token based conditional access policies.

Ordinarily, a user obtains use of an id token, by a resource provider redirecting the user to an identity provider to authenticate to the identity provider to allow the resource provider to obtain and id token to allow the user to access resources at a web-based resource provider. Typically, the id token has a short lifespan, such as <NUM> hour. This lifespan is selected due to the need to evaluate policies on a regular basis due to those policies being updated. Alternatively or additionally, policies may need to be updated as a computing environment changes over time. For example, if the user deletes their account, access should be revoked. This can occur by an identity provider not providing an additional id token to a web application for the entity when the entity tries to re-authenticate with the identity provider after having removed their user account. Alternatively or additionally, new policies may be established at the identity provider. Any requests for id tokens from the identity provider will be evaluated in light of these new policies. Id tokens are therefore issued based on the updated policies. Thus, it is desirable that reauthentication occur according to reasonable time periods to allow reasonable enforcement of changing user contexts, computing environments, or policies.

At the expiration of the id token, the id token can no longer be used to authenticate the user to a front end of a web service. This causes the entity to be redirected back to an identity provider to have a new id token issued to the web application for the entity. Previously, this was done in a fashion whereby the user context would be lost when reauthentication occurred as the user was required to re-authenticate their identity by providing appropriate credentials in order for a new id token to be issued to the resource provider which could be used to allow the entity access to the web application.

However, currently, systems allow for reauthentication in a fashion such that the user is unaware that a new id token is being requested. For example, the user will be accessing a web application, such as a web-based email or word processing application. The id token will expire. This causes the web application to be redirected to the identity provider to obtain a current id token. The entity will use a refresh token provided to the identity provider which allows a new id token to be issued without the need for providing access credentials. Rather, the refresh token can be used so long as the entity is compliant with conditional access policy at the identity provider. Nonetheless, the entity will need to cause a new id token to be issued due to an invalidated user session. As intimated above, this occurs approximately every <NUM> hour in some common embodiments. This can be particularly troublesome for web applications, as context may be lost when there is a need to obtain a new id token. For example, consider the scenario when a user is typing an email in a web-based email application. In the middle of typing the email, the web-based email application will revert back to the identity provider to obtain a new id token because the current id token has expired. This can cause a loss in context for the email application, which results in difficulty for the user.

To solve this problem, current systems allow the resource provider to drop a cookie with an entity that may be valid for much longer time periods (as compared to the id token validity) based on an id token that is issued for a shorter time period. For example, a resource provider may drop a cookie that is valid for several days for an id token that is only valid for <NUM> hour. This creates a security gap in that an entity may have access to resources at a resource provider long after the id token has expired, and potentially when the entity should be denied access to the resource provider altogether due to noncompliance of certain policies by the entity.

For example, in some embodiments, the user account may have been deleted. However, the resource provider will not be aware of this account deletion resulting in an entity having a rogue account accessing the resource provider by virtue of the cookie provided to the entity.

D Hardt: "RFC <NUM> The OAuth <NUM> Authorization Framework" describes an authorization framework which enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf.

<CIT> describes that a system and method that grants a token to authenticate a user requesting access to an application in a domain is disclosed. The method includes receiving a response from an identity (ID) provider in a second domain responsive to a first request from a user to access an application provided by an application server in a first domain, the response indicating the authenticity of the user in the second domain, randomly selecting a first key and a second key from a key store, generating a secret by randomly permuting the first key and the second key, generating a signature by signing user information associated with the user using the secret, generating an authentication token including the signature, determining whether the authentication token is valid, and responsive to determining that the authentication token is valid, granting access to the first application to the user based on the authentication token.

<CIT> describes a flexible authentication system that fluidly switches between a federated authentication model and a local short-lived token model that does not require sophisticated authentication infrastructure at the relying party site. Upon detecting an event that causes the identity provider to be unavailable for authentication, the relying party switches to a temporary token model. The system generates a bearer token or challenge associated with the user's identity and (optionally) associated with time data that limits the period during which the token is valid. The relying party communicates the short-lived token to the user using contact information associated with the user and already stored by the relying party. Upon receiving the short-lived token, the user provides the short-lived token to the relying party, and the relying party processes the token to validate the user's identity and then allows the user to access the relying party's online services.

The invention is set out in the amended set of claims.

One embodiment illustrated herein includes a method that may be practiced in a networked computing environment. The method includes acts for managing user sessions in the networked computing environment. The method includes at an identity provider computer system, providing a first id token to a resource provider for an entity. The first id token has therein a first policy check interval having a value defining a period when the first id token should be revalidated. Due to expiration of the first policy check interval, a first refresh token is received from the resource provider computer system that received the first id token. As a result of receiving the first refresh token from the resource provider computer system, the identity provider computer system evaluates conditional access policy for the entity. If the identity provider computer system determines that the conditional access policy for the entity has been met, the identity provider computer system provides a new id token and a new refresh token to the resource provider computer system.

As discussed above, there are several problems that exist when implementing web-based applications. In particular, short id token refresh times can result in a user constantly losing focus in a web-based application as the user needs to be re-authenticated with an identity provider to continue using the web-based application. Solutions to this problem have resulted in security gaps whereby unauthorized users or users that do not comply with current policy are able to access the web-based application in contradiction with present policy considerations. Thus, a technical problem exists whereby web applications are either more difficult to use due to loss of context for the user requiring additional user interaction, or alternatively security problems exist due to solutions which attempt to resolve the loss of context issues. Embodiments illustrated herein implement a technical means of implementing server to server communication to allow an identity provider computer and a resource provider computer to communicate such that user sessions can be invalidated for reasons other than token expiration or cookie expiration. That is, a resource provider computer system can contact an identity provider computer system to identify current policy information for a particular entity. The particular policy information (e.g., a new id token or a rejection as described below) for the entity can be provided back to the resource provider computer system which can then enforce the policy as appropriate thus providing a technical solution to the problems described above. That is, embodiments implement a practical application of server to server communication whereby interface functionality and responsiveness is realized by the user while still protecting system security and policy enforcement.

Embodiments illustrated herein allow communication between a resource provider implementing a web application and an identity provider to allow the resource provider to ask for status information regarding the entities attempting to access the resource provider in a fashion that allows the entities to maintain context at the resource provider to eliminate the security gaps described previously.

Referring now to <FIG>, an example is illustrated. <FIG> illustrates an entity <NUM>. In the illustrated example, the entity <NUM> may include a user as well as the device and associated clients (including applications) used by the user. The entity <NUM> may have need to access resources from a resource provider <NUM>, which in the illustrated example, is a web based resource provider, such as a web application. To obtain access to the resources, such as web application resources, the entity will first authenticate with an identity provider <NUM>. In some embodiments, the identity provider <NUM> is a Security Token Service. In a web-based application scenario, a client web application initiates communication and redirects the user to the identity provider <NUM> and, as a result, the web-based application receives an id token <NUM>-<NUM> that allows the entity <NUM> to access the resource provider <NUM>. The entity <NUM> can authenticate to the identity provider <NUM> through any one of a number of different well-known authentication and id token issuance schemes, other less well-known authentication schemes, or even future authentication schemes yet to be developed. Suffice it to say, in the particular example shown in <FIG>, the resource provider <NUM> receives from the identity provider <NUM> an id token <NUM>-<NUM> and a refresh token <NUM>-<NUM>. While the example in <FIG> illustrates that a refresh token <NUM>-<NUM> is issued, in other embodiments, an authorization code may be provided to the resource provider <NUM>. The authorization code can be exchanged for the refresh token <NUM>-<NUM>. In some embodiments, the id token, the authorization code, or both are provided to the resource provider by providing them to a web server and web API, which along with a backing data store storing the resources <NUM>, implement the resource provider <NUM>.

The id token <NUM>-<NUM> typically includes a timestamp indicating when the id token was issued. The id token <NUM>-<NUM> may alternatively or additionally include information indicating when the id token <NUM>-<NUM> expires. In some embodiments, the id token <NUM>-<NUM> may include information about authentication procedures used by the entity <NUM> to authenticate to the identity provider <NUM>. For example, the id token <NUM>-<NUM> may indicate that the id token <NUM>-<NUM> was obtained by the entity <NUM> authenticating to the identity provider using a simple user identity and secret authentication protocol. One such common protocol is the password authentication protocol, where the identity is a username and the secret is a password. Alternatively or additionally, if the entity <NUM> is authenticated to the identity provider <NUM> using double factor authentication, this can be indicated in the id token <NUM>-<NUM>. Alternatively or additionally, if the entity <NUM> is authenticated to the identity provider using a certain strength of password, this sort of information can be indicated in the id token <NUM>-<NUM> itself. For example, the id token may indicate the minimum length of password used to authenticate to the identity provider, use of special characters in the password used to authenticate to the identity provider, use of both upper and lowercase letters in the password used to authenticate to the identity provider, absence of common passwords or other words in the password used to authenticate to the identity provider, etc..

<FIG> illustrate various versions of information that may be included in an id token, illustrated generically at <NUM>. In <FIG>, the id token <NUM> may include identifiers <NUM>. The identifiers <NUM> may include for example, an identifier for a particular log on session. Alternatively or additionally, the identifiers <NUM> may include an identifier identifying the entity. Alternatively or additionally, the identifiers <NUM> may include an identifier identifying groups (e.g., roles) to which the entity belongs, and which can be used to grant additional privileges to the entity. Alternatively or additionally, the identifiers <NUM> may include an identifier identifying restricting group identifiers identifying groups to which the entity belongs, and which can be used to restrict privileges of the entity. Alternatively or additionally, the identifiers <NUM> may include an identifier identifying special capabilities that the entity has. Alternatively or additionally, the identifiers <NUM> may include an identifier identifying the owner of the id token <NUM>. Other identifiers may alternatively or additionally be included in the identifiers <NUM>.

<FIG> further illustrates that the id token <NUM> includes a policy check interval <NUM>. The policy check interval <NUM> includes a value used by a resource provider <NUM>, as discussed in more detail below, to cause the identity provider <NUM> to evaluate conditional access polices including entity health, entity access conditions (e.g., location or network), computing environment conditions, entity behavior, or other items. In some embodiments, this interval may be the same value as an id token renewal time. For example, for the examples illustrated above, this may be <NUM> hour. In some embodiments, this value is not configurable by a tenant administrator.

<FIG> illustrates that other additional information may be included in the id token <NUM>. In some embodiments, the id token <NUM> includes a max policy check interval <NUM>. This value <NUM> will be used by the resource provider <NUM> to determine how long a user session can be kept alive when a policy evaluation endpoint (illustrated by the identity provider <NUM>) is not accessible. This may occur, for example, if the identity provider <NUM> is not accessible due to computer system failure, network issues, or other reasons. In one example embodiment, the max policy check interval <NUM> may be <NUM> days. In some embodiments, the max policy check interval <NUM> is not configurable by the tenant administrator.

<FIG> illustrates that in some embodiments, the id token <NUM> includes a web session idle timeout <NUM> that was configured by an administrator as part of enforced conditional access policy. This value will be used by a resource provider <NUM> to control browser idle timeouts. That is, if a user client is idle for a particular time as specified in the web session idle timeout <NUM>, then the user may be logged out of the user session. In one example embodiment, the web session idle timeout is <NUM> minutes.

In some embodiments, the id token <NUM>-<NUM> will be for a particular user as well as for a client used by the particular user. Thus, in this example, the entity <NUM> includes both the user and the client (including potentially a particular application) used by the user. For example, the user may use a laptop computer with a corresponding laptop computer client application to perform the authentication and resource requests. Thus, the id token <NUM>-<NUM> may include information about the laptop computer client of the entity <NUM>. Alternatively, the user may use a smart phone to perform the authentication, in which case a corresponding smart phone client application is used to perform the authentication and to perform resource requests, meaning that the id token <NUM>-<NUM> will be for an entity <NUM> including a user using a smart phone client.

Returning once again to the example illustrated in <FIG>, the identity provider <NUM> can provide the id token <NUM>-<NUM> to the resource provider <NUM>. The resource provider <NUM> can evaluate the id token to determine that the entity <NUM> has been properly authenticated to the identity provider <NUM> and that the id token <NUM>-<NUM> is otherwise valid. In particular, the id token <NUM>-<NUM> may have an expiration and the resource provider <NUM> can determine that the id token <NUM>-<NUM> has not expired. Ordinarily, so long as this evaluation of the id token <NUM>-<NUM> passes the various checks, then the resources <NUM> will be provided to the entity <NUM>, when requested by the entity <NUM>.

In the example illustrated in <FIG>, the resource provider <NUM> caches the id token <NUM>-<NUM> and the refresh token <NUM>-<NUM> in the cache <NUM>. The resource provider <NUM> issues a long lived session cookie <NUM>-<NUM>, which in the illustrated example has an infinite lifetime, that points to the cache <NUM>. While the session cookie lifetime is technically infinite, in reality it will be that of refresh token <NUM>-<NUM> lifetime.

On every request from the entity <NUM>, the resource provider <NUM> evaluates the policy check interval <NUM>. If the policy check interval <NUM> has expired, the refresh token <NUM>-<NUM> causes the resource provider <NUM> to make a server to server call to the identity provider <NUM> on behalf of the entity <NUM>. It sends the refresh token <NUM>-<NUM> and, optionally, the client IP address to the identity provider <NUM>. The identity provider <NUM> evaluates conditional access policies before when reissuing id token. The refresh token <NUM>-<NUM> only needs to cause renewal of the id token <NUM>-<NUM> when the entity <NUM> is requesting access to resource provider <NUM> resources <NUM>.

As illustrated in <FIG>, the resource provider sends the refresh token <NUM>-<NUM> to the identity provider <NUM> as specified in the policy check interval <NUM>. That is, the policy check interval <NUM> in the id token <NUM> identifies how often the resource provider <NUM> should provide the refresh token <NUM>-<NUM> to the identity provider <NUM> to allow the identity provider <NUM> to perform various policy checks. <FIG> illustrates that assuming that all policy checks are satisfied, then the identity provider <NUM> will provide a new refresh token <NUM>-<NUM> and a new id token <NUM>-<NUM>. This will allow the user session to continue allowing the resource provider <NUM> to provide resources <NUM> to the entity <NUM> without interruption. This process can be repeated as needed to keep the user session active.

However, it should be appreciated that conditions may result in the refresh token <NUM>-<NUM> in the id token <NUM>-<NUM> not being able to be returned to the resource provider <NUM>. In particular, <FIG> illustrate examples of various alternatives that may occur under various conditions.

<FIG> illustrates the condition illustrated above whereby all policy checks are satisfied and where the identity provider <NUM> provides the refresh token <NUM>-<NUM> and the id token <NUM>-<NUM> to the resource provider <NUM> in response to the refresh token <NUM>-<NUM> being sent to the identity provider <NUM>. This assumes the ordinary and successful case where a user session can be continued based on various policies having been met. Such policies may include, for example, policies related to user state, client application state, policy state, location of the entity, networks being used by the entity, behavior patterns of the entity, or other conditional access conditions.

Note that in some embodiments, the identity provider <NUM> may wish to change the interval at which the resource provider <NUM> communicates with the identity provider <NUM> for policy regarding the entity <NUM>. This can be accomplished by simply changing the policy check interval <NUM> included in an id token <NUM> returned to the resource provider <NUM>. For example, the id token <NUM>-<NUM> may be updated with a policy check interval as determined by the identity provider <NUM>. This may occur for various reasons. For example, the identity provider <NUM> may determine that network conditions exist that warrant a shorter policy check interval. For example, a network may be under attack. During the attack period, the policy check interval can be lowered in the id tokens sent to entities to allow the identity provider to perform more frequent policy checks for entities. As network conditions improve, the policy check intervals included in id tokens may be lengthened. A longer policy check interval can be used to reduce network traffic and overhead computing processes needed for authentication and user session maintenance.

However, it can occur that the identity provider <NUM> identifies that policies have not been met and therefore causes the resource provider <NUM> to invalidate the user session. An example of this is illustrated in <FIG>. In this example, the resource provider <NUM> provides the refresh token <NUM>-<NUM> to the identity provider <NUM>. The identity provider <NUM> evaluates policy with respect to the entity <NUM> and identifies that certain policy has not been met. The identity provider <NUM> can then send an error <NUM> to the resource provider <NUM>. For example, the identity provider <NUM> may identify that the entity <NUM> has deleted their user account. Alternatively or additionally, the identity provider <NUM> can identify that the entity <NUM> has had other change to the entity that would cause the entity <NUM> to not comply with certain policy.

As discussed previously, in some embodiments, the resource provider <NUM> will provide the IP address of the entity <NUM> to the identity provider <NUM>. The identity provider <NUM> may identify that the entity <NUM> is attempting access from a network or location that is not compliant with policy at the identity provider <NUM>. In some embodiments, the identity provider <NUM> may identify that an insufficient authentication method was used by the entity <NUM> based on the IP address of the entity <NUM>. Thus, the identity provider <NUM> can send the error <NUM> causing the user session between the resource provider <NUM> and the entity <NUM> to be terminated.

In some embodiments, the error <NUM> may include information that can be provided to the entity <NUM> to indicate to the entity <NUM> why the user session is being terminated. For example, in some embodiments the resource provider can use the information in the error <NUM> to indicate to the entity <NUM> that the user session is being ended due to use of a token that was obtained from the identity provider <NUM> using an authentication method that is not sufficient for the location or network being used by the entity <NUM>. For example, the entity <NUM> may be on an un-trusted network. Policy may require that the entity use multifactor authentication when accessing the resource provider <NUM> from an un-trusted network. If the id token <NUM>-<NUM> was obtained from the identity provider <NUM> using single factor authentication, then as illustrated in the example in <FIG>, when the refresh token <NUM>-<NUM> and the id token <NUM>-<NUM> are sent to the identity provider <NUM>, the identity provider <NUM> can emit an error <NUM> to the resource provider <NUM> indicating that insufficient authentication methods were used given the location or network being used by the entity <NUM>. In some embodiments, this requires that the entity <NUM> have specialized functionality. In particular, ordinarily an entity <NUM> will simply use a cached id token <NUM>-<NUM> at the entity <NUM> when attempting to establish a user session between the entity <NUM> and the resource provider <NUM>. If the refresh token id token <NUM>-<NUM> has not expired, the entity <NUM> will assume that the id token <NUM>-<NUM> at the entity <NUM> is valid and will continue to attempt to establish a user session between the entity <NUM> and the resource provider <NUM>. However, if the entity <NUM> has extended functionality beyond what typical client systems possess, the entity will be able to understand information identifying why a user session has been invalidated. In this case, the entity <NUM> can evaluate the information indicating why a user session was invalidated and does not need to continue retrying attempting to establish a user session using an id token that cannot be used to establish the user session. Rather the entity <NUM> can simply return to the identity provider <NUM> to obtain a new refresh token in a fashion that complies with policy. For example, in the example described above, the entity <NUM> will use multifactor authentication to obtain the id token when the entity <NUM> is at a particular location or using a particular network for which policy requires multifactor authentication.

Thus, <FIG> illustrates that if the identity provider <NUM> responds with an error <NUM> indicating that a refresh token <NUM>-<NUM> is invalid, then the resource provider <NUM> will redirect the entity <NUM> to the identity provider <NUM> for reauthentication.

<FIG> illustrates another example of where errors may be provided. In this example, the resource provider <NUM> sends the refresh token <NUM>-<NUM> to an endpoint <NUM> where the resource provider <NUM> believes that the identity provider <NUM> resides. However, due to hardware failure, system failure, network unavailability, or for other reasons, the identity provider <NUM> may be unavailable at the endpoint <NUM>. In this case an identity provider error <NUM> is returned to the resource provider <NUM>. This indicates that no identity provider is available to evaluate the policy for the entity <NUM>. However, as this is a fairly common occurrence, provisions may be made to allow the user session to continue for a limited period of time. For example, as discussed above a max policy check interval <NUM> may be included in the id token <NUM>-<NUM>. So long as this max policy check interval <NUM> has not been exceeded, the user session can continue between the resource provider <NUM> and the entity <NUM> as the resource provider <NUM> periodically resends the refresh token <NUM>-<NUM> and the id token <NUM>-<NUM> to the endpoint <NUM> to attempt to have policy evaluated for the entity <NUM>. If the max policy check interval <NUM> expires and the resource provider <NUM> has still not been able to obtain a new refresh token and new id token, then the resource provider <NUM> will terminate this user session and redirect the entity <NUM> to the resource provider <NUM> to obtain new credentials. Thus, as illustrated in <FIG>, if the resource provider receives a network or another error which indicates an identity provider outage, the resource provider <NUM> can treat the Max policy check interval <NUM> as the policy check interval and continue the session.

For completeness, the following illustrates an example of pseudocode describing aspects of the process is illustrated above for implementing various embodiments of the invention. //On Sign In:
Validate AccessToken
Use Code and get RefreshToken, (this also returns another AccessToken). Create cache entry and cache Session Info
Cache xms_pci, xms_mpci, inactivity interval from AccessToken. Add last_policy_check _time=AccessToken _issuanceTime in the cache entry. Cache RefreshToken. If KMSI==true
Issue persisted cookie and include reference to the cache entry. //Cookie lifetime=current_time + <NUM> days (same as Evo's SSO cookie)
Else
Issue session cookie and include reference to the cache entry. //On Every request:
Validate cookie. Load cache entry associated with the cookie. // policy check logic
If current_time > last_policy_check_time+xms_pci
Load RefreshToken and Call token endpoint to check policy. If (policy check fails)
Force re-signin
EndIf
If (policy check unavailable) && (current_time> last_policy_check_time+xms_mpci)
Force resignin
Elself (policy check unavailable) && (current_time <=
last_policy_check_time+xms_mpci)
// Optional if high value operations exist
Set internal claim/call context: restrict _high_value_operations=true
EndIf
//policy check returned success. Validate AccessToken and RefreshToken
Update Cache Entry
Update new RefreshToken in the same cache entry
Update new xms_pci, xms_mpci,. from AccessToken in the cache entry
Update last_policy_check_time=AccessToken_issuanceTime in the cache entry. If KMSI==true
Re-Issue persisted cookie. Cookie_lifetime=current_time + 90days (matching the Evo
behavior). Else
Issue session cookie
EndIf
EndIf. // Optional at authorization time
If restrict_high_value_operations==true
// This is the case where there is an outage and the policy check is a bit stale. Block high value operation
EndIf.

Referring now to <FIG>, a method <NUM> is illustrated. The method <NUM> includes acts for managing user sessions in a networked computing environment. The method includes at an identity provider computer system, providing a first id token to a resource provider (act <NUM>). The first id token has therein a first policy check interval having a value defining a period when the first id token should be revalidated.

The method <NUM> further includes, at the identity provider computer system, due to expiration of the first policy check interval, receiving a first refresh token from the resource provider computer system (act <NUM>).

The method <NUM> further includes, at the identity provider computer system, as a result of receiving the first refresh token from the resource provider computer system, evaluating conditional access policy for the entity (act <NUM>).

The method <NUM> further includes, at the identity provider computer system, determining that the conditional access policy for the entity has been met (act <NUM>).

The method <NUM> further includes, providing a new id token and a new refresh token to the resource provider computer system (act <NUM>).

The method <NUM> may further include the identity provider computer system providing an authorization code to the entity that is exchanged at the resource provider computer system for the first refresh token.

The method <NUM> may be practiced where the new id token comprises a new policy check interval having a value that is different than the value of the first policy check interval in the first refresh token.

The method <NUM> may be practiced where evaluating conditional access policy for the entity comprises evaluating at least one of user state changes, client state changes, policy state changes, conditional access conditions being met, location of the entity, or behavior patterns by the entity.

The method <NUM> may be practiced where the first id token comprises a max policy check interval having a value defining a maximum time that can elapse when the identity provider computer system is unavailable to the resource provider computer system before a user session must be invalidated.

The method <NUM> may be practiced where the first id token comprises a web session idle timeout having a value defining when a web application at the resource provider computer system should timeout due to lack of interaction from a user. In some such embodiments, the method <NUM> may further include receiving input from an administrator at the identity provider computer system defining the value of the web session idle timeout.

Referring now to <FIG>, a method <NUM> is illustrated. The method <NUM> includes acts for managing user sessions in a networked computing environment. The method <NUM> includes, at a resource provider computer system, receiving a first id token, having therein a first policy check interval (act <NUM>). The first policy check interval has a value defining a period when the first id token should be revalidated. The first id token is used to provide resources from the resource provider computer system to an entity. In particular, the first id token indicates that the resource provider can provide resources to the entity.

The method <NUM> further includes, at the resource provider computer system, due to expiration of the first policy check interval, sending a first refresh token from the resource provider computer system to an identity provider computer system (act <NUM>).

The method <NUM> further includes receiving from the identity provider computer system a new id token (act <NUM>). This is performed as a result of the identity provider computer system evaluating conditional access policy for the entity and determining that the conditional access policy for the entity has been met.

The method <NUM> may further includes the receiving an authorization code provided to the entity by the identity provider computer system and exchanging the authorization code for the first refresh token.

The method <NUM> may further include receiving the first refresh token from the identity provider computer system.

The method <NUM> may be practiced where the first id token is received from the identity provider computer system.

The method <NUM> may be practiced where the first id token comprises a web session idle timeout having a value defining when a web application at the resource provider computer system should timeout due to lack of interaction from a user.

The method <NUM> may further include providing a long lived cookie, which points to a cache at the resource provider computer system, to the entity.

Having just described the various features and functionalities of some of the disclosed embodiments, attention is now directed to <FIG>, which illustrates an example computer system <NUM> that may be used to facilitate the operations described herein. Computer systems, such as system <NUM> may be used to implement any of the computer systems described above.

The methods may be practiced by a computer system <NUM> including one or more processors <NUM> and computer-readable storage <NUM> such as computer memory. In particular, the computer memory may store computer-executable instructions that when executed by one or more processors <NUM> cause various functions to be performed, such as the acts recited in the embodiments.

Embodiments within the scope of the present invention also include physical and other computer-readable media, such as the storage <NUM>, for carrying or storing computer-executable instructions, data structures, or combinations thereof.

A "network" (e.g., network <NUM>) is defined as one or more data links that enable the transport of electronic data between computer systems, modules, other electronic devices, or combinations thereof. When information is transferred or provided over a network or another communications connection (either hardwired, wireless, or a combination of hardwired or wireless) to a computer (e.g., remote system <NUM>), the computer properly views the connection as a transmission medium. Transmissions media can include a network, or data links which can be used to carry desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer.

For example, computer-executable instructions or data structures received over a network or data link can be buffered in RAM within a network interface module (e.g., a "NIC"), and then eventually transferred to computer system RAM, to less volatile computer-readable physical storage media at a computer system, or combinations thereof.

Although the subject matter has been described in language specific to structural features, methodological acts, or combinations thereof, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the described features or acts described above.

Claim 1:
A method for managing user sessions in a networked computing environment, the method comprising:
at an identity provider computer system (<NUM>), providing a first id token (<NUM>-<NUM>) for an entity (<NUM>) to a resource provider computer system (<NUM>), wherein the first id token (<NUM>-<NUM>) includes an expiration indicator reflecting when the first id token (<NUM>-<NUM>) expires, and the first id token (<NUM>-<NUM>) further includes a first policy check interval (<NUM>) defining how often the resource provider computer system is to communicate with the identity provider computer system (<NUM>) to inquire about a conditional access policy that is to be implemented against the entity (<NUM>);
at the identity provider computer system (<NUM>), due to expiration of the first policy check interval (<NUM>), receiving a first refresh token (<NUM>-<NUM>) from the resource provider computer system (<NUM>);
at the identity provider computer system (<NUM>), as a result of receiving the first refresh token (<NUM>-<NUM>) from the resource provider computer system (<NUM>), evaluating conditional access policy for the entity (<NUM>);
at the identity provider computer system (<NUM>), determining that the conditional access policy for the entity (<NUM>) has been met; and
as a result, providing a new id token (<NUM>-<NUM>) and a new refresh token (<NUM>-<NUM>) to the resource provider computer system (<NUM>).