Consumption control of protected cloud resources by open authentication-based applications in end user devices

A server computer system identifies a request from an application hosted on a mobile device to consume a protected resource hosted by a cloud. The request is transmitted via a resource authorization protocol. The server computer system identifies a token state of an application on the mobile device. The token state is stored in a policy data store that is separate from expiration data that is stored on an access token on the mobile device. The server computer system determines whether the token state violates a security policy that is associated with a user that is assigned to the mobile device and prevents consumption of the protected resource in response to a determination that the token state violates the security policy. The server computer system allows consumption of the protected resource in response to a determination that the token state does not violate the security policy.

TECHNICAL FIELD

The present disclosure relates to OAuth (Open Authentication)-based applications, and more particularly, to controlling consumption of protected cloud resources by OAuth-based applications in end user devices.

BACKGROUND

Enterprise clouds can provide solutions to enterprises using cloud computing and software as a service (SaaS) to distribute software on a subscription basis. For example, cloud computing company Salesforce.com® can host Customer Relationship Management (CRM)/Salesforce Automation applications and services offsite via a cloud. Enterprises can use a variety of SaaS clouds to conduct their business. For example, enterprise users can access the Salesforce® cloud for CRM/Salesforce Automation services and applications. Users may use mobile devices, such as mobile phones, laptops, tablet computers, etc. to consume protected resources that are hosted on a cloud.

Users can grant mobile applications access to resources hosted in their cloud accounts using a resource authorization protocol, such as an OAuth (Open Authentication) protocol. For example, a user can authorize a contact book application running on a mobile phone to access his/her protected resources (e.g., contact list) hosted by the Salesforce.com® cloud by granting the contact book application an OAuth token. The contact book mobile application can use the OAuth token to automatically access the user's private resources stored in the Salesforce.com® cloud without the user having to expose their Salesforce.com® cloud credentials (e.g., Salesforce.com® cloud username and password), to the contact book mobile application.

A common problem is that when the mobile device is lost, the mobile device continues to use the OAuth token to automatically consume (e.g., synchronize) the protected resource (e.g., contact list) in the cloud, even after a user has changed his/her cloud service username/password. Another problem can occur when a user travels from a location, such as a European (EU) country to a non-EU country, where privacy regulations may not permit personal information to be shared across borders without express permission from the data owner. The user device may automatically download personal information (e.g., email address, phone number, address) in a contact list that is hosted on the cloud to the mobile device, which may inadvertently violate a privacy regulation.

SUMMARY

In one implementation, a system for controlling consumption of protected cloud resources by Open Authentication (OAuth)-based applications in user devices is described. An example system may include a memory and a processing device that identifies a request from an application (e.g., mobile application, web browser) hosted on a mobile device to consume a protected resource hosted by a cloud. The request is transmitted via a resource authorization protocol. The system identifies a token state of an application on the mobile device. The token state is stored in a policy data store that is separate from expiration data that is stored on an access token on the mobile device. The system determines whether the token state violates a security policy that is associated with a user that is assigned to the mobile device and prevents consumption of the protected resource in response to a determination that the token state violates the security policy. The system allows consumption of the protected resource in response to a determination that the token state does not violate the security policy.

In one implementation, preventing consumption includes the system determining that the token state in the policy data store is in an expired state. The token state in the policy data store may not match the expiration data that is stored on the access token on the mobile device which indicates that the access token is not expired. In one implementation, preventing consumption includes the system sending a message to the mobile device to obtain a new access token. In one implementation, the system receives user input indicating a password to access the protected resource has changed and assigns an expired state as the token state in the policy data store to one or more mobile devices that are associated with the user in response to the changed password.

In one implementation, the system determines whether a current geographic location of the mobile device violates the security policy of the user that is assigned to the mobile device and prevents consumption of the protected resource in response to a determination that the current geographic location violates the security policy and allowing consumption of the protected resource in response to a determination that the current geographic location does not violate the security policy. In one implementation, the resource authorization protocol is Open Authentication (OAuth) protocol. In one implementation, the system is hosted by a reverse proxy, an enterprise network proxy, or a cloud-based host machine.

