GENERATION OF MULTIPLE LIMITED-SCOPE ACCESS TOKENS

In some disclosed embodiments, a first computing system may receive a message indicating that a resource owner has authorized a client application to make application programming interface (API) calls to both (A) a first access-restricted resource controlled by the resource owner, and (B) a second access-restricted resource controlled by the resource owner. In response to the message, the first computing system may generate both (A) a first token that is configured to authenticate to a first API endpoint to access the first access-restricted resource but is not configured to authenticate to a second API endpoint to access the second access-restricted resource, and (B) a second token that is configured to authenticate to the second API endpoint to access the second access-restricted resource but is not configured to authenticate to the first API endpoint to access the first access-restricted resource.

BACKGROUND

Many software applications or websites may employ one or more application programming interfaces (APIs). An API of an application may allow outside communication with the application by systems running other applications. For example, another application or system may call the API of the application and request to obtain data, a service, or something else of value. The API may outline how other applications or systems may communicate with the API, such as the types and/or formats of calls or requests that can be made with the API. The API or a related server(s) may authenticate the other applications or systems or authorize calls or requests made by the other applications or systems.

SUMMARY

In some of the disclosed embodiments, a method involves receiving, by a first computing system, a first message indicating that a resource owner has authorized a client application to make application programming interface (API) calls to both (A) a first access-restricted resource controlled by the resource owner, and (B) a second access-restricted resource controlled by the resource owner; in response to the first message, generating, by the first computing system, both (A) a first token that is configured to authenticate to a first API endpoint to access the first access-restricted resource but is not configured to authenticate to a second API endpoint to access the second access-restricted resource, and (B) a second token that is configured to authenticate to the second API endpoint to access the second access-restricted resource but is not configured to authenticate to the first API endpoint to access the first access-restricted resource; and sending, from the first computing system to a second computing system, the first token and the second token to enable the second computing system to use the first token to make a first API call to the first API endpoint to access the first access-restricted resource, and to use the second token to make a second API call to the second API endpoint to access the second access-restricted resource.

In some disclosed embodiments, a first computing system comprises at least one first processor, and at least one first computer-readable medium encoded with instructions which, when executed by the at least one first processor, cause the first computing system to receive a first message indicating that a resource owner has authorized a client application to make application programming interface (API) calls to both (A) a first access-restricted resource controlled by the resource owner, and (B) a second access-restricted resource controlled by the resource owner, to generate, in response to the first message, both (A) a first token that is configured to authenticate to a first API endpoint to access the first access-restricted resource but is not configured to authenticate to a second API endpoint to access the second access-restricted resource, and (B) a second token that is configured to authenticate to the second API endpoint to access the second access-restricted resource but is not configured to authenticate to the first API endpoint to access the first access-restricted resource, and to send, to a second computing system, the first token and the second token to enable the second computing system to use the first token to make a first API call to the first API endpoint to access the first access-restricted resource, and to use the second token to make a second API call to the second API endpoint to access the second access-restricted resource.

In some disclosed embodiments, at least one non-transitory computer-readable medium is encoded with instructions which, when executed by at least one processor of a first computing system, cause the first computing system to receive a first message indicating that a resource owner has authorized a client application to make application programming interface (API) calls to both (A) a first access-restricted resource controlled by the resource owner, and (B) a second access-restricted resource controlled by the resource owner, to generate, in response to the first message, both (A) a first token that is configured to authenticate to a first API endpoint to access the first access-restricted resource but is not configured to authenticate to a second API endpoint to access the second access-restricted resource, and (B) a second token that is configured to authenticate to the second API endpoint to access the second access-restricted resource but is not configured to authenticate to the first API endpoint to access the first access-restricted resource, and to send, to a second computing system, the first token and the second token to enable the second computing system to use the first token to make a first API call to the first API endpoint to access the first access-restricted resource, and to use the second token to make a second API call to the second API endpoint to access the second access-restricted resource.

DETAILED DESCRIPTION

It is common for applications (or “apps,” for short) to integrate with multiple application programming interface (API) endpoints to obtain data, services, or something else of value from other applications. In some circumstances, such APIs may be “first party APIs,” which are provided by the same organization that is creating the app. In other circumstances, such APIs may additionally or alternatively be “third party APIs,” which are provided by an organization different than the one creating the app. Applications that interface with APIs of other resources are referred to herein as “client apps.”

As an example, the Citrix Workspace App, offered by Citrix Systems, Inc., of Fort Lauderdale, Fla., integrates with first party APIs, such as Files, Podio, Notifications, Workspace (core), Wrike, etc., which are all provided by different Citrix apps/services. At the same time, the Citrix Workspace App may also call third party APIs, such as SAP Concur, Workday, Salesforce, etc., through microapps implemented within it. In some sense, the Citrix Workspace App behaves as a “super-app” which provides a one stop solution for getting things done on other applications through the respective APIs.

To invoke the APIs of other apps/services, authentication and authorization mechanisms may be employed so that the client app can access resources on behalf of users in a secure and transparent way. Often, industry standards, such as the Open Authorization 2.0 (“OAuth 2”) protocol, are used to get the consent of the user on whose behalf a resource is to be accessed (referred to herein as the “resource owner”) prior to providing the client app with a token (e.g., a bearer token or an access token) that client app can use to access one or more resources/APIs on the user's behalf. The OAuth 2.0 protocol is described by “The OAuth 2.0 Authorization Framework,” Request for Comments (RFC) 6749, a product of the Internet Engineering Task Force (IETF), October 2012, the entire contents of which is incorporated herein by reference.

To simplify the experience of the resource owner, it is common for an authorization service (e.g., the “authorization server” of the OAuth 2.0 protocol) to implement a single consent process so that the resource owner can view all the scopes (permissions) requested for a set of different APIs, and to accept or reject all such scopes as a group.FIG.1Ashows an example user interface (UI) screen100that an authorization server may generate for presentation to a resource owner to implement such a single consent process. In the illustrated example, the UI screen100is requesting for the resource owner (i.e., an individual with the email address “james_bond007@acme.com”) to authorize a client app (i.e., an application named “super_cool_app”) to access APIs of four different resources (i.e., “Files,” “Notifications,” “Podio,” and “Workspace”). Via the UI screen100, the resource owner may authorize the client app to access all four such resources by clicking on or otherwise selecting a single “allow” UI element102, or may instead deny access to the indicated resources by clicking on or otherwise selecting a single “deny” UI element104. The use of such a single consent process is typically done to prevent the resource owner from being burdened from having to click through multiple, separate consent screens for the various different APIs for which consent is being requested.

While the use of such a single consent process makes the client app implementation and experience optimal, as explained below, it creates new challenges.FIG.1Billustrates an example scenario in which a client app106authenticates to an authorization service108(e.g., an OAuth 2.0 authorization server) and obtains a multi-scope access token110that can be used to access multiple different resources. As shown, in such a scenario, the master access token110issued by the authorization service108may contain all the scopes requested and approved by the resource owner (e.g., via a multi-resource consent process such as that described above in connection withFIG.1A). Such an access token110essentially behaves as a “master” token because it can invoke any of the services for which it has a scope specified in claims. In the illustrated example, the master access token110has been configured to includes scopes that allow access to at least three different APIs (i.e., “API1,” “API2” and “API3”) belonging to respective services113a,113b,113c(i.e., “Svc 1,” “Svc 2,” and “Svc 3”).

As indicated by arrows112a,112b, and112cinFIG.1B, the client app106may use the same master access token110to call any of the three APIs of the respective services113. While this is the desired behavior from the client app perspective, the inventor has recognized and appreciated that the use of such a master access token can produce undesirable side effects and introduce potential security risks. Those side effects/security risks can be summarized as follows. When the client app106presents the master access token110to Svc 1 to access API1, access will be granted to API1 because API1 is included among the scopes listed within the master access token110. However, the master access token110also has additional scopes (i.e., API2 and API3) which mean nothing to Svc 1. As such, as indicated on the right-hand side ofFIG.1B, in the event that the master access token110is compromised by an attack on Svc 1, the attacker would be able to call Svc 2 and Svc 3 as well because the compromised access token110includes scopes for API2 and API3, respectively. In an ideal and secure scenario, this sequence of events would not occur. That is, in the event that the master access token110gets compromised while accessing API1, it would be better if the attacker could not also gain access to API2 and API3 using the compromised token.

Before describing details of the novel systems and techniques disclosed herein for solving the above problem, various drawbacks of existing solutions to the problem will first be discussed. One known way to solve the problem is to introduce an intermediate component, e.g., an API Gateway114, which does additional processing, as depicted inFIG.1C. As shown inFIG.1C, like the system described in connection withFIG.1B, a master access token110including scopes for multiple resources may be generated and sent to the client app106in response to a single consent by the resource owner (e.g., via a multi-resource consent process such as that described above in connection withFIG.1A). As indicated by an arrow116inFIG.1C, to call any of the APIs within the authorized scopes, the client app106may send the master access token110to the API Gateway114. Upon receipt of the master access token110, the API Gateway114determines the API endpoint invoked by the client app106. In the illustrated example, the client app106has invoked “API1” of an application named “App1.” As indicated by an arrow118inFIG.1C, the API gateway114then calls a token exchange API of the authorization service108to exchange the master access token110for another, substitute access token120which has only the scope(s) needed by API1. As indicated by an arrow122inFIG.1C, the substitute access token120is returned to the API gateway114. A new substitute access token120including the requisite scope(s) for a single service113is generated by the authorization service108each time the token exchange API is called (per the arrow118). As indicated by an arrow124inFIG.1C, the API gateway114then replaces the master access token110with the newly-generated substitute access token120received from the authorization service108, and uses the substitute access token120to call the requested API, i.e., API1. Although not illustrated inFIG.1C, another known approach with a similar result is for the authorization service108to send an opaque token, rather than a master access token110, to the client app106, and for the API gateway114to call a token exchange API of the authorization service108using the opaque token, rather than a master access token110, to obtain a substitute access token120. Unlike the master access token110, an opaque token would not be recognized by any of the services113and would thus be useful to an attacker only if the attacker were able to successfully interact with the API gateway114to exchange the opaque token for a substitute access token120that one or more of the services113would recognize. In connection with such an opaque token exchange process, similar to the master access token exchange scenario described above, a new substitute access token120including the requisite scope(s) for a single service113is generated by the authorization service108each time the token exchange API is called using an opaque token.

The inventor has recognized and appreciated that, although the foregoing approaches can be used to solve the above-noted problem to at least some extent, there are a number of drawbacks to using them. A first drawback is that either such approach necessitates use of an intermediary component, such an API gateway, to exchange and swap tokens. A second drawback of these approaches is that they necessitate new APIs in the authorization service108to generate new single-service access tokens when a token exchange request, requesting an exchange for either a master access token or an opaque token, is received from the API gateway114. Another drawback of these approaches is that every API call requires a call to the authorization service108to exchange tokens. This can be mitigated to some extent by caching previously-generated, single-service tokens but can't be avoided altogether. Further, caching generally imposes new security, cost, and scaling concerns. Further, in scenarios in which a master access token110, as opposed to an opaque token, is provided to the client app106, another drawback is that a need to trust the API gateway114is introduced because the API gateway114receives the master access token110from the client app106.

Certain of the novel systems and methods described herein eliminate one or more, or in some cases all, of the foregoing drawbacks of existing solutions.

For purposes of reading the description of the various embodiments below, the following descriptions of the sections of the specification and their respective contents may be helpful:Section A provides an introduction to example embodiments of a novel system for generating multiple limited-scope access tokens in accordance with some aspects of the present disclosure;Section B describes a network environment which may be useful for practicing embodiments described herein;Section C describes a computing system which may be useful for practicing embodiments described herein;Section D describes embodiments of systems and methods for accessing computing resources using a cloud computing environment;Section E provides a more detailed description of example embodiments of the system for generating multiple limited-scope access tokens introduced in Section A; andSection F describes example implementations of methods, systems/devices, and computer-readable media in accordance with the present disclosure.

A. Introduction to Illustrative Embodiments of a Novel System for Generating Multiple Limited-Scope Access Tokens

Offered are systems and techniques for generating multiple, different access tokens that can each be used to access only a single service (or a single subset of services) on behalf of a resource owner in response to a single consent of the resource owner. After such multiple, limited-scope access tokens have been generated, they can be made available for use in calling respective APIs on behalf of the resource owner in any of numerous ways. Several example implementations of systems capable of providing such functionality are described further below.

One of the novel features disclosed herein is that, after proper consent has been provided by the resource owner, the authorization service108(e.g., the “authorization server” of the OAuth 2.0 protocol) may generate multiple limited-scope access tokens, each specific to a single service/API113(or subset of services/APIs113) and having only the scope(s) applicable to that service/API113(or subset of services/APIs113). In some implementations, all such limited-scope access tokens may be packed/embedded into a “main” access token using custom claims so that those limited-scope access tokens can subsequently be unpacked and used individually by the client app106or an intermediate component (e.g., an API gateway114) to access respective services113.FIG.1Dillustrates an example of a main access token126that has been configured to include claims130for multiple, limited-scope access tokens128a,128b,128c(referred to herein as “substitute tokens” or “sub tokens,” for short) embedded within it. As explained in more detail below, in some implementations, the main access token126may be provided to the client app106for use in making API calls to one or more of the services/APIs113for which the resource owner has provided consent. As further shown inFIG.1D, in some implementations, the main access token126may additionally include claims132that allow it to be used as a “master” access token, similar to the master access token110described above in connection withFIGS.1B and1C. By including the claims132in the main access token126, the main access token126may optionally be used as a master access token to access any of the multiple services/APIs113indicated by its scopes, such as when a client app106or intermediate component (e.g., an API gateway114) is not configured to extract the sub tokens128from the main access token126, as described in more detail below, thus allowing the main access token126to be backwards compatible with existing system, such as those described in connection withFIGS.1B and1C. In some implementations, the custom claims130for the sub tokens128may be optionally compressed before embedding them into the main access token128so that size of the main access token128does not become excessive. In such case, those custom claims130may be decompressed as a part of the sub token extraction process described below.

In some implementations, rather than having just two “levels” of access tokens as shown inFIG.1D(i.e., a main access token126and a set of embedded sub tokens128), additional “levels” of tokens may additionally be provided, with higher-level tokens containing broader scopes and embedded sub tokens containing finer scopes. For example, with reference toFIG.1D, in some implementations, multiple additional sub tokens (not illustrated) may be embedded within one or more of the individual sub tokens128a,128b,128c.

In some implementations, in addition to or in lieu of embedding the generated sub tokens128into a main access token126that is returned to the client app106, the sub tokens128(which are generated in response to the single consent provided by the resource owner) may be stored in a storage medium associated with an intermediate component, such as an API gateway114. In such implementations, the authorization service108may cause the sub tokens128to be stored (either individually or as a part of a main access token126) in the storage medium in association with another token that is sent to the client app106. In some implementations, the other token that is sent to the client app106may include a master access token, such as the master access token110described in connection withFIGS.1B and1C, and the generated sub tokens128may be stored in the storage medium (either individually or as a part of a main access token126) in association with that master access token. In other implementations, the other token that is sent to the client app106may include an opaque token, such as described above in connection withFIG.1C, and the generated sub tokens128may be stored (either individually or as a part of a main access token126) in the storage medium in association with that opaque token.

As described in more detail below, in some such implementations, upon the intermediate component (e.g., the API gateway114) receiving from the client app106a request that includes the other token the client app106received from the authorization service108(e.g., a master access token110, an opaque token, or otherwise), a token lookup service included within or associated with the intermediate component (e.g., the API gateway114) may use the other token to retrieve the pre-generated sub token128for the requested service113from the storage medium and use that retrieved sub token128to make an API call to the service113. As noted above, in some such implementations, the sub tokens128may be embedded within a main access token126(as described above) and the main access token126may be stored in the storage medium associated with the intermediate component (e.g., the API gateway114). In such implementations, the token lookup service and/or the intermediate component (e.g., the API gateway114) may extract the needed sub token128from the main access token126in response to the intermediate component (e.g., the API gateway114) receiving an API access request from the client app106. In other implementations, the individual sub tokens128may be separately stored in the storage medium associated with the intermediate component (e.g., the API gateway114). In such implementations, the token lookup service may simply retrieve the needed sub token128from the storage medium in response to the intermediate component (e.g., the API gateway114) receiving an API access request from the client app106, without having to extract the desired sub token128from a main access token126.

Accordingly, in some implementations, the authorization service108may send the client app106a master access token110that is also sent to a token lookup service included within or associated with an intermediate component (e.g., an API gateway114), and the sub tokens128may be stored in the storage medium (either separately or embedded within a main access token126) in association with the master access token110. In such implementations, the client app106may include the master access token110in an API call sent to the intermediate component (e.g., the API gateway114), and the token lookup service and/or the intermediate component (e.g., the API gateway114) may exchange the master access token110for an appropriate one of the pre-stored sub tokens128prior to the intermediate component (e.g., the API gateway114) forwarding the API call to the requested service113. If the sub tokens128are embedded within a main access token126, the token lookup service and/or the intermediate component (e.g., the API gateway114) may extract the desired sub token128from the main access token126upon receiving an API access request from the client app106.

Similarly, in other implementations, the authorization service108may send the client app106an opaque token that is also sent to a token lookup service included within or associated with an intermediate component (e.g., the API gateway114), and the sub tokens128may be stored in the storage medium (either separately or embedded within a main access token126) in association with the opaque token. In such implementations, the client app106may include the opaque token in an API call sent to the intermediate component (e.g., the API gateway114), and the token lookup service and/or the intermediate component (e.g., the API gateway114) may exchange the opaque token for an appropriate one of the pre-stored sub tokens128prior to the intermediate component (e.g., the API gateway114) forwarding the API call to the requested service113. If the sub tokens128are embedded within a main access token126, the token lookup service and/or the intermediate component (e.g., the API gateway114) may extract the desired sub token128from the main access token126upon receiving an API access request from the client app106.

