OAuth framework

• US 8,935,757 B2
• Filed: 09/28/2012
• Issued: 01/13/2015
• Est. Priority Date: 09/29/2011
• Status: Active Grant

• Current Assignee: Oracle International Corporation (Oracle Corporation)
• Original Assignee: Oracle International Corporation (Oracle Corporation)
• Inventors: Srinivasan, Venkataraman Uppili, Angal, Rajeev, Sondhi, Ajay
• Primary Examiner(s): Patel, Nirav B
• Assistant Examiner(s): Waliullah, Mohammed
• Application Number:
  US13/631,538
• Publication Number:
  US 20130086645A1
• Time in Patent Office: 837 Days
• US Class Current: 726/4
• CPC Class Codes: H04L 63/0815 providing single-sign-on or federations
• CPC Class Codes: H04L 63/10 for controlling access to devices or network resources
• CPC Class Codes: H04L 9/3234 involving additional secure or trusted devices, e.g. TPM, smartcard, USB or software token network architectures or network communication protocols for supporting authentication of entities using an additional device in a packet data network H04L63/0853

Abstract

A framework, which conforms to the OAuth standard, involves a generic OAuth authorization server that can be used by multiple resource servers in order to ensure that access to resources stored on those resource servers is limited to access to which the resource owner consents. Each resource server registers, with the OAuth authorization server, metadata for that resource server, indicating scopes that are recognized by the resource server. The OAuth authorization server refers to this metadata when requesting consent from a resource owner on behalf of a client application, so that the consent will be of an appropriate scope. The OAuth authorization server refers to this metadata when constructing an access token to provide to the client application for use in accessing the resources on the resource server. The OAuth authorization server uses this metadata to map issued access tokens to the scopes to which those access tokens grant access.

Claims

1. A method comprising:

receiving, at an OAuth authorization server, from a first resource server that is separate from the OAuth authorization server, a first set of metadata indicating a first set of scopes that are recognized by the first resource server;

in response to receiving the first set of metadata, storing, at the OAuth authorization server, mappings between scopes in the first set of scopes and subsets of resources maintained by the first resource server;

storing, at the OAuth authorization server, a mapping between a first access token and a first scope from the first set of scopes;

receiving, at the OAuth authorization server, from the first resource server, a request to validate the first access token;

in response to receiving the request to validate the first access token, the OAuth authorization server validating the first access token based on the mapping between the first access token and the first scope; and

in response to validating the first access token, the OAuth authorization server indicating, to the first resource server, that a client application that presented the first access token to the first resource server is authorized to perform operations relative to a set of resources that are maintained by the first resource server and specified by the first scope;

receiving, at the OAuth authorization server, from a second resource server that is separate from the first resource server, a second set of metadata indicating a second set of scopes that are recognized by the second resource server, the second set of scopes differing from the first set of scopes;

in response to receiving the second set of metadata, storing, at the OAuth authorization server, mappings between scopes in the second set of scopes and subsets of resources maintained by the second resource server;

storing, at the OAuth authorization server, a mapping between a second access token and a second scope from the second set of scopes;

receiving, at the OAuth authorization server, from the second resource server, a request to validate the second access token;

in response to receiving the request to validate the second access token, the OAuth authorization server validating the second access token based on the mapping between the second access token and the second scope; and

in response to validating the second access token, the OAuth authorization server indicating, to the second resource server, that a client application that presented the second access token to the second resource server is authorized to perform operations relative to a set of resources that are maintained by the second resource server and specified by the second scope;

wherein the OAuth authorization server does not manage the set of resources that are maintained by the first resource server.

2. The method of claim 1, further comprising:

receiving, at the OAuth authorization server, a particular request specifying the first scope;

in response to receiving the request specifying the first scope, the OAuth authorization server asking an owner of resources contained within the first scope for consent to grant the client application access consistent with the first scope;

in response to receiving the consent from the owner, the OAuth authorization server (a) creating the first access token, (b) storing the mapping between the first access token and the first scope, and (c) sending the first access token to the client application.

3. The method of claim 1, further comprising:

