Resource access authorization

Techniques for resource access authorization are described. In one or more implementations, an application identifier is used to control access to user resources by an application. A determination is made whether to allow the application to access the user resources by comparing an application identifier received from an authorization service with a system application identifier for the application obtained from a computing device on which the application is executing.

BACKGROUND

Today's computer user has access to a wide variety of applications, such as media services, web applications, social media applications, and so on. Many of these applications use some type of identification technique to ascertain a user's identity and gain access to user information, such as an online authentication and/or authorization service. A primary challenge in utilizing such techniques is enabling an application to be authorized to access user resources while ensuring that the user's identity is protected.

SUMMARY

Techniques for resource access authorization are described. In one or more implementations, an application identifier is used to control access to user resources by an application. A determination is made whether to allow the application to access the user resources by comparing an application identifier received from an authorization service with a system application identifier for the application obtained from a computing device on which the application is executing.

In one or more implementations, a reply is received from an authorization entity in response to a request seeking to determine whether or not an application is permitted access to user resources, the reply including an application identifier for the application. The application is allowed to access the user resources if the application identifier matches a system application identifier for the application obtained from a computing device on which the application is executing.

In one or more implementations, techniques detect that an application executing on a computing device is requesting access to user resources via a persisted authentication mode. A determination is made whether an application identifier received from an authorization service matches a system application identifier obtained from the computing device. If the application identifier matches the system application identifier, the application is allowed to access the user resources via authentication data received from the authorization service.

DETAILED DESCRIPTION

Overview

Techniques for resource access authorization are described. In one or more implementations, the techniques may be employed to authorize an application to access user resources while protecting user credentials, such as a user name and/or a password, from unauthorized entities. For instance, an access broker can be utilized that acts as an intermediary between an application that is requesting access to user resources and an authorization entity that can confirm a user's identity and enable access to the user resources. Examples of user resources include user content (e.g., images, audio, video, and so on), user data (e.g., files), user profiles for applications and/or services, and so on.

In implementations, the access broker enables an application to be authorized by an authorization entity to allow the application to access user resources. For example, an application can invoke the access broker, which communicates with the authorization entity to cause a user interface associated with the authorization entity to be presented. A user can provide authentication information to the user interface, such as a username and password. If the username and password match a user profile known by the authorization entity, the authorization entity returns authorization information to the access broker. In implementations, an authorization prompt can be presented to the user that enables the user to provide authorization for the application to access the user resources. The access broker can enable the application to access the user resources via the authorization information.

Further to embodiments, a persisted authentication mode can be utilized that enables an application to access user resources during multiple separate transactions without requiring a user to provide authentication information for each transaction. For example, when a user provides authentication information to an authorization service to enable an application to access user resources, the application and/or the user can request the persisted authentication mode. The authentication information, along with other information, can be cached (e.g., by the access broker) as part of a cached authentication state for the application.

When the application requests access to user resources during a subsequent transaction, the access broker forwards the request along with the cached authentication state to the authorization service. The authorization service ascertains based on the cached authentication state that the application was previously authorized by a user to access user resources, and returns an access token and an application identifier for the application to the access broker. In implementations, the authorization service can request user authorization (e.g., via an authorization prompt) prior to returning the indication of authorization to the access broker.

The access broker checks to see if the application identifier received from the authorization service matches a system-level identifier for the application provided by a computing device on which the application is running. If the identifiers match, the access broker provides the access token to the application. The application can use the access token to access user resources. If the identifiers do not match, the application may be denied access to the resources and/or a user may be prompted to provide authentication information to allow the application to access the user resources.

As used herein, the term “authorization” refers generally to techniques for enabling applications and other entities to access resources, and is not limited to particular protocols, procedures, conventions, or standards. Thus, the term is to be interpreted broadly to include any suitable technique within the spirit and scope of the embodiments discussed herein.

