Search This Blog

Friday, January 22, 2010

OAuth Web Resource Authorization Profiles

IETF has published an Internet Draft for "OAuth Web ResourceAuthorization Profiles." The OAuth Web Resource Authorization Profiles(OAuth WRAP) allow a server hosting a Protected Resource to delegateauthorization to one or more authorities. An application (Client)accesses the Protected Resource by presenting a short lived, opaque,bearer token (Access Token) obtained from an authority (AuthorizationServer). There are Profiles for how a Client may obtain an Access Tokenwhen acting autonomously or on behalf of a User.
Background: "As the internet has evolved, there is a growing trend fora variety of applications (Clients) to access resources through an APIover HTTP or other protocols. Often these resources require authorizationfor access and are Protected Resources. The systems that are trustedto make authorization decisions may be independent from the ProtectedResources for scale and security reasons. The OAuth Web ResourceAuthorization Profiles (OAuth WRAP) enable a Protected Resource todelegate the authorization to access a Protected Resource to one ormore trusted authorities.
Clients that wish to access a Protected Resource first obtainauthorization from a trusted authority (Authorization Server). Differentcredentials and profiles can be used to obtain this authorization, butonce authorized, the Client is provided an Access Token, and possiblea Refresh Token to obtain new Access Tokens. The Authorization Servertypically includes authorization information in the Access Token anddigitally signs the Access Token. Protected Resource can verify thatan Access Token received from a Client was issued by a trustedAuthorization Server and is valid. The Protected Resource can thenexamine the contents of the Access Token to determine the authorizationthat has been granted to the Client.
The Access Token is opaque to the Client, and can be any format agreedto between the Authorization Server and the Protected Resource enablingexisting systems to reuse suitable tokens, or use a standard tokenformat such as a Simple Web Token or JSON Web Token. Since the AccessToken provides the Client authorization to the Protected Resource forthe life of the Access Token, the Authorization Server should issueAccess Tokens that expire within an appropriate time. When an AccessToken expires, the Client requests a new Access Token from theAuthorization Server, which once again computes the Client'sauthorization, and issues a new Access Token... Two Profiles arerecommended for scenarios involving a Client acting autonomously:(1) Client Account and Password Profile, where the Client is provisionedwith an account name and corresponding password by the AuthorizationServer; (2) Assertion Profile, which enables a Client with a SAML orother assertion recognized by the Authorization Server...
More Info

No comments: