BR112016026309B1 - METHOD IMPLEMENTED BY A COMPUTING DEVICE FOR FORKED AUTHENTICATION TOKEN TECHNIQUES - Google Patents

Abstract

FORK AUTHENTICATION TOKEN TECHNIQUES Forked authentication token techniques are described, in which access control credentials are separated from corresponding privilege data for resources. During client authentication, a determination is made by considering whether a service provider is configured to support forked authentication token techniques. If the techniques are supported, a lightweight token is issued to the client and corresponding privilege data is stored separately from the token in a centralized authentication database. If a service provider does not support forked authentication token techniques, a traditional combined authentication token that includes privilege data is issued to the customer. The lightweight token contains identity information and a reference to privilege data, but does not contain the actual privilege data. Therefore, the lightweight cookie token alone is not enough to gain access to corresponding resources. Furthermore, the privileges associated with a lightweight token can be revoked or changed without having to exchange or invalidate the lightweight token itself.

Description

BACKGROUND

[001] Users of computing devices can use local and online accounts to access various computing resources. Users can seek access to their accounts from different devices and can also share devices to access respective accounts. User authentication to prove that users "are who they say they are", differentiate between users, and provide selective access to computing resources is a persistent challenge faced by service providers. Traditionally, authentication techniques may rely on shared secrets such as passwords and/or digital tokens (e.g., TGTs ticket grant tickets, encrypted blobs, cookies, or other access control credentials). However, shared secrets and digital tokens can be stolen or compromised. Furthermore, traditional tokens can include both identity and privilege data so that possession of a valid digital token (even if stolen) is sufficient to gain access to corresponding resources by presenting the token to a service provider. Thus, although authentication techniques based on shared secrets can be effective, there are some drawbacks associated with existing techniques.

SUMMARY

[002] Forked authentication token techniques are described. In one or more implementations, an authentication service is configured to separate access control credentials from corresponding privilege data for resources that support forked authentication token techniques. To do so, the authentication service may make a determination in connection with the authentication of a client as if a service provider were configured to support forked authentication token techniques. If the techniques are supported, a lightweight token is issued to the client and corresponding privilege data is stored in a centralized authentication database from which service providers can search privilege data. If, on the other hand, a service provider does not support forked authentication token techniques, a traditional client-side authentication token that includes privilege data is issued to the client.

[003] The lightweight token used for forked authentication token techniques may be configured to contain identity information and a link/reference to privilege data, but does not contain the actual privilege data. Therefore, the lightweight cookie token alone is not enough to gain access to corresponding resources. Furthermore, the privileges associated with a lightweight token can be revoked or changed by exchanging the privilege data in the centralized authentication database and without having to exchange or invalidate the lightweight token yourself.

[004] This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This summary is not intended to identify key aspects or essential aspects of the subject matter claimed, nor is it intended to be used to limit the scope of the subject matter claimed.

BRIEF DESCRIPTION OF THE DRAWINGS

[005] Figure 1 illustrates an exemplary operating environment in which forked authentication token techniques can be employed.

[006] Figure 2 is a diagram showing an exemplary interaction scenario for issuing tokens according to one or more implementations.

[007] Figure 3 is a diagram showing an exemplary interaction scenario in which tokens are employed to control access to resources according to one or more implementations.

[008] Figure 4 is a flow diagram describing details of an exemplary procedure in which an authentication service selectively issues authentication tokens for access to resources.

[009] Figure 5 is a flow diagram describing details of an exemplary procedure in which a service provider controls access to resources based on a lightweight token.

[0010] Figure 6 is a flow diagram describing details of an exemplary procedure in which privileges associated with a lightweight token are modified.

[0011] Figure 7 is a block diagram of a system showing details of exemplary devices and components in accordance with one or more implementations.

DETAILED DESCRIPTION Overview

[0012] Traditionally, authentication techniques may rely on shared secrets such as passwords and/or digital tokens (e.g., TGTs ticket grant tickets, encrypted blobs cookies, or other access control credentials). However, shared secrets and digital tokens can be stolen or compromised. Furthermore, tokens can be issued with long validity periods during which access rights can change. Furthermore, traditional tokens can include both identity and privilege data so that possession of a valid digital token (even if stolen) is sufficient to gain access to corresponding resources by presenting the token to a service provider.

[0013] Forked authentication token techniques are described. In one or more implementations, an authentication service is configured to separate corresponding privilege data access control credentials for resources and service providers that support forked authentication token techniques. To do so, the authentication service may make a determination in connection with authenticating a client as to whether a service provider associated with a resource that the client is attempting to access is configured to support forked authentication token techniques. If forked authentication token techniques are supported, a lightweight token (e.g., a cookie) is issued to the client and the corresponding privilege data is stored in a centralized authentication database from which service providers can look up the privilege data. If, on the other hand, a service provider does not support forked authentication token techniques, a combined traditional authentication token that includes privilege data is issued to the customer.