FIG.1Eshows an example routine150that may be performed by a first computing system134(e.g., an authorization service108) to generate and distribute multiple limited-scope access tokens (e.g., as indicated by an arrow136) to a second computing system138(e.g., a client app106, an API gateway114, a token lookup service, etc.) in response to receipt of a single consent (e.g., as indicated by an arrow140) from a resource owner142in accordance with some aspects of the present disclosure.

As shown, the routine150may begin at a step152, at which the first computing system (e.g., an authorization service108) may receive a first message (e.g., as indicated by the arrow140) indicating that the resource owner142has authorized a client app106to make application programming interface (API) calls to both (A) a first access-restricted resource controlled by the resource owner, and (B) a second access-restricted resource controlled by the resource owner. For example, in some implementations, such a message may correspond to a communication received by an authorization service108(e.g., an OAuth 2.0 authorization server) in response to the resource owner142selecting a particular element on a UI screen for a single consent process, such as the “allow” UI element102of the UI screen100shown inFIG.1A. The first and second access-restricted resources may, for example, correspond to respective services/APIs113to which API calls can be made using appropriate access tokens110,126,128, as described above.

At a step154of the routine150, in response to receipt of the first message, the first computing system134(e.g., an authorization service108) may generate both (A) a first access token (e.g., the sub token128ashown inFIG.1D) that is configured to authenticate to a first API endpoint to access the first access-restricted resource (e.g., the service113ashown inFIG.1B) but is not configured to authenticate to a second API endpoint to access the second access-restricted resource (e.g., the service113bshown inFIG.1B), and (B) a second access token (e.g., the sub token128bshown inFIG.1D) that is configured to authenticate to the second API endpoint to access the second access-restricted resource (e.g., the service113bshown inFIG.1B) but is not configured to authenticate to the first API endpoint to access the first access-restricted resource (e.g., the service113ashown inFIG.1B). As noted above, in some implementations, the first computing system (e.g., an authorization service108) may additionally embed the first token (e.g., the sub token128ashown inFIG.1D) and the second token (e.g., the sub token128bshown inFIG.1D) within a main access token, such as the main access token126shown in shown inFIG.1D.

Finally, at a step156of the routine150, the first computing system134(e.g., an authorization service108) may send (e.g., as indicated by the arrow136inFIG.1E) the first token (e.g., the sub token128ashown inFIG.1D) and the second token (e.g., the sub token128bshown inFIG.1D) to the second computing system138to enable the second computing system138to use the first token (e.g., the sub token128ashown inFIG.1D) to make a first API call to the first API endpoint to access the first access-restricted resource (e.g., the service113ashown inFIG.1B), and to use the second token (e.g., the sub token128bshown inFIG.1D) to make a second API call to the second API endpoint to access the second access-restricted resource (e.g., the service113bshown inFIG.1B).

In some implementations, the second computing system138may include a client app106that is configured to receive a main access token (e.g., the main access token126shown in shown inFIG.1D) from the first computing system (e.g., an authorization service108), and is further configured to extract the individual sub tokens128from the main access token126, to allow the client app106to use appropriate sub tokens128to make API calls to respective services113.

In other implementations, the second computing system138may include both a client app106to which the first computing system134(e.g., an authorization service108) may send a main access token (e.g., the main access token126shown inFIG.1D) as well as an intermediate component (e.g., an API gateway114) that is configured to receive the main access token126from the client app106, and is further configured to extract the individual sub tokens128from the main access token126, to allow the intermediate component (e.g., an API gateway114) to use appropriate sub tokens128to make API calls to respective services113.

In still other implementations, the second computing system138may comprise a storage medium and a token lookup service that are included within or associated with an intermediate component (e.g., an API gateway114), and first computing system134(e.g., an authorization service108) may send the first and second access tokens it generated at the step154to the token lookup service for storage in the storage medium in association with another token (e.g., a master access token or an opaque token, as described above) that is also sent to the client app106. As noted above, in some such implementations, the first and second access tokens may be embedded within a main access token (e.g., the main access token126shown inFIG.1D) and that main access token may be stored in the storage medium in association with a copy of the other token (e.g., a master access token or an opaque token) that was sent to the client app106. In other implementations, the first and second access tokens may be stored separately in the storage medium in association with a copy of the other token (e.g., a master access token or an opaque token) that was sent to the client app106.

Additional details and example implementations of embodiments of the present disclosure are set forth below in Section E, following a description of example systems and network environments in which such embodiments may be deployed.

B. Network Environment

Referring toFIG.2, an illustrative network environment200is depicted. As shown, the network environment200may include one or more clients202(1)-202(n) (also generally referred to as local machine(s)202or client(s)202) in communication with one or more servers204(1)-204(n) (also generally referred to as remote machine(s)204or server(s)204) via one or more networks206(1)-206(n) (generally referred to as network(s)206). In some embodiments, a client202may communicate with a server204via one or more appliances208(1)-208(n) (generally referred to as appliance(s)208or gateway(s)208). In some embodiments, a client202may have the capacity to function as both a client node seeking access to resources provided by a server204and as a server204providing access to hosted resources for other clients202.

Although the embodiment shown inFIG.2shows one or more networks206between the clients202and the servers204, in other embodiments, the clients202and the servers204may be on the same network206. When multiple networks206are employed, the various networks206may be the same type of network or different types of networks. For example, in some embodiments, the networks206(1) and206(n) may be private networks such as local area network (LANs) or company Intranets, while the network206(2) may be a public network, such as a metropolitan area network (MAN), wide area network (WAN), or the Internet. In other embodiments, one or both of the network206(1) and the network206(n), as well as the network206(2), may be public networks. In yet other embodiments, all three of the network206(1), the network206(2) and the network206(n) may be private networks. The networks206may employ one or more types of physical networks and/or network topologies, such as wired and/or wireless networks, and may employ one or more communication transport protocols, such as transmission control protocol (TCP), internet protocol (IP), user datagram protocol (UDP) or other similar protocols. In some embodiments, the network(s)206may include one or more mobile telephone networks that use various protocols to communicate among mobile devices. In some embodiments, the network(s)206may include one or more wireless local-area networks (WLANs). For short range communications within a WLAN, clients202may communicate using 802.11, Bluetooth, and/or Near Field Communication (NFC).

As shown inFIG.2, one or more appliances208may be located at various points or in various communication paths of the network environment200. For example, the appliance208(1) may be deployed between the network206(1) and the network206(2), and the appliance208(n) may be deployed between the network206(2) and the network206(n). In some embodiments, the appliances208may communicate with one another and work in conjunction to, for example, accelerate network traffic between the clients202and the servers204. In some embodiments, appliances208may act as a gateway between two or more networks. In other embodiments, one or more of the appliances208may instead be implemented in conjunction with or as part of a single one of the clients202or servers204to allow such device to connect directly to one of the networks206. In some embodiments, one of more appliances208may operate as an application delivery controller (ADC) to provide one or more of the clients202with access to business applications and other data deployed in a datacenter, the cloud, or delivered as Software as a Service (SaaS) across a range of client devices, and/or provide other functionality such as load balancing, etc. In some embodiments, one or more of the appliances208may be implemented as network devices sold by Citrix Systems, Inc., of Fort Lauderdale, Fla., such as Citrix Gateway™ or Citrix ADC™.

In some embodiments, a server204may execute a remote presentation services program or other program that uses a thin-client or a remote-display protocol to capture display output generated by an application executing on a server204and transmit the application display output to a client device202.

In yet other embodiments, a server204may execute a virtual machine providing, to a user of a client202, access to a computing environment. The client202may be a virtual machine. The virtual machine may be managed by, for example, a hypervisor, a virtual machine manager (VMM), or any other hardware virtualization technique within the server204.

As shown inFIG.2, in some embodiments, groups of the servers204may operate as one or more server farms210. The servers204of such server farms210may be logically grouped, and may either be geographically co-located (e.g., on premises) or geographically dispersed (e.g., cloud based) from the clients202and/or other servers204. In some embodiments, two or more server farms210may communicate with one another, e.g., via respective appliances208connected to the network206(2), to allow multiple server-based processes to interact with one another.

As also shown inFIG.2, in some embodiments, one or more of the appliances208may include, be replaced by, or be in communication with, one or more additional appliances, such as WAN optimization appliances212(1)-212(n), referred to generally as WAN optimization appliance(s)212. For example, WAN optimization appliances212may accelerate, cache, compress or otherwise optimize or improve performance, operation, flow control, or quality of service of network traffic, such as traffic to and/or from a WAN connection, such as optimizing Wide Area File Services (WAFS), accelerating Server Message Block (SMB) or Common Internet File System (CIFS). In some embodiments, one or more of the appliances212may be a performance enhancing proxy or a WAN optimization controller.

