Step-up authentication for single sign-on

BACKGROUND

0001Modern computing systems provide various methods for user authentication. Some authentication methods include a password requirement, where the user enters his or her user identifier as well as a secret password. This is referred to as single-factor authentication. More secure authentication regimes, such as multiple-factor authentication, require, in addition to a password, a second means of verification, such as a token, smartcard, fingerprint, retinal scan, etc. For example, with smartcard authentication, a user inserts a smartcard into a smartcard reader and enters a personal identification number (PIN). When a correct PIN is entered, one or more certificates that are stored in the smartcard are used to authenticate the user.

0002In computing systems that access remote resources, a user may need to be authenticated each time the remote resources are accessed, requiring the user to repeatedly enter his or her credentials. As a result, for user convenience, a feature referred to as single sign-on (SSO) may be used to reduce the burden on the user by enabling user credentials to be shared between and reused by multiple applications. For example, a web browser that uses SSO may rely on a JSON Web Token (JWT) that identifies the user and stores an authentication event. The JWT can then be stored in a browser cookie for subsequent use by other applications that require a similar type of authentication. That is, a request to the authentication service on behalf of other applications executed within the same browser may include the browser cookie, enabling the authentication service to validate the JWT and verify that the user has already authenticated.

0003In enterprise applications, SSO is an increasingly popular feature due to trends such as Bring Your Own Device (BYOD) and Corporate-Owned Personally Enabled (COPE) devices. For example, enterprise administrators may require enforcement of specific authentication policies when a user accesses sensitive resources, such as payroll, banking, and health care. Consequently, SSO provides a convenient way for a user to enter his or her credentials once and reuse the stored credentials to access various types of sensitive resources.

0004However, because native mobile applications do not store tokens in a browser, the native applications cannot share authentication information in a cookie associated with a shared authentication service. Accordingly, one common mobile SSO approach is token sharing. Token sharing occurs when one native application obtains a token from an authentication service (AS) and then shares that token with other mobile applications. Because the token is shared, the token works only in the situation where all applications are owned by one enterprise resource server. Additionally, because the AS does not know which application submitted the token to access the resource server, the AS cannot revoke the token to prevent only that application from accessing resources, since doing so would block all applications.

0005Further, in some circumstances, even if the user has already been authenticated to the SSO system, accessing sensitive resources may require further authentication via a more secure authentication method, commonly referred to as step-up authentication. As a result, the user is still required to enter his or her credentials each time authentication via the more secure method is requested by an application. Moreover, after the user has provided his or her credentials to perform step-up authentication for a particular application, the user may have to re-enter those credentials (e.g., re-authenticate) to access a resource with that application each time the user's session expires.

0006Accordingly, there are challenges faced by system administrators when attempting to provide users with convenient and secure access to sensitive resources.

SUMMARY

0007One or more embodiments of the present disclosure provide a method for authenticating a user seeking access to first and second resources that have different authentication levels. The method includes receiving a primary token that is associated with a first authentication event of the user and authenticates the user to access the first resource, and receiving a first request to access the second resource. The method further includes receiving first credentials of the user. The method further includes, responsive to validating the first credentials, generating a second authentication event, associating the second authentication event with the primary token, and issuing a first secondary token that authenticates the user to access the second resource.

0008One or more embodiments of the present disclosure further provide a non-transitory computer-readable storage medium comprising instructions that, when executed in a computing device, authenticates a user seeking access to first and second resources that have different authentication levels. The non-transitory computer-readable storage medium includes instructions for receiving a primary token that is associated with a first authentication event of the user and authenticates the user to access the first resource, and receiving a first request to access the second resource. The non-transitory computer-readable storage medium further includes instructions for receiving first credentials of the user. The non-transitory computer-readable storage medium further includes instructions for, responsive to validating the first credentials, generating a second authentication event, associating the second authentication event with the primary token, and issuing a first secondary token that authenticates the user to access the second resource.

0009One or more embodiments of the present disclosure further provide a computer system for authenticating a user seeking access to first and second resources that have different authentication levels. The computer system includes a memory and a processor programmed to carry out the step of receiving, from a token agent, a primary token that is associated with a first authentication event of the user and authenticates the user to access the first resource, and receiving a first request associated with a first application to access the second resource. The memory and the processor are further programmed to carry out the steps of receiving first credentials of the user, and, responsive to validating the first credentials, generating a second authentication event, associating the second authentication event with the primary token, and issuing, to the token agent, a first secondary token that authenticates the user to access the second resource.

BRIEF DESCRIPTION OF THE DRAWINGS

<figref idref="DRAWINGS">FIG. 1</figref> illustrates a system configured to implement one or more aspects of various embodiments.

<figref idref="DRAWINGS">FIG. 2</figref> is a sequence diagram that illustrates example operations for authenticating a user of computing device via authentication service, according to one embodiment.

<figref idref="DRAWINGS">FIG. 3</figref> is a sequence diagram that illustrates example operations for reusing the additional authentication event (e.g., the step-up authentication) described in <figref idref="DRAWINGS">FIG. 2</figref> with one or more other applications, according to one embodiment.

<figref idref="DRAWINGS">FIG. 4</figref> is a flow diagram of an exemplary method performed by authentication service to authenticate a user.

DETAILED DESCRIPTION

0014<figref idref="DRAWINGS">FIG. 1</figref> illustrates a system <b>100</b> configured to implement one or more aspects of various embodiments. As shown, the system <b>100</b> includes, without limitation, a computing device <b>102</b>, an authentication service (AS) <b>120</b>, and one or more resource servers <b>112</b> (e.g., resource server <b>112</b>₁and resource server <b>112</b>₂). Computing device <b>102</b> includes, without limitation, a central processing unit (CPU) <b>104</b> and a memory <b>106</b>. Memory <b>106</b> is configured to store a token agent (TA) 108 and software application(s) <b>110</b> (e.g., application <b>110</b>₁, application <b>110</b>₂, and application <b>110</b>₃). CPU <b>104</b> is configured to execute token agent <b>108</b> and software application(s) <b>110</b>.

0015Computing device <b>102</b> may be any type of electronic device that enables a user to connect to (e.g., via the Internet, a local area network (LAN), an ad hoc network, etc.) and communicate with authentication service <b>120</b>, resource server(s) <b>112</b>, and/or one or more other users. Exemplary electronic devices include, without limitation, desktop computing devices, portable or hand-held computing devices, laptops, tablets, smartphones, mobile phones, personal digital assistants (PDAs), etc. Software application(s) <b>110</b> may be any type of software application. However, in the exemplary embodiment described herein, software application(s) <b>110</b> include native mobile applications that are configured to be executed within a mobile operating system on a mobile device, such as a smartphone. Native mobile applications are generally tied to one type of mobile operating system and are coded in a specific programming language (e.g., Objective C for iOS and Java for Android operating systems). A user of the native mobile applications may issue commands to computing device <b>102</b>, for example, in order to access resources stored on one or more resource servers <b>112</b>.

0016Authentication service <b>120</b> may be offered by an authentication server and include a directory of users and may store user credentials and/or access policies associated with the users. In one embodiment, the authentication service <b>120</b> is external to and independent from the computing device <b>102</b>. For example, the authentication service <b>120</b> may be connected to multiple computing devices to provide authentication service. Access policies stored by authentication service <b>120</b> (e.g., via Active Directory) may be used to track user permissions, such as whether certain users or groups of users are authorized to access various types of resources, as well as the authentication method(s) required before access to such resources can be granted. Authentication service <b>120</b> may further store other types of information associated with user authentication, such as when authentication events occurred (e.g., a timestamp), which authentication method(s) were used, which token(s) are associated with particular users, which tokens have been issued by authentication service <b>120</b>, and the like.