[0014] The lightweight token used for the forked authentication token techniques may be configured to contain identity information and a link/reference to the privilege data, but does not contain the actual privilege data. Therefore, the lightweight token alone is not enough to gain access to corresponding resources. Because the lightweight token does not contain privilege data, the lightweight token can have a size that is significantly smaller than traditional blended tokens. Furthermore, the privileges associated with a lightweight token can be revoked or changed by exchanging the privilege data in the centralized authentication database and without having to exchange or invalidate the lightweight token itself.

[0015] In the discussion that follows, a section entitled "Operational Environment" is provided and describes an environment in which one or more modalities may be employed. After this, a section titled "Forked Authentication Token Examples" describes techniques and details according to one or more implementations. Lastly, a section entitled "Exemplary System" describes exemplary computing systems and devices that can be used in one or more implementations.

Operating Environment

[0016] Figure 1 generally illustrates an operating environment in accordance with one or more embodiments, generally in 100. The environment 100 includes a computing device 102 that is communicatively coupled over a network 104 to a service provider 106. The computing device computing may be configured in various ways to access and interact with various resources 107 (e.g., content and services) that are made available by the service provider over the network 104. The resources 107 may include any appropriate combination of content and/or services typically made available over a network by one or more service providers. For example, content may include various combinations of text, video, advertisements, audio, multimedia streams, animations, images, web pages, and the like. Some examples of services include, but are not limited to, an online computing service (e.g., "cloud" computing), an authentication service, web-based applications, a file storage and collaboration service, a search, messaging services such as email and/or instant messaging, and a social networking service.

[0017] The computing device is also represented as including an operating system 108 and one or more applications 110 that may reside on the computer-readable media and that are executable by a processing system of the computing device. The processing system may be configured in various ways to retrieve and execute application computer program instructions 110 to provide a wide range of functionality to the computing device 102, including but not limited to accessing local resources available from the operating system. 108, gaming, office productivity, email, media management, printing, networking, web browsing to access resources 107, and so on. A variety of application-related data and program files may be included, examples of which include game files, office documents, multimedia files, emails, data files, web pages, user profile and/or data preference, and so on.

[0018] The computing device 102 may be incorporated as any appropriate computing system and/or device such as, by way of example and not limitation, a gaming system, a desktop computer, a laptop computer, a tablet or desktop computer. imager, a handheld computer such as a personal digital assistant (PDA), a cellular telephone, a set-top box, and the like. For example, the computing device 102 may be implemented as a television client device, a computer, and/or a gaming system that is connected to a video device to display media content. Alternatively, the computing device may be any type of portable computer, mobile telephone, handheld device, or still image device, and/or may include an integrated display. Any of the computing devices can be implemented with multiple components, such as one or more processors and memory devices, as well as with any combination of different components. An example of a computing system that can represent multiple systems and/or devices including computing device 102 is shown and described below in Figure 7.

[0019] Computer-readable media may include, by way of example and not limitation, all forms of volatile and non-volatile memory and/or storage media that are typically associated with a computing device. Such media may include ROM, RAM, flash memory, hard disk, removable media, and the like. Computer-readable media may include both "computer-readable storage media" and "communication media", examples of which can be found in the discussion of the exemplary computing system of Figure 7.

[0020] The forked authentication token techniques described herein can be used to control customer access to either or both local accounts and web-based accounts. The computing device may, for example, be employed by a user to attempt to log in to a user account by asserting credentials 112 that may be verified through an authentication service 114 as part of the authentication sequence. Accordingly, authentication service 114 represents functionality operable to resolve a user ID to control access to resources 107. Authentication service 114 may be provided by a service provider 106 from which resources 107 are sought, as a service as a standalone service (as illustrated), or otherwise. The authentication service 114 may implement a sequence of authentications using various protocols to determine that a user seeking access to resources is what they claim to be and/or are authorized to access the resources. Exemplary authentication protocols that can be used include, but are not limited to Kerberos, Active Directory Federation Services (ADFS), and Host Identity Protocol (HIP), to name a few.

[0021] Authentication service 114 may verify asserted credentials 112 against credentials (e.g., user ID, password, key, shared secret, etc.) that are maintained in association with accounts as part of user account data when authentication is successful (e.g., the client "is who they say they are"), the authentication service may issue token(s) (e.g., TGTs encrypted blobs, cookies, and/or other security control credentials). appropriate access) to enable access to corresponding resources. In one implementation, the authentication service 114 may be configured to support traditional blended token techniques as well as forked authentication token techniques in which the privilege data is separated from a corresponding token, e.g., a lightweight token. A single authentication may correspond to one or more resources 107, such that authentication for a single account by a "single written control" may provide access to individual resources, resources from multiple service providers 106, and/or to a package of available resources from a service provider 106. Thus, on successful verification of credentials 112, the computing device can be connected to a user account and therefore authorized access to resources 107 can be given to the account. If the authentication service is unable to verify credentials, access to resources 107 is denied, a reminder to retry may be issued, and so on.

