An identity management system is an information system, or a set of technologies that can be used for enterprise or cross-network identity management. Identity management describes the management of individual identities, their authentication, authorization, roles, and privileges within or across system and enterprise boundaries with the goal of increasing security and productivity while decreasing cost, downtime, and repetitive tasks. One aspect of identity management is “single sign-on” (SSO). One standard that is particularly useful in the field of identity management is OAuth.
SSO is a property of access control of multiple related but independent software systems. With this property, a user logs in once and gains access to all systems without being prompted to log in again at each of them. Conversely, single sign-off is the property whereby a single action of signing out terminates access to multiple software systems. As different applications and resources support different authentication mechanisms, single sign-on internally translates to and stores different credentials compared to what is used for initial authentication. SSO reduces phishing success, because users are not trained to enter passwords everywhere without thinking SSO reduces password fatigue from different user name and password combinations. SSO reduces time spent re-entering passwords for the same identity. SSO reducing information technology (IT) costs due to a lower number of IT help desk calls about passwords. SSO provides security on all levels of entry/exit/access to systems without the inconvenience of re-prompting users. SSO also allows for centralized reporting for compliance adherence. SSO uses centralized authentication servers that all other applications and systems utilize for authentication purposes, and combines this with techniques to ensure that users do not have to actively enter their credentials more than once.
OAuth is an open standard for authorization. An indirect effect of authorization is authentication. OAuth allows users to share their private resources (e.g., photos, videos, contact lists, etc.) stored on one site with another site without having to hand out their credentials, typically supplying username and password tokens instead. Each token grants access to a specific site for specific resources and for a defined duration. This allows a user to grant a third party site access to their information stored with another service provider, without sharing their access permissions or the full extent of their data. For example, a token might grant access to a video editing site for videos from a specific album for the next two hours.
For example, in a typical scenario, a user of LinkedIn might be asked for permission to import, into LinkedIn, that user's contacts from Yahoo. LinkedIn might want to obtain these contacts in order to send e-mail messages inviting each of the user's contacts to join LinkedIn, for example. Prior to OAuth, this request for permission might have involved a request that the user provide, to LinkedIn, the user's Yahoo user identity and password. This information was requested so that LinkedIn could log-in to the user's Yahoo account as that user, and then obtain that user's contacts from that user's Yahoo account. Generally speaking, permitting LinkedIn (or any site) with the user's Yahoo (or any other site) identity and password is a bad idea because it grants the former site unlimited access to the user's account on the latter site. Such unlimited access is nearly always much more access than the former site actually requires to accomplish its goal, such as merely obtaining a contact list.
A better idea is to provide the former site with a limited authorization relative to the user's account on the latter site. The limited authorization may specify a specific set of operations that the former site can perform relative to the user's account on the latter site. For example, referring to the typical scenario above, the limited authorization might specify that LinkedIn can only access the user's contact list, but perform no other operations relative to the user's account, on Yahoo. OAuth allows for such limited authorization. OAuth provides delegation of authorization.
The technique by which OAuth delegates authorization may be understood relative to an analogy. Often, when a car owner temporarily relinquishes control of his car to a valet so that the valet can park the car for the owner, the owner does not provide a general-use master key to the valet, but instead provides a more limited-use valet key to the valet. The valet key permits the valet with sufficient access to drive the car, but does not provide the valet with access to everything that the owner possesses within the car. In the same manner, the use of OAuth may grant a first site access to a user's contact list stored by a second site, without also permitting the first site to perform other operations relative to the user's account on the second site—such as reading e-mail messages that might be stored on the second site, for example. OAuth allows the first site to be given a limited authorization to perform a specified set of operations, and no others, relative to the second site.
For another example, a user might want to use a photo printing service provided by a first site, such as Snapfish, to print certain color photos that are electronically stored on a second site, such as Flickr, which is independent of the first site. More specifically, the user might want to print only the photos that are stored in a particular album on Flickr, such as an album containing photos from the user's recent visit to Alaska. Although the user might have a multitude of different albums stored on his Flickr account, the user might want to print only the photos from the Alaska album. Under such circumstances, the user probably prefers that Snapfish does not access the contents of any of his Flickr albums other than those contained within the Alaska album. In the foregoing scenario, using OAuth terminology, Snapfish is considered to be a client, and Flickr is considered to be a resource server (the photo data being the resources) as well as an OAuth authorization server. As the owner of the resources (e.g., photo data) stored by the resource server, the user is also a resource owner.
Given the example presented above, the user might first use his Internet browser application to instruct the client (e.g., Snapfish) to print the photos in the user's Alaska album on the resource server (e.g., Flickr). In response, the client (e.g., Snapfish) redirects the user to the site of the resource server (e.g., Flickr). This redirection operation may indicate, to the resource server, the limited set of data (e.g., contents of the Alaska album) to which the client desires access. At that moment, the resource server does not know who the user is, as the user has not yet authenticated himself to the resource server. Therefore, the resource server requires the user to authenticate. As is mentioned above, an indirect effect of authorization is authentication. After the user authenticates himself to the resource server (e.g., by providing his username and password that are relevant to the resource server), the resource server sends a consent page to the user's Internet browser. The consent page asks the user to verify that the resource server (e.g., Flickr) has the user's permission to provide a limited, specified set of data (e.g., contents of the Alaska album) to the client (e.g., Snapfish). Assuming that the user consents, the resource server then responsively sends an authorization code to the client. This authorization code may be sent through the “front channel;” or, in other words, via the user's Internet browser using a redirect.
For purposes of the following discussion, the resource server also serves the role of OAuth authorization server, but is referred to as being the resource server. In this scenario, the client (e.g., Snapfish) is a trusted partner of the resource server (e.g., Flickr). The client receives the authorization code, or “grant,” and stores the authorization code. The client maintains this authorization code indefinitely, until the user actively revokes that authorization code. The user may log-in to the OAuth authorization server in order to see a list of grants that the OAuth authorization server has provided on the user's behalf to various clients. In response to receiving the authorization code, the client (e.g., Snapfish) makes a “back channel” call to the resource server (e.g., Flickr). A back channel call is a communication that does not involve the user's Internet browser. The back channel call requests an access token from the resource server. The access token specifies the scope of the access that the client is permitted to the user's account on the resource server. For example, the access token might indicate that the client is permitted access only to contents of the user's Alaska album. The resource server sends the requested access token back to the client via the back channel. The client stores the access token. Thereafter, until the access token expires, or until the user revokes the grant (i.e., the authorization code), the client can present the access token to the resource server in order to access, on the resource server, the resources specified by the access token. If the user has already revoked the grant related to the access token, then the access token becomes ineffective even if the access token has not yet expired.
In addition to an access token, the resource server may provide a “refresh token” to the client. While the access token often has a specified longevity after which it expires, a refresh token is a long-lived token. The client may store the refresh token along with the related access token. Thereafter, if the resource server objects that the client's current access token has expired, then the client may present the refresh token to the resource server in order to obtain a new access token from the resource server.
Beneficially, the approach employed by OAuth avoids the disclosure, to the client, of the user's password for the user's account on the resource server. The avoidance of this disclosure of credentials prevents the client from performing unauthorized actions relative to the user's account on the resource server. The only time that the user supplies his password is during the user's initial authentication directly with the resource server, after being redirected from the client's site.
USPTO Backgrounds
USPTO Backgrounds