MULTIPLE RESOURCE SERVERS INTERACTING WITH SINGLE OAUTH SERVER

• US 20150089597A1
• Filed: 04/30/2014
• Published: 03/26/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, Uppili, Sondhi, Ajay, Chu, Ching-Wen, Kim, Beomsuk, Evani, Venkata S.
• Granted Patent: US 9,197,623 B2
• Time in Patent Office: Days
• US Class Current: 726/4
• CPC Class Codes: G06F 2221/2103 Challenge-response
• CPC Class Codes: H04L 63/08 for authentication of entities cryptographic mechanisms or cryptographic arrangements for entity authentication H04L9/32
• CPC Class Codes: H04L 63/0807 using tickets, e.g. Kerberos cryptographic mechanisms or cryptographic arrangements for entity authentication using tickets or tokens H04L9/3213
• CPC Class Codes: H04L 63/0815 providing single-sign-on or federations
• CPC Class Codes: H04L 63/0853 using an additional device, e.g. smartcard, SIM or a different communication terminal cryptographic mechanisms or cryptographic arrangements for entity authentication involving additional secure or trusted devices H04L9/3234
• CPC Class Codes: H04L 63/10 for controlling access to devices or network resources
• CPC Class Codes: H04L 63/102 Entity profiles
• CPC Class Codes: H04L 63/20 for managing network security; network security policies in general filtering policies H04L63/0227
• CPC Class Codes: H04L 63/205 involving negotiation or determination of the one or more network security mechanisms to be used, e.g. by negotiation between the client and the server or between peers or by selection according to the capabilities of the entities involved negotiation of communication capabilities H04L69/24
• CPC Class Codes: H04W 12/06 Authentication

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 computer-implemented method comprising:

receiving, at an OAuth authorization server, a request from a first client application that executes in a context of a first identity domain of a plurality of isolated identity domains;

selecting, from a plurality of OAuth service profiles that the OAuth authorization server maintains, a first OAuth service profile that is applicable only to the first identity domain;

determining, based on the first OAuth service profile, whether the first client application is permitted to access a first resource server;

in response to determining that the first client application is permitted to access the first resource server, generating a first token for the first client application based on scope information that the OAuth authorization server obtains from the first resource server;

receiving, at the OAuth authorization server, a request from a second client application that executes in a context of a second identity domain of the plurality of isolated identity domains, the second identity domain being separate from the first identity domain;

selecting, from the plurality of OAuth service profiles that the OAuth authorization server maintains, a second OAuth service profile that is applicable only to the second identity domain;

determining, based on the second OAuth service profile, whether the second client application is permitted to access a second resource server; and

in response to determining that the second client application is permitted to access the second resource server, generating a second token for the second client application based on scope information that the OAuth authorization server obtains from the second resource server.

2. The computer-implemented method of claim 1, further comprising:

reading a first value for a particular attribute from the first OAuth service profile;

generating the first token with first characteristics based on the first value for the particular attribute;

reading a second value for the particular attribute from the second OAuth service profile, the second value differing from the first value; and

generating the second token with first characteristics based on the first value for the particular attribute;

wherein the particular attribute is a time-out value, and wherein the first and second values are different durations of time after which tokens expressing those values expire following issuance.

3. The computer-implemented method of claim 1, further comprising:

reading user attributes about a first user from a directory in response to receiving the request from the first client application the OAuth authorization server; and

inserting the user attributes into the first token as part of generating the first token;

wherein the request from the first client application is made by the first client application on behalf of the first user.

4. The computer-implemented method of claim 1, further comprising:

receiving, at the OAuth authorization server, a first authentication request to authenticate the first client application;

in response to receiving the first authentication request, selecting, from a plurality of client plug-ins, a first client plug-in that is mapped to the first identity domain;

sending the first authentication request to the first client-plug in;

receiving, at the OAuth authorization server, a second authentication request to authenticate the second client application;

in response to receiving the second authentication request, selecting, from a plurality of client plug-ins, a second client plug-in that is mapped to the second identity domain; and

sending the second authentication request to the second client plug-in;

wherein the second client plug-in is separate from the first client plug-in.

5. The computer-implemented method of claim 1, further comprising:

in response to the request from the first client application, generating the first token based on scope information that the OAuth authorization server obtains from multiple separate resource servers; and

returning the first token to the first client application;