[0022] Having described an exemplary operating environment, we now consider exemplary details regarding input challenge-based authentication in accordance with one or more embodiments.

Forked Authentication Token Examples

[0023] In the following section, implementation details and exemplary techniques for forked authentication token techniques are discussed. The discussion includes some of the exemplary procedure(s) that can be implemented in connection with any appropriate hardware, software, firmware, or combination thereof. In at least some embodiments, the procedures may be implemented through an appropriately configured computing device that includes or otherwise makes use of an authentication service 114. Aspects of the procedure may also be implemented by a computing device 102 and /or by functionality that is distributed between a service provider 106 and a computing device 102.

Exemplary Interaction Scenarios

[0024] Figure 2 represents generally 200 an exemplary interaction scenario in which authentication tokens are issued to a client. In particular, the exemplary interaction scenario represents operations that may be performed by one or more components of the exemplary operating environment 100 of Figure 1 that are labeled using the letters "A" through "E". For example, at "A" a client/user 201 may operate a computing device 102 to form an access request 202 to obtain resources 107 from a service provider 106. For example, a browser may be navigated to a website particular and/or web service made accessible by the service provider 106 over a network 104. In response to the access request 202, the service provider 106 at "B" may issue a challenge 204 for user authentication, which initiates a sequence of authentications. In some implementations, the service provider 106 may incorporate an authentication service 114 to perform client/user authentication 201 on its own behalf. Additionally, or alternatively, service provider 106 may configure challenge 204 to cause redirection of the computing device to an external and/or third-party authentication service 114 operable to perform authentications on behalf of one or more service providers. 106 for access to corresponding resources.

[0025] As part of the authentication sequence, the client/user 201 may be represented with a login page or other appropriate interface associated with the authentication service 114 that provides a request to enter credentials 112 for authentication. In "C", the computing device 102 may communicate the credentials 112 provided by the client/user in response to the request to the authentication service 114 for verification. Credentials 112 may be, for example, a user ID and password combination. Other types of authentication schemes and corresponding types of credentials are also contemplated, such as the use of image-based challenges, an established input pattern, a combination of touch gesture, biometric authentication, a code, and so on. As noted, the authentication service 114 may verify the asserted credentials 112 by checking them against known credentials that are maintained in association with accounts as part of user account data. Additionally, authentication service 114 may be configured to support traditional combined token techniques as well as forked authentication token techniques in which privilege data is separated from a corresponding token (e.g., a lightweight token).

