Patent Application
20180375791
Technical Field
This disclosure relates generally to computer systems that authorize access to resources stored on a resource server.
Description of the Related Art
Resource servers may provide various resources and functionality to an end user. For example, a resource server that stores contact information may provide an end user the ability to access various contacts stored by the resource server or to perform various types of operations provided by the resource server, such as sending messages to contacts. The resource server may protect access to the user's resources, for example by verifying the user's credentials or otherwise authenticating the user's identity prior to providing access to such resources. In some cases, a third-party application may be permitted to utilize one or more resources provided by a resource server. For example, a third-party streaming audio application may allow an end user to share playlists with the end user's contacts stored by the resource server. One standard that facilitates such third-party access is the OAuth 2.0 authorization framework.
Techniques are disclosed relating to authorizing varying levels of access to resources of a resource server. In various embodiments, an authorization server may receive information indicative of a grant of access privileges by a user to an application server. For example, in some embodiments, the grant of access privileges may authorize the application server to access resources of the user that are managed by a resource server. The authorization server may provision a plurality of access tokens corresponding to the grant of access privileges to the application server. Further, the authorization server may store authorization information associated with the grant of access privileges. In some embodiments, the authorization information may include, for each of the plurality of access tokens, a particular scope of access to the resources of the user managed by the resource server and a corresponding duration based on the particular scope of access.
The authorization server may, in various embodiments, receive from the resource server an authorization request that corresponds to an access request by the application server to access one or more resources of the user managed by the resource server. In some embodiments, the authorization request may include one or more access tokens. In various embodiments, the authorization server may determine, based on the authorization information, whether to authorize the authorization request. In some embodiments, the determining may include comparing the received one or more access tokens to the plurality of access tokens provisioned by the application server. Further, in response to detecting that the received one or more access tokens match a provisioned access token, the authorization server may determine whether a type of the access request is permitted by the particular scope of the provisioned access token. The authorization server may determine, based on the corresponding duration of the provisioned access token, whether the received one or more access tokens have expired for the type of the access request. Further, the authorization server may send an authorization indication to the resource server.
This disclosure describes, with reference to
Referring now to
In various embodiments, authorization server 108 may be configured to provide an application 105 hosted by application server 104 with varying levels of access to one or more resources 107 of resource server 106. The term “resource” is intended to be in interpreted broadly to refer to something that may be provided by a computer to a user—for example, a requested item of data, a result of a function or service, computer code, personal information of the user (e.g., login credentials), etc. In the depicted embodiment, resource server 106 may manage various resources 107 for user 102. In some embodiments, resource server 106 may be an API server operable to service API requests for resources 107 from various applications 105 executing on various application servers 104. For example, in some embodiments, resource server 106 may be a server of a social media service, such as FACEBOOK™, which may provide various resources to user 102, such as storing information (e.g., contact lists, photos, personal information, etc.) for user 102 and providing user 102 with various application functionalities (e.g., messaging, photo sharing, personalized information feed, etc.).
In various embodiments, it may be desired for an application 105 hosted by application server 104 to incorporate one or more resources 107 of the resource server 106 into its own functionality. For example, in one embodiment, application 105 may be a streaming audio provider, such as SPOTIFY™. As part of its functionality, SPOTIFY™ may incorporate various resources provided, for example, by FACEBOOK™. For example, SPOTIFY™ may allow user 102 to share playlists with user 102's FACEBOOK™ friends and suggest local bands based on user 102's personal information associated with her FACEBOOK™ account. To provide these features, however, application server 104 may require access to user 102's resources that are managed on a FACEBOOK™ resource server, such as resource server 106, for example.
Application 105 may access user 102's resources 107 managed by resource server 106 according to various techniques. For example, user 102 may simply provide application 105 with the credentials to access resources 107 on resource server 106. This approach, however, presents various drawbacks. For example, by providing these credentials, user 102 is granting application 105 wide-ranging access to her resources 107, which may allow application 105 to perform actions beyond those agreed to or anticipated by user 102. Further, use of such an approach may leave the user 102's credentials vulnerable to unauthorized detection, for example due to a compromise in the security of application server 104.
Alternatively, resource server 106 may implement an authorization framework, such as OAuth 2.0, to provide application 105 with more limited access to resources 107. In various embodiments, such an authorization framework may be implemented, for example, using authorization server 108. For example, resource server 106 may delegate the process of authorizing the access requests that it receives (e.g., from application 105) to authorization server 108. Note that, although resource server 106 and authorization server 108 are shown separately in
Authorization server 108 may implement an authorization framework, in some embodiments, by provisioning an access token to application 105. As used herein, “access token” is to be understood according to its ordinary meaning in the art, which includes a string representing an authorization credential used to access protected resources. One of ordinary skill in the art with the benefit of this disclosure will recognize that an access token may take various formats. For example, in some embodiments, an access token may indicate an identifier that may be used to retrieve authorization information. In other embodiments, however, an access token may self-contain authorization information. In some embodiments, the access token may specify the scope and duration of access to the resource server permitted by the access token. For instance, continuing with the example above, an access token provisioned to SPOTIFY™ may specify that the token permits the application server 104 to access resources 107 managed by resource server 106 for a duration of one week. Once it receives this access token, application 105 may send access requests, along with the access token, to resource server 106, requesting access to one or more of user 102's resources 107. In response to these access requests, resource server 106 may send an authorization request, which may include the received access token, to authorization server 108. Authorization server 108 may then determine whether to authorize the authorization request based on the received access token.
The systems and methods described herein contemplate the provision of multiple access tokens that correspond to a reduction of application 105's access to resource server 106 over time. This approach allows, in response to a single access request, provisioning of a suite of access tokens, at least some of which vary in scope and duration from one another. (While application 105 and application server 104 are distinct, references may be made herein to either application 105's or application server 104's access to resources 107.) In various embodiments, resources 107 may be protected resources that, as noted above, require user 102's authorization to be accessed. As shown in
In various embodiments, authorization server 108 may provision a plurality of access tokens to application 105 corresponding user 102's grant of access privileges. In some embodiments, each of the plurality of access tokens may authorize a particular scope of access to resources 107 for a particular duration. For example, authorization server 108 may provision two access tokens to application 105, one authorizing application 105 to access user 102's contact list for a duration of one week and one authorizing application 105 to access user 102's location information for a duration of one day. In some embodiments, authorization server 108 may store authorization information associated with the grant of access privileges. In some embodiments, for example, this authorization information may include, for each of the plurality of access tokens, a particular scope of access to the resources of user 102 that are managed by resource server 106 and a corresponding duration that is based on that particular scope of access. As shown in
In various embodiments, authorization server 108 may be configured to determine whether to authorize the authorization request based on the stored authorization information. In some embodiments, for example, authorization server 108 may compare the received one or more access tokens to the plurality of access tokens provisioned to application 105. Further, in response to detecting that one or more of the received access tokens match one or more of the provisioned access tokens, authorization server 108 may determine whether a type of the access request is permitted by the scope of the matched access tokens. For example, authorization server 108 may detect that the two access tokens received from resource server 106 match the two access tokens provisioned to application 105 for user 102. In response to this detection, authorization server 108 may determine whether the types of access requested by application 105 are permitted by the particular scope of the provisioned access tokens. In the described example, in which application 105 attempts to access user 102's contact list and location information, authorization server 108 may determine that the types of access included in the one or more access requests are permitted by the scopes of the provisioned access tokens. Further, in various embodiments, authorization server 108 may be configured to determine whether the received one or more access tokens have expired for the type of access requested. For example, authorization server 108 may be configured to determine, based on the duration of the provisioned access tokens, whether the two access tokens sent by application 105 have expired for their respective types of access. That is, in this example, authorization server 108 may determine whether the received access token corresponding to accessing user 102's contact list has expired based on the stored authorization information for the provisioned access token corresponding to accessing user 102's access list. Similarly, authorization server 108 may determine whether the received access token corresponding to accessing user 102's location information has expired based on the stored authorization information for the provisioned access token corresponding to accessing user 102's location information. After determining whether to authorize the authorization request, authorization server 108 may send an authorization indication to resource server 106. This authorization indication may, in various embodiments, indicate whether the access requests by application server 104 are authorized, partially authorized, or denied.
The disclosed systems and methods for providing varying levels of access over time to resources may provide various improvements to the functioning of system 100 as a whole, including authorization server 108. For example, consider a situation in which the duration of an access token is not based on its corresponding scope of access to a resource server. In such a situation, an access token may have multiple scopes with a single duration. This duration, however, may need to be limited to a time period that is appropriate for the most sensitive type of access permitted by the scopes. Thus, in such a situation, the access tokens provisioned may expire more quickly, resulting in an increased number of requests to users for authorization credentials and an increased number of requests to the authorization server for access tokens. Conversely, if the single duration is not limited and instead authorizes access to all of the types of access included within the scopes for an extended duration, this may compromise the security of the resources managed by the resource server. The disclosed systems and methods, however, allow for the provisioning of access tokens in which the duration is based on the scope of access, resulting in fewer requests to the authorization server and an improved user experience without compromising the security of the resources managed by the resource server. Further, the disclosed systems and methods may provide increased granularity to the levels of access granted to a third-party application to access resources managed by a resource server. This improved access control may, in turn, provide improved security to the resources managed by the resource server by limiting the duration of access to resources deemed to be more sensitive. Thus, in various embodiments, the disclosed systems and methods may provide various improvements to the functioning of the authorization server, particularly as it relates to securely authorizing access requests by third-party applications.
Turning now to
As used herein, the term “module” refers to circuitry configured to perform specified operations or to physical non-transitory computer readable media that stores information (e.g., program instructions) that instructs other circuitry (e.g., a processor) to perform specified operations. Such circuitry may implemented in multiple ways, including as a hardwired circuit or as a memory having program instructions stored therein that are executable by one or more processors to perform the operations. The hardware circuit may include, for example, custom very-large-scale integration (VLSI) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, or the like. A module may also be any suitable form of non-transitory computer readable media storing program instructions executable to perform specified operations.
In the embodiment depicted in
As shown in
Authorization server 108 of
As depicted in
Further, authorization request 214 may specify the scope 218 of the access request by application server 104. That is, in various embodiments, the types of access to resource server 106 requested by application server 104 may be specified by scope 218. For example, application 105 may send an access request to resource server 106 requesting access to user 102's contact list and location information. In that access request, application 105 may include the two access tokens provisioned to it by authorization server 108. After receiving the access request, resource server 106 may then send an authorization request 214 to authorization server 108 that includes the two access tokens 216 (e.g., the first and second access tokens described above, in this particular example) and specify the scope 218 of application 105's access request (e.g., to access user 102's contact list and location information). Note that, in other embodiments, the types of access requested by application server 104 may be otherwise specified in authorization request 214 in any suitable manner (e.g., as part of the access token(s) 216, etc.).
In various embodiments, authorization server 108 may be configured to determine, based on the authorization information 204, whether to authorize the authorization request 214. For example, as shown in
Authorization server 108 further includes authorization determination module 208, which, as described in more detail below with reference to
Referring now to
Further, access token response 300 specifies, for each of the access tokens, a scope and a corresponding duration. The “scope” parameter of access token response 300 may take various embodiments. For example, in some embodiments, the scope parameter may be in the format of an identifier (e.g., an alphanumeric string) that specifies the resources of a resource server 106 that a bearer (e.g., an application hosted on application server 104) of the associated access token is permitted to access. The syntax used for the scope parameter may vary between resource servers or authorization servers, and may be defined, for example, by the operators of the given authorization server 108, resource server 106, etc. In the embodiment depicted in
Access token response 300 further specifies, for each of the access tokens, a duration (e.g., a time period) during which the corresponding scope of access is authorized. In the depicted embodiment, the duration specified as the “expires_in” parameter expressed in seconds. Note that, although the depicted duration is expressed in terms of seconds, any other suitable units (e.g., milliseconds, etc.) may be used. As shown in
Referring now to
In the depicted embodiment, the access tokens in access token response 350A are provided in a JSON Web Token format, but may also take other suitable forms known in the art. As shown in
Note that the described access tokens are provided merely as examples and are not intended to limit the scope of this disclosure. One of ordinary skill in the art with the benefit of this disclosure will recognize that access tokens may be implemented in any suitable format without departing from the scope of the present disclosure. Further, any suitable scope or duration may be defined (e.g., by user 102, by the operators of resource server 106, authorization server 108, or application server 104, etc.) for use in various access tokens.
Turning now to
Method 400 then proceeds to block 404, which includes provisioning a plurality of access tokens corresponding to the grant of access privileges. In some embodiments, for example, an authorization server 108 may provision the plurality of access tokens to an application 105 executing on an application server 104. In some embodiments, the plurality of access tokens may include a first access token associated with a first scope and a first duration that is based on the first scope. Further, in some embodiments, the plurality of access tokens may include a second access token associated with a second, different scope and a second duration based on the second, different scope. In some embodiments, the second, different scope may be more expansive than the first scope, and the second duration may be shorter than the first duration. For instance, in the example provided above with reference to
In various embodiments, some type of access to resources 107 (e.g., accessing user 102's location information) may be considered to be more sensitive than other types of access to resources 107 (e.g., accessing user 102's contact list). Accordingly, in some embodiments, one or more entities (e.g., resource server 106, authorization server 108, application 105, user 102, etc.) may define, for the various types of access to resources 107, the corresponding duration for which access is authorized. In some embodiments, authorization server 108 may be configured to provision access tokens with durations that differ based on the expansiveness of their respective scope. For more expansive types of access, as determined by one or more of the entities noted above, authorization server 108 may provision access tokens with shorter durations. Conversely, for types of access that are relatively less expansive, authorization server 108 may provision access tokens with longer durations.
Method 400 then proceeds to block 406, which includes storing authorization information associated with the grant of access privileges. For example, in some embodiments, the authorization server may store authorization information that includes, for each of the plurality of provisioned access tokens, a particular scope of access to the resources of the user that are managed by the resource server, and a corresponding duration based on the particular scope of access.
Method 400 then proceeds to block 408, which includes receiving an authorization request from the resource server that includes one or more access tokens. As depicted in
Method 400 then proceeds to block 410, which includes determining, by the authorization server, whether to authorize the authorization request sent by the resource server. As explained in more detail below with reference to
Note that various ones of blocks 402-412 in method 400 may be repeated to provide varying levels of access to resources 107 of a resource server 106. In some embodiments, block 408 may include authorization server 108 receiving a subsequent authorization request, including the first and second access tokens, associated with a subsequent access request by application server 104. For example, the subsequent access request may be made by the SPOTIFY™ application to access user 102's FACEBOOK™ contact list and location information. In such embodiments, authorization server 108 may determine at block 410 whether to access this subsequent authorization request, as discussed in more detail below with reference to
Referring now to
Block 502 includes receiving information indicative of a grant of access privileges, as in block 402. In some embodiments, the grant of access privileges may include a first access privilege authorizing a first type of access to the resource server for a first duration and a second access privilege authorizing a second type of access to the resource server for a second duration. Method 500 then proceeds to block 504, which includes provisioning, by the authorization server to the application server, an access token based on the grant of access privileges. For example, in some embodiments, authorization server may provision a single access token 212 to application server 104, which authorizes application 105 to perform the first type of access for the first duration and the second type of access for the second duration.
Method 500 then proceeds to block 506, which includes storing authorization information associated with the access token. In some embodiments, for example, authorization server 108 stores authorization information 204 specifying that the first type of access to the resource server 106 is authorized for the first duration and that the second type of access to the resource server 106 is authorized for the second duration.
Method 500 then proceeds to block 508, which includes receiving an authorization request 214 from the resource server 106 that specifies the type(s) of access requested and includes the access token 216. In contrast to block 408 of
Method 500 then proceeds to block 510, which includes determining, by the authorization server, whether to authorize the authorization request sent by the resource server. As described in more detail below with reference to
Note that various ones of blocks 502-512 in method 500 may be repeated to provide varying levels of access to resources 107 of a resource server 106. In some embodiments, block 508 may include authorization server 108 receiving, from resource server 106, a subsequent authorization request associated with a subsequent access request by the application server 104, which may include a request to perform a first type of access and a second type of access. In various embodiments, authorization server 108 may determine at block 510 whether to authorize this subsequent authorization request, as discussed in more detail below with reference to
Turning now to
Method 600 then proceeds to block 604, which includes determining whether the received access tokens match any of the provisioned access tokens. For example, authorization server 108 may determine whether any of the received access tokens 216 match any of the access tokens 212 provisioned to application 105. If no match is detected at block 604, method 600 continues to block 612, which includes denying the authorization request.
If, however, a match is detected at block 604, method 600 continues to block 606, which includes determining whether the type of access requested by the application is permitted. For example, the authorization determination module 208 may compare the scope 218 specified by the authorization request 214 with the scope of the access token(s) 212 matched at block 604, which may be stored as part of the authorization information 204. If the authorization determination module 208 determines that the type of access requested by application 105, as specified by scope 218, is not within the scope of access authorized by the provisioned access tokens 212, method 600 continues to block 612. If, however, the type of access is permitted by the matched access token(s), method 600 continues to block 608.
Block 608 includes determining, for example by authorization determination module 208, whether the received one or more access tokens 216 have expired. In some embodiments, this determination may include calculating a time period from which the access token(s) 212 were provisioned to the application 105 until a time that the authorization request 214 was received by the authorization server 108. This calculated time period may then be compared to the duration information for access tokens 212 included in authorization information 204 to determine whether the one or more access tokens 216 have expired.
Note, however, that this manner of determining whether the access token(s) have expired is provided merely as an example and is not intended to limit the scope of the present disclosure. In other embodiments, for example, the authorization server 108 determine whether the access token(s) have expired based on various time periods using, for example, any of the following: a time that the grant of access privileges was sent or received, a time that the access token(s) 212 were provisioned, a time that the application 105 submitted the access request to resource server 106, a time that the resource server 106 received the access request or access token(s), a time that the resource server 106 sent the authorization request 214 or access token(s) 216, etc. Further, as noted above, in some embodiments the duration information may be specified as a time that the corresponding access token expires. In such embodiments, authorization server 108 may determine whether the access token(s) have expired by comparing the time specified in the authorization information 204 with the time that the authorization request 214 was sent or received, a time that the access request was sent or received, etc.
If, at block 608, it is determined that the access token(s) have not expired, then method 600 proceeds to block 610, which includes authorizing the authorization request 214. In one embodiment, for example, authorization server 108 may determine that the authorization request 214 is authorized by determining, for example at block 606, that the first type of access and the second type of access are permitted by the grant of access privileges, and determining, for example at block 608, that the access token has not expired for the first type of access and the second type of access. Method 600 then proceeds to block 614, which includes generating an authorization indication that, as shown in block 412 of
In some embodiments, authorization server 108 may determine that an authorization request 214 is both partially authorized and partially denied. That is, a given authorization request 214 may be both authorized at block 610 with regard to one type of access request and denied at block 612 with regard to a different type of access request. For example, with reference to method 400, consider the embodiment in which an authorization request 214 includes first and second received access tokens 216 and a scope 218 that specifies a first and second type of access requested to resources 107. In this example, the authorization request 214 may be partially authorized and partially denied based on authorization server 108: detecting (e.g., at block 604) that one of the first and second received access tokens 216 do not match any of the provisioned access tokens 212, determining (e.g., at block 606) that one of the first or second type of access requested is not permitted by the scope of the corresponding access token 212, determining (e.g., at block 608) that one of the first and second received access tokens 216 have expired, or any combination thereof. In one embodiment, for example, authorization server 108 may determine that the authorization request 214 is partially authorized by detecting, for example at block 604, that the first and second received access tokens 216 match first and second provisioned access tokens 212 and determining, for example at block 608, that the duration for the second access token, but not the first access token, has expired. In such an embodiment, authorization server 108 may both authorize the authorization request with respect to the first access token and deny the authorization request with respect to the second access token.
As a further example, consider, with reference to method 500, an embodiment in which an authorization request 214 includes an access token 216 and a scope 218 specifying that the access request includes a request to perform a first and second type of access to resources 107. In some embodiments, the second type of access may be more expansive than the first type of access, and the second duration may be shorter than the first duration. In this example, the authorization request 214 may be partially authorized and partially denied based on authorization server 108 determining (e.g., at block 606) that one of the first or second types of access requested is not permitted by the scope of the corresponding access token 212, determining (e.g., at block 608) that the received access token 216 has expired for one of the first or second types of access requested, etc. In such an embodiment, the authorization indication generated at block 614 may indicate that authorization request 214 is partially authorized and partially denied.
Turning now to
In
As shown in
Once user 102 selects a bank on interface 710, an interface 720, depicted in
In the depicted embodiment, by selecting the “allow” button on interface 730, user 102 may send a grant of access privileges to authorization server 108 that authorizes Banking Aggregator App 700 to access resources 107 of user 102 managed by one or more resource servers 106 associated with BankOne. After receiving the grant of access privileges from user 102, authorization server 108 may, as described above, provision a plurality of access tokens to Banking Aggregator App 700. For example, in the depicted embodiment, authorization server 108 may provision two access tokens to Banking Aggregator App 700: a first access token that permits Banking Aggregator App 700 to access user 102's account statements with BankOne for a duration of one month, and a second access token that permits Banking Aggregator App 700 to transfer funds from user 102's BankOne bank account for a duration of thirty minutes.
User 102 may select additional banking services to access via the Banking Aggregator App 700, for example by repeating the process described above with reference to
In some embodiments, the same authorization server 108 may perform authorization services for both BankOne' s resource servers and BankTwo' s resource servers. Note, however, that in various embodiments, BankOne and BankTwo may use separate or unassociated authorization servers 108. That is, the disclosed systems and methods do not require that different resource servers, such as those operated by BankOne and BankTwo, use the same authorization server to authorize their respective access requests. Further, note that although the scope and duration of the access tokens provisioned by the authorization server 108 associated with BankTwo are the same as the access tokens provisioned by the authorization server 108 associated with BankOne, this embodiment is provided merely as an example and is not intended to limit the scope of the present disclosure. In other embodiments, for example, the scope or duration of the access tokens provisioned by various authorization servers 108 may vary (e.g., based on a set of policy rules of the authorization servers 108, the resource servers 106, application 105, user 102, etc.).
After access tokens have been provisioned to Banking Aggregator App 700 for BankOne and BankTwo, user 102 may use Banking Aggregator App 700 to access resources 107 managed by resource servers associated with either BankOne or BankTwo. For example, immediately after the access tokens are provisioned, Banking Aggregator App 700 has access tokens that permit it to access user 102's account statements for one month and make payment transactions from user 102's bank accounts for thirty minutes. User 102 may then make payment transactions via Banking Aggregator App 700, for example by transferring $100 from her account at BankOne to her account at BankTwo. After thirty minutes, however, user 102 will no longer be able to make such payment transactions using Banking Aggregator App 700 as the access tokens that permit that operation have expired. In such situations, Banking Aggregator App 700 will be required to acquire a new access token associated with making payment transactions, as discussed with reference to
Turning now to
Processor subsystem 820 may include one or more processors or processing units. In various embodiments of computer system 800, multiple instances of processor subsystem 820 may be coupled to interconnect 880. In various embodiments, processor subsystem 820 (or each processor unit within 820) may contain a cache or other form of on-board memory.
System memory 840 is usable to store program instructions executable by processor subsystem 820 to cause system 800 perform various operations described herein. System memory 840 may be implemented using different physical, non-transitory memory media, such as hard disk storage, floppy disk storage, removable disk storage, flash memory, random access memory (RAM-SRAM, EDO RAM, SDRAM, DDR SDRAM, RAMBUS RAM, etc.), read only memory (PROM, EEPROM, etc.), and so on. Memory in computer system 800 is not limited to primary storage such as system memory 840. Rather, computer system 800 may also include other forms of storage such as cache memory in processor subsystem 820 and secondary storage on I/O Devices 870 (e.g., a hard drive, storage array, etc.). In some embodiments, these other forms of storage may also store program instructions executable by processor subsystem 820.
I/O interfaces 860 may be any of various types of interfaces configured to couple to and communicate with other devices, according to various embodiments. In one embodiment, I/O interface 860 is a bridge chip (e.g., Southbridge) from a front-side to one or more back-side buses. I/O interfaces 860 may be coupled to one or more I/O devices 870 via one or more corresponding buses or other interfaces. Examples of I/O devices 870 include storage devices (hard drive, optical drive, removable flash drive, storage array, SAN, or their associated controller), network interface devices (e.g., to a local or wide-area network), or other devices (e.g., graphics, user interface devices, etc.). In one embodiment, I/O devices 870 includes a network interface device (e.g., configured to communicate over WiFi, Bluetooth, Ethernet, etc.), and computer system 800 is coupled to a network via the network interface device.
Although the embodiments disclosed herein are susceptible to various modifications and alternative forms, specific embodiments are shown by way of example in the drawings and are described herein in detail. It should be understood, however, that drawings and detailed description thereto are not intended to limit the scope of the claims to the particular forms disclosed. On the contrary, this application is intended to cover all modifications, equivalents and alternatives falling within the spirit and scope of the disclosure of the present application as defined by the appended claims.
This disclosure includes references to “one embodiment,” “a particular embodiment,” “some embodiments,” “various embodiments,” or “an embodiment.” The appearances of the phrases “in one embodiment,” “in a particular embodiment,” “in some embodiments,” “in various embodiments,” or “in an embodiment” do not necessarily refer to the same embodiment. Particular features, structures, or characteristics may be combined in any suitable manner consistent with this disclosure.
As used herein, the term “based on” is used to describe one or more factors that affect a determination. This term does not foreclose the possibility that additional factors may affect the determination. That is, a determination may be solely based on specified factors or based on the specified factors as well as other, unspecified factors. Consider the phrase “determine A based on B.” This phrase specifies that B is a factor that is used to determine A or that affects the determination of A. This phrase does not foreclose that the determination of A may also be based on some other factor, such as C. This phrase is also intended to cover an embodiment in which A is determined based solely on B. As used herein, the phrase “based on” is synonymous with the phrase “based at least in part on.”
As used herein, the phrase “in response to” describes one or more factors that trigger an effect. This phrase does not foreclose the possibility that additional factors may affect or otherwise trigger the effect. That is, an effect may be solely in response to those factors, or may be in response to the specified factors as well as other, unspecified factors. Consider the phrase “perform A in response to B.” This phrase specifies that B is a factor that triggers the performance of A. This phrase does not foreclose that performing A may also be in response to some other factor, such as C. This phrase is also intended to cover an embodiment in which A is performed solely in response to B.
As used herein, the terms “first,” “second,” etc. are used as labels for nouns that they precede, and do not imply any type of ordering (e.g., spatial, temporal, logical, etc.), unless stated otherwise. For example, if an authorization server provisions four access tokens, the terms “first access token” and “second access token” can be used to refer to any two of the four access tokens, and not, for example, just a first two access tokens to be generated, received, etc.
When used in the claims, the term “or” is used as an inclusive or and not as an exclusive or. For example, the phrase “at least one of x, y, or z” means any one of x, y, and z, as well as any combination thereof (e.g., x and y, but not z).
It is to be understood that the present disclosure is not limited to particular devices or methods, which may, of course, vary. It is also to be understood that the terminology used herein is for the purpose of describing particular embodiments only, and is not intended to be limiting. As used herein, the singular forms “a,” “an,” and “the” include singular and plural referents unless the content clearly dictates otherwise. Furthermore, the word “may” is used throughout this application in a permissive sense (i.e., having the potential to, being able to), not in a mandatory sense (i.e., must). The term “include,” and derivations thereof, mean “including, but not limited to.” The term “coupled” means directly or indirectly connected.
Within this disclosure, different entities (which may variously be referred to as “units,” “circuits,” other components, etc.) may be described or claimed as “configured” to perform one or more tasks or operations. This formulation—[entity] configured to [perform one or more tasks]—is used herein to refer to structure (i.e., something physical, such as an electronic circuit). More specifically, this formulation is used to indicate that this structure is arranged to perform the one or more tasks during operation. A structure can be said to be “configured to” perform some task even if the structure is not currently being operated. A “memory device configured to store data” is intended to cover, for example, an integrated circuit that has circuitry that performs this function during operation, even if the integrated circuit in question is not currently being used (e.g., a power supply is not connected to it). Thus, an entity described or recited as “configured to” perform some task refers to something physical, such as a device, circuit, memory storing program instructions executable to implement the task, etc. This phrase is not used herein to refer to something intangible.
The term “configured to” is not intended to mean “configurable to.” An unprogrammed FPGA, for example, would not be considered to be “configured to” perform some specific function, although it may be “configurable to” perform that function after programming.
Reciting in the appended claims that a structure is “configured to” perform one or more tasks is expressly intended not to invoke 35 U.S.C. § 112(f) for that claim element. Accordingly, none of the claims in this application as filed are intended to be interpreted as having means-plus-function elements. Should Applicant wish to invoke Section 112(f) during prosecution, it will recite claim elements using the “means for” [performing a function] construct.
Although specific embodiments have been described above, these embodiments are not intended to limit the scope of the present disclosure, even where only a single embodiment is described with respect to a particular feature. Examples of features provided in the disclosure are intended to be illustrative rather than restrictive unless stated otherwise. The above description is intended to cover such alternatives, modifications, and equivalents as would be apparent to a person skilled in the art having the benefit of this disclosure.
The scope of the present disclosure includes any feature or combination of features disclosed herein (either explicitly or implicitly), or any generalization thereof, whether or not it mitigates any or all of the problems addressed herein. Accordingly, new claims may be formulated during prosecution of this application (or an application claiming priority thereto) to any such combination of features. In particular, with reference to the appended claims, features from dependent claims may be combined with those of the independent claims and features from respective independent claims may be combined in any appropriate manner and not merely in the specific combinations enumerated in the appended claims.