wherein the request from the first client application requests access to multiple separate services provided by the multiple separate resource servers.

6. The computer-implemented method of claim 1, further comprising:

receiving, at the OAuth authorization server, a first authentication request to authenticate a first user that is defined within the first identity domain;

in response to receiving the first authentication request, selecting, from a plurality of adaptive access managers, a first adaptive access manager that is mapped to the first identity domain;

requesting, from the first adaptive access manager, information regarding whether an additional credential is to be requested from the first user as part of authentication;

receiving, at the OAuth authorization server, a second authentication request to authenticate a second user that is defined within the second identity domain;

in response to receiving the second authentication request, selecting, from the plurality of adaptive access managers, a second adaptive access manager that is mapped to the second identity domain; and

requesting, from the second adaptive access manager, information regarding whether an additional credential is to be requested from the second user as part of authentication;

wherein the second adaptive access manager is separate from the first adaptive access manager.

7. The computer-implemented method of claim 1, further comprising:

receiving, from a user, through an interface that uses Representational State Transfer (REST), consent for the first client application to access information about the user; and

storing the consent through the interface.

8. The computer-implemented method of claim 1, further comprising:

issuing, from the OAuth authorization server to a first application on a mobile device, a first client registration token that specifies at least a hardware identifier that is unique to the mobile device;

issuing, from the OAuth authorization server to a second application on the mobile device, a second client registration token that also specifies at least the hardware identifier that is unique to the mobile device;

in response to receiving the first client registration token from the first application, instructing the first application to authenticate a user of the first application;

after the user of the first application has been authenticated, creating, on the OAuth authorization server, in a device store that is associated with the hardware identifier, a user session for the user;

in response to receiving the second client registration token from the second application, determining that the hardware identifier contained in the second client registration token is associated with the device store; and

in response to determining that the hardware identifier contained in the second client registration token is associated with the device store, instructing the second application not to authenticate a user of the second application.

9. The computer-implemented method of claim 8, further comprising:

receiving, at the OAuth authorization server, from the first application on the mobile device, a device token that the first application received from a vendor-specific notification service as a result of registering with that vendor-specific notification service;

in response to receiving the device token, using the device token to send at least a portion of the first client registration token from the OAuth authorization server to the first application through the vendor-specific notification service, thereby at least partially issuing the first client registration token to the first application;

sending another portion of the first client registration token from the OAuth authorization server to the first application through a Hypertext Transfer Protocol (HTTP) channel separate from the vendor-specific notification service;

wherein the vendor-specific notification service is either Apple Push Notification Service (APNS) or Google Cloud Messaging (GCM).

10. A 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, a request from a first client application that executes in a context of a first identity domain of a plurality of isolated identity domains;

selecting, from a plurality of OAuth service profiles that the OAuth authorization server maintains, a first OAuth service profile that is applicable only to the first identity domain;

determining, based on the first OAuth service profile, whether the first client application is permitted to access a first resource server;

in response to determining that the first client application is permitted to access the first resource server, generating a first token for the first client application based on scope information that the OAuth authorization server obtains from the first resource server;

receiving, at the OAuth authorization server, a request from a second client application that executes in a context of a second identity domain of the plurality of isolated identity domains, the second identity domain being separate from the first identity domain;

selecting, from the plurality of OAuth service profiles that the OAuth authorization server maintains, a second OAuth service profile that is applicable only to the second identity domain;

determining, based on the second OAuth service profile, whether the second client application is permitted to access a second resource server; and

in response to determining that the second client application is permitted to access the second resource server, generating a second token for the second client application based on scope information that the OAuth authorization server obtains from the second resource server.

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

reading a first value for a particular attribute from the first OAuth service profile;

generating the first token with first characteristics based on the first value for the particular attribute;

reading a second value for the particular attribute from the second OAuth service profile, the second value differing from the first value; and

generating the second token with first characteristics based on the first value for the particular attribute;

wherein the particular attribute is a time-out value, and wherein the first and second values are different durations of time after which tokens expressing those values expire following issuance.

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

reading user attributes about a first user from a directory in response to receiving the request from the first client application the OAuth authorization server; and

inserting the user attributes into the first token as part of generating the first token;

wherein the request from the first client application is made by the first client application on behalf of the first user.

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

receiving, at the OAuth authorization server, a first authentication request to authenticate the first client application;

in response to receiving the first authentication request, selecting, from a plurality of client plug-ins, a first client plug-in that is mapped to the first identity domain;