In the following discussion, example environments are first described that are operable to employ resource access authorization techniques described herein. Example procedures involving resource access authorization techniques are then described which may be employed in the example environments as well as in other environments. Accordingly, the example environments are not limited to performing the example procedures. Likewise, the example procedures are not limited to implementation in the example environment. Finally, an example system and device are described that are operable to employ techniques discussed herein in accordance with one or more embodiments.

Example Environments

FIG. 1is an illustration of an environment100in an example implementation that is operable to employ techniques for resource access authorization. Environment100includes a computing device102having one or more processors104, one or more computer-readable storage media106and one or more applications108that reside on the computer-readable storage media106and which are executable by the processor104. Computing device102can be embodied as any suitable computing device such as, by way of example and not limitation, a desktop computer, a portable computer, a handheld computer such as a personal digital assistant (PDA), mobile phone, tablet computer, and the like. One of a variety of different examples of a computing device102is shown and described below inFIGS. 7 and 8.

The computing device102ofFIG. 1is also illustrated as including a browser110, e.g., a web browser, which is representative of functionality that is configured to navigate via a network112. Although the network112is illustrated as the Internet, the network may assume a wide variety of configurations. For example, the network112may include a wide area network (WAN), a local area network (LAN), a wireless network, a public telephone network, an intranet, and so on. Further, although a single network112is shown, the network112may be configured to include multiple networks.

The browser110, for instance, may be configured to navigate via the network112to interact with content available from one or more web resources114as well as communicate data to the one or more web resources114, e.g., perform downloads and uploads. The web resources114may include any suitable computing resource that is configured to provide content that is accessible via the network112. Examples of such content include web pages, text content, video, audio, and so on.

One or more of the applications108may also be configured to access the network112, e.g., directly themselves and/or through the browser110. For example, one or more of the applications108may be configured to access one or more of the web resources114to retrieve and/or upload content. Thus, the applications108may also be configured for a variety of functionality that may involve direct or indirect network112access. For instance, the applications108may include configuration settings and other data that may be leveraged locally by the application108as well as synchronized with applications that are executed on another computing device. In this way, these settings may be shared by the devices. A variety of other instances are also contemplated. Thus, the computing device102may interact with content in a variety of ways from a variety of different sources.

Further illustrated as part of the computing device102is an operating system116that is representative of functionality to manage resources of the computing device102and provide access to functionalities of the computing device102. In implementations, the operating system116maintains identification information for the applications108that can be utilized to implement techniques discussed herein. For example, when one of the applications108is installed and/or initiated on the computing device102, the computing device can record a system application identifier for the application. The system application identifier can be stored in a portion of the computing device102that is not accessible to and/or manipulable by the applications108, such as a protected database, a kernel for the operating system116, and so on. Additionally or alternatively, the system application identifier can be digitally signed such that the application cannot modify the identifier.

The computing device102in the illustrated example is also shown as including an access broker module118that is representative of functionality of the computing device102to mediate authorization and authentication transactions for the applications108. The access broker module118is configured to communicate various forms of authorization and authentication information between entities involved in an authorization transaction. In implementations, the access broker module is configured to communicate information via browser functionality, and thus can be combined with and/or embodied as the browser110.

Further to such authorization transactions, the environment100includes an authorization service120that is representative of functionality to track user profiles and to interact with the access broker module118to determine if the applications108and/or other entities are authorized to access user resources. For example, the authorization service120can be implemented as a web-based authorization service that can be accessed by multiple users and multiple different devices to conduct authorization and/or authentication transactions. In implementations, the authorization service120can maintain application identifiers for various applications, such as the applications108. For example, the system application identifier discussed above for a particular one of the applications108can be communicated to the authorization service120, e.g., as part of a registration of the application with the authorization service. The authorization service120can store the application identifiers to be used as part of the resource access operations discussed herein.