In some embodiments, one or more of the appliances208,212may be implemented as products sold by Citrix Systems, Inc., of Fort Lauderdale, Fla., such as Citrix SD-WAN™ or Citrix Cloud™. For example, in some implementations, one or more of the appliances208,212may be cloud connectors that enable communications to be exchanged between resources within a cloud computing environment and resources outside such an environment, e.g., resources hosted within a data center of+ an organization.

C. Computing Environment

FIG.3illustrates an example of a computing system300that may be used to implement one or more of the respective components (e.g., the clients202, the servers204, the appliances208,212) within the network environment200shown inFIG.2. As shown inFIG.3, the computing system300may include one or more processors302, volatile memory304(e.g., RAM), non-volatile memory306(e.g., one or more hard disk drives (HDDs) or other magnetic or optical storage media, one or more solid state drives (SSDs) such as a flash drive or other solid state storage media, one or more hybrid magnetic and solid state drives, and/or one or more virtual storage volumes, such as a cloud storage, or a combination of such physical storage volumes and virtual storage volumes or arrays thereof), a user interface (UI)308, one or more communications interfaces310, and a communication bus312. The user interface308may include a graphical user interface (GUI)314(e.g., a touchscreen, a display, etc.) and one or more input/output (I/O) devices316(e.g., a mouse, a keyboard, etc.). The non-volatile memory306may store an operating system318, one or more applications320, and data322such that, for example, computer instructions of the operating system318and/or applications320are executed by the processor(s)302out of the volatile memory304. Data may be entered using an input device of the GUI314or received from I/O device(s)316. Various elements of the computing system300may communicate via communication the bus312. The computing system300as shown inFIG.3is shown merely as an example, as the clients202, servers204and/or appliances208and212may be implemented by any computing or processing environment and with any type of machine or set of machines that may have suitable hardware and/or software capable of operating as described herein.

The communications interfaces310may include one or more interfaces to enable the computing system300to access a computer network such as a Local Area Network (LAN), a Wide Area Network (WAN), a Personal Area Network (PAN), or the Internet through a variety of wired and/or wireless connections, including cellular connections.

D. Systems and Methods for Delivering Shared Resources Using a Cloud Computing Environment

Referring toFIG.4, a cloud computing environment400is depicted, which may also be referred to as a cloud environment, cloud computing or cloud network. The cloud computing environment400can provide the delivery of shared computing services and/or resources to multiple users or tenants. For example, the shared resources and services can include, but are not limited to, networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, databases, software, hardware, analytics, and intelligence.

In the cloud computing environment400, one or more clients202(such as those described in connection withFIG.2) are in communication with a cloud network404. The cloud network404may include back-end platforms, e.g., servers, storage, server farms and/or data centers. The clients202may correspond to a single organization/tenant or multiple organizations/tenants. More particularly, in one example implementation, the cloud computing environment400may provide a private cloud serving a single organization (e.g., enterprise cloud). In another example, the cloud computing environment400may provide a community or public cloud serving multiple organizations/tenants.

In some embodiments, a gateway appliance(s) or service may be utilized to provide access to cloud computing resources and virtual sessions. By way of example, Citrix Gateway, provided by Citrix Systems, Inc., may be deployed on-premises or on public clouds to provide users with secure access and single sign-on to virtual, SaaS and web applications. Furthermore, to protect users from web threats, a gateway such as Citrix Secure Web Gateway may be used. Citrix Secure Web Gateway uses a cloud-based service and a local cache to check for URL reputation and category.

In still further embodiments, the cloud computing environment400may provide a hybrid cloud that is a combination of a public cloud and one or more resources located outside such a cloud, such as resources hosted within one or more data centers of an organization. Public clouds may include public servers that are maintained by third parties to the clients202or the enterprise/tenant. The servers may be located off-site in remote geographical locations or otherwise. In some implementations, one or more cloud connectors may be used to facilitate the exchange of communications between one more resources within the cloud computing environment400and one or more resources outside of such an environment.

The cloud computing environment400can provide resource pooling to serve multiple users via clients202through a multi-tenant environment or multi-tenant model with different physical and virtual resources dynamically assigned and reassigned responsive to different demands within the respective environment. The multi-tenant environment can include a system or architecture that can provide a single instance of software, an application or a software application to serve multiple users. In some embodiments, the cloud computing environment400can provide on-demand self-service to unilaterally provision computing capabilities (e.g., server time, network storage) across a network for multiple clients202. By way of example, provisioning services may be provided through a system such as Citrix Provisioning Services (Citrix PVS). Citrix PVS is a software-streaming technology that delivers patches, updates, and other configuration information to multiple virtual desktop endpoints through a shared desktop image. The cloud computing environment400can provide an elasticity to dynamically scale out or scale in response to different demands from one or more clients202. In some embodiments, the cloud computing environment400may include or provide monitoring services to monitor, control and/or generate reports corresponding to the provided shared services and resources.

In some embodiments, the cloud computing environment400may provide cloud-based delivery of different types of cloud computing services, such as Software as a service (SaaS)402, Platform as a Service (PaaS)404, Infrastructure as a Service (IaaS)406, and Desktop as a Service (DaaS)408, for example. IaaS may refer to a user renting the use of infrastructure resources that are needed during a specified time period. IaaS providers may offer storage, networking, servers or virtualization resources from large pools, allowing the users to quickly scale up by accessing more resources as needed. Examples of IaaS platforms include AMAZON WEB SERVICES provided by Amazon.com, Inc., of Seattle, Wash., Azure IaaS provided by Microsoft Corporation or Redmond, Wash., RACKSPACE CLOUD provided by Rackspace US, Inc., of San Antonio, Tex., Google Compute Engine provided by Google Inc. of Mountain View, Calif., and RIGHTSCALE provided by RightScale, Inc., of Santa Barbara, Calif.

PaaS providers may offer functionality provided by IaaS, including, e.g., storage, networking, servers or virtualization, as well as additional resources such as, e.g., the operating system, middleware, or runtime resources. Examples of PaaS include WINDOWS AZURE provided by Microsoft Corporation of Redmond, Wash., Google App Engine provided by Google Inc., and HEROKU provided by Heroku, Inc. of San Francisco, Calif.

SaaS providers may offer the resources that PaaS provides, including storage, networking, servers, virtualization, operating system, middleware, or runtime resources. In some embodiments, SaaS providers may offer additional resources including, e.g., data and application resources. Examples of SaaS include GOOGLE APPS provided by Google Inc., SALESFORCE provided by Salesforce.com Inc. of San Francisco, Calif., or OFFICE 365 provided by Microsoft Corporation. Examples of SaaS may also include data storage providers, e.g. Citrix ShareFile® from Citrix Systems, DROPBOX provided by Dropbox, Inc. of San Francisco, Calif., Microsoft SKYDRIVE provided by Microsoft Corporation, Google Drive provided by Google Inc., or Apple ICLOUD provided by Apple Inc. of Cupertino, Calif.

Similar to SaaS, DaaS (which is also known as hosted desktop services) is a form of virtual desktop infrastructure (VDI) in which virtual desktop sessions are typically delivered as a cloud service along with the apps used on the virtual desktop. Citrix Cloud from Citrix Systems is one example of a DaaS delivery platform. DaaS delivery platforms may be hosted on a public cloud computing infrastructure, such as AZURE CLOUD from Microsoft Corporation of Redmond, Wash., or AMAZON WEB SERVICES provided by Amazon.com, Inc., of Seattle, Wash., for example. In the case of Citrix Cloud, Citrix Workspace app may be used as a single-entry point for bringing apps, files and desktops together (whether on-premises or in the cloud) to deliver a unified experience.

E. Detailed Description of Example Embodiments of the Novel System for Generating Multiple Limited-Scope Access Tokens Introduced in Section A

Section A introduced several example implementations of a system configured to generate multiple limited-scope access tokens (e.g., the sub tokens128described in connection withFIG.1D) in response a single consent provided by a resource owner142(shown in FIG.1E), as well as to allow the limited-scope access tokens that are so generated to be used to make API calls to individual services113on behalf of the resource owner142.

As noted near the end of Section A, in some implementations, the first computing system134(shown inFIG.1E) may correspond to an authorization service108(e.g., an OAuth 2.0 authorization server) to which the resource owner142provides a single consent authorizing a client app106to access to a plurality of resources controlled by the resource owner142(e.g., via the single consent UI100shown inFIG.1A), and the second computing system138(also shown inFIG.1E) may correspond to the client app106for which such consent has been provided.FIG.5shows an example implementation of such a configuration.

As shown inFIG.5, after the client app106has authenticated to the authorization service108(e.g., as indicated by an arrow502), the authorization service108may generate a main access token126(which may include multiple embedded sub tokens128, as described above) and may return that main access token126to the client app106(e.g., as indicated by an arrow504). An example routine600that may be employed by the authorization service108to generate the main access token126is described below in connection withFIG.6. Although not illustrated inFIG.5, in some implementations, the authorization service may be configured to send the main access token126to the client app106(per the arrow504) only if the client app106first presents a suitable credential (referred to in the OAuth 2.0 specification as an “authorization grant”) to the authorization service108to prove that the resource owner142has consented to the client app106accessing the resources113corresponding to the sub tokens128(e.g., using a single consent process, as described above). As described in Section 1.3 of RFC 6749, incorporated by reference above, such an authorization grant may take on any of a number of forms and may be obtained in any of numerous ways.