Further, a method for controlling consumption of protected cloud resources by Open Authentication (OAuth)-based applications in user devices is described. In one implementation, a method comprises identifying a request from an application (e.g., mobile application, web browser) hosted on a mobile device to consume a protected resource hosted by a cloud. The request is transmitted via a resource authorization protocol. The method includes identifying a token state of the mobile device. The token state is stored in a policy data store that is separate from expiration data that is stored on an access token on the mobile device. The method includes determining whether the token state violates a security policy that is associated with a user that is assigned to the mobile device and preventing consumption of the protected resource in response to a determination that the token state violates the security policy. The method includes allowing consumption of the protected resource in response to a determination that the token state does not violate the security policy.

In addition, a non-transitory computer readable storage medium for controlling consumption of protected cloud resources by Open Authentication (OAuth)-based applications in user devices is described. An exemplary non-transitory computer readable storage medium includes instructions that will cause a processing device to perform a method that includes identifying a request from an application hosted on a mobile device to consume a protected resource hosted by a cloud. The request is transmitted via a resource authorization protocol. The method includes identifying a token state of the mobile device. The token state is stored in a policy data store that is separate from expiration data that is stored on an access token on the mobile device. The method includes determining whether the token state violates a security policy that is associated with a user that is assigned to the mobile device and preventing consumption of the protected resource in response to a determination that the token state violates the security policy. The method includes allowing consumption of the protected resource in response to a determination that the token state does not violate the security policy.

DETAILED DESCRIPTION

Described herein are a method and apparatus for controlling consumption of protected cloud resources in Open Authentication (OAuth)-based applications in end user devices. A user may initially grant an application (e.g., mobile application, web browser) on a mobile device (e.g., smart phone, tablet computer) automatic access to consume a protected resource in a cloud via an OAuth access token that is assigned to the application on the device. A protected resource is an access restricted resource that requires authentication and authorization before the protected resource can be accessed. For example, a protected resource may be a customer contact list that requires a username and password for access to the customer contact list. The user may wish to limit the access of the application on the mobile device to the protected resource. For example, the user may have lost a smart phone and may no longer want any application on the lost smart phone to automatically consume (download) protected resources from the cloud. The application may also on the user's other mobile devices, which are not lost, and may continue to use an OAuth token to automatically consume protected resources. In another example, the user may travel to Country-XYZ that prohibits personal identification information (e.g., email address, phone number, mailing address, etc.) from being shared across borders without express permission from the data owner. The user, while in Country-XYZ, may wish to disable the automatic consumption (download) by one or more mobile devices of personal identification information from a cloud.

Implementations of the present disclosure control consumption of protected cloud resources in OAuth-based applications in end user devices. A server computer system identifies a request from an application (e.g., mobile application, web browser) hosted on a mobile device to consume a protected resource hosted by a cloud. Examples of mobile applications can include, and are not limited to, a calendar application, a contacts application, a mail application, a word processing application, a customer resource management application, a social networking application, etc. The request can be transmitted via a resource authorization protocol. A resource authorization protocol is a protocol that authorizes authenticated entities to share protected resources with one another without having to disclose authentication credentials. An example of a resource authorization protocol is OAuth (Open Authorization) protocol. For brevity and simplicity, the OAuth protocol is used as an example of a resource authorization protocol throughout this document.

The server computer system identifies a token state of an application that is hosted on the mobile device. The token state of the application is stored in a policy data store that is separate from expiration data that is stored on an access token on the mobile device. The server computer system determines whether the token state of the application violates a security policy that is associated with a user that is assigned to the mobile device and prevents consumption of the protected resource in response to a determination that the token state violates the security policy. The server computer system allows consumption of the protected resource in response to a determination that the token state does not violate the security policy. A variety of such OAuth tokens, corresponding to different cloud services, can be stored on a mobile device. A consumption control module hosted by the server can be used to selectively allow application access to cloud services through some OAuth tokens, and to disable application access to cloud services through other OAuth tokens.