Further to such embodiments, the environment100includes user resources122, which are representative of resources associated with a user of the computing device102. Examples of the user resources122include user content (e.g., images, audio, video, and so on), user data (e.g., files), user profiles for applications and/or services, and so on.

Although the authorization service120and the user resources122are illustrated as separate entities, in some implementations the user resources122can be managed and/or maintained by the authorization service120. For example, the authorization service120can be associated with a type of content service that manages the user resources122, such as a social networking service, a photo sharing service, a web log (blog) service, and so on. In such implementations, the authorization service120may be implemented to authenticate a user to a content service as well as to other services (e.g., the applications108) that may interact with the content service.

In implementations, when the access broker module118determines that one of the applications108is authorized to access the user resources122, the access broker module118provides an access token or other authorization mechanism to the application. The application can utilize the access token or other authorization mechanism to access the user resources122. Thus, access token or other authorization mechanism can be employed to enable the applications108and/or other entities to access the user resources122.

For example, the computing device102may also include an entity (e.g., software) that causes hardware of the computing device102to perform operations, e.g., processors, functional blocks, and so on. For example, the computing device102may include a computer-readable medium that may be configured to maintain instructions that cause the computing device, and more particularly hardware of the computing device102to perform operations. Thus, the instructions function to configure the hardware to perform the operations and in this way result in transformation of the hardware to perform functions. The instructions may be provided by the computer-readable medium to the computing device102through a variety of different configurations.

One such configuration of a computer-readable medium is signal bearing medium and thus is configured to transmit the instructions (e.g., as a carrier wave) to the hardware of the computing device, such as via a network. The computer-readable medium may also be configured as a computer-readable storage medium and thus is not a signal bearing medium. Examples of a computer-readable storage medium include a random-access memory (RAM), read-only memory (ROM), an optical disc, flash memory, hard disk memory, and other memory devices that may use magnetic, optical, and other techniques to store instructions and other data.

FIG. 2illustrates an example authorization environment in accordance with one or more implementations, generally at200. Included as part of the authorization environment200is a display screen202that can be included as part of the computing device102. In implementations, the display screen202may or may not be configured to receive physical input, e.g., touch input or stylus input. Presented on the display screen202is an application user interface204that is associated with an application, e.g., the application108.

To enable a user to provide authorization for an application to access user resources, an authorization user interface206is provided. In implementations, the authorization user interface206can be displayed automatically, e.g., in response to the application108being opened. For example, when a user initiates the application108, the access broker module118can communicate with the browser110and/or the authorization service120to cause the authorization user interface206to be displayed. For instance, the authorization service120can provide the authorization user interface206to the web browser110, e.g., as a web page. Alternatively or additionally, a user can cause the authorization user interface206to be launched by selecting a login button or other control (not illustrated) associated with the application user interface204.

In implementations, the authorization user interface206can be modal with respect to the application user interface204. For example, the application user interface204can be prevented from receiving input and/or being closed until the authorization user interface206is dismissed, e.g., in response to user input to the authorization interface.

Illustrated as part of the authorization user interface206is a username field208and a password field210. The username field208is configured to receive a username and/or other identifying indicia (e.g., a user email) from a user. Additionally, the password field210is configured to receive a password from a user. In implementations, a username and password are associated with a user profile for a user, e.g., a user profile that is previously established with the authorization service120. Thus, providing a username and a password to the authorization user interface206can authenticate a user as being authorized to access a particular user profile and/or user resources associated with the user profile.

Further illustrated as part of the authorization user interface206is a login control212that, if selected, submits login information provided to the authorization user interface206. For example, a username provided to the username field208and a password provided to the password field210can be submitted to the authorization service120in response to a selection of the login control212.

The authorization user interface206also includes a cancel control214that, if selected, can cause an authorization transaction to be cancelled and/or the authorization user interface206to be closed.

Further included as part of the authorization user interface206is a persisted login option216that is selectable to activate a persisted authentication mode. In implementations, the persisted authentication mode can be activated by a user (e.g., via selection of the persisted login option216) and/or by another entity, such as the application108and/or the access broker module118. Further details regarding the persisted authentication mode are discussed in more detail above and below.