0017Token agent <b>108</b> may be an application on the computing device <b>102</b> configured to acquire, store, and transmit authentication tokens that are used to electronically verify the identity of a user of computing device <b>102</b>. More specifically, token agent <b>108</b> may be configured to collect and securely transmit user credentials (e.g., a username/password, smartcard, SecurID, PIN, etc.) to authentication service <b>120</b> for validation. In response, after validating the user credentials (e.g., via Active Directory or similar service), authentication service <b>120</b> may issue one or more tokens to token agent <b>108</b>. In some embodiments, communications between token agent <b>108</b> and authentication service <b>120</b> are performed via a representational state transfer (REST) API.

0018In various embodiments, token agent <b>108</b> may initially request a user to input user credentials to enable token agent <b>108</b> to log in and obtain a primary token. The primary token may be stored in a local memory of the token agent <b>108</b>. Token agent <b>108</b> may then use the primary token to obtain secondary tokens for application(s) <b>110</b> running on computing device <b>102</b>. The secondary tokens acquired by token agent <b>108</b> may then be stored and/or passed to application(s) <b>110</b>, which use the secondary tokens to obtain access to one or more resources stored on resource server(s) <b>112</b>. For example, application <b>110</b>₁may receive a secondary token from token agent <b>108</b> and transmit the secondary token to resource server <b>112</b>₁. Resource server <b>112</b>₁may validate the secondary token by transmitting the secondary token to authentication service <b>120</b>. Additionally or alternatively, resource server <b>112</b>₁may validate the secondary token locally, for example, based on a trust relationship previously established with application <b>110</b>₁. If resource server <b>112</b>₁successfully validates the secondary token, resource server <b>112</b>₁then grants application <b>110</b>₁access to the requested resource(s). In some embodiments, token agent <b>108</b> issues each native application a different secondary token. Accordingly, in such embodiments, token agent <b>108</b> and/or authentication service <b>120</b> is able to revoke a specific application's <b>110</b> access to a resource without revoking access by all applications.

0019Although <figref idref="DRAWINGS">FIG. 1</figref> shows token agent <b>108</b> as a separate software module, it is also contemplated that token agent <b>108</b> may be integrated with one or more of applications <b>110</b>. When configured as a separate software module, token agent <b>108</b> may be capable of communicating with and transmitting tokens between a variety of different software applications <b>110</b>.

0020Token agent <b>108</b> may be controlled by a user, or token agent <b>108</b> may operate as a background process. Consequently, token agent <b>108</b> may include an interface that is designed for use with conventional input devices, such as a touchscreen device, a mouse, a keyboard, and the like. When token agent <b>108</b> is controlled by the user, the user may initiate a request for a token, authorize certain applications <b>110</b> to use one or more tokens to access remote resources, and/or revoke usage of one or more tokens. Token agent <b>108</b> may further operate automatically or semi-automatically by receiving requests for resources from application(s) <b>110</b>, determining (e.g., based on an access policy) whether an application <b>110</b> is authorized to access certain resources, prompting a user of computing device <b>102</b> for user credentials (when necessary), transmitting acquired tokens to one or more applications <b>110</b>, and/or revoking access of one or more applications <b>110</b> to a token or remote resource.

0021In some embodiments, resource servers <b>112</b> include one or more application deployment environments provided by one or more cloud computing platform providers (sometimes referred to simply as “cloud providers”). For example, computing device <b>102</b> may access resources stored in a deployment environment for development, testing, staging, and production of a web application. Accordingly, each resource server <b>112</b> may include one or more host computers that are organized into one or more clusters. The host computers may include conventional components of a computing device, such as memory, a processor, a disk interface, and a network interface and may be configured to support a virtualized environment to deliver one or more application services related to information technology, including but not limited to, web services, database services, data processing services, and directory services. Authentication service <b>120</b> may be similarly configured.