After the client app106receives the main access token126(per the arrow504inFIG.5), the client app106may determine a service113it seeks to access, and may extract the sub token128corresponding to that service from the main access token126. The client app106may then use the extracted sub token128to make an API call to the desired service113. For example, as indicated by an arrow506inFIG.5, the client app106may extract the sub token128a(shown inFIG.1D) from the main access token126, and may use that sub token to make an API call to the service113a. An example routine800that may be employed by the client app106to extract and use a sub token128in such fashion is described below in connection withFIG.8.

In implementations in which the main access token126further includes claims132(shown inFIG.1D) that allow the main access token126to be used as a master access token (e.g., such as the master access token110described in connection withFIGS.1B and1C), the client app106may instead use the main access token126to make API calls to one or more of the services113, rather than extracting and using individual sub tokens128. In such a case, the services113may ignore the custom claims130for the sub tokens, and may instead rely only on the claims132to allow access by the client app106. As noted above, such a feature may allow client apps106that are not configured to extract sub tokens128from a main access token126to nonetheless use the main access token126to access the various services113for which access authorization consent was received from the resource owner142, thus allowing the main access tokens126to be backwards compatible with existing client apps106.

As noted above,FIG.6shows an example routine600that may be employed by the authorization service108to generate a main access token126that includes custom claims130corresponding to multiple different limited-scope sub tokens128. As shown, the routine600may begin at a step602, at which the authorization service108may generate an unsigned main access token126that includes claims132for all of the scopes requested by the client app106. In some implementations, if the main access token126generated at the step602were signed in its current form, it would resemble the master access token110described above in connection withFIGS.1B and1C.

At a step604of the routine600, the authorization service108may identify all of the scopes specified by the claims132of the unsigned main access token126generated at the step602. Pursuant to a step606and decisions608and614of the routine600, the authorization service108may iterate through all of the scopes identified at the step604and determine (at the decision608) whether an unsigned sub token128has already been generated for the service113(e.g., an API endpoint) corresponding to the scope under consideration. Although the routine600illustrates the processing of the scopes identified at the step604as being performed sequentially, it should be appreciated that such processing may instead be performed wholly or partially in parallel.

When, at the decision608, the authorization service108determines that an unsigned sub token128has not yet been generated for the service (e.g., an API endpoint) corresponding to the scope selected at the step606, the routine600may proceed to a step610, at which the authorization service108may generate a new unsigned sub token128that includes claims for the scope. When, on the other hand, the authorization service108determines (at the decision608) that an unsigned sub token128has already been generated for the service (e.g., an API endpoint) corresponding to the scope, the authorization service108may instead add claims for the scope to the existing unsigned sub token128for that service.

When, at the decision614, the authorization service108determines that all of the scopes identified at the step604have been evaluated, the routine600may proceed to a step616, at which the authorization service108may identify all of the unsigned sub tokens128that were generated at the step610and/or supplemented with additional claims per the step612. Pursuant to a step618and a decision624of the routine600, the authorization service108may iterate through all of the unsigned sub tokens128that were identified at the step616and, for each such sub token128, may (per a step620) sign the sub token128, and (per a step622) embed the signed sub token128, as a custom claim130, into the unsigned main access token126that was generated at the step602. An example process for signing the respective sub tokens128is described below in connection withFIG.7A. Although the routine600illustrates the processing of the sub tokens128identified at the step616as being performed sequentially, it should be appreciated that such processing may instead be performed wholly or partially in parallel.

When, at the decision624, the authorization service108determines that all of the sub tokens128identified at the step616have been signed and embedded, as custom claims130, into the unsigned main access token126, the routine600may proceed to a step626, at which the authorization service108may sign the fully-configured main access token126. An example process for signing the main access token126is described below in connection withFIG.7B.

Finally, at a step628of the routine600, the authorization service108may send the signed main access token126to a recipient computing system138(shown inFIG.1E) for use in allowing the client app106to access the various resources113(e.g., API endpoints) for which the resource owner142provided consent. As noted above, in the implementation shown inFIG.5, that recipient computing system138may include the client app106. As explained in more detail below in connection withFIGS.11and12, in other implementations, the recipient computing system138may additionally or alternatively include a token lookup service included within or associated with an intermediate component (e.g., an API gateway114).

FIG.7Ashows elements of an example sub token128that has been signed per the step620of the routine600. As illustrated, the sub token128may include a header702, a payload704, and a signature706. The sub token128may, for example, be configured as a JSON Web Token (JWT). As illustrated, in some implementations, the payload704may include claims defining the scope(s) for a single service113(or subset of services113). Further, in some implementations, the header702may specify a signing technique that the authorization service108used to generate the signature706based on the content of the header702and/or the payload704. In some implementations, for example, the specified signing technique may involve (A) combining the base64url encoded header702and the base64url encoded payload704, (B) hashing the combined base64url value with a hashing technique, e.g., SHA256, and (C) encrypting the determined hash using a private key.

In some implementations, a public key corresponding to the private key used to generate the signature706may be stored at or otherwise accessible to the service113(e.g., API endpoint) for which the sub token128is configured. As such, when the sub token128is received by that service113, the service may validate the signature706using the public key and the specified signing technique, thus enabling the service113to confirm the sub token128has not been tampered with.

FIG.7Bshows elements of an example main access token126that has been signed per the step626of the routine600. As illustrated, similar to the sub token128shown inFIG.7A, the main access token126shown inFIG.7Bmay include a header708, a payload710, and a signature712. Like the sub token128shown inFIG.7A, the main access token126shown inFIG.7B, may, for example, be configured as a JSON Web Token (JWT). As illustrated, in some implementations, the payload710of the main access token126may include both (1) claims132defining the scope(s) for multiple services, thus allowing the main access token126to be used to access any of those services, and (2) custom claims130defining the respective embedded sub tokens128. Further, in some implementations, the header708may specify a signing technique that the authorization service108used to generate the signature712based on the content of the header708and/or the payload710. In some implementations, for example, the specified signing technique may involve (A) combining the base64url encoded header708and the base64url encoded payload710, (B) hashing the combined base64url value with a hashing technique, e.g., SHA256, and (C) encrypting the determined hash using a private key.

Similar to the signature validation technique described above for the sub tokens128, a public key corresponding to the private key used to generate the signature712for the main access token126may be stored at or otherwise accessible to the various services113(e.g., API endpoints) specified by the claims132. As such, when the main access token126is received by any one of those services113, that service113may validate the signature712using the public key and the specified signing technique, thus enabling the service113to confirm the main access token126has not been tampered with.

FIG.8shows an example routine800that may be employed by the client app106to extract an appropriate sub token128from the main access token126and to use that extracted sub token to call a service113(e.g., an API endpoint). As shown, the routine800may begin at a step802, at which the client app106may determine a service113that is to be called. The step802may, for instance, correspond to the client app106determining a need to access to a remote service113to enable the performance of some business logic.

At a step804of the routine800, the client app106may identify the main access token126that it previously received from the authorization service108(e.g., per the arrow504inFIG.5) for the service113identified at the step802. In some implementations, this may be done by evaluating the claims132of the various main access tokens126the client app106possesses, and identifying the main access token126that includes the appropriate scope(s) for the service identified at the step802.

As illustrated inFIG.8, in some implementations, the routine800may involve a decision806, at which the client app106may determine whether a limited-scope sub token128, rather than the main access token126, is to be used to call the service113identified at the step802. For client apps106that are configured to perform the sub-token extraction process described further below, the decision806may involve a determination as to whether such extraction functionality is currently enabled for the main access token126identified at the step804. In such implementations, when (at the decision806), the client app106determines that sub-token extraction functionality is not currently enabled for the identified main access token126, the routine800may proceed to a step808, at which the client app106may use the main access token126identified at the step804, rather than a sub token128, to call the service identified at the step802. When, on the other hand, the client app106determines (at the decision806) that sub-token extraction functionality is currently enabled for the identified main access token126, the routine800may instead proceed to a step810at which the custom claim130, within the main access token126, for the service113identified at the step802may be identified. In some implementations, this may be accomplished by evaluating the custom claims130of the main access token126identified at the step804, and identifying the custom claim130that includes the appropriate scope(s) for the service identified at the step802.

At a step812of the routine800, the client app106may extract the sub token128from the custom claim130identified at the step810. In some implementations, such an extraction process may yield a sub token128having a configuration such as that shown inFIG.7A, e.g., a JWT.

At a step814of the routine800, the client app106may use the limited-scope sub token128, e.g., a JWT, extracted from the main access token126per the step812, to make an API call to service113(e.g., an API endpoint) identified at the step802.