Having described example environments in which the techniques described herein may operate, consider now a discussion of some example procedures in accordance with one or more embodiments.

Example Procedures

The following discussion describes resource access authorization techniques that may be implemented utilizing the systems and devices described herein. Aspects of each of the procedures may be implemented in hardware, firmware, or software, or a combination thereof. The procedures are shown as a set of blocks that specify operations performed by one or more devices and are not necessarily limited to the orders shown for performing the operations by the respective blocks. Further, an operation shown with respect to a particular procedure may be combined and/or interchanged with an operation of a different procedure in accordance with one or more implementations. In portions of the following discussion, reference will be made to the environments100and/or200ofFIGS. 1 and 2.

FIG. 3depicts a procedure300in an example implementation in which a user can authorize an application to access user resources. Step302detects a request to allow an application to access user resources. For example, the access broker module118can receive a request from the application108for access to the user resources122. Alternatively or additionally, the request can be received from an entity other than the application prior to the application initiating a request to access the user resources. For example, an entity can obtain permission in advance for the application to access the user resources. In implementations, portions of the computing device102and/or the browser110can store user identification information, such as logon information, authentication and/or authorization cookies, usernames, passwords, and so on. To prevent the application108from gaining unauthorized access to such identification information, the access broker module118can clear the identification information from portions of the computing device102that are accessible to the application108, e.g., in response to receiving the request from the application.

Step304forwards an authorization request including an application identifier to an authorization entity. For example, the access broker module118can communicate with the browser110to cause the authorization request to be forwarded from the browser to the authorization service120. In implementations, the authorization request can include a uniform resource locator (URL) for the authorization service120that includes the application identifier and a redirect address (e.g., a uniform resource identifier (URI)) that can be used to return information to the application. One example of such a URL can be “https://www.authozationservice.com/requestAccess.html?applicationID=X&redirectAddress=http://redirect.com”.

In implementations, the authorization service120receives the authorization request and causes the authorization user interface206to be presented via the browser110. A user can then provide authentication information to the authorization user interface206, e.g., a username and password. Additionally or alternatively, the user can provide consent for the application to access the user resources, e.g., via the authorization user interface206.

Step306receives a response from the authorization entity indicating user authorization, the response including the application identifier. For example, authentication information provided to the authorization user interface206is submitted to the authorization service120, which determines that the authentication information matches a user profile known to the authorization service. The authorization service120sends a reply to the authorization request to the access broker module118. In implementations, the reply includes the application identifier and can include additional information, such as an access token that can be utilized to access user resources.

Step308caches an authentication state for the application in an event that a persisted authentication mode is selected. For example, a user can select the persisted authentication mode, e.g., via the authorization user interface206as part of providing user credentials. If the persisted authentication state is selected, the authentication state is cached, e.g., by the access broker module118. A cached authentication state can include authentication and other information that enables an application to access user resources during a subsequent request for access to user resources without requiring a user to perform further authentication. Further aspects of the persisted authentication mode are discussed below. If the persisted authentication mode is not selected, an authentication state is not cached for subsequent use and/or a user may be requested for authentication as part of a subsequent resource access request.

Step310compares the application identifier received from the authorization entity to a system application identifier maintained by the computing device. For example, the system application identifier can be a unique identifier that differentiates the application from other applications and/or resources of the computing device. Further discussion of the system application identifier is presented above.

If the application identifier received from the authorization entity matches the system application identifier (“Match”), step312provides a token to the application that enables access to the user resources. In implementations, the access broker module118can receive the token from the authorization service120and forward the token to the application108. The application108can use the token to access user resources. If the application identifier received from the authorization entity does not match the system application identifier (“Does Not Match”), step314prevents the application from accessing the token. Thus, the application may not access the user resources since access to the user resources can be limited to applications that present the token.