0022As described above, native mobile applications do not store tokens in a browser. Consequently, when a user authenticates via one application, the token received by the application typically is not accessible to other applications. Additionally, current authentication solutions to obtain tokens from an authentication service require user authentication and authorization, but that user authentication is not saved for future use, preventing the authentication event from being used to subsequently obtain tokens for other applications. Thus, when step-up authentication is performed by one application, there is currently no way to preserve the user authentication information to be used for SSO by other applications. As a result, each time step-up authentication is required by a different application, current authentication solutions require the user to enter his or her credentials and submit the credentials to authentication service <b>120</b> for validation to authorize the application to access resources on their behalf.

0023Accordingly, in various embodiments, to enable step-up authentication to be performed via SSO, user authentication information, such as when a user authenticated and which authentication method was used, may be associated with a primary token stored by token agent <b>108</b>. Then, when the primary token is presented to authentication service <b>120</b> by token agent <b>108</b>, the associated user authentication information may be retrieved and used for dynamic policy evaluation. Such techniques are described below in further detail in conjunction with <figref idref="DRAWINGS">FIGS. 2-4</figref>.

Step-Up Authentication for Single Sign-On

0024The operations of system <b>100</b> are shown in <figref idref="DRAWINGS">FIG. 2</figref>. <figref idref="DRAWINGS">FIG. 2</figref> is a sequence diagram that illustrates example operations for authenticating a user of computing device <b>102</b> via authentication service <b>120</b>, according to one embodiment. While the example operations are depicted as being performed by the system <b>100</b> of <figref idref="DRAWINGS">FIG. 1</figref>, it is contemplated that embodiments may be performed by other suitable systems.

0025At step <b>202</b>, token agent <b>108</b> requests a primary token from authentication service <b>120</b>. In some embodiments, after installing token agent <b>108</b> on computing device <b>102</b>, token agent <b>108</b> may request initial authentication of the user to authentication service <b>120</b>. During initial authentication, token agent <b>108</b> user may pass user credentials to authentication service <b>120</b> to generate an initial authentication event. In return, at step <b>204</b>, token agent <b>108</b> receives a primary token associated with the initial authentication event and stores the primary token in local memory. In some embodiments, authentication events are stored by authentication service <b>120</b> and are associated with the primary token (e.g., via a record).

0026In some embodiments, the primary token includes a JSON Web Token (JWT). The primary token may include an alpha-numeric string that is unique to the user (or to a group of users). Authentication service <b>120</b> may store a record associated with the alpha-numeric string in a directory. The record may include an access policy that is evaluated by authentication service <b>120</b> and indicates the types of resources that a user is authorized to access via the primary token (e.g., by using a secondary token issued by authentication service <b>120</b>). The types of resources that the user is authorized to access may be based on one or more authentication methods (e.g., the initial authentication event) that have been performed by the user. In addition, the primary token may include claims, such as a username, user identification, email address, TenantID, issuer, audience, scope, authentication context (AuthContext), authentication timestamp (AuthTime), issue time, expiration time. Further, the primary token may be signed, for example, in order to detect and/or prevent unauthorized modification of the primary token, or the primary token may be unsigned.

0027Next, at step <b>206</b>, application <b>110</b>₁(“App1”) requests a token from token agent <b>108</b> to access resources stored on resource server <b>112</b>₁. In response to the request from App1, at step <b>208</b>, token agent <b>108</b> transmits the request for resources, the primary token, and an optional identification (ID) associated with App1 (“App1 ID”) to authentication service <b>120</b>. Additionally, in some embodiments, a request for resources from application <b>110</b> may include a device identification (“device ID”), which enables token agent <b>108</b> and/or authentication service <b>120</b> to track which user device (e.g., laptop computer, smartphone, desktop computer, etc.) is requesting resources and/or receiving a secondary token. At step <b>210</b>, authentication service <b>120</b> reads the alpha-numeric string stored in the primary token and accesses the record associated with the primary token. Authentication service <b>120</b> then evaluates an access policy associated with the record to determine whether the user is authorized to access the resources specified in App1's request for resources.