in response to receiving the first set of metadata, storing, at the OAuth authorization server, a mapping between the first scope, a first subset of resources stored by the first resource server, and a first set of operations that a holder of a token mapped to the first scope is permitted to perform relative to resources in the first subset of resources.

4. The method of claim 1, wherein validating the first access token comprises the OAuth authorization server invoking programmatic code provided by a customer who does not provide the OAuth authorization server;

wherein the programmatic code implements an interface provided to the customer by a provider of the OAuth authorization server;

wherein the programmatic code validates the first access token.

5. The method of claim 1, further comprising:

receiving, at the OAuth authorization server, a particular request specifying the first scope;

in response to receiving the request specifying the first scope, the OAuth authorization server asking an owner of resources contained within the first scope for consent to grant the client application access consistent with the first scope;

in response to receiving the consent from the owner, the OAuth authorization server invoking programmatic code provided by a customer who does not provide the OAuth authorization server;

wherein the programmatic code implements an interface provided to the customer by a provider of the OAuth authorization server;

wherein the programmatic code creates the first access token.

6. A non-transitory computer-readable memory comprising instructions which, when executed by one or more processors, cause the one or more processors to perform:

receiving, at an OAuth authorization server, from a first resource server that is separate from the OAuth authorization server, a first set of metadata indicating a first set of scopes that are recognized by the first resource server;

in response to receiving the first set of metadata, storing, at the OAuth authorization server, mappings between scopes in the first set of scopes and subsets of resources maintained by the first resource server;

storing, at the OAuth authorization server, a mapping between a first access token and a first scope from the first set of scopes;

receiving, at the OAuth authorization server, from the first resource server, a request to validate the first access token;

in response to receiving the request to validate the first access token, the OAuth authorization server validating the first access token based on the mapping between the first access token and the first scope; and

in response to validating the first access token, the OAuth authorization server indicating, to the first resource server, that a client application that presented the first access token to the first resource server is authorized to perform operations relative to a set of resources that are maintained by the first resource server and specified by the first scope;

receiving, at the OAuth authorization server, from a second resource server that is separate from the first resource server, a second set of metadata indicating a second set of scopes that are recognized by the second resource server, the second set of scopes differing from the first set of scopes;

in response to receiving the second set of metadata, storing, at the OAuth authorization server, mappings between scopes in the second set of scopes and subsets of resources maintained by the second resource server;

storing, at the OAuth authorization server, a mapping between a second access token and a second scope from the second set of scopes;

receiving, at the OAuth authorization server, from the second resource server, a request to validate the second access token;

in response to receiving the request to validate the second access token, the OAuth authorization server validating the second access token based on the mapping between the second access token and the second scope; and

in response to validating the second access token, the OAuth authorization server indicating, to the second resource server, that a client application that presented the second access token to the second resource server is authorized to perform operations relative to a set of resources that are maintained by the second resource server and specified by the second scope;

wherein the OAuth authorization server does not manage the set of resources that are maintained by the first resource server.

7. The non-transitory computer-readable memory of claim 6, wherein the instructions, when executed by the one or more processors, further cause the one or more processors to perform:

receiving, at the OAuth authorization server, a particular request specifying the first scope;

in response to receiving the request specifying the first scope, the OAuth authorization server asking an owner of resources contained within the first scope for consent to grant the client application access consistent with the first scope;

in response to receiving the consent from the owner, the OAuth authorization server (a) creating the first access token, (b) storing the mapping between the first access token and the first scope, and (c) sending the first access token to the client application.

8. The non-transitory computer-readable memory of claim 6, wherein the instructions, when executed by the one or more processors, further cause the one or more processors to perform:

in response to receiving the first set of metadata, storing, at the OAuth authorization server, a mapping between the first scope, a first subset of resources stored by the first resource server, and a first set of operations that a holder of a token mapped to the first scope is permitted to perform relative to resources in the first subset of resources.

9. The non-transitory computer-readable memory of claim 6, wherein validating the first access token comprises the OAuth authorization server invoking programmatic code provided by a customer who does not provide the OAuth authorization server;

wherein the programmatic code implements an interface provided to the customer by a provider of the OAuth authorization server;

wherein the programmatic code validates the first access token.