The server computer system can also determine the current geographic location of the mobile device and determine whether the current geographic location violates a security policy. The server computer system can prevent consumption of the protected resource in response to a determination that the current location violates the security policy and can allow consumption of the protected resource in response to a determination that the current location does not violate the security policy. A variety of such OAuth tokens, corresponding to different cloud services, can be stored on a mobile device. The consumption control module implemented in the server can be used to selectively allow application access to cloud services through some OAuth tokens, and disable application access to cloud services through other OAuth tokens based on the geographic location of the mobile device.

FIG. 1is an example system architecture100in which implementations of the present disclosure can be implemented. The system architecture100can include an enterprise environment160including one or more user devices110A communicating with one or more clouds130via a network120. The network120may be a public network, a private network, or a combination thereof. Network120can include a wireless/cellular network. The wireless/cellular infrastructure may be provided by one or multiple wireless/cellular communications systems, such as a wireless fidelity (WiFi) hotspot connected with the network120and/or a wireless/cellular carrier system that can be implemented using various data processing equipment, communication towers, etc.

A cloud130can provide solutions to enterprises using cloud computing such as a Software-as-a-Service (SaaS) model in which cloud computing companies can distribute software on a subscription basis. A cloud130can include one or more authorization server machines170to authenticate users101,103and access tokens105A-B (e.g., OAuth tokens) requesting access to protected resources in the cloud130. The authorization server machines170can be hosted by any type of computing device including server computers, gateway computers, or similar computing device.

For example, cloud computing company Salesforce.com® can host CRM/Salesforce Automation applications and services offsite via cloud130. Enterprises can use a variety of SaaS clouds130to conduct their business. For example, enterprise end-users101,103can access the Salesforce® cloud130for CRM/Salesforce Automation services and applications. End-users101,103are users of clouds130. A user that has special access rights, such as an enterprise security administrator106, can not only use clouds130, but can set enterprise policies.

The enterprise environment160can include a firewall163to create a secure boundary for the enterprise. In one implementation, an end-user101can access the clouds130from within the firewall163, also known as within the enterprise premise and ‘on-premise.’ A user device110A can host an application107A (e.g., mobile application, web browser), to access the clouds130from within the firewall163.

The user devices110A-B can be a portable computing device such as, and not limited to, mobile telephones, personal digital assistants (PDAs), portable media players, netbooks, laptop computers, tablet computers, an electronic book reader, a gaming device, and the like. The user device110A-B can also be other types of computing devices such as a desktop computer, a set-top box, a gaming console, a television, etc. that may not traditionally be considered to be portable.

The user device110A-B can include one or more applications107A-B. The applications107A-B can be OAuth-based applications that use an access token105A-B (e.g., OAuth token) to automatically consume protected resources in the cloud130. The applications107A-B (e.g., mobile application, web browser) can access protected resources directly from the cloud130based on user privileges, which end-users101,103can grant to the applications107A-B using a resource authorization protocol, such as an OAuth protocol. For example, an application107A-B can be assigned an access token105A-B (e.g., OAuth token). A protected resource is owned by a resource owner, such as an enterprise end-user101,103. For example, an end-user101,103can assign an access token105A-B to an application107A-B to grant the application107A-B access to his/her protected resource that is hosted by the Salesforce® cloud150. OAuth is a multi-step authorization protocol that allows end-users101,103to share their protected resources that are stored on a cloud130with an application107A-B without having an end-user101,103expose his/her user credentials.

The enterprise environment160can include one or more network proxy server machines190that can detect and intercept the resource authorization messages (e.g., OAuth messages) being directed to an application107A-B (e.g., mobile application, web browser) on a user device110A. The resource authorization traffic (e.g., OAuth traffic) intercepted by the network proxy server machines190can include resource authorization messages, such as OAuth messages, which relate to a request to consume a protected resource on the cloud130.