FIG. 4depicts a procedure400in an example implementation in which a persisted authentication mode is utilized for user resource access. According to one or more embodiments, the procedure400can be performed as part of a resource access request subsequent to that discussed above inFIG. 3.

Step402detects that an application executing on a computing device is requesting access to user resources via a persisted authentication mode. Example ways of initiating a persisted authentication mode are discussed above. Step404forwards an authorization request including an application identifier to an authorization entity. For example, the access broker module118can receive the authorization request from the application and forward the cached authentication state information discussed above to the authorization service120.

In implementations, the authorization request can include a custom uniform resource identifier (URI) scheme that indicates that the persisted authentication mode is being used. For example, a URL that is used to navigate to the authorization service120(an example of which is discussed above) can be appended with the custom URI scheme. The custom URI scheme can include the application identifier and indicia that is specific to the persisted authentication mode, e.g., “persisted://application_id”. In implementations, the access broker module118can stipulate that the custom URI scheme be utilized by an application for the persisted authentication scheme to be implemented for the application.

Step406receives an authorization confirmation from the authorization entity, the authorization confirmation including the application identifier and an access token. In implementations, the authorization confirmation can be receive based at least in part on a user providing authorization for the application to access the user resources, e.g., via an authorization prompt provided by the authorization entity. The authorization entity can discern (e.g., based on the application identifier from the authorization request) that the authorization request is from an application that is authorized to access user resources. For example, the application may have been previously authorized to access user resources via user interaction with the authorization entity. Further to such implementations, the authorization entity can return the custom URI provided as part of the authorization request to the access broker module118along with an access token appended to the custom URI.

Step408compares the application identifier to a system application identifier for the application maintained by the computing device. Details regarding matching application identifiers are presented above. If the application identifier received from the authorization entity matches the system application identifier (“Match”), step410provides a token that enables the application to access the user resources. For example, the access broker module118can receive an authentication token from the authorization service120, and can provide the authentication token to the application108. The application108can use the authentication token to access the user resources122.

If the application identifier received from the authorization entity does not match the system application identifier (“Does Not Match”), step412denies the application access to the token.

Thus, in implementations the persisted authentication mode enables a determination whether an application is authorized to access user resources to be made independent of a user authentication transaction and/or user interaction, e.g., with an authorization service.

FIG. 5depicts a procedure500in an example implementation in which a determination is made whether an application may participate in an authorization transaction. Step502receives an application identifier from an application as part of a request to access user resources. Step504compares the application identifier with a system application identifier for the application maintained by the computing device. Details regarding matching application identifiers are presented above. In implementations, the access broker module118can receive the application identifier from the application and query the operating system116for a system application identifier for the application. The access broker module118can then compare the application identifier with the system application identifier to determine whether they match.

If the application identifier received from the application does not match the system application identifier (“Does Not Match”), step506prevents the application from proceeding with an authorization transaction. If the application identifier received from the application does match the system application identifier (“Match”), step508proceeds with an authorization transaction. Example authorization transactions are discussed elsewhere herein with reference toFIGS. 3,4, and6.

FIG. 6depicts a procedure600in an example implementation in which local authorization information is used to determine if an application is authorized to access user resources. Step602receives application authorization information from an authorization entity, including an application identifier and an authorization entity identifier. For example, the authorization information can be received from the authorization service120in response to a user authenticating with the authorization service and providing permission for the application to access the user resources122. Examples ways of providing user authentication and user permission are discussed above. In implementations, the authorization entity identifier enables other entities (e.g., the access broker module118) to identify from which authorization entity the authorization information was received.

Step604stores the authorization information locally. In implementations, the authorization information can be stored by the access broker module118and/or in a location accessible to the access broker module. Step606receives a request from an application for authorization to access user resources, the request including the authorization entity identifier. For example, the access broker module118can receive the request from the application108.