0028If, at step <b>210</b>, authentication service <b>120</b> determines (e.g., based on the initial authentication event) that the user is authorized to access the requested resources, then the sequence proceeds to step <b>228</b>, where authentication service <b>120</b> issues a secondary token for App1 to token agent <b>108</b>. Then, at step <b>230</b>, token agent <b>108</b> passes the secondary token to App1. At step <b>232</b>, App1 transmits the secondary token and the request for resources to resource server <b>112</b>₁, which attempts to validate the secondary token. If resource server <b>112</b>₁determines that the secondary token is valid, at step <b>234</b>, resource server <b>112</b>₁transmits the requested resources to App1.

0029If, however, at step <b>210</b>, authentication service <b>120</b> determines that the user is not authorized to access the requested resources, then the sequence may proceed to step <b>212</b>, where authentication service <b>120</b> replies to token agent <b>108</b> with App1 ID and authentication advice to re-authenticate with an additional authentication method. A one-time access (OTA) token also may be transmitted to token agent <b>108</b> along with the authentication advice.

0030In some embodiments, various types of resources stored in resource server(s) <b>112</b> may be associated with different authentication levels. For example, access to highly sensitive resources (e.g. payroll data) may require a higher authentication level than access to less sensitive resources (e.g., a company message board). Accordingly, if the resources requested by App1 require an authentication level that is higher than the authentication level currently associated with the primary token, then, at step <b>212</b>, authentication service <b>120</b> may indicate to token agent <b>108</b> that more secure authentication (e.g., an additional authentication event) is needed, and, thus, step-up authentication should be performed.

0031At step <b>214</b>, token agent <b>108</b> may launch a user interface into which the user may input additional user credentials associated with the additional authentication method. In order to securely transmit the additional user credentials to, and receive a secondary token from, authentication service <b>120</b>, a protocol such as OAuth (e.g., OAuth 2.0) may be used. At step <b>216</b>, token agent <b>108</b> sends the OTA token as well as a request to authentication service <b>120</b> to authenticate with the additional authentication method (e.g., to perform step-up authentication). In some embodiments, the OTA token indicates how token agent's request should be handled after step-up authentication is successfully performed. Then, at step <b>220</b>, the user interface (e.g., a browser) of token agent <b>108</b> is redirected to the appropriate identity provider in order to collect additional user credentials via a secure connection, such as a secure connection established using the OTA token. In some embodiments, at step <b>220</b>, authentication service <b>120</b> redirects the user interface launched at step <b>214</b> to a webpage of an identity provider. The user then inputs the additional user credentials via the identity provider's webpage.

0032Next, at step <b>222</b>, authentication service <b>120</b> and/or the identity provider accesses the record associated with the primary token and determines whether the additional user credentials submitted by the user are valid. If the additional user credentials are valid, then an additional authentication event associated with the additional authentication method may be generated and associated with the primary token. The additional authentication event that is associated with the primary token may include an authentication method and a time at which the authentication was performed. In some embodiments, the authentication event is associated with the primary token by storing the authentication event in the primary token itself. For example, the authentication event (e.g., the authentication method and an authentication timestamp) may be stored in the AuthContext field of a JWT. In the same or other embodiments, the authentication event may be stored in a record (e.g., stored on authentication service <b>120</b>) that is associated with the primary token, such that the authentication event can be accessed next time the primary token is submitted to authentication service <b>120</b>.

0033At step <b>224</b>, the updated primary token (e.g., including the authentication event associated with the additional user credentials) may be transmitted back to token agent <b>108</b>. Token agent <b>108</b> may then replace its primary token with the updated primary token. Alternatively, if the authentication event is not stored in the primary token itself, step <b>224</b> may be omitted.