[0026] Thus, upon successful authentication of credentials 112 by the authentication service 114, the authentication service 114 at "D" may issue at least one authentication token 206 and communicate the authentication token(s) 206 back to computing device 102 for use in accessing corresponding resources. The authentication tokens 206 may be configured as various types of tokens such as TGTs ticket grant tickets, encrypted blobs, cookies, or other access control appropriate credentials used in connection with various authentication protocols. As discussed in detail above and below, the authentication service 114 may further operate to make determination about a resource by the resource and/or provider by the provider bases if it is issued (e.g., lightweight tokens (e.g., when token techniques authentication tokens are supported) or combined tokens of the traditional type (e.g. for providers and resources that do not support forked authentication token). In order to identify and distinguish between providers/resources that support forked authentication tokens and those that do not, The authentication service 114 may reference appropriate data such as a table, database, file, list, or other data structure having properties, fields, and/or metadata indicative of whether or not particular providers/resources support forked authentication. authentication tokens 114 may then selectively provide authentication tokens in different formats based on support determinations.

[0027] Accordingly, authentication tokens 206 issued by authentication service 114 may or may not be configured to contain corresponding privilege data 208. Privilege data 208 is configured to indicate access privileges that are granted to clients/users through of corresponding accounts. In other words, privilege data 208 provides indications of resources and/or service providers with which a client/user is permitted to interact. The privilege data 208 may also include an indication of a designated validity period of time during which the token is valid, which may be on the order of hours, days, or weeks. Privilege data 208 may further encompass various other metadata such as preferences, group membership numbers, context cues, location cues, language selections, identity claims, service levels, device capabilities, and so on.

[0028] In traditional tokens, privilege data 208 may be combined with identity information into a granted token. For example, privilege data 208 may be encrypted within a Kerberos-based token such as a privilege attribute certificate (PAC) and/or in other modes for different authentication protocols. A service provider can therefore utilize a token containing privilege data 208 directly to identify a user and extract corresponding access privileges to control resource 107. This approach does not involve having to look up privileges from a source other than the presented token. . A drawback to this approach, however, is that during the validity time period a token, even if understood or stolen, is sufficient to gain access to corresponding resources by presenting the token to a service provider. Since the combined token is essentially self-contained, it may be difficult to revoke or exchange associated privileges. Additionally, embedding privilege data 208 within the token increases the size of the token and in some cases may result in bandwidth overruns or size limits placed on headers, token size, and/or network traffic.

[0029] Thus, in accordance with forked authentication token techniques, authentication service 114 may be configured to separate privilege data 208 from issued tokens and store the privilege data in a network-accessible storage location, such as in a centralized authentication database 210 as depicted in Figure 2. The centralized authentication database 210 may be representative of a centralized and/or replicated repository for customer/user account data including privilege data 208. Centralized authentication database 210 may be configured as an integrated component of the authentication service 114 or alternatively may be provided as a stand-alone service implemented by the same or different server(s) and/or provider(s) (e.g., an external service ).

[0030] For example, in "E" the privilege data 208 associated with an issued token is represented as being communicated for storage in the centralized authentication database 210. In this example, the authentication token 206 issued in "D" may be configured as a lightweight token that does not contain privilege data 208. Preferably, the lightweight token may be configured to contain a link, URL, address, or other reference to the network-accessible storage location from which service providers can obtain corresponding privilege data 208. In one approach, the lightweight token may be configured as a relatively small cookie that includes a reference to network-accessible storage. The reference is usable by a service provider to look up privilege data associated with the client from the centralized authentication database 210 (or other storage location). The lightweight token, however, does not contain sufficient privilege data to enable the service provider to determine resources that the client is authorized to use without a lookup from the centralized authentication database. Thus, generally speaking, combined authentication tokens do not contain sufficient information to enable a determination by service providers with reference to clients' access privileges without reliance on external information.

[0031] Privileges associated with an issued soft token may be revoked or exchanged by modifying privilege data 208 maintained in centralized authentication databases 210. This modification of privileges may occur without altering the soft token or affecting the validity of the soft token . In other words, privileges can be exchanged while a token remains valid and the token is subsequently usable to access resources according to the modified privilege. Little or no delay exists between modifying privileges or enforcing access privileges when a token is presented. Furthermore, privilege switches take effect without having to re-authenticate or issue a new authentication token to the user/client.

[0032] Figure 3 generally represents at 300 an exemplary interaction scenario in which tokens are employed to control access to resources according to one or more implementations. In particular, the exemplary interaction scenario represents operations that may be performed by one or more components of the exemplary operating environment 100 of Figure 1 that are labeled using the letters "F" through "I". After obtaining an authentication token 206 in the manner just described in Figure 2, a client/user 201 may navigate to access various resources available from service providers 106. For example, the computing device 102 may be operated to form an access request . In "F" the authentication token 206 may be communicated as part of the access request and/or in response to a request from the provider to supply the authentication token 206. For the purpose of this example, it is assumed that the token Authentication token 206 is a lightweight token as described herein that does not include privilege data 208.

[0033] Accordingly, the service provider 106 in this example may be "a forked authentication token-aware provider" that is configured to recognize and handle lightweight tokens in addition to or in place of traditional blended tokens. By way of example, service provider 106 may detect that the token is a lightweight token based on identifying data included with the token such as a header field, a code, a token format, a reference or link to the data of privilege within the token, absence of privilege data within the token, and so on. Responsive to detecting a lightweight token, the service provider 106 is configured to perform operations to fetch the total privilege data 208 corresponding to the token.

[0034] In particular, the service provider 106 may parse the token to extract a link or other reference to the centralized authentication database 210 (or other designated storage locations). In "G", the service provider uses the extracted link/reference to form a query 302 and then communicates the query 302 to the centralized authentication database 210 to look up the corresponding privilege data 208. In response to the query 302, the service provider in "H" obtains privilege data 208, which can be used to control access to resources 107 as specified by privilege data 208. In verifying that a client/user is allowed access to the requested resources in accordance with the privilege data 208, the service provider 106 in "I" enables access to the resource 107, and the computing device 102 is capable of interacting with the resources 107. Additional details with reference to these and other aspects of token techniques Forked authentication methods are discussed in relation to the exemplary procedures they follow.

Exemplary Procedures

[0035] Figure 4 represents an exemplary procedure 400 in which an authentication service selectively issues authentication tokens for access to resources. Credentials are obtained from a client for authentication to access resources from a service provider (block 402). For example, a computing device 102 may be operated to supply credentials 112 (e.g., user ID and password or other authentication credentials) associated with a user/client in connection with an attempt to access resources of a service provider. 106. The authentication service 114 is configured to use the supplied credentials to authenticate the client to access resources from the service provider. To do so, a comparison is made between the credentials that are obtained and the corresponding credentials maintained in association with the client (block 404). Based on the comparison, a determination is made regarding whether the client is authenticated to gain access to resources (block 406). If the client is not authenticated, access to resources is denied (block 408). Conversely, when authentication is successful, a determination is made regarding whether the service provider from which resources are fetched is a provider aware of the forked authentication token (block 410). In the case where the service provider is not aware, the combined authentication token is issued to the client (block 412). The combined authentication token is configured to include the privilege data 208. For example, the privilege data may be encrypted within the combined authentication tokens 206 issued to service providers 106 and resources 107 that are not configured to support the combined authentication techniques. forked token. By way of example, the privilege data 208 may be embedded within a token using an encrypted PAC, data blobs, or other appropriate mechanism for including the privilege data with the token. As noted previously, privilege data is configured to provide indications of resources from one or more service providers that a client is authorized to use in successful authentication, as well as client identifying information and other metadata. Because the combined token includes both client identification information and privilege data, the combined authentication token enables a direct determination by the service provider of resources that the client is authorized to use.

[0036] When the service provider is aware, however, forked authentication token techniques are employed (block 414). At present, a lightweight token is issued to the client (block 416) and corresponding privilege data is communicated to a centralized authentication database (block 418) for storage separately from the lightweight token. The lightweight token does not contain sufficient privilege data to enable the service provider to determine resources that the client is authorized to use without a lookup from the centralized authentication database. Instead, the lightweight token is configured to include a reference usable by the service provider to look up privilege data associated with the client from the centralized authentication database. Privilege data may vary depending on one or more client access rights, the type of resource that is accessed, and/or additional contextual information in the lightweight token that is passed by the resource to the centralized authentication database. For example, the reference may be an address, link, or URL to a storage location for privilege data in the centralized authentication database. Access privileges associated with the lightweight token are controlled based on the privilege data stored in the centralized authentication database. Consequently, possession of the lightweight cookie token alone is not sufficient to gain access to resources. Furthermore, a switch in the access privileges associated with a lightweight token can be accomplished by modifying the corresponding privilege data stored in the centralized authentication database without having to revoke or exchange the lightweight token itself. More details regarding techniques for modifying the privileges associated with a lightweight token are discussed below in relation to the exemplary procedure in Figure 6.

[0037] Because the lightweight token does not include full privilege data, the amount of information included in the lightweight token is substantially less than the information that is included in the combined authentication token (e.g., full privilege data). As such, the lightweight token has a size that can be considerably smaller than the size of a corresponding combined authentication token. Consequently, the lightweight token may be easier to manipulate and transport as well as more likely to satisfy any bandwidth or token size constraints. Additionally, the relatively small size of the lightweight token may make it possible to communicate the lightweight cookie in an uncompressed format in some scenarios, which is not generally possible with larger combined tokens that carry full privilege data.

[0038] Figure 5 represents an exemplary procedure 500 in which a service provider controls access to resources based on a lightweight token. A lightweight token is obtained that is provided by a client for access to resources from a service provider (block 502). A client/user may obtain the lightweight token in accordance with the above procedure 400 of Figure 4 and the exemplary interaction scenario of Figure 2. For example, a lightweight token may be issued to a client by an authentication service 114 configured to determine whether service providers 106 support forked authentication token techniques. Based on these determinations, authentication service 114 operates to: (1) issue lightweight tokens that do not include privilege data 208 for access to resources 107 of service providers 106 that support forked authentication token techniques, and (2) issuing combined authentication tokens that include privilege data 208 for accessing resources 107 from service providers 106 that do not support forked authentication token techniques.

[0039] During an established validity time period for a lightweight token, the lightweight token may be presented by the client/user in connection with an attempt to access resources from the service provider. The resource access provider presents as a lightweight token and parses the token to extract a reference to a location where the corresponding privilege data is available. For example, the service provider may recognize the token as a lightweight token based on various identification data included with the token as described previously.

[0040] Once the service provider recognizes the token as a lightweight token, the service provider is configured to perform operations to obtain corresponding privilege data 208 which, in accordance with the forked authentication token techniques described herein are kept separate from a lightweight token itself. Instead of enclosing the privilege data with a token, the lightweight token is linked to the privilege data associated with the client through a reference to a storage location for the privilege data, such as in a centralized authentication database. as described in this document. The service provider uses this reference to look up privilege data for the client from the location specified by the lightweight token (block 504). For example, the lightweight cookie token alone is insufficient to enable the service provider to determine the resources that the client is authorized to use without looking up the privilege data from the location specified by the lightweight cookie token. Consequently, access to resources is selectively controlled by the service provider based on the privilege data that the service provider looks for.

[0041] In particular, the service provider verifies and the client has privileges to access resources (block 506) according to the privilege data maintained at the location indicated in the lightweight token. For example, the service provider may interact with the centralized authentication database to look up group memberships, resource authorizations, service levels, and/or other customer privileges with respect to resources that are reflected by the privilege data 208 When the client has privileges for particular resources, access to those individual resources is precluded (block 508). On the other hand, when the client does not have privileges for some resources, access to those resources is denied (block 510).

[0042] Note that forked authentication token techniques can also be used for references between different domains or segments of a domain. Within a trust boundary for a set of domains that use the same authentication database (for example, a domain forest) a lightweight token can be issued or transferred to the referring domain (as long as the resource supports the approach forked) to enable access to privileged data. Additionally, forked authentication token techniques can be applied to resources and domains across trust boundaries that can have separate authentication databases and privilege data, such as in the case of Active Directory domain forests. In such cross-boundary reference situations, a lightweight token cannot work across domain forests if the privilege data switches the trust boundary. In order to handle these situations, a combined authentication token containing the full privilege data can be issued across such a trust boundary. Within separate domains, however, lightweight tokens and forking techniques can be used for resources within trust boundaries as well as for references leading up to the root domain of a forest, and after the forest trust boundary is crossed, to down to the resources in the reference domain in the manner described in this document.

[0043] Figure 6 represents an exemplary procedure 600 in which privileges associated with a lightweight token are modified. An exchange is in privileges associated with a lightweight token issued to a client that is identified (block 602). Exchanges in privileges can be initiated in several ways. For example, a user or administrator can change the membership of a corresponding account from multiple groups that have different privileges. Additionally, a user may subscribe to different service levels and/or existing service authorizations may expire. These and other actions may cause a corresponding change in privileges for a client/user. An authentication service 114 and/or service providers may be configured to detect and/or obtain notifications of changes in privileges.

[0044] In response to identifying exchanges, privileges are modified through interaction with a centralized authentication database to exchange the corresponding privilege data held therein without invalidating the lightweight token (block 604). Then, responsive to a subsequent request to access the resources using the lightweight token, access is electively provided in accordance with the modified privileges (block 606). For example, in accordance with the techniques discussed herein, privileges can be modified through privilege data 208 that is kept separate from lightweight tokens without changing the data or validity of lightweight tokens that are already issued to an account. Consequently, clients/users can continue to use the lightweight tokens and as long as they are valid and associated access rights will exchange substantially in "real time" to the extent that exchanges are made to corresponding privilege data 208 that are separate from tokens light. Furthermore, rights can be revoked quickly and easily by changing privilege data. For example, privileges associated with a token may be deleted from the centralized authentication database 210, thereby rendering the token useless even if the token is still valid (e.g., the validity time period has not expired). Thus, the understood tokens can be revoked simply by updating the privilege data in the centralized authentication database 210.

[0045] Having considered the exemplary details and techniques relating to forked authentication token input techniques, consider a discussion of an exemplary system in accordance with one or more implementations.

Exemplary System

[0046] Figure 7 illustrates an exemplary system 700 that includes an exemplary computing device 702 that is representative of one or more computing systems and/or devices that can implement the various techniques described herein. The computing device 702 may be, for example, a server of a service provider, a device associated with a customer (e.g., a customer device), a system on chip, and/or any other computing device or system. appropriate computing.

[0047] The exemplary computing device 702 as illustrated includes a processing system 704, one or more computer-readable media 706, and one or more I/O interfaces 708 that are communicatively coupled to each other. Although not shown, computing device 702 may further include a system bus or other data and command transfer system that couples the various components together. A system bus may include any one or a combination of different bus structures, such as a memory bus or memory controller, a peripheral bus, a universal serial bus, and/or a processor or local bus that uses any one of a variety of architectures. A variety of other examples are also covered, such as control and data lines.

[0048] Processing system 704 is representative of functionality for performing one or more operations using hardware. Accordingly, processing system 704 is illustrated as including hardware elements 710 that can be configured as processors, function blocks, and so on. This may include implementation in hardware such as an application-specific integrated circuit or other logic device formed using one or more semiconductors. The hardware elements 710 are not limited by the materials from which they are formed or the processing mechanisms employed therein. For example, processors may be comprised of semiconductor(s) and/or transistor(s) (e.g., electronic integrated circuits (ICs)). In such a context, processor-executable instructions may be electronically executable instructions.

[0049] Computer-readable media 706 is illustrated as including memory/storage 712. Memory/storage 712 represents the memory/storage capacity associated with one or more computer-readable media. Memory/storage 712 may include volatile memory media (such as random access memory (RAM)) and/or non-volatile media (such as read-only memory (ROM), Flash memory, optical disks, magnetic disks, and so on. onwards). Memory/storage 712 may include fixed media (e.g., RAM, ROM, a fixed hard disk, and so on) as well as removable media (e.g., Flash memory, a removable hard disk, an optical disk, and so on). ). The computer-readable media 706 may be configured in a variety of other ways as further described below.