Step608retrieves the authorization information locally based on the authorization entity identifier received from the application and compares the application identifier from the authorization information with a system application identifier for the application. Example ways of comparing an application identifier and a system application identifier are discussed above. Step610determines whether the application identifier matches the system application identifier.

If the application identifier matches the system application identifier (“Match”), step612provides a token to the application that enables access to the user resources. If the application identifier does not match the system application identifier (“Does Not Match”), step614prevents the application from accessing the token.

In implementations, the procedure600illustrates an example technique whereby authorization for an application to access user resources can be determined without requiring communication with an authorization service at application runtime. For example, a user can interact with an authorization service to authorize an application to access user resources. Information from the user authorization transaction can then be stored for subsequent retrieval, e.g., as discussed in steps602and604, above. Further to a subsequent request from the application for access to the user resources, the access broker module118can use the locally-stored authorization information to determine, without communicating with the authorization service, whether to allow the application to access the user resources.

In at least some embodiments, an application can maintain a persisted authorization mode, which differs in one or more respects from the persisted authentication mode discussed above. For example, an application can maintain a token that enables the application to access user resources, such as a token received via the techniques discussed above. The token can enable access to user resources during multiple different resource access transactions, e.g., in response to multiple different requests from the application for access to user resources. When the application is seeking to access user resources using the token, the application can ascertain whether the token has expired such that it is no longer effective to enable access to the user resources. If the token has expired, the application can use the techniques discussed above to obtain a new, valid token, such as from the access broker module118and/or the authorization service120. Thus, in implementations the persisted authorization mode can enable an application to access user resources during multiple resource access transactions without requiring the application to request the access, e.g., via the access broker module118and/or the authorization service120.

Example System and Device

FIG. 7illustrates an example system700that includes the computing device102as described with reference toFIGS. 1 and 2. The example system700enables ubiquitous environments for a seamless user experience when running applications on a personal computer (PC), a television device, and/or a mobile device. Services and applications run substantially similar in all three environments for a common user experience when transitioning from one device to the next while utilizing an application, playing a video game, watching a video, and so on.

In the example system700, 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 or more embodiments, the central computing device may be a cloud of one or more server computers that are connected to the multiple devices through a network, the Internet, or other data communication link. In one or more embodiments, this interconnection architecture enables functionality to be delivered 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 attributes and capabilities, and the central computing device uses a platform to enable the delivery 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 may be defined by physical features, types of usage, or other common characteristics of the devices.

In various implementations, the computing device102may assume a variety of different configurations, such as for computer702, mobile704, and television706uses. Each of these configurations includes devices that may have generally different constructs and capabilities, and thus the computing device102may be configured according to one or more of the different device classes. For instance, the computing device102may be implemented as the computer702class of a device that includes a personal computer, desktop computer, a multi-screen computer, laptop computer, netbook, and so on.

The computing device102may also be implemented as the mobile704class of device that includes mobile devices, such as a mobile phone, portable music player, portable gaming device, a tablet computer, a multi-screen computer, and so on. The computing device102may also be implemented as the television706class of device that includes devices having or connected to generally larger screens in casual viewing environments. These devices include televisions, set-top boxes, gaming consoles, and so on. The techniques described herein may be supported by these various configurations of the computing device102and are not limited to the specific examples the techniques described herein.

The cloud708includes and/or is representative of a platform710for content services712. The platform710abstracts underlying functionality of hardware (e.g., servers) and software resources of the cloud708. The content services712may include applications and/or data that can be utilized while computer processing is executed on servers that are remote from the computing device102. Content services712can be provided as a service over the Internet and/or through a subscriber network, such as a cellular or Wi-Fi network.

The platform710may abstract resources and functions to connect the computing device102with other computing devices. The platform710may also serve to abstract scaling of resources to provide a corresponding level of scale to encountered demand for the content services712that are implemented via the platform710. Accordingly, in an interconnected device embodiment, implementation of functionality described herein may be distributed throughout the system700. For example, the functionality may be implemented in part on the computing device102as well as via the platform710that abstracts the functionality of the cloud708, as shown through inclusion of the applications108, the browser110, and the access broker module118.