0034Next, at step <b>226</b>, token agent <b>108</b> re-submits the request for resources for App <b>1</b>, the primary token, and the optional App1 ID to authentication service <b>120</b>. At step <b>228</b>, authentication service <b>120</b> reads the alpha-numeric string stored in the primary token and accesses the record associated with the primary token. Authentication service <b>120</b> then determines—based on the authentication event stored in the record and/or the authentication event stored in the primary token—that the user has performed the additional authentication method (e.g., the step-up authentication) and, thus, is authorized to access the resources specified in App1's request for resources. A secondary token (e.g., a first secondary token) is then transmitted to token agent <b>108</b>. In some embodiments, the secondary token issued by authentication service <b>120</b> is for use by App1 only. Accordingly, if the secondary token and/or App1 are compromised, access to the requested resources may be revoked for App1 without affecting other applications' <b>110</b> access to various resources.

0035At step <b>230</b>, token agent <b>108</b> passes the first secondary token to App1. At step <b>232</b>, App1 transmits the first secondary token and the request for resources to resource server <b>112</b>₁. Then, at step <b>234</b>, resource server <b>112</b>₁transmits the requested resources to App1.

0036<figref idref="DRAWINGS">FIG. 3</figref> is a sequence diagram that illustrates example operations for reusing the additional authentication event (e.g., the step-up authentication) described in <figref idref="DRAWINGS">FIG. 2</figref> with one or more other applications <b>110</b>, according to one embodiment. While the example operations are depicted as being performed by the system <b>100</b> of <figref idref="DRAWINGS">FIG. 1</figref>, it is contemplated that embodiments may be performed by other suitable systems.

0037At step <b>302</b>, application <b>110</b>₂(“App2”) requests a token from token agent <b>108</b> to access resources stored on resource server <b>112</b>₁. In response to the request from App1, at step <b>304</b>, token agent <b>108</b> transmits the request for resources, the primary token, an optional identification (ID) associated with App2 (“App2 ID”), and an optional device ID to authentication service <b>120</b>. At step <b>306</b>, authentication service <b>120</b> reads the alpha-numeric string stored in the primary token and accesses the record associated with the primary token. Authentication service <b>120</b> then evaluates an access policy associated with the record to determine whether the user is authorized to access the resources specified in App2's request for resources.

0038If the request for resources submitted by App2 specifies the same or similar type(s) of resources that were previously requested by App1 and/or specifies resources that require the same or similar authentication method(s) as the resources that were previously requested by App1, then authentication service <b>120</b> may determine that the user is authorized to access the requested resources. The sequence then proceeds to step <b>324</b>, where authentication service <b>120</b> issues a secondary token (e.g., a second secondary token) for App2 to token agent <b>108</b>. In some embodiments, the secondary token issued for App2 is different than the secondary token issued for App1, enabling authentication service <b>120</b> and/or resource server(s) <b>112</b> to determine which application <b>110</b> is attempting to access resources and revoke such access to a specific application <b>110</b>, if necessary. At step <b>326</b>, token agent <b>108</b> passes the second secondary token to App2. At step <b>328</b>, App2 transmits the secondary token and the request for resources to resource service <b>112</b>₁, which validates the secondary token. Then, at step <b>330</b>, resource server <b>112</b>₁transmits the requested resources to App2.

0039Accordingly, by associating user authentication information, such as when a user authenticated and which authentication method was used, with a primary token stored by token agent <b>108</b>, the technique described above enables step-up authentication to be performed via SSO. Consequently, user credentials may be inputted once to perform step-up authentication, and the resulting authentication event may be used by multiple applications, increasing user convenience while maintaining secure access to sensitive resources.

0040Alternatively, if, at step <b>306</b>, authentication service <b>120</b> determines that the user is not authorized to access the resources requested by App2, then the sequence may proceed to step <b>308</b>, where authentication service <b>120</b> replies to token agent <b>108</b> with App2 ID, an OTA token, and advice to re-authenticate with yet another authentication method. In some embodiments, yet another authentication method may be required if App2 attempts to access a different type of resources than the resources that were accessed by App1 and/or attempts to access resources from a different resource server <b>112</b> (e.g., resource server <b>112</b>₂) than was accessed by App1. In response to the advice to re-authenticate, at step <b>310</b>, token agent <b>108</b> may again launch a user interface into which the user may input user credentials associated with yet another authentication method. At step <b>312</b>, token agent <b>108</b> sends the OTA token and a request to authentication service <b>120</b> to authenticate with the additional authentication method (e.g., to perform step-up authentication once again). The request may include App2 ID as well as the authentication advice provided by authentication service <b>120</b>. At step <b>316</b>, the user interface of token agent <b>108</b> is redirected to the appropriate identity provider in order to collect the user credentials via a secure connection, such as a secure connection established using the OTA token.