sending the first authentication request to the first client-plug in;

receiving, at the OAuth authorization server, a second authentication request to authenticate the second client application;

in response to receiving the second authentication request, selecting, from a plurality of client plug-ins, a second client plug-in that is mapped to the second identity domain; and

sending the second authentication request to the second client plug-in;

wherein the second client plug-in is separate from the first client plug-in.

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

in response to the request from the first client application, generating the first token based on scope information that the OAuth authorization server obtains from multiple separate resource servers; and

returning the first token to the first client application;

wherein the request from the first client application requests access to multiple separate services provided by the multiple separate resource servers.

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

receiving, at the OAuth authorization server, a first authentication request to authenticate a first user that is defined within the first identity domain;

in response to receiving the first authentication request, selecting, from a plurality of adaptive access managers, a first adaptive access manager that is mapped to the first identity domain;

requesting, from the first adaptive access manager, information regarding whether an additional credential is to be requested from the first user as part of authentication;

receiving, at the OAuth authorization server, a second authentication request to authenticate a second user that is defined within the second identity domain;

in response to receiving the second authentication request, selecting, from the plurality of adaptive access managers, a second adaptive access manager that is mapped to the second identity domain; and

requesting, from the second adaptive access manager, information regarding whether an additional credential is to be requested from the second user as part of authentication;

wherein the second adaptive access manager is separate from the first adaptive access manager.

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

receiving, from a user, through an interface that uses Representational State Transfer (REST), consent for the first client application to access information about the user; and

storing the consent through the interface.

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

issuing, from the OAuth authorization server to a first application on a mobile device, a first client registration token that specifies at least a hardware identifier that is unique to the mobile device;

issuing, from the OAuth authorization server to a second application on the mobile device, a second client registration token that also specifies at least the hardware identifier that is unique to the mobile device;

in response to receiving the first client registration token from the first application, instructing the first application to authenticate a user of the first application;

after the user of the first application has been authenticated, creating, on the OAuth authorization server, in a device store that is associated with the hardware identifier, a user session for the user;

in response to receiving the second client registration token from the second application, determining that the hardware identifier contained in the second client registration token is associated with the device store; and

in response to determining that the hardware identifier contained in the second client registration token is associated with the device store, instructing the second application not to authenticate a user of the second application;

receiving, at the OAuth authorization server, from the first application on the mobile device, a device token that the first application received from a vendor-specific notification service as a result of registering with that vendor-specific notification service;

in response to receiving the device token, using the device token to send at least a portion of the first client registration token from the OAuth authorization server to the first application through the vendor-specific notification service, thereby at least partially issuing the first client registration token to the first application.

18. The computer-readable memory of claim 17, wherein the instructions, when executed by the one or more processors, cause the one or more processors to perform:

sending another portion of the first client registration token from the OAuth authorization server to the first application through a Hypertext Transfer Protocol (HTTP) channel separate from the vendor-specific notification service;

wherein the vendor-specific notification service is either Apple Push Notification Service (APNS) or Google Cloud Messaging (GCM).

19. An OAuth authorization server comprising:

one or more hardware processors configured to receive, at an OAuth authorization server, a request from a first client application that executes in a context of a first identity domain of a plurality of isolated identity domains;

one or more hardware processors configured to select, from a plurality of OAuth service profiles that the OAuth authorization server maintains, a first OAuth service profile that is applicable only to the first identity domain;

one or more hardware processors configured to determine, based on the first OAuth service profile, whether the first client application is permitted to access a first resource server;

one or more hardware processors configured to generate, in response to determining that the first client application is permitted to access the first resource server, a first token for the first client application based on scope information that the OAuth authorization server obtains from the first resource server;

one or more hardware processors configured to receive, at the OAuth authorization server, a request from a second client application that executes in a context of a second identity domain of the plurality of isolated identity domains, the second identity domain being separate from the first identity domain;

one or more hardware processors configured to select, from the plurality of OAuth service profiles that the OAuth authorization server maintains, a second OAuth service profile that is applicable only to the second identity domain;

one or more hardware processors configured to determine, based on the second OAuth service profile, whether the second client application is permitted to access a second resource server; and

one or more hardware processors configured to generate, in response to determining that the second client application is permitted to access the second resource server, a second token for the second client application based on scope information that the OAuth authorization server obtains from the second resource server.