The network proxy server machines190can include a consumption control module161to determine whether to allow an application107A running on a user device110A to consume a protected resource in the cloud130. The consumption control module161can use the intercepted resource authorization messages to identify a request from an application107(e.g., mobile application, web browser) to consume the protected resource. The consumption control module161can determine whether one or more parameters of the user device110A violate a policy that is associated with the user that is assigned to the user device110A. The policy can be stored in a policy data store163A-C that is coupled to the consumption control module161.

For example, the parameter may be a token state for a token that is granted to an application107A running on the user device110A. The token state for the application107A can be stored in the policy data store163A that is separate from expiration data that is stored on an access token105A on the user device110A. One implementation of using a token state to control consumption of cloud resources by OAuth-based applications is described in greater detail below in conjunction withFIG. 4. In another example, the parameter may be current geographic location of the user device (e.g., user device110A). One implementation of using a location of a user device to control consumption of cloud resources by OAuth-based applications is described in greater detail below in conjunction withFIG. 5. If a parameter violates a policy, the consumption control module161can prevent the application107A running on the user device110A from consuming the protected resource. If the parameter(s) do not violate the policy, the consumption control module161can allow the application107A on the user device110A to consume the protected resource.

The one or more network proxy server machines190can communicate to the user device110A via a network (not shown). The network proxy server machines190may be web proxies. The network proxy server machines190can be deployed and managed by an enterprise. The network proxy server machines190can be implemented behind a firewall163between an application107A (e.g., mobile application, web browser) and the clouds130. The network proxy server machines190can be hosted on computing devices including server computers, gateway computers, or similar computing devices.

In one implementation, an enterprise end-user, such as end-user103, can use a user device110B which communicates with one or more clouds130from outside the enterprise firewall163, also known as outside the enterprise premise and ‘off-premise’. A user device110B can communicate to the clouds130from outside the enterprise firewall163via one or more reverse proxy server machines180or forward proxy server machines. A user device110B can host an application (e.g., mobile application, web browser) to access the clouds130via a reverse proxy server machine180or a forward proxy server machine. A user device110B can be provisioned with URLs (uniform resource locators) of the service names of the clouds130. The service names can force the user device110B to connect to a reverse proxy server machine180or forward proxy server machine to communicate to the clouds130.

The one or more reverse proxy server machines180or forward proxy server machines can detect and intercept off-premise resource authorization traffic (e.g., OAuth traffic), for example, between a user device110B and the clouds130. The reverse proxy server machines180or forward proxy server machines can intercept resource authorization messages occurring outside the firewall163. The reverse proxy server machines180or forward proxy server machines can include a consumption control module161to determine whether to allow an application107B executing on a user device110B to consume a protected resource in the cloud130. For example, the consumption control module161can use the token state for the application107B in the policy data store163B or the geographic location of the user device110B to determine whether to allow the application107B on the user device110B to consume the protected resource in the cloud130. The consumption control module161can use policy data that is stored in a policy data store163B that is coupled to the consumption control module161. The reverse proxy server machines180or forward proxy server machines can be deployed and managed by an enterprise. The reverse proxy server machines180or forward proxy server machines can be hosted by any type of computing device including server computers, gateway computers, or similar computing devices.

In one implementation, the consumption control module161resides in an authentication server machine170in the cloud130. The consumption control module161can receive resource authorization traffic (e.g., OAuth traffic), for example, from user devices110A-B and/or proxy server machines180,190. The consumption control module161can use policy data in a policy data store163C that is coupled to the consumption control module161to determine whether to allow an application107A-B executing on a user device110A-B to consume a protected resource in the cloud130. The consumption control modules161can synchronize the policy data in the various policy data stores163A-C.

In one implementation, the network proxy server machine190includes an identity authentication system, such as, a Single Sign-On (SSO) system. The SSO system can allow a user101to login to a corresponding local enterprise network in the enterprise environment160using a single set of credentials and have access, according to access policies, to the cloud services provided by the clouds130without having to individually login to each cloud service.