[0050] The input/output interface(s) 708 are representative of functionality for letting a user input commands and information to the computing device 702, and also allowing information to be presented to the user and/or other components or devices using multiple input/output devices. Examples of input devices include a keyboard, a cursor control device (e.g., a mouse), a microphone for voice operations, a scanner, touch functionality (e.g., capacitive sensors or other sensors that are configured to detect physical touch), a camera (e.g., which may employ visible or non-visible wavelengths to input commands that may employ visible or non-visible wavelengths such as infrared frequencies to detect movement that does not involve touch or gestures), and so on. Examples of output devices include a display device (e.g., a monitor or projector), speakers, a printer, a network card, haptic feedback device, and so on. Thus, computing device 702 may be configured in a variety of modes as further described below to support user interaction.

[0051] Various techniques may be described herein in the general context of software, hardware elements, or program modules. Generally, such modules include routines, programs, objects, elements, components, data structures, and so on that perform tasks or implement particular abstract data types. The terms "module," "feature," and "component" as used herein generally represent software, firmware, hardware, or a combination thereof. Aspects of the techniques described in this document are platform independent meaning that the techniques can be implemented on a variety of commercial computing platforms having a variety of processors.

[0052] An implementation of the described modules and techniques may be stored in or transmitted through some form of computer-readable media. Computer-readable media may include a variety of media that can be accessed by computing device 702. By way of example, and not limitation, computer-readable media may include "computer-readable storage media" and "computer-readable storage media." communication".