10. The non-transitory computer-readable memory of claim 6, wherein the instructions, when executed by the one or more processors, further cause the one or more processors to perform:

receiving, at the OAuth authorization server, a particular request specifying the first scope;

in response to receiving the request specifying the first scope, the OAuth authorization server asking an owner of resources contained within the first scope for consent to grant the client application access consistent with the first scope;

in response to receiving the consent from the owner, the OAuth authorization server invoking programmatic code provided by a customer who does not provide the OAuth authorization server;

wherein the programmatic code implements an interface provided to the customer by a provider of the OAuth authorization server;

wherein the programmatic code creates the first access token.

11. An OAuth authorization server comprising:

one or more hardware processors that are configured to receive, from a first resource server that is separate from the OAuth authorization server, a first set of metadata indicating a first set of scopes that are recognized by the first resource server;

one or more hardware processors that are configured to store, in response to receiving the first set of metadata, mappings between scopes in the first set of scopes and subsets of resources maintained by the first resource server;

one or more hardware processors that are configured to store a mapping between a first access token and a first scope from the first set of scopes;

one or more hardware processors that are configured to receive, from the first resource server, a request to validate the first access token;

one or more hardware processors that are configured to validate the first access token based on the mapping between the first access token and the first scope in response to receiving the request to validate the first access token; and

one or more hardware processors that are configured to indicate, to the first resource server, in response to validating the first access token, that a client application that presented the first access token to the first resource server is authorized to perform operations relative to a set of resources that are maintained by the first resource server and specified by the first scope;

one or more hardware processors configured to receive, from a second resource server that is separate from the first resource server, a second set of metadata indicating a second set of scopes that are recognized by the second resource server, the second set of scopes differing from the first set of scopes;

one or more hardware processors configured to store, in response to receiving the second set of metadata, mappings between scopes in the second set of scopes and subsets of resources maintained by the second resource server;

one or more hardware processors configured to store a mapping between a second access token and a second scope from the second set of scopes;

one or more hardware processors configured to receive, from the second resource server, a request to validate the second access token;

one or more hardware processors configured to validate the second access token based on the mapping between the second access token and the second scope in response to receiving the request to validate the second access token; and

one or more hardware processors configured to indicate, to the second resource server, in response to validating the second access token, that a client application that presented the second access token to the second resource server is authorized to perform operations relative to a set of resources that are maintained by the second resource server and specified by the second scope;

wherein the OAuth authorization server does not manage the set of resources that are maintained by the first resource server.

12. The OAuth authorization server of claim 11, further comprising:

one or more hardware processors configured to receive a particular request specifying the first scope;

one or more hardware processors configured to ask an owner of resources contained within the first scope for consent to grant the client application access consistent with the first scope in response to receiving the request specifying the first scope;

one or more hardware processors configured to (a) create the first access token, (b) store the mapping between the first access token and the first scope, and (c) send the first access token to the client application in response to receiving the consent from the owner.

13. The OAuth authorization server of claim 11, further comprising:

one or more hardware processors configured to store, in response to receiving the first set of metadata, a mapping between the first scope, a first subset of resources stored by the first resource server, and a first set of operations that a holder of a token mapped to the first scope is permitted to perform relative to resources in the first subset of resources.

14. The OAuth authorization server of claim 11, wherein one or more hardware processors are configured to validate the first access token at least in part by invoking programmatic code provided by a customer who does not provide the OAuth authorization server;

wherein the programmatic code implements an interface provided to the customer by a provider of the OAuth authorization server;

wherein the programmatic code is configured to validate the first access token.

15. The OAuth authorization server of claim 11, further comprising:

one or more hardware processors configured to receive, at the OAuth authorization server, a particular request specifying the first scope;

one or more hardware processors configured to ask an owner of resources contained within the first scope for consent to grant the client application access consistent with the first scope in response to receiving the request specifying the first scope;

one or more hardware processors configured to invoke programmatic code provided by a customer who does not provide the OAuth authorization server in response to receiving the consent from the owner;

wherein the programmatic code implements an interface provided to the customer by a provider of the OAuth authorization server;

wherein the programmatic code is configured to create the first access token.