0041Next, at step <b>318</b>, authentication service <b>120</b> and/or the identity provider accesses the record associated with the primary token and determines whether the user credentials submitted by the user are valid. If the user credentials are valid, then another authentication event associated with the additional authentication method may be associated with the primary token (e.g., stored in the primary token itself and/or stored in a record associated with the primary token).

0042At step <b>320</b>, the updated primary token (e.g., including the authentication event generated at step <b>318</b>) may be transmitted to token agent <b>108</b>. Then, at step <b>322</b>, token agent <b>108</b> re-submits the request for resources for App <b>2</b>, the primary token, and the optional App2 ID to authentication service <b>120</b>. At step <b>324</b>, authentication service <b>120</b> accesses the record associated with the primary token and determines that the user has performed the required authentication method (e.g., the additional step-up authentication). A secondary token (e.g., a second secondary token) is then transmitted to token agent <b>108</b>. At step <b>326</b>, token agent <b>108</b> passes the second secondary token App2. At step <b>328</b>, App2 transmits the first secondary token and the request for resources to resource server <b>112</b>₁(or, as described above, to resource server <b>112</b>₂). Then, at step <b>330</b>, resource server <b>112</b>₁(or resource server <b>112</b>₂) transmits the requested resources to App2.

0043Although not explicitly shown in <figref idref="DRAWINGS">FIGS. 2 and 3</figref>, one or more additional applications <b>110</b> (e.g., application <b>110</b>₃) also may use the authentication events associated with the primary token to access resources using SSO. Additionally, one or more of applications <b>110</b> may use the primary token and its associated authentication events to re-authenticate a user session, such as when the session has timed out.

0044<figref idref="DRAWINGS">FIG. 4</figref> is a flow diagram of an exemplary method <b>400</b> performed by authentication service <b>120</b> to authenticate a user. It should be recognized that, even though the method <b>400</b> is described in conjunction with the systems of <figref idref="DRAWINGS">FIGS. 1-3</figref>, any system configured to perform the method steps is within the scope of embodiments of the disclosure.

0045Method <b>400</b> begins at step <b>402</b>, where authentication service <b>120</b> receives user credentials from a user (e.g., via a user interface generated by token agent <b>108</b>). Authentication service <b>120</b> may validate the user credentials based on a record stored in a user directory. At step <b>404</b>, after validating the user credentials, authentication service <b>120</b> associates the initial authentication event with the primary token and issues the primary token to token agent <b>108</b>, as described above in conjunction with <figref idref="DRAWINGS">FIG. 2</figref>.

0046At step <b>406</b>, when an application <b>110</b> (e.g., application <b>110</b>₁) executing on computing device <b>102</b> requests access to resources, authentication service <b>120</b> receives the primary token, the request for resources, an optional App ID (e.g., App1 ID), and an optional device ID from token agent <b>108</b>. Then, at step <b>408</b>, authentication service <b>120</b> evaluates an access policy associated with the primary token. Based on the access policy, at step <b>410</b>, authentication service <b>120</b> determines whether the authentication event associated with the primary token is sufficient to enable application <b>110</b>₁to access the requested resources. If the authentication event is sufficient, then, at step <b>420</b>, authentication service <b>120</b> issues a secondary token associated with the requested resources to token agent <b>108</b>.