[0053] "Computer-readable storage media" refers to means and/or devices that enable the storage of information in contrast to mere signal transmission, transport waves or signals per se. Thus, computer-readable storage media does not include signal-carrying media, transient signals, or signals per se. Computer-readable storage media includes hardware such as volatile and non-volatile, removable and non-removable media and/or storage devices implemented in a method or technology appropriate for storing information such as computer-readable instructions, data structures, modules program, logic elements/circuits or other data. Examples of computer-readable storage media may include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile discs (DVD) or other optical storage, hard drives, cassettes magnetic devices, magnetic tape, magnetic disk storage or other magnetic storage devices, or other magnetic device, tangible means, or article of manufacture suitable for storing the desired information and which can be accessed by a computer.

[0054] "Communication media" may refer to signal-bearing means that are configured to transmit instructions to the hardware of the computing device 702, such as over a network. The communication media typically may incorporate computer-readable instructions, data structures, program modules, or other data into a modulated data signal, such as transport waves, data signals, or other transport mechanism. Media also includes any means of releasing information. The term "modulated data signal" means a signal that has one or more of its characteristics fixed or changed in such a way as to encode information in the signal. By way of example, and not limitation, means of communication include wired means such as wired network or direct wired connection, and wireless means such as acoustic, RF, infrared and other wireless means.

