Patent Description:
The service is often arranged to maintain the resources based on different tenants or organizations that are using the resources. Thus, when a client computing system wishes to gain access to a resource, the client computing system calls the API, exposed by the service, and includes an organization identifier, or a user identifier, as one of the parameters in the API call. The tenant identifier identifies an organization, or organization object, corresponding to the resource to be accessed, and the user identifier identifies a user, or user object, corresponding to the resource to be accessed.

<NPL> describes giving security considerations based on a comprehensive threat model for the OAuth <NUM> Protocol. <CIT> describes that a computerized device can implement a content player to access a content stream using a network interface, the content stream comprising encrypted content and an embedded license comprising a content key encrypted according to a global key accessible by the content player. <NPL> describes that the OAuth <NUM> authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth <NUM> protocol described in RFC <NUM>.

A service computing system receives an API call in which an authorization token, that contains an identifier in the content of the authorization token, is included in a header of the API call. The identifier is also included as a parameter passed in with the API call. The service computing system parses the API call to obtain the authorization token, and the identifier included in the authorization token. It also obtains the identifier passed in as a parameter of the API call. The service computing system compares the identifier obtained from the authorization token to the identifier passed in as a parameter of the API call to determine whether they match. A security system in the service computing system authorizes the API call based on the comparison.

The claimed subject matter is not limited to implementations that solve any or all disadvantages noted in the background.

As discussed above, in a client-server computing system architecture, client computing systems often access resources at the server level by making API calls using an API exposed by the server. As one example, a first service located in the cloud, can act as a client and interact with a second service, located in the cloud, by making an API call on the API exposed by the second service. In some current architectures, as long as the API call can be authenticated, then it is processed and there is no check on the parameters passed into the API, with the API call. In order to increase security, in some current systems, the API call has a header in which information can be placed by the first service, acting as the client computing system. Thus, in some current systems, the client computing system places an identifier, that identifies a tenant or user whose resources are to be accessed, in the header of the API call. The client also inserts the identifier as a parameter in the API call. In such a system, a security system on the server side (in this example, the second service) accesses the identifier in the header, and compares it to the identifier passed in as a parameter, and if the two match, then the API call is authorized to proceed.

However, this can still lead to security issues. For instance, if a surreptitious user obtains access to a client DLL, the surreptitious user can then create an instance of the client. That client can generate an API call that has, as a parameter, an identifier identifying an entity (such as an organization or user) and which also requests access to resources of the identified entity. The surreptitious actor can also place the identifier in the header of the API call. Thus, if the surreptitious actor obtains access to a client DLL, then the surreptitious actor can also obtain access to the client's resources at the server level.