For client apps106that are not configured to extract a sub token128from the custom claims130of a main access token126, the decision806may be omitted, and the routine800may instead simply proceed directly from the step804to the step808.

As additionally noted near the end of Section A, in some implementations, the first computing system134(shown inFIG.1E) may correspond to an authorization service108(e.g., an OAuth 2.0 authorization server) to which the resource owner142provides a single consent authorizing a client app106to access to a plurality of resources controlled by the resource owner142(e.g., via the single consent UI100shown inFIG.1A), and the second computing system138(also shown inFIG.1E) may correspond to an intermediate component (e.g., an API gateway114). In this configuration, the intermediate component (e.g., an API gateway114), rather than the client app106, may be responsible for extracting an appropriate sub token128from a main access token126for use in calling a desired service113(e.g., an API endpoint).FIG.9shows an example implementation of such a configuration.

As shown inFIG.9, after the client app106has authenticated to the authorization service108(e.g., as indicated by an arrow902), the authorization service108may generate a main access token126(which may include multiple embedded sub tokens128, as described above) and may return that main access token126to the client app106(e.g., as indicated by an arrow904). In some implementations, the example routine600described above in connection withFIG.6may be employed by the authorization service108to generate the main access token126. Although not illustrated inFIG.9, in some implementations, the authorization service may be configured to send the main access token126to the client app106(per the arrow904) only if the client app106first presents a suitable credential (referred to in the OAuth 2.0 specification as an “authorization grant”) to the authorization service108to prove that the resource owner142has consented to the client app106accessing the resources113corresponding to the sub tokens128(e.g., using a single consent process, as described above). As described in Section 1.3 of RFC 6749, incorporated by reference above, such an authorization grant may take on any of a number of forms and may be obtained in any of numerous ways.

In the configuration shown inFIG.9, rather than calling a service113(e.g., an API endpoint) directly, the client app106may make include the main access token126in an API call made to an API gateway114that serves as a proxy for the API endpoint of the service113. The API gateway114may be configured to extract an appropriate sub token128from the received main access token126, and may be further configured to include that extracted sub token128in the API call it forwards to the API endpoint of the service113.

FIG.10shows an example routine1000that may be performed by the API gateway114shown inFIG.9to extract an appropriate sub token128from a received main access token126, and to use that extracted sub token128to call a service113on behalf of the client app106. As shown, the routine1000may begin at a step1002, at which the API gateway114may receive an API call that includes a main access token126from a client app106.

As illustrated inFIG.10, in some implementations, the routine1000may involve a decision1004, at which the API gateway114may determine whether a limited-scope sub token128, rather than the main access token126, is to be used to call a service113. For API gateways114that are configured to perform the sub-token extraction process described further below, the decision1004may involve a determination as to whether such extraction functionality is currently enabled for the main access token126included in the received API call. In such implementations, when (at the decision1004), the API gateway114determines that sub-token extraction functionality is not currently enabled for the received main access token126, the routine1000may proceed to a step1006, at which the API gateway114may use the received main access token126, rather than a sub token128, to call the service113. When, on the other hand, the API gateway114determines (at the decision1004) that sub-token extraction functionality is currently enabled for the received main access token126, the routine1000may instead proceed to a step1008, at which the API gateway114may determine the service113that is to be called. This determination may be made, for example, based on the content of the API call that was received from the client app106.

At a step1010of the routine1000, the API gateway114may identify the custom claim130, within the main access token126, for the service113identified at the step1008. In some implementations, this may be accomplished by evaluating the custom claims130of the main access token126received from the client app106, and identifying the custom claim130that includes the appropriate scope(s) for the service identified at the step1008.

At a step1012of the routine1000, the API gateway114may extract the sub token128from the custom claim130identified at the step1010. In some implementations, such an extraction process may yield a sub token128having a configuration such as that shown inFIG.7A, e.g., a JWT.

At a step1014of the routine1000, the API gateway114may swap the main access token126received from the client app106with the sub token extracted per the step1012.

At a step1016of the routine1000, the API gateway114may make an API call to service113(e.g., an API endpoint) identified at the step1008using the limited-scope sub token128, e.g., a JWT, that was swapped with the main access token126per the step1014.

For API gateways114that are not configured to extract a sub token128from the custom claims130of a main access token126, the decision1004may be omitted, and the routine1000may instead simply proceed directly from the step1002to the step1006.

As further noted near the end of Section A, in some implementations, the first computing system134(shown inFIG.1E) may correspond to an authorization service108(e.g., an OAuth 2.0 authorization server) to which the resource owner142provides a single consent authorizing a client app106to access to a plurality of resources controlled by the resource owner142(e.g., via the single consent UI100shown inFIG.1A), and the second computing system138(also shown inFIG.1E) may correspond to token lookup service that is associated with or included within an intermediate component (e.g., an API gateway114).FIG.11shows an example of such a configuration, including a token lookup service1102.

As shown inFIG.11, similar to the configurations shown inFIGS.5and9, after the client app106has authenticated to the authorization service108(e.g., as indicated by an arrow1106), the authorization service108may generate a main access token126(which may include multiple embedded sub tokens128, as described above). Rather than sending the main access token126to the client app106, however, the authorization service108may generate an opaque token1104(described above) corresponding to the main access token126, and may send that opaque token1104to the client app106(per an arrow1108). As indicated by an arrow1110inFIG.11, the authorization service108may also send both the main access token126and the corresponding opaque token1104to the token lookup service1102, and the token lookup service1102may store the opaque token1104in association with the main access token126so that the opaque token1104may be used as a key to look up and retrieve the corresponding main access token126from a storage medium of the token lookup service1102. In some implementations, the token lookup service1102may be included within or proximate (e.g., within a common network infrastructure) to the API gateway114.

In some implementations, the example routine600described above in connection withFIG.6may be employed by the authorization service108to generate the main access token126. Although not illustrated inFIG.11, in some implementations, the authorization service108may be configured to send the opaque token1104to the client app106(per the arrow1108) only if the client app106first presents a suitable credential (referred to in the OAuth 2.0 specification as an “authorization grant”) to the authorization service108to prove that the resource owner142has consented to the client app106accessing the resources113corresponding to the sub tokens128(e.g., using a single consent process, as described above). As described in Section 1.3 of RFC 6749, incorporated by reference above, such an authorization grant may take on any of a number of forms and may be obtained in any of numerous ways.

In the configuration shown inFIG.11, similar to the configuration shown inFIG.9, rather than calling a service113(e.g., an API endpoint) directly, the client app106may include the opaque token1104in an API call made to an API gateway114that serves as a proxy for the API endpoint of the service113. In the configuration ofFIG.11, however, the API gateway114may be configured to swap the opaque token1104received from the client app106for an appropriate one of the sub tokens128prior to making an API call to the indicated service113. In implementations in which the sub tokens128are include in a main access token126, the token lookup service1102may first retrieve the main access token126corresponding to the received opaque token1104, and may then extract the appropriate sub token128from the retrieved main access token126.

FIG.12shows an example routine1200that may be performed by the API gateway114shown inFIG.11to use an opaque token1104received from a client app106to obtain an appropriate sub token128, and to use that sub token128to call a service113on behalf of the client app106. As shown, the routine1200may begin at a step1202, at which the API gateway114may receive an API call that includes an opaque token1104from a client app106.

At a step1204of the routine1200, the API gateway114may obtain the main access token126that corresponds to the received opaque token1104. In some implementations, for example, the API gateway114may provide the received opaque token1104to the token lookup service1102, and the token lookup service1102may retrieve and return the main access token126keyed by the opaque token1104to the API gateway114.

As illustrated inFIG.12, in some implementations, the routine1200may involve a decision1206, at which the API gateway114may determine whether a limited-scope sub token128, rather than the main access token126, is to be used to call a service113. For API gateways114that are configured to perform the sub-token extraction process described further below, the decision1206may involve a determination as to whether such extraction functionality is currently enabled for the main access token126obtained from the token lookup service1102. In such implementations, when (at the decision1206), the API gateway114determines that sub-token extraction functionality is not currently enabled for the retrieved main access token126, the routine1200may proceed to steps1208and1210, at which the API gateway114may swap the main access token126for the opaque token1104in the received API call (per the step1208), and use the main access token126, rather than a sub token128, to call the service113(per step1210). When, on the other hand, the API gateway114determines (at the decision1206) that sub-token extraction functionality is currently enabled for the retrieved main access token126, the routine1200may instead proceed to a step1212, at which the API gateway114may determine the service113that is to be called. This determination may be made, for example, based on the content of the API call received from the client app106.

At a step1214of the routine1200, the API gateway114may identify the custom claim130, within the main access token126, for the service113identified at the step1212. In some implementations, this may be accomplished by evaluating the custom claims130of the main access token126received from the token lookup service1102, and identifying the custom claim130that includes the appropriate scope(s) for the service identified at the step1212.

At a step1216of the routine1200, the API gateway114may extract the sub token128from the custom claim130identified at the step1214. In some implementations, such an extraction process may yield a sub token128having a configuration such as that shown inFIG.7A, e.g., a JWT.