[0055] As previously described, hardware elements 710 and computer-readable media 706 are representative of instructions, modules, programmable device logic and/or fixed device logic implemented in a form of hardware that may be employed in some embodiments to implement at least some aspects of the techniques described in this document. Hardware elements may include components of an integrated circuit of an integrated circuit or system on chip. An application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a complex programmable logic device (CPLD), and other implementations in silicon or other hardware devices. In this context, a hardware element may operate as a processing device that performs program tasks defined by instructions, modules, and/or logic embedded by the hardware element as well as a hardware device used to store instructions for execution, e.g. the computer-readable storage media described above.

[0056] Combinations of the above can also be employed to implement various techniques and modules described in this document. Accordingly, software, hardware, or program modules including operating 108, applications 110, authentication service 114, and other program modules may be implemented as one or more instructions and/or logic embedded in some form of human-readable storage media. computer and/or by one or more hardware elements 710. The computing device 702 may be configured to implement particular instructions and/or functions corresponding to the software and/or hardware modules. Accordingly, implementation of modules as a module that is executable by the computing device 702 as software can be achieved at least partially in hardware, for example, through the use of computer-readable storage media and/or hardware elements 710 of the system. of processing. The instructions and/or functions may be executable/operable by one or more articles of manufacture (e.g., one or more computing devices 702 and/or processing systems 704) to implement techniques, modules, and examples described herein.

[0057] As further illustrated in Figure 7, exemplary system 700 enables ubiquitous environments for a seamless user experience when running applications on a personal computer (PC), a television device, and/or a mobile device. The services and applications function substantially similar across all three environments for a common user experience when transitioning from one device to the next while using an application, playing a video game, watching a video, and so on.

[0058] In exemplary system 700, multiple devices are interconnected through a central computing device. The central computing device may be local to the multiple devices or may be located remotely from the multiple devices. In one embodiment, the central computing device may be a cloud of one or more server computers that are connected to the multiple devices via a network, the Internet, or other data communications link.

[0059] In one embodiment, this interconnect architecture enables functionality to be released across multiple devices to provide a common and seamless experience to a user of the multiple devices. Each of the multiple devices may have different physical requirements and capabilities, and the central computing device uses a platform to enable the release of an experience to the device that is both tailored to the device and yet common to all devices. In one embodiment, a class of target devices is created and experiences are tailored to the generic class of devices. A class of devices can be defined by physical aspects, types of use, or other common characteristics of the devices.

[0060] In various implementations, computing device 702 may have a variety of configurations, such as uses for computer 714, cell phone 716, and television 718. Each of these configurations includes devices that may have generally different constructions and capabilities, and thus The computing device 702 may be configured according to one or more of the different device classes. For example, computing device 702 may be implemented as computer class 714 of a device that includes a personal computer, desktop computer, a multi-screen computer, laptop computer, netbook, and so on.