The present description thus proceeds with respect to a system in which the client computing system obtains a signed authorization token, that includes the identifier, and places the signed authorization token in the header of the API call, and also includes the identifier as a parameter in the API call. When the server computing system receives the API call, it parses the header information to obtain the signed authorization token and ensures that the authorization token is authorized (that it hasn't been changed). It then obtains the identifier from the authorization token and compares it against the identifier that was passed in as a parameter. It authorizes the API call based upon the comparison. In this way, even if a surreptitious actor obtains a client DLL, it cannot make an authorized API call to obtain access to the client's resources, because it will not be able to obtain a signed authorization token from the token issuer. Thus, at the server level, the API call will be processed as an unauthorized API call.

<FIG> is a block diagram of one example of a computing system architecture <NUM> that further illustrates this. In the example shown in <FIG>, architecture <NUM> includes a service computing system <NUM> and a plurality of different client computing systems <NUM>-<NUM> that can access resources on service computing system <NUM> over network <NUM>. Network <NUM> can thus be any of a wide variety of different types of networks such as a wide area network, a local area network, a near field communication network, a cellular network, among a wide variety of other networks or combinations of networks.

Also, in the example shown in <FIG>, service computing system <NUM> exposes an application programming interface (API) <NUM> for interaction by client computing systems <NUM>-<NUM>. The client computing systems <NUM>-<NUM> can make API calls on the exposed API <NUM> in order to gain access to service computing system <NUM> and the resources.

For the purposes of the present description, it is assumed that client computing system <NUM> is a service that is a client (or can act as a client) of service computing system <NUM>. It can be running, for example, in the same cloud service computing system <NUM>.

Architecture <NUM> also shows that, in one example, client computing system <NUM> generates user interfaces <NUM> for interaction by user <NUM>. User <NUM> can be an administrative user, or another user, who may wish to access resources on service computing system <NUM>. User <NUM> illustratively interacts with user interfaces <NUM>, in order to control and manipulate client computing system <NUM>, and some portions of service computing system <NUM>.

By way of example, assume that service computing system <NUM> is an electronic mail (email) service computing system administrative user <NUM> wishes to move a mailbox in service computing system <NUM>. Administrative user <NUM> Assume further that can run a command on computing system <NUM> to create a request to move the identified mailbox. In that case, client computing system <NUM> may pick up that request and call service computing system <NUM> (as a client of system <NUM>) requesting access to the resource (e.g., the mailbox). It can do so by making an access request call on the API <NUM> exposed by system <NUM>.

Also, in the example shown in <FIG>, architecture <NUM> shows a token issuer service <NUM> that can issue tokens to client computing system <NUM> directly (if they are in the same cloud) or over network <NUM>. Briefly, by way of example, client computing system <NUM> can obtain an authorization token from token issuer service <NUM>. The request for a token generated by client computing system <NUM> can be scoped by an identifier that identifies the user or organization which corresponds to the resources that are to be accessed on service computing system <NUM>. The authorization token issued by service <NUM> includes, in the content of the token, that identifier. Continuing with the above example, the identifier may identify the tenant or user corresponding to the mailbox to be moved.

Client computing system <NUM> then generates an API call on API <NUM> which includes the authorization token in the header of the API call, and the identifier as a parameter that is passed in with the API call. Service computing system <NUM> authorizes the API call by comparing the identifier in the token (which is retrieved from the header of the API call) to the identifier that is passed in as a parameter with the API call. If the two match then the API call proceeds. If not, it is unauthorized.

Before describing the operation of architecture <NUM> in more detail, a brief description of some of the items in architecture <NUM>, and their operation, will first be described. Client computing systems <NUM>-<NUM> can be similar or different. In the example described herein, it is assumed that client computing system <NUM> is a service that acts as a client of service computing system <NUM>. Client computing system <NUM> is illustratively a computing system used by an administrative user or other user who requests access to resources on computing system <NUM>. Therefore, only client computing system <NUM> is described in more detail.

In the example shown in <FIG>, client computing system <NUM> illustratively includes one or more processors or servers <NUM>, data store <NUM>, communication system <NUM>, API interaction system <NUM>, and it can include a wide variety of other client system functionality <NUM>. Communication system <NUM> can be used to communicate over network <NUM> with token issuer service <NUM> and service computing system <NUM> (using API <NUM>). Thus, communication system <NUM> can be any of a wide variety of different types of communication systems, depending on the particular type of network or combinations of networks over which it is to communicate.

API interaction system <NUM> illustratively generates API calls for API <NUM>. Thus, in one example, API interaction system <NUM> illustratively receives a request generated by user <NUM> indicating that user <NUM> wishes to gain access to resources on service computing system <NUM>. It thus generates an API call that is used to call API <NUM> to gain access to those resources. In doing so, it illustratively obtains the authorization token from token issuer service <NUM> and puts it in the header of the API call. It also illustratively receives responses to the API call and processes those accordingly. This is described in greater detail below. Other client system functionality <NUM> can include a wide variety of other client computing system functionality.

Token issuer service <NUM> illustratively includes one or more processors or servers <NUM>, data store <NUM>, requestor authentication system <NUM>, token generation system <NUM>, communication system <NUM>, and it can include a wide variety of other token issuer functionality <NUM>. Communication system <NUM> illustratively communicates over network <NUM>. Therefore, it can be any of a wide variety of different types of communication systems or combinations of systems that are used to communicate over network <NUM>.

Requestor authentication system <NUM> illustratively authenticates requests for tokens. In one example, token issuer service <NUM> receives an indication from service computing system <NUM> indicating that client computing system <NUM> is authorized to access certain resources on service computing system <NUM>. Thus, requestor authentication system <NUM> shares a secret with client computing system <NUM>. API interaction system <NUM> uses that secret when requesting an authorization token from token issuer service <NUM>. Requestor authentication system <NUM> also uses that secret in order to authenticate client computing system <NUM> as being a system that can request authorization tokens from service <NUM>.

Token generation system <NUM> generates the authorization tokens. In one example, a request for an authorization token to access resources on service computing system <NUM> includes an identifier identifying the organization or user whose resources are being accessed. In that case, token generation system <NUM> generates the authorization token so that it includes the identifier within the authorization token, itself. As one example, system <NUM> can generate authorization tokens to include three or more different portions. They can include a metadata portion, a content (or claims) portion, and a signature portion. The content or claims portion may be a portion in which the identifier is contained. The signature portion includes a signature. Once the token is signed an authorized recipient of the token will be able to determine whether the token has been modified, based upon the signature.

In the example shown in <FIG>, service computing system <NUM> includes one or more different servers <NUM>, protected resources <NUM>, a frontend system <NUM>, a backend system <NUM>, a security system <NUM>, and it can include a wide variety of other service computing system functionality <NUM>. Front end system <NUM> illustratively exposes API <NUM> which can receive API calls from client computing system <NUM>.

When a call is received that requests access to protected resources <NUM>, frontend system <NUM> illustratively provides security system <NUM> with access to that API call. In one example, security system <NUM> parses the API call to obtain the authorization token from the header of the API call. It first authenticates the authorization token, itself. Using the signature on the authorization token, it determines whether any of the content or metadata or other information in the authorization token has been modified. If so, then the call will fail, because the authorization token has been modified. Assuming that the authorization token, itself, is authenticated by security system <NUM>, security system <NUM> then goes on to determine whether the API call is authorized. Security system <NUM> obtains the identifier from the authorization token, and it obtains the identifier that was passed in as a parameter at the API call. It compares the two and determines whether the API call is authorized.

If the API call is authorized, then it is passed to backend system <NUM> which provides the requested access to protected resources <NUM>. If it is not authorized, then it is processed by service computing system <NUM> as an unauthorized API request. This can include such things as alerting security personnel, simply refusing the requested access, among other things.

<FIG> is a block diagram showing one example of API interaction system <NUM>, in more detail. API interaction system <NUM> illustratively includes token request logic <NUM>, API call generator <NUM> (which, itself, includes token insertion logic <NUM>, parameter insertion logic <NUM>, and it can include other items <NUM>), response processing logic <NUM>, and it can include other items <NUM>. Token request logic <NUM> illustratively requests an access token from, and handles interactions with, token issuer service <NUM>. Thus, when an authorization token (or access token) is needed, it requests the token from token issuer service <NUM> and provides that token to API call generator <NUM>. In the example illustrated herein, API call generator <NUM> illustratively generates an API call which can include a header and parameters, among other things. Token insertion logic <NUM> inserts the authorization token received from token request logic <NUM> into the header of the API call. Parameter insertion logic <NUM> generates and inserts the parameters, based on the particular access request being made in the API call. API call generator <NUM> can then provide the API call to communication system <NUM> (shown in <FIG>) where it is provided to API <NUM>. When API <NUM> provides a response to the API call, response processing logic <NUM> obtains that response and processes it, as desired, based upon the access request performed.

<FIG> is a block diagram showing one example of security system <NUM>, in more detail. In the example shown in <FIG>, security system <NUM> illustratively includes API call header parsing logic <NUM>, token processing logic <NUM>, parameter parsing logic <NUM>, identifier comparison logic <NUM>, unauthorized call processing logic <NUM>, call authorization logic <NUM>, and it can include a wide variety of other items <NUM>. API call header parsing logic <NUM> illustratively parses the API call to identify the authorization token in the header of the API call. It provides the authorization token to token processing logic <NUM>. Token processing logic <NUM> illustratively processes the authorization token to determine whether it is authentic and authorized. For instance, based upon the signature in the authorization token, logic <NUM> can determine whether any part of the authorization token has been altered, since it was signed. If not, and the authorization token, itself, is authentic and authorized, then token processing logic <NUM> illustratively identifies the particular identifier, that was used by token request logic <NUM> to scope the authorization token request when it requested a token from token issuer service <NUM>. Recall that, in one example, that identifier is included in the content portion of the authorization token. Parameter parsing logic <NUM> then parses the parameters in the API call to obtain the identifier that was passed in as a parameter.

Identifier comparison logic <NUM> compares the identifier that was retrieved from the authorization token with the identifier that was retrieved from the parameters of the API call. It determines whether those identifiers are the same. If not, then unauthorized call processing logic <NUM> processes the API call as an unauthorized call. If so, then call authorization logic <NUM> indicates that processing of the API call can proceed.

<FIG> is a flow diagram illustrating one example of the operation of client computing system <NUM> and API interaction system <NUM> in requesting an authorization token and generating an API call using that authorization token. It is first assumed that a service (e.g., service computing system <NUM>) is providing access to protected resources (e.g., resources <NUM>) and that it exposes an API <NUM> for interaction by a client computing system (in this example, client computing system <NUM>). This is indicated by block <NUM> in the flow diagram of <FIG>.

It is also assumed that a token issuer service <NUM> has shared a token request secret with client computing system <NUM>, and that client computing system <NUM> has been approved (to token issuer service <NUM>) by service computing system <NUM>. This is indicated by block <NUM> in the flow diagram of <FIG>.

At some point, when client computing system <NUM> wishes to obtain access to protected resources <NUM> on service computing system <NUM>, then token request logic <NUM> requests a resource access token from the token issuer service <NUM>. In doing so, it illustratively scopes the access request with an identifier (which identifies the user or organization whose resources are to be accessed). Requesting the token and scoping the request with the identifier is indicated by block <NUM> in the flow diagram of <FIG>. The identifier can be a tenant identifier. This is indicated by block <NUM>. It can be a user identifier as indicated by block <NUM>, or another identifier as indicated by block <NUM>.

The token is generated by token generation system <NUM> which includes the identifier in the content portion of the token. It also signs the token and provides it back to token request logic <NUM>. Receiving the resource access token from the token issuer <NUM> with the identifier being part of the content (e.g., claims) of the resource access token is indicated by block <NUM> in the flow diagram of <FIG>.

API call generator <NUM> then generates an API call to request access to the resources using the API <NUM> exposed by service computing system <NUM>. Token insertion logic <NUM> inserts the resource access token in the header of the API call. Parameter insertion logic <NUM> inserts the identifier as a parameter of the API call. Generating the API call in this way is indicated by block <NUM> in the flow diagram of <FIG>.

Service computing system <NUM> then authenticates and authorizes the API call and, if authenticated and authorized, responds to the API call. Response processing logic <NUM> illustratively receives requested access to the resources, as indicated by the response from service computing system <NUM>. Receiving the requested access is indicated by block <NUM> in the flow diagram of <FIG>.

<FIG> is a flow diagram illustrating one example of the operation of security system <NUM>, and service computing system <NUM>, in processing an API call that requests access to protected resources <NUM>. Frontend system <NUM> first receives the resource access request as an API call through API <NUM>. This is indicated by block <NUM> in the flow diagram of <FIG>. Header parsing logic <NUM> then parses the header of the API call to obtain the resource access token that was inserted in the header by token insertion logic <NUM> on client computing system <NUM>. Parsing the header to obtain the resource access token is indicated by block <NUM> in the flow diagram of <FIG>.

Token processing logic <NUM> then validates the token. For instance, it can access the signature on the token to determine whether the token has been changed since it was issued by the token issuer service <NUM>. Validating the token is indicated by block <NUM> in the flow diagram of <FIG>. If the token is not valid, as indicated by block <NUM>, then the API call is processed as an unauthorized API call, as indicated by block <NUM>.

However, if, at block <NUM>, token processing logic <NUM> does validate the token, then token processing logic <NUM> obtains the identifier from the content portion of the resource access token. This is indicated by block <NUM> in the flow diagram of <FIG>.

Parameter parsing logic <NUM> then obtains the identifier that was passed in as a parameter of the API call. This is indicated by block <NUM>. Identifier comparison logic <NUM> compares the identifier obtained from the token with the identifier passed in as a parameter of the API call. This is indicated by block <NUM>.

If the two identifiers do not match, as indicated by block <NUM>, then unauthorized call processing logic <NUM> processes the API call as an unauthorized API call. Again, this is indicated by block <NUM>.

However, if, at block <NUM>, it is determined that the two identifiers do match, then call authorization logic <NUM> proceeds to process the call as an authorized API call, thus granting the requested access to the protected resources <NUM>. This is indicated by block <NUM> in the flow diagram of <FIG>.

It can thus be seen that the present description greatly enhances the security of protected resources in a client server architecture. By obtaining an authorization token, that includes an identifier provided by the requesting client in the token, and by then having the client include that token in the API call, a surreptitious user is unable to gain unauthorized accesses to the protected resources, even if the surreptitious user were to obtain a client DLL. Thus, security is greatly enhanced.

The present discussion has mentioned processors and servers. In one example, the processors and servers include computer processors with associated memory and timing circuitry, not separately shown. They are functional parts of the systems or devices to which they belong and are activated by, and facilitate the functionality of the other components or items in those systems.

<FIG> is a block diagram of architecture <NUM>, shown in <FIG>, except that its elements are disposed in a cloud computing architecture <NUM>. Cloud computing provides computation, software, data access, and storage services that do not require end-user knowledge of the physical location or configuration of the system that delivers the services. In various examples, cloud computing delivers the services over a wide area network, such as the internet, using appropriate protocols. For instance, cloud computing providers deliver applications over a wide area network and they can be accessed through a web browser or any other computing component. Software or components of architecture <NUM> as well as the corresponding data, can be stored on servers at a remote location. The computing resources in a cloud computing environment can be consolidated at a remote data center location or they can be dispersed. Cloud computing infrastructures can deliver services through shared data centers, even though they appear as a single point of access for the user. Thus, the components and functions described herein can be provided from a service provider at a remote location using a cloud computing architecture. Alternatively, they can be provided from a conventional server, or they can be installed on client devices directly, or in other ways.

The description is intended to include both public cloud computing and private cloud computing. Cloud computing (both public and private) provides substantially seamless pooling of resources, as well as a reduced need to manage and configure underlying hardware infrastructure.

A public cloud is managed by a vendor and typically supports multiple consumers using the same infrastructure. Also, a public cloud, as opposed to a private cloud, can free up the end users from managing the hardware. A private cloud may be managed by the organization itself and the infrastructure is typically not shared with other organizations. The organization still maintains the hardware to some extent, such as installations and repairs, etc..

In the example shown in <FIG>, some items are similar to those shown in <FIG> and they are similarly numbered. <FIG> specifically shows that systems <NUM> and <NUM> and service <NUM> can be located in cloud <NUM> (which can be public, private, or a combination where portions are public while others are private). Therefore, user <NUM> uses a user device and client computing system <NUM> to access those systems through cloud <NUM>.

<FIG> also depicts another example of a cloud architecture. <FIG> shows that it is also contemplated that some elements of architecture <NUM> can be disposed in cloud <NUM> while others are not. By way of example, token issuer service <NUM>, as well as data store <NUM> can be disposed outside of cloud <NUM>, and accessed through cloud <NUM>. Regardless of where they are located, they can be accessed directly by systems, through a network (either a wide area network or a local area network), they can be hosted at a remote site by a service, or they can be provided as a service through a cloud or accessed by a connection service that resides in the cloud. All of these architectures are contemplated herein.

It will also be noted that architecture <NUM>, or portions of it, can be disposed on a wide variety of different devices. Some of those devices include servers, desktop computers, laptop computers, tablet computers, or other mobile devices, such as palm top computers, cell phones, smart phones, multimedia players, personal digital assistants, etc..

<FIG> is one example of a computing environment in which architecture <NUM>, or parts of it, (for example) can be deployed. With reference to <FIG>, an example system for implementing some embodiments includes a general-purpose computing device in the form of a computer <NUM>. Components of computer <NUM> may include, but are not limited to, a processing unit <NUM> (which can comprise processors or servers from previous FIGS. ), a system memory <NUM>, and a system bus <NUM> that couples various system components including the system memory to the processing unit <NUM>. The system bus <NUM> may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. By way of example, and not limitation, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus also known as Mezzanine bus. Memory and programs described with respect to <FIG> can be deployed in corresponding portions of <FIG>.

Communication media typically embodies computer readable instructions, data structures, program modules or other data in a transport mechanism and includes any information delivery media. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the above should also be included within the scope of computer readable media.

By way of example only, <FIG> illustrates a hard disk drive <NUM> that reads from or writes to non-removable, nonvolatile magnetic media, and an optical disk drive <NUM> that reads from or writes to a removable, nonvolatile optical disk <NUM> such as a CD ROM or other optical media. Other removable/non-removable, volatile/nonvolatile computer storage media that can be used in the exemplary operating environment include, but are not limited to, magnetic tape cassettes, flash memory cards, digital versatile disks, digital video tape, solid state RAM, solid state ROM, and the like.

Operating system <NUM>, application programs <NUM>, other program modules <NUM>, and program data <NUM> are given different numbers here to illustrate that, at a minimum, they are different copies.

These and other input devices are often connected to the processing unit <NUM> through a user input interface <NUM> that is coupled to the system bus, but may be connected by other interface and bus structures, such as a parallel port, game port or a universal serial bus (USB).

The computer <NUM> is operated in a networked environment using logical connections to one or more remote computers, such as a remote computer <NUM>. The remote computer <NUM> may be a personal computer, a hand-held device, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer <NUM>. The logical connections depicted in <FIG> include a local area network (LAN) <NUM> and a wide area network (WAN) <NUM>, but may also include other networks. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Internet.

The modem <NUM>, which may be internal or external, may be connected to the system bus <NUM> via the user input interface <NUM>, or other appropriate mechanism. In a networked environment, program modules depicted relative to the computer <NUM>, or portions thereof, may be stored in the remote memory storage device. By way of example, and not limitation, <FIG> illustrates remote application programs <NUM> as residing on remote computer <NUM>. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.

Claim 1:
A computing system, comprising:
a processor (<NUM>);
a front end system (<NUM>) that exposes an application programming interface (API) that receives an access request requesting access to a protected resource, the access request having a header portion and a parameter portion; and
a security system (<NUM>) that:
identifies a signed resource access token including a signature in the header portion of the access request, wherein the signed resource access token has a content portion that includes a first identifier, and the parameter portion of the access request has a second identifier;
generates a comparison result indicative of a comparison of the first identifier with the second identifier; and
authorizes the access request based on ensuring that the signed resource access token is authorized using the signature and on the comparison result being a match, wherein the security system comprises API header parsing logic configured to parse the header portion to identify the signed resource access token.