0047If, however, the authentication event is insufficient, then, at step <b>430</b>, authentication service <b>120</b> requests and receives additional user credentials from the user, as described in further detail in steps <b>212</b>-<b>220</b> and steps <b>308</b>-<b>316</b> of <figref idref="DRAWINGS">FIGS. 2 and 3</figref>, respectively. Once valid additional user credentials are received from the user, at step <b>432</b>, authentication service <b>120</b> associates the additional authentication event with the primary token. Next, at optional step <b>434</b>, if authentication service <b>120</b> stores the additional authentication event associated with the additional user credentials in the primary token, then authentication service <b>120</b> may transmit the updated primary token to token agent <b>108</b>. Alternatively, if the additional authentication event is not stored in the primary token itself, then step <b>434</b> may be omitted. Method <b>400</b> then returns to step <b>406</b>, where the primary token is received from token agent <b>108</b>. At step <b>408</b>, authentication service <b>120</b> evaluates the access policy based on the primary token and, at step <b>410</b>, determines that the authentication events associated with the primary token are sufficient to access the requested resources. Then, at step <b>420</b>, authentication service <b>120</b> issues a first secondary token to token agent <b>108</b>. Method <b>400</b> then terminates.

0048The various embodiments described herein may employ various computer-implemented operations involving data stored in computer systems. For example, these operations may require physical manipulation of physical quantities usually, though not necessarily, these quantities may take the form of electrical or magnetic signals where they, or representations of them, are capable of being stored, transferred, combined, compared, or otherwise manipulated. Further, such manipulations are often referred to in terms, such as producing, identifying, determining, or comparing. Any operations described herein that form part of one or more embodiments may be useful machine operations. In addition, one or more embodiments also relate to a device or an apparatus for performing these operations. The apparatus may be specially constructed for specific required purposes, or it may be a general purpose computer selectively activated or configured by a computer program stored in the computer. In particular, various general purpose machines may be used with computer programs written in accordance with the teachings herein, or it may be more convenient to construct a more specialized apparatus to perform the required operations.

0049The various embodiments described herein may be practiced with other computer system configurations including hand-held devices, microprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, and the like.

0050One or more embodiments may be implemented as one or more computer programs or as one or more computer program modules embodied in one or more computer readable media. The term computer readable medium refers to any data storage device that can store data which can thereafter be input to a computer system computer readable media may be based on any existing or subsequently developed technology for embodying computer programs in a manner that enables them to be read by a computer. Examples of a computer readable medium include a hard drive, network attached storage (NAS), read-only memory, random-access memory (e.g., a flash memory device), a CD (Compact Discs) CD-ROM, a CD-R, or a CD-RW, a DVD (Digital Versatile Disc), a magnetic tape, and other optical and non-optical data storage devices. The computer readable medium can also be distributed over a network coupled computer system so that the computer readable code is stored and executed in a distributed fashion.

0051Although one or more embodiments have been described in some detail for clarity of understanding, it will be apparent that certain changes and modifications may be made within the scope of the claims. For example, while embodiments herein have referred to certain types of communications services <b>220</b> and methods of transmitting messages between users of communications services <b>220</b>, it should be recognized that other types of communication services <b>220</b> and messaging techniques may be utilized in alternative embodiments. Accordingly, the described embodiments are to be considered as illustrative and not restrictive, and the scope of the claims is not to be limited to details given herein, but may be modified within the scope and equivalents of the claims. In the claims, elements and/or steps do not imply any particular order of operation, unless explicitly stated in the claims.

0052Plural instances may be provided for components, operations or structures described herein as a single instance. Finally, boundaries between various components, operations and data stores are somewhat arbitrary, and particular operations are illustrated in the context of specific illustrative configurations. Other allocations of functionality are envisioned and may fall within the scope of the embodiments. In general, structures and functionality presented as separate components in exemplary configurations may be implemented as a combined structure or component. Similarly, structures and functionality presented as a single component may be implemented as separate components. These and other variations, modifications, additions, and improvements may fall within the scope of the appended claims(s).