[0061] The computing device 702 may also be implemented as the cell phone class 716 of device which includes mobile devices such as a mobile phone, portable music player, portable gaming device, a tablet computer, a multi-screen computer , and so on. Computing device 702 may also be implemented as television class 718 of device which includes devices having or generally connected to larger screens in casual viewing environments. These devices include televisions, set-top boxes, game consoles, and so on.

[0062] The techniques described herein can be supported by these various configurations of computing device 702 and is illustrated through the inclusion of authentication service 114 in computing device 702. The functionality represented by authentication service 114 and other modules/ Applications may also be implemented in whole or in part through the use of a distributed system, such as on a "cloud" 720 via a platform 722 as described below.

[0063] Cloud 720 includes and/or is representative of a platform 722 for resources 724. Platform 722 abstracts adjacent hardware functionality (e.g., servers) and software resources of cloud 720. Resources 724 may include applications and /or data that can be used while computer processing is performed on servers that are remote from the computing device 702. Resources 724 may also include services provided over the Internet and/or over the subscriber's network, such as a cellular or Wi-Fi network.

[0064] Platform 722 may abstract resources and functions to connect computing device 702 with other computing devices. Platform 722 may also serve to abstract resource scaling to provide a corresponding level of scaling to the demand encountered for resources 724 that are implemented through platform 722. Accordingly, in an interconnected device embodiment, the implementation of functionality described in This document can be distributed throughout the system 700. For example, the functionality can be implemented in part on the computing device 702 as well as through the platform 722 that abstracts the functionality from the cloud 720.

CONCLUSION

[0065] Although the subject matter has been described in specific language for structural aspects and/or methodological acts, it should be understood that the subject matter defined in the attached claims is not necessarily limited to the specific aspects or acts described above. Preferably, the specific aspects and acts described above are disclosed as exemplary ways of implementing the claims.

Claims (11)

1. Method implemented by a computing device (102) characterized by the fact that it comprises: authenticating a client (201) to access resources from a service provider (106); in connection with client authentication (201), determining whether the service provider (106) is configured to support privilege data-free forked authentication tokens; and based on the determination: issuing a combined authentication token (206) to the client (201) that includes privilege data associated with the client (201) when the service provider (106) is not configured to support forked authentication tokens which are free from privilege data, the combined authentication token (206) containing sufficient information to provide indications to service providers (106) about client access privileges without relying on external information; or issue a lightweight token (206) to the client (201) and communicate the privilege data (208) associated with the client (201) for storage in a centralized authentication database (201) separate from the service provider (106 ) when the service provider (106) is configured to support privilege data-exempt tokens; wherein the lightweight token (206) is configured to contain identity information and a reference usable by the service provider (106) to query privilege data (208) associated with the client (201) from the centralized authentication database ( 210); wherein, upon detecting a lightweight token (206) in a request to access resources, the reference is obtained from the lightweight token (206), and the privilege data associated with the reference is checked to allow the user access to the resources. 2. Method according to claim 1, characterized by the fact that authenticating the client (201) comprises obtaining credentials (112) from the client (201) for authentication and comparing the credentials (112) with corresponding credentials maintained in association with the client. 3. Method according to claim 1, characterized by the fact that the privilege data (208) provides indications of resources of one or more service providers (106) that the client (201) is authorized to use upon proper authentication -successful. 4. Method according to claim 1, characterized by the fact that it further comprises encrypting the privilege data (208) within the combined authentication token (206) when the service provider (106) is not configured to support tokens that do not include privilege data. 5. Method according to claim 1, characterized by the fact that the privilege data reference (208) comprises a connection to the centralized authentication database (210). 6. Method according to claim 1, characterized by the fact that the combined authentication token (206) issued when the service provider (106) is not configured to support tokens that do not include privilege data includes both identification information as privilege data (208) that allows a direct determination by the service provider (106) of resources that the customer (201) is authorized to use. 7. Method according to claim 1, characterized by the fact that the lightweight token issued (206) when the service provider (106) is configured to support tokens that do not include privilege data does not contain privilege data (208) sufficient to allow the service provider (106) to determine resources that the client (201) is authorized to use without searching from the centralized authentication database (210). 8. Method according to claim 1, characterized by the fact that information included in the lightweight token (206) is smaller than information included in the combined authentication token (206) so that the lightweight token (206) has a size which is smaller than a combined authentication token size (206). 9. Method according to claim 8, characterized by the fact that the size of the soft token (206) allows communication of the soft token (206) in an uncompressed format. 10. Method according to claim 1, characterized by the fact that the access privileges associated with the lightweight token (206) are controlled based on privilege data (208) stored in the centralized authentication database (210) so possession of the lightweight token alone is not enough to gain access to resources. 11. Method according to claim 1, characterized by the fact that it further comprises exchanging access privileges (208) associated with the lightweight token (206) by modifying privilege data (208) stored in the centralized authentication database ( 210) without revoking the lightweight token (206) itself.