At a step1218of the routine1200, the API gateway114may swap the opaque token1104received from the client app106with the sub token128extracted per the step1216.

At a step1220of the routine1200, the API gateway114may make an API call to service113(e.g., an API endpoint) identified at the step1212using the limited-scope sub token128, e.g., a JWT, that was swapped with the opaque token1104per the step1218.

For API gateways114that are not configured to extract a sub token128from the custom claims130of a main access token126, the decision1206may be omitted, and the routine1200may instead simply proceed directly from the step1204to the step1208.

F. Example Implementations of Methods, Systems, and Computer-Readable Media in Accordance with the Present Disclosure

The following paragraphs (M1) through (M12) describe examples of methods that may be implemented in accordance with the present disclosure.

(M1) A method may involve receiving, by a first computing system, a first message indicating that a resource owner has authorized a client application to make application programming interface (API) calls to both (A) a first access-restricted resource controlled by the resource owner, and (B) a second access-restricted resource controlled by the resource owner; in response to the first message, generating, by the first computing system, both (A) a first token that is configured to authenticate to a first API endpoint to access the first access-restricted resource but is not configured to authenticate to a second API endpoint to access the second access-restricted resource, and (B) a second token that is configured to authenticate to the second API endpoint to access the second access-restricted resource but is not configured to authenticate to the first API endpoint to access the first access-restricted resource; and sending, from the first computing system to a second computing system, the first token and the second token to enable the second computing system to use the first token to make a first API call to the first API endpoint to access the first access-restricted resource, and to use the second token to make a second API call to the second API endpoint to access the second access-restricted resource.

(M2) A method may be performed as described in paragraph (M1), and may further involve embedding, by the first computing system, the first token and the second token into a main token; and sending, from the first computing system to the second computing system, the main token.

(M3) A method may be performed as described in paragraph (M2), and may further involve receiving, by the second computing system, the main token; extracting, by the second computing system, first data representing the first token from the main token to obtain a copy of the first token; and using, by the second computing system, the copy of the first token to make the first API call to the first API endpoint.

(M4) A method may be performed as described in paragraph (M2) or paragraph (M3), and may further involve configuring, by the first computing system, the main token to further enable the second computing system to use the main token to both (A) to authenticate to the first API endpoint to access the first access-restricted resource, and (B) to authenticate to the second API endpoint to access the second access-restricted resource.

(M5) A method may be performed as described in paragraph (M4), and may further involve generating the first token comprises adding a first signature to the first token that is based at least in part on content of the first token; generating the second token comprises adding a second signature to the second token that is based at least in part on content of the second token; and configuring the main token comprises adding a third signature to the main token that is based at least in part on the first signature and the second signature.

(M6) A method may be performed as described in paragraph (M2), wherein the second computing system may comprise the client application; and sending the main token to the second computing system may further involve sending the main token to the client application.

(M7) A method may be performed as described in paragraph (M6), and may further involve receiving, by the client application, the main token; extracting, by the client application, first data representing the first token from the main token to obtain a copy of the first token that is used to make the first API call; and using, by the client application, the copy of the first token to make the first API call to the first API endpoint.

(M8) A method may be performed as described in paragraph (M6), wherein the second computing system may further comprise an API gateway, and the method may further involve receiving, by the API gateway and from the client application, the main token; extracting, by the API gateway, first data representing the first token from the main token to obtain a copy of the first token that is used to make the first API call; and using, by the API gateway, the copy of the first token to make the first API call to the first API endpoint.

(M9) A method may be performed as described in paragraph (M1), wherein the second computing system may comprise an API gateway, a token lookup service, and a storage medium accessible to the token lookup service, and the method may further involve storing, in the storage medium, first data representing the first token and second data representing the second token; receiving, by the API gateway and from the client application, a request to make the first API call to the first API endpoint; in response to the request, retrieving, by the token lookup service, the first data from the storage medium to obtain a copy of the first token that is used to make the first API call to the first API endpoint; and using, by the API gateway, the copy of the first token to make the first API call to the first API endpoint.

(M10) A method may be performed as described in paragraph (M9), wherein storing the first data and the second data in the storage medium may further involve embedding the first data representing the first token and the second data representing the second token into a main token, and storing a copy of the main token in the storage medium; retrieving the first data from the storage medium may further involve retrieving the copy of the main token from the storage medium on a first occasion, and extracting the first data representing the first token from the copy of the main token of the first occasion; and retrieving the second data from the storage medium may further involve retrieving the copy of the main token from the storage medium on a second occasion, and extracting the first token from the main token on the second occasion.

(M11) A method may be performed as described in paragraph (M10), wherein the first computing system may further comprise an authorization service configured to generate the main token, and the method may further involve sending, from the authorization service to the client application, an opaque token corresponding to the main token; determining, by the API gateway and based at least in part on receipt of the opaque token from the client application on the first occasion, that the client application has requested that the first API call be made to the first access-restricted resource; and determining, by the API gateway and based at least in part on receipt of the opaque token from the client application on the second occasion, that the client application has requested that the second API call be made to the second access-restricted resource.

(M12) A method may be performed as described in paragraph (M10), wherein the first computing system may further comprise an authorization service configured to generate the first token and the second token, and the method may further involve sending, from the authorization service to the client application, an opaque token corresponding to each of the first token and the second token; determining, by the API gateway and based at least in part on receipt of the opaque token from the client application on a first occasion, that the client application has requested that the first API call be made to the first access-restricted resource; and determining, by the API gateway and based at least in part on receipt of the opaque token from the client application on a second occasion, that the client application has requested that the second API call be made to the second access-restricted resource.

The following paragraphs (S1) through (S12) describe examples of systems and devices that may be implemented in accordance with the present disclosure.

(S1) A system may comprise a first computing system including at least one first processor and at least one first computer-readable medium encoded with instructions which, when executed by the at least one first processor, cause the first computing system to receive a first message indicating that a resource owner has authorized a client application to make application programming interface (API) calls to both (A) a first access-restricted resource controlled by the resource owner, and (B) a second access-restricted resource controlled by the resource owner, to generate, in response to the first message, both (A) a first token that is configured to authenticate to a first API endpoint to access the first access-restricted resource but is not configured to authenticate to a second API endpoint to access the second access-restricted resource, and (B) a second token that is configured to authenticate to the second API endpoint to access the second access-restricted resource but is not configured to authenticate to the first API endpoint to access the first access-restricted resource, and to send, to a second computing system, the first token and the second token to enable the second computing system to use the first token to make a first API call to the first API endpoint to access the first access-restricted resource, and to use the second token to make a second API call to the second API endpoint to access the second access-restricted resource.

(S2) A system may be configured as described in paragraph (S1), and the at least one first computer-readable medium may be further encoded with additional instructions which, when executed by the at least one first processor, further cause the first computing system to embed the first token and the second token into a main token, and to send, to the second computing system, the main token.

(S3) A system may be configured as described in paragraph (S2), and may further include at least one second processor, and at least one second computer-readable medium encoded with instructions which, when executed by the at least one second processor, cause the second computing system to receive the main token, to extract first data representing the first token from the main token to obtain a copy of the first token, and to use the copy of the first token to make the first API call to the first API endpoint.

(S4) A system may be configured as described in paragraph (S2) or paragraph (S3), and the at least one first computer-readable medium may be further encoded with additional instructions which, when executed by the at least one first processor, further cause the first computing system to configure the main token to further enable the second computing system to use the main token to both (A) to authenticate to the first API endpoint to access the first access-restricted resource, and (B) to authenticate to the second API endpoint to access the second access-restricted resource.

(S5) A system may be configured as described in paragraph (S4), and the at least one first computer-readable medium may be further encoded with additional instructions which, when executed by the at least one first processor, further cause the first computing system add a first signature to the first token that is based at least in part on content of the first token, to add a second signature to the second token that is based at least in part on content of the second token, and to add a third signature to the main token that is based at least in part on the first signature and the second signature.

(S6) A system may be configured as described in paragraph (S2), wherein the second computing system may comprise the client application; and the at least one first computer-readable medium may be further encoded with additional instructions which, when executed by the at least one first processor, further cause the first computing system to send the main token to the client application.

(S7) A system may be configured as described in paragraph (S6), wherein the client application may be configured to receive the main token, to extract first data representing the first token from the main token to obtain a copy of the first token that is used to make the first API call, and to use the copy of the first token to make the first API call to the first API endpoint.

(S8) A system may be configured as described in paragraph (S6), wherein the second computing system may further include an API gateway, and the system may further include at least one second processor, and at least one second computer-readable medium encoded with instructions which, when executed by the at least one second processor, cause the second computing system to receive, by the API gateway and from the client application, the main token, to extract, by the API gateway, first data representing the first token from the main token to obtain a copy of the first token that is used to make the first API call, and to use, by the API gateway, the copy of the first token to make the first API call to the first API endpoint.