FIG. 8illustrates various components of an example device800that can be implemented as any type of computing device as described with reference toFIGS. 1 and 7to implement embodiments of the techniques described herein. Device800includes communication devices802that enable wired and/or wireless communication of device data804(e.g., received data, data that is being received, data scheduled for broadcast, data packets of the data, etc.). The device data804or other device content can include configuration settings of the device, media content stored on the device, and/or information associated with a user of the device. Media content stored on device800can include any type of audio, video, and/or image data. Device800includes one or more data inputs806via which any type of data, media content, and/or inputs can be received, such as user-selectable inputs, messages, music, television media content, recorded video content, and any other type of audio, video, and/or image data received from any content and/or data source.

Device800also includes communication interfaces808that can be implemented as any one or more of a serial and/or parallel interface, a wireless interface, any type of network interface, a modem, and as any other type of communication interface. The communication interfaces808provide a connection and/or communication links between device800and a communication network by which other electronic, computing, and communication devices communicate data with device800.

Device800includes one or more processors810(e.g., any of microprocessors, controllers, and the like) which process various computer-executable instructions to control the operation of device800and to implement embodiments of the techniques described herein. Alternatively or in addition, device800can be implemented with any one or combination of hardware, firmware, or fixed logic circuitry that is implemented in connection with processing and control circuits which are generally identified at812. Although not shown, device800can include a system bus or data transfer system that couples the various components within the device. A system bus can include any one or 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 utilizes any of a variety of bus architectures.

Device800also includes computer-readable media814, such as one or more memory components, examples of which include random access memory (RAM), non-volatile memory (e.g., any one or more of a read-only memory (ROM), flash memory, EPROM, EEPROM, etc.), and a disk storage device. A disk storage device may be implemented as any type of magnetic or optical storage device, such as a hard disk drive, a recordable and/or rewriteable compact disc (CD), any type of a digital versatile disc (DVD), and the like. Device800can also include a mass storage media device816.

Computer-readable media814provides data storage mechanisms to store the device data804, as well as various device applications818and any other types of information and/or data related to operational aspects of device800. For example, an operating system820can be maintained as a computer application with the computer-readable media814and executed on processors810. The device applications818can include a device manager (e.g., a control application, software application, signal processing and control module, code that is native to a particular device, a hardware abstraction layer for a particular device, etc.). The device applications818also include any system components or modules to implement embodiments of the techniques described herein.

In this example, the device applications818include an interface application822and an input/output module824that are shown as software modules and/or computer applications. The input/output module824is representative of software that is used to provide an interface with a device configured to capture inputs, such as a touchscreen, track pad, camera, microphone, and so on. Alternatively or in addition, the interface application822and the input/output module824can be implemented as hardware, software, firmware, or any combination thereof. Additionally, the input/output module824may be configured to support multiple input devices, such as separate devices to capture visual and audio inputs, respectively.

Device800also includes an audio and/or video input-output system826that provides audio data to an audio system828and/or provides video data to a display system830. The audio system828and/or the display system830can include any devices that process, display, and/or otherwise render audio, video, and image data. Video signals and audio signals can be communicated from device800to an audio device and/or to a display device via an RF (radio frequency) link, S-video link, composite video link, component video link, DVI (digital video interface), analog audio connection, or other similar communication link. In an embodiment, the audio system828and/or the display system830are implemented as external components to device800. Alternatively, the audio system828and/or the display system830are implemented as integrated components of example device800.

CONCLUSION

Techniques for resource access authorization are described. Although embodiments are described in language specific to structural features and/or methodological acts, it is to be understood that the embodiments defined in the appended claims are not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as example forms of implementing the claimed embodiments.