FIG. 2is a block diagram of one implementation of consumption control module200. The consumption control module200may be the same as the consumption control module161in a server machine170,180,190ofFIG. 1. The consumption control module200can include a policy sub-module210, a request sub-module213, a token state sub-module215, and an action sub-module219. The sub-modules can be combined together or separated in further sub-modules, according to a particular implementation.

The policy sub-module210can identify a user request to change a user credential (e.g., password) for a protected resource. In one implementation, the policy sub-module210is hosted on an authorization server in a cloud and the policy sub-module210receives a user request to change the user credential. In another implementation, the policy sub-module210is hosted on a reverse proxy server and/or a network proxy server and the policy sub-module210receives data from the authorization server in the cloud indicating that a user has requested to change the user credential (e.g., password) and/or the policy sub-module210intercepts a user request to change the user credential sent by a mobile device to the authorization server in the cloud.

The policy sub-module210can determine from one or more policies251that are stored in a data store250that is coupled to the consumption control module200that the token states for one or more access tokens that are assigned to applications on a mobile device should be changed to an “expired” state in response to the changed user credential (e.g., password).

Enterprises can define and store one or more policies251to specify, for example, what action should be taken when a user changes a user credential for a protected resource, what action should be taken when a mobile device is in a particular geographic location (e.g., country, state, city, etc.) and requests to consume a protected resource, and what action should be taken when a token state for a token that is assigned to an application (e.g., mobile application, web application) is in an “expired” state, etc. There can be one or more policies251for each cloud user. The security policies251can include a mobile device identifier of mobile devices that correspond to the cloud user.

The request sub-module213can identify a request (e.g., consumption request) made by an application (e.g., mobile application, web application) to consume a protected resource in a cloud. The request sub-module213can analyze resource authorization messages (e.g., OAuth messages) that are being intercepted by a proxy and identify a consumption request from the resource authorization messages. The request sub-module213can receive resource authorization messages (e.g., OAuth messages) at a cloud and identify a consumption request from the resource authorization messages.

The token state sub-module215can examine token state data253that is stored in the data store250to determine a current state of an access token that is assigned to an application on a mobile device. The token state data253is data that is separate from expiration data that is stored on an access token (e.g., OAuth token) on the mobile device. The token state data253can include a mobile device identifier and a token state (e.g., “expired,” “valid”) that corresponds to the mobile device identifier. The token state sub-module215can locate a mobile device identifier in the consumption request and locate a matching mobile device identifier in the token state data253.

The policy sub-module210can determine whether the token state violates a policy251that corresponds to the mobile device identifier and the action sub-module219can take appropriate action based on the determination. For example, the current token state that is stored in the data store250may be “expired.” A policy251may indicate that only unexpired token states may be permitted to consume a protected resource.

The policy sub-module210can use the current geographic location of a mobile device requesting to consume a protected resource to determine whether the current location violates a policy251that corresponds to the mobile device identifier in the consumption request. For example, the policy251may include a list of locations (e.g., list of countries, list of cities, etc.) where the mobile device, if located in one of the listed locations, is prohibited from consuming the protected resource. For example, Country-XYZ may not permit personal identity information (e.g., phone number, email address, physical address, etc.) to be shared across borders without express permission from the data owner.

The action sub-module215can perform one or more actions based on a policy251. A policy251can include a set of rules that specify, for example, which actions should be taken when the rules are satisfied and when the rules are not satisfied. For example, the policy251may indicate that when a user request to change a user credential (e.g., password) is received, the token state for any mobile devices that are associated with a user should be changed to an “expired” state in the token state data253. In another example, the policy251may indicate that access to the protected resources should be blocked, reported, etc. when the rules are not satisfied and that access to the protected resources should be allowed when the rules are satisfied.

Examples of an action can include, and are not limited to, allowing an application (e.g., mobile application, web application) access to a protected resource, denying an application access to a protected resource, sending a notification to one or more users indicating access is denied, sending a notification to one or more users indicating a new access token should be obtained, etc.