(S9) A system may be configured as described in paragraph (S1), wherein the second computing system may comprise an API gateway, a token lookup service, and a storage medium accessible to the token lookup service, and the system may further include at least one second processor, and at least one second computer-readable medium encoded with instructions which, when executed by the at least one second processor, cause the second computing system to store, in the storage medium, first data representing the first token and second data representing the second token, to receive, by the API gateway and from the client application, a request to make the first API call to the first API endpoint, to retrieve, by the token lookup service and in response to the request, the first data from the storage medium to obtain a copy of the first token that is used to make the first API call to the first API endpoint, and to use, by the API gateway, the copy of the first token to make the first API call to the first API endpoint.

(S10) A system may be configured as described in paragraph (S9), and the at least one second computer-readable medium may be further encoded with additional instructions which, when executed by the at least one second processor, further cause the second computing system to store the first data and the second data in the storage medium at least in part by embedding the first data representing the first token and the second data representing the second token into a main token, and storing a copy of the main token in the storage medium, to retrieve the first data from the storage medium at least in part by retrieving the copy of the main token from the storage medium on a first occasion, and extracting the first data representing the first token from the copy of the main token of the first occasion, and to retrieve the second data from the storage medium at least in part by retrieving the copy of the main token from the storage medium on a second occasion, and extracting the first token from the main token on the second occasion.

(S11) A system may be configured as described in paragraph (S10), wherein the first computing system may further comprise an authorization service configured to generate the main token, the at least one first computer-readable medium may be further encoded with additional instructions which, when executed by the at least one first processor, further cause the first computing system to send, from the authorization service to the client application, an opaque token corresponding to the main token, and the at least one second computer-readable medium may be further encoded with additional instructions which, when executed by the at least one second processor, further cause the second computing system to determine, by the API gateway and based at least in part on receipt of the opaque token from the client application on the first occasion, that the client application has requested that the first API call be made to the first access-restricted resource, and to determine, by the API gateway and based at least in part on receipt of the opaque token from the client application on the second occasion, that the client application has requested that the second API call be made to the second access-restricted resource.

(S12) A system may be configured as described in paragraph (S10), wherein the first computing system may further comprise an authorization service configured to generate the first token and the second token, the at least one first computer-readable medium may be further encoded with additional instructions which, when executed by the at least one first processor, further cause the first computing system to send, from the authorization service to the client application, an opaque token corresponding to each of the first token and the second token, and the at least one second computer-readable medium may be further encoded with additional instructions which, when executed by the at least one second processor, further cause the second computing system to determine, by the API gateway and based at least in part on receipt of the opaque token from the client application on a first occasion, that the client application has requested that the first API call be made to the first access-restricted resource, and to determine, by the API gateway and based at least in part on receipt of the opaque token from the client application on a second occasion, that the client application has requested that the second API call be made to the second access-restricted resource.

The following paragraphs (CRM1) through (CRM12) describe examples of computer-readable media that may be implemented in accordance with the present disclosure.

(CRM1) At least one non-transitory computer readable medium may include at least one first computer-readable medium that may be encoded with instructions which, when executed by at least one first processor of a first computing system, cause the first computing system to receive a first message indicating that a resource owner has authorized a client application to make application programming interface (API) calls to both (A) a first access-restricted resource controlled by the resource owner, and (B) a second access-restricted resource controlled by the resource owner, to generate, in response to the first message, both (A) a first token that is configured to authenticate to a first API endpoint to access the first access-restricted resource but is not configured to authenticate to a second API endpoint to access the second access-restricted resource, and (B) a second token that is configured to authenticate to the second API endpoint to access the second access-restricted resource but is not configured to authenticate to the first API endpoint to access the first access-restricted resource, and to send, to a second computing system, the first token and the second token to enable the second computing system to use the first token to make a first API call to the first API endpoint to access the first access-restricted resource, and to use the second token to make a second API call to the second API endpoint to access the second access-restricted resource.

(CRM2) At least one non-transitory computer readable medium may be configured as described in paragraph (CRM1), and the at least one first computer-readable medium may be further encoded with additional instructions which, when executed by the at least one first processor, further cause the first computing system to embed the first token and the second token into a main token, and to send, to the second computing system, the main token.

(CRM3) At least one non-transitory computer readable medium may be configured as described in paragraph (CRM2), and may further include at least one second computer-readable medium encoded with instructions which, when executed by at least one second processor of the second computing system, cause the second computing system to receive the main token, to extract first data representing the first token from the main token to obtain a copy of the first token, and to use the copy of the first token to make the first API call to the first API endpoint.

(CRM4) At least one non-transitory computer readable medium may be configured as described in paragraph (CRM2) or paragraph (CRM3), and the at least one first computer-readable medium may be further encoded with additional instructions which, when executed by the at least one first processor, further cause the first computing system to configure the main token to further enable the second computing system to use the main token to both (A) to authenticate to the first API endpoint to access the first access-restricted resource, and (B) to authenticate to the second API endpoint to access the second access-restricted resource.

(CRM5) At least one non-transitory computer readable medium may be configured as described in paragraph (CRM4), and the at least one first computer-readable medium may be further encoded with additional instructions which, when executed by the at least one first processor, further cause the first computing system add a first signature to the first token that is based at least in part on content of the first token, to add a second signature to the second token that is based at least in part on content of the second token, and to add a third signature to the main token that is based at least in part on the first signature and the second signature.

(CRM6) At least one non-transitory computer readable medium may be configured as described in paragraph (CRM2), wherein the at least one first computer-readable medium may be further encoded with additional instructions which, when executed by the at least one first processor, further cause the first computing system to send the main token to the client application.

(CRM7) At least one non-transitory computer readable medium may be configured as described in paragraph (CRM6), and may further include at least one second computer-readable medium encoded with instructions which, when executed by at least one second processor of the second computing system, cause the client application to receive the main token, to extract first data representing the first token from the main token to obtain a copy of the first token that is used to make the first API call, and to use the copy of the first token to make the first API call to the first API endpoint.

(CRM8) At least one non-transitory computer readable medium may be configured as described in paragraph (CRM6), and may further include at least one second computer-readable medium encoded with instructions which, when executed by at least one second processor of the second computing system, cause the second computing system to receive, by an API gateway and from the client application, the main token, to extract, by the API gateway, first data representing the first token from the main token to obtain a copy of the first token that is used to make the first API call, and to use, by the API gateway, the copy of the first token to make the first API call to the first API endpoint.

(CRM9) At least one non-transitory computer readable medium may be configured as described in paragraph (CRM1), and may further include at least one second computer-readable medium encoded with instructions which, when executed by at least one second processor of the second computing system, cause the second computing system to store, in a storage medium, first data representing the first token and second data representing the second token, to receive, by an API gateway and from the client application, a request to make the first API call to the first API endpoint, to retrieve, by a token lookup service and in response to the request, the first data from the storage medium to obtain a copy of the first token that is used to make the first API call to the first API endpoint, and to use, by the API gateway, the copy of the first token to make the first API call to the first API endpoint.

(CRM10) At least one non-transitory computer readable medium may be configured as described in paragraph (CRM9), and the at least one second computer-readable medium may be further encoded with additional instructions which, when executed by the at least one second processor, further cause the second computing system to store the first data and the second data in the storage medium at least in part by embedding the first data representing the first token and the second data representing the second token into a main token, and storing a copy of the main token in the storage medium, to retrieve the first data from the storage medium at least in part by retrieving the copy of the main token from the storage medium on a first occasion, and extracting the first data representing the first token from the copy of the main token of the first occasion, and to retrieve the second data from the storage medium at least in part by retrieving the copy of the main token from the storage medium on a second occasion, and extracting the first token from the main token on the second occasion.

(CRM11) At least one non-transitory computer readable medium may be configured as described in paragraph (CRM10), wherein at least one first computer-readable medium may be further encoded with additional instructions which, when executed by the at least one first processor, further cause the first computing system to send, from an authorization service to the client application, an opaque token corresponding to the main token, and the at least one second computer-readable medium may be further encoded with additional instructions which, when executed by the at least one second processor, further cause the second computing system to determine, by the API gateway and based at least in part on receipt of the opaque token from the client application on the first occasion, that the client application has requested that the first API call be made to the first access-restricted resource, and to determine, by the API gateway and based at least in part on receipt of the opaque token from the client application on the second occasion, that the client application has requested that the second API call be made to the second access-restricted resource.

(CRM12) At least one non-transitory computer readable medium may be configured as described in paragraph (CRM10), wherein the at least one first computer-readable medium may be further encoded with additional instructions which, when executed by the at least one first processor, further cause the first computing system to send, from an authorization service to the client application, an opaque token corresponding to each of the first token and the second token, and the at least one second computer-readable medium may be further encoded with additional instructions which, when executed by the at least one second processor, further cause the second computing system to determine, by the API gateway and based at least in part on receipt of the opaque token from the client application on a first occasion, that the client application has requested that the first API call be made to the first access-restricted resource, and to determine, by the API gateway and based at least in part on receipt of the opaque token from the client application on a second occasion, that the client application has requested that the second API call be made to the second access-restricted resource.