A data store250can be a persistent storage unit. A persistent storage unit can be a local storage unit or a remote storage unit. Persistent storage units can be a magnetic storage unit, optical storage unit, solid state storage unit, electronic storage units (main memory), or similar storage unit. Persistent storage units can be a monolithic device or a distributed set of devices. A ‘set’, as used herein, refers to any positive whole number of items.

FIG. 3is a flow diagram of an implementation of a method300for controlling consumption of protected cloud resources by OAuth-based applications in user devices. Method300can be performed by processing logic that can comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (e.g., instructions run on a processing device), or a combination thereof. In one implementation, method300is performed by a consumption control module161in a server machine170,180,190ofFIG. 1.

At block301, processing logic identifies a consumption request from a mobile device to consume a protected resource hosted by a cloud. The consumption request can be made by an application (e.g., mobile application, web application) sending a resource authorization message. Processing logic can analyze resource authorization messages (e.g., OAuth messages) that are being intercepted by a proxy and can identify a consumption request from the resource authorization messages. Processing logic can receive resource authorization messages (e.g., OAuth messages) at a cloud and can identify a consumption request from the resource authorization messages.

The consumption request can include an access token, which automatically grants the application access to protected resource. An access token allows an enterprise end-user to grant an application (e.g., mobile application, web application) cloud access to their information stored with a cloud, without sharing their access credentials (e.g., username and password). An access token can be a string denoting an expiration state, and other access attributes. For example, an access token may include data describing that the access token is not expired. An access token can be an OAuth token.

At block303, processing logic determines whether one or more parameters of the mobile device violate a policy that is associated with a user that is assigned to the mobile device. For example, the parameter may be a token state for a token that is granted to an application residing on the mobile device. The token state for the application on a particular mobile device can be stored in policy data that is separate from expiration data that is stored on an access token on the mobile device. One implementation of using a token state to control consumption of cloud resources by OAuth-based applications is described in greater detail below in conjunction withFIG. 4. In another example, the parameter may be a current geographic location of the mobile device. One implementation of using a location of a user device to control consumption of cloud resources by OAuth-based applications is described in greater detail below in conjunction withFIG. 5.

FIG. 4is a flow diagram of an implementation of a method400for using a token state to control consumption of cloud resources by OAuth-based applications in user devices. Method400can be performed by processing logic that can comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (e.g., instructions run on a processing device), or a combination thereof. In one implementation, method400is performed by a consumption control module161in a server machine170,180,190ofFIG. 1.

At block401, processing logic locates a mobile device identifier in a consumption request that is sent by a mobile device. The consumption request can be a request from an application (e.g., mobile application, web browser) running on the mobile device to consume a protected resource in a cloud. The request can be made via the OAuth protocol and can include a mobile device identifier and an access token (e.g., OAuth token). At block403, processing logic uses the mobile device identifier to identify a security policy that corresponds to the mobile device. A data store that is coupled to the consumption control module can store one or more security policies for each user using a mobile device to consume protected resources in a cloud. Processing logic can locate a mobile device identifier in the data store that matches the mobile device identifier in the request.

At block405, processing logic uses the mobile device identifier to locate and examine token state data that is stored in the data store to identify a current state of an access token that is assigned to the application on the mobile device. Examples of a current state of an access token can include, and are not limited to, “expired” and “valid.” The data store can store token state data that can be managed, for example, by a system administrator (e.g., enterprise system administrator, cloud system administrator). The system administrator can change the token state data for one or more access tokens that are assigned to a mobile device to “expired,” for example, when a user changes a cloud password. For example, a user, John Smith, may have lost his smart phone having a serial number “C44GKPH1DTD0.” John Smith may have changed his cloud account password. The access tokens on his lost smart phone may still be valid (e.g., may have not expired) and may still continue to automatic consume (download) data from the cloud accounts via the access tokens, even though John Smith has changed his cloud account password. In response to John Smith changing his cloud account password, the policy that is associated with John Smith may indicate that a system administrator should change the token state data for the access tokens that are assigned to the applications on John Smith's smart phone having a serial number “C44GKPH1DTD0” to “expired.” In one implementation, processing logic automatically changes the token state data for the access tokens that are assigned to the applications on a user's particular mobile device to “expired” based on the policy.

At block407, processing logic determines whether the current token state violates the corresponding security policy. For example, the current token state that is stored in the data store may be “expired” and the policy may indicate that only applications on mobile devices that have unexpired token states that are stored in the data store are permitted to consume a protected resource.

Processing logic can perform one or more actions based on whether the token state violates the policy. Examples of an action can include, and are not limited to, allowing an application on the mobile device access to a protected resource, denying an application on the mobile device access to a protected resource, sending a notification to one or more users (e.g., end-users, security administrators, system administrators, etc.), etc. If the token state does not violate the policy (block409), processing logic allows the application on the mobile device to consume the protected resource at block411. If the token state violate the policy (block409), processing logic prevents the application on the mobile device from consuming the protected resource at block413, and sends a message to the mobile device to obtain a new access token at block415. Processing logic can send a token-expired message to the mobile device indicating that the mobile device should be re-authenticated. Examples of a message can include, and are not limited to, messages communicated over a network (e.g., email messages, text messages, instant messages, social network messages, etc.), visual/sound alarm indicators on a computer system, etc.

FIG. 5is a flow diagram of an implementation of a method500for using a current physical location of a user device to control consumption of cloud resources by OAuth-based applications in the user device. Method500can be performed by processing logic that can comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (e.g., instructions run on a processing device), or a combination thereof. In one implementation, method500is performed by a consumption control module161in a server machine170,180,190ofFIG. 1.

At block501, processing logic locates a mobile device identifier in a consumption request that is sent by a mobile device. The consumption request can be a message with an OAuth token from an application (e.g., mobile application, web browser) running on the mobile device to consume a protected resource in a cloud. At block503, processing logic uses the mobile device identifier to identify a security policy that corresponds to the mobile device.

At block505, processing logic identifies a current geographic location of the mobile device. Processing logic can identify the current geographic location from the global positioning system of the mobile device. At block507, processing logic determines whether the current geographic location violates the corresponding security policy for the resource being accessed. For example, the policy may specify locations (e.g., list of countries, list of cities, etc.) where the mobile device, if located in one of the specified locations, is prohibited from consuming the protected resource. For example, Country-XYZ may not permit personal identity information (e.g., phone number, email address, physical address, etc.) to be shared across borders without express permission from the data owner.

If the current geographic location does not violate the policy (block509), processing logic allows the application on the mobile device to consume the protected resource at block511. If the current geographic location violates the policy (block509), processing logic prevents the application on the mobile device from consuming the protected resource at block513, and sends a message to the mobile device indicating that the geographic location violates the policy at block515. Examples of a message can include, and are not limited to, messages communicated over a network (e.g., email messages, text messages, instant messages, social network messages, etc.), visual/sound alarm indicators on a computer system, etc.

The example computer system600includes a processing device602, a main memory604(e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM) or DRAM (RDRAM), etc.), a static memory606(e.g., flash memory, static random access memory (SRAM), etc.), and a data storage device618, which communicate with each other via a bus630.

The computer system600may further include a network interface device608. The computer system600also may include a video display unit610(e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)), an alphanumeric input device612(e.g., a keyboard), a cursor control device614(e.g., a mouse), and a signal generation device616(e.g., a speaker).

The data storage device618may include a machine-readable storage medium628(also known as a computer-readable medium) on which is stored one or more sets of instructions622or software embodying any one or more of the methodologies or functions described herein. The instructions622may also reside, completely or at least partially, within the main memory604and/or within the processing device602during execution thereof by the computer system600, the main memory604and the processing device602also constituting machine-readable storage media.

It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the above discussion, it is appreciated that throughout the description, discussions utilizing terms such as “identifying” or “determining” or “preventing” or “allowing” or “sending” or “receiving” or “assigning” or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage devices.