Introduction :
OAuth 2.0 defines a framework for securing application access to protected resources (often but not solely identity attributes of a particular user) through Application Programming Interfaces (APIs). There are three primary participants in the OAuth flow. OAuth allows a client (an application that desires information) to send an API query to a resource server (RS), the application hosting the desired information, such that the RS can authenticate that the message was indeed sent by the client. The client authenticates to the RS through the inclusion of an access token in its API message – a token previously provided to the client by an authorization server (AS). In those OAuth scenarios in which the API in question protects access to a user’s identity attributes, it may be the case that the access token will only be issued by the AS after the user has explicitly given consent to the client accessing those attributes.
The OAuth model :
Notwithstanding the above complexity, a useful organizing model for thinking of OAuth 2.0 is:
a. mechanisms by which a client can obtain a security token from an appropriate authority in order to use that token for authenticating a subsequent API call.
b. mechanisms by which a client can present a security token as part of an API call in order to authenticate itself (and thereby enable an authorization decision by the API hosting RS).
The above distinction can be simply described as ‘getting a token’ and ‘using a token.’ These two logical halves of OAuth are shown in the diagram below. The client ‘gets a token’ from the AS and then ‘uses the token’ to authenticate to the RS – behind which is the data the client desires to obtain or manipulate.
OAuth 2.0 Overview :
For an overview of OAuth 2.0, we use the previous distinction between ‘getting a token’ and ‘using a token.’
Getting a token
To get an access token, a client interacts with an authorization server, sending a request for an access token that includes an access grant. In some scenarios, the client also sends its own credentials to the AS on this request message.
OAuth defines five different access grant types – the different grant types reflecting different authorisation mechanisms:
1. Authorization code – the authorization code access grant is returned to the client after the resource owner explicitly gave his consent to the AS for the client’s desired privileges.
2. Resource owner credentials – this access grant implies the client collecting the resource owner’s password at the AS, and presenting the password to the AS on the access token request. While reminiscent of the password anti-pattern, the client must discard the password after using it to obtain the access token. Although Twitter uses this model for some mobile apps, it is not generally seen as preferred.
3. Refresh token – in some situations, OAuth allows the AS to return to the Client both an access token and an associated refresh token. Once the original access token expires, the corresponding refresh token can be sent to the AS in order to obtain a fresh access token. Refresh tokens are never sent to the RS.
4. Assertion – the assertion access grant involves the client trading some other representation of a resource owner’s identity and/or consent for an access token.
5. The client credentials access grant is special; it has the client presenting his own credentials to the AS in order to obtain an access token. This access token is either associated with the client’s own resources and not a particular resource owner, or is associated with a resource owner for which the client is otherwise authorized to act.
Related to the above access grant types are four client profiles – web server, user-agent, native application, and autonomous. The four profiles stipulate how a client can obtain an access token from an AS in a given deployment model (typically with particular constraints and challenges) and which of the access grant types are relevant for such deployments. For instance, the web server profile is optimized for clients capable of redirecting the resource owner’s browser to the AS and that are capable of protecting a client credential used to authenticate to the AS when trading an authorization code for an access token.
Using a token
To use an access token, a client interacts with an RS – including the access token previously obtained from the AS on its API call to the RS. The access token serves to allow the RS to determine that the client is authorized to access the resources in question.
OAuth 2.0 will allow for two broad categories of access tokens: bearer tokens (in which the mere possession of the access token will be interpreted as providing sufficient proof to the RS that the entity presenting the token is the same as that to which the AS issued it) and Holder of Key tokens (in which the client will need to demonstrate knowledge of some secret bound to the token in order for the RS to grant access to the corresponding resources).
Token type
OAuth 1.0a did not stipulate a particular structure for access tokens; by default they were opaque text strings that served only to look up the corresponding set of authorizations. Work is now underway in the IETF OAuth 2.0 Working Group to define, in addition to the opaque token model, a JSON (JavaScript Object Notation) formatted structured alternative – providing similar advantages as do SAML assertions.
The advantages of OAuth 2.0
A standardised protocol supported by a wider set of Service Providers.
like Facebook, Google,LinkedIn, ...
The user grants access for a consumer to a specific resource by providing an access token to the consumer. The user need not to be online, when the consumer accesses the resource, i.e. actually makes use of the access token.
The consumer always requires the consent of the user for receiving the access token.
The user is in full control of who can access his resources.
OAuth 2.0 Roles :
Resource Owner
Resource Server
Client Application
Authorisation Server
These roles are illustrated in this diagram:
The resource owner is the person or application that owns the data that is to be shared. For instance, a user on Facebook or Google could be a resource owner. The resource they own is their data. The resource owner is depicted in the diagram as a person, which is probably the most common situation.
The resource server is the server hosting the resource owned by the resource server. For instance, Facebook or Google is a resource server (or has a resource server).
The client application is the application requesting access to the resources stored on the resource server. The resources, which are owned by the resource owner. A client application could be a game requesting access to a user's Facebook account.
The authorisation server is the server authorizing the client app to access the resources of the resource owner. The authorization server and the resource server can be the same server, but it doesn't have to. The OAuth 2.0 specification does not say anything about how these two servers should communicate, if they are separate. This is an internal design decision to be made by the resource server + authorization server developers.
Conclusions
The API is a key technical underpinning of the cloud – more and more, it will be through APIs that cloud data moves. OAuth enables a single, consistent, and flexible identity and policy architecture for web applications, web services, devices, and desktop clients for accessing cloud APIs. Critically, OAuth’s token-based architecture provides important security characteristics compared to alternative API security mechanisms – including delegation support, replay prevention, and granular permissions.
References :
http://oauth.net/code/
http://code.google.com/p/oauth/
http://oauth.googlecode.com/svn/code/java/core/
http://oauth.googlecode.com/svn/code/java/example/
http://tutorials.jenkov.com/oauth2/index.html
http://www.youtube.com/watch?v=LRNg4tDtrkE
http://www.youtube.com/watch?v=2KG05SnAYlE&feature=relmfu
http://www.youtube.com/watch?v=qPHLsLlQ7Rw&feature=relmfu
http://www.youtube.com/watch?v=0PvQcLzVGF0&feature=relmfu
http://tutorials.jenkov.com/oauth2/roles.html
OAuth 2.0 defines a framework for securing application access to protected resources (often but not solely identity attributes of a particular user) through Application Programming Interfaces (APIs). There are three primary participants in the OAuth flow. OAuth allows a client (an application that desires information) to send an API query to a resource server (RS), the application hosting the desired information, such that the RS can authenticate that the message was indeed sent by the client. The client authenticates to the RS through the inclusion of an access token in its API message – a token previously provided to the client by an authorization server (AS). In those OAuth scenarios in which the API in question protects access to a user’s identity attributes, it may be the case that the access token will only be issued by the AS after the user has explicitly given consent to the client accessing those attributes.
The OAuth model :
Notwithstanding the above complexity, a useful organizing model for thinking of OAuth 2.0 is:
a. mechanisms by which a client can obtain a security token from an appropriate authority in order to use that token for authenticating a subsequent API call.
b. mechanisms by which a client can present a security token as part of an API call in order to authenticate itself (and thereby enable an authorization decision by the API hosting RS).
The above distinction can be simply described as ‘getting a token’ and ‘using a token.’ These two logical halves of OAuth are shown in the diagram below. The client ‘gets a token’ from the AS and then ‘uses the token’ to authenticate to the RS – behind which is the data the client desires to obtain or manipulate.
OAuth 2.0 Overview :
For an overview of OAuth 2.0, we use the previous distinction between ‘getting a token’ and ‘using a token.’
Getting a token
To get an access token, a client interacts with an authorization server, sending a request for an access token that includes an access grant. In some scenarios, the client also sends its own credentials to the AS on this request message.
OAuth defines five different access grant types – the different grant types reflecting different authorisation mechanisms:
1. Authorization code – the authorization code access grant is returned to the client after the resource owner explicitly gave his consent to the AS for the client’s desired privileges.
2. Resource owner credentials – this access grant implies the client collecting the resource owner’s password at the AS, and presenting the password to the AS on the access token request. While reminiscent of the password anti-pattern, the client must discard the password after using it to obtain the access token. Although Twitter uses this model for some mobile apps, it is not generally seen as preferred.
3. Refresh token – in some situations, OAuth allows the AS to return to the Client both an access token and an associated refresh token. Once the original access token expires, the corresponding refresh token can be sent to the AS in order to obtain a fresh access token. Refresh tokens are never sent to the RS.
4. Assertion – the assertion access grant involves the client trading some other representation of a resource owner’s identity and/or consent for an access token.
5. The client credentials access grant is special; it has the client presenting his own credentials to the AS in order to obtain an access token. This access token is either associated with the client’s own resources and not a particular resource owner, or is associated with a resource owner for which the client is otherwise authorized to act.
Related to the above access grant types are four client profiles – web server, user-agent, native application, and autonomous. The four profiles stipulate how a client can obtain an access token from an AS in a given deployment model (typically with particular constraints and challenges) and which of the access grant types are relevant for such deployments. For instance, the web server profile is optimized for clients capable of redirecting the resource owner’s browser to the AS and that are capable of protecting a client credential used to authenticate to the AS when trading an authorization code for an access token.
Using a token
To use an access token, a client interacts with an RS – including the access token previously obtained from the AS on its API call to the RS. The access token serves to allow the RS to determine that the client is authorized to access the resources in question.
OAuth 2.0 will allow for two broad categories of access tokens: bearer tokens (in which the mere possession of the access token will be interpreted as providing sufficient proof to the RS that the entity presenting the token is the same as that to which the AS issued it) and Holder of Key tokens (in which the client will need to demonstrate knowledge of some secret bound to the token in order for the RS to grant access to the corresponding resources).
Token type
OAuth 1.0a did not stipulate a particular structure for access tokens; by default they were opaque text strings that served only to look up the corresponding set of authorizations. Work is now underway in the IETF OAuth 2.0 Working Group to define, in addition to the opaque token model, a JSON (JavaScript Object Notation) formatted structured alternative – providing similar advantages as do SAML assertions.
The advantages of OAuth 2.0
A standardised protocol supported by a wider set of Service Providers.
like Facebook, Google,LinkedIn, ...
The user grants access for a consumer to a specific resource by providing an access token to the consumer. The user need not to be online, when the consumer accesses the resource, i.e. actually makes use of the access token.
The consumer always requires the consent of the user for receiving the access token.
The user is in full control of who can access his resources.
OAuth 2.0 Roles :
Resource Owner
Resource Server
Client Application
Authorisation Server
These roles are illustrated in this diagram:
The resource owner is the person or application that owns the data that is to be shared. For instance, a user on Facebook or Google could be a resource owner. The resource they own is their data. The resource owner is depicted in the diagram as a person, which is probably the most common situation.
The resource server is the server hosting the resource owned by the resource server. For instance, Facebook or Google is a resource server (or has a resource server).
The client application is the application requesting access to the resources stored on the resource server. The resources, which are owned by the resource owner. A client application could be a game requesting access to a user's Facebook account.
The authorisation server is the server authorizing the client app to access the resources of the resource owner. The authorization server and the resource server can be the same server, but it doesn't have to. The OAuth 2.0 specification does not say anything about how these two servers should communicate, if they are separate. This is an internal design decision to be made by the resource server + authorization server developers.
Conclusions
The API is a key technical underpinning of the cloud – more and more, it will be through APIs that cloud data moves. OAuth enables a single, consistent, and flexible identity and policy architecture for web applications, web services, devices, and desktop clients for accessing cloud APIs. Critically, OAuth’s token-based architecture provides important security characteristics compared to alternative API security mechanisms – including delegation support, replay prevention, and granular permissions.
References :
http://oauth.net/code/
http://code.google.com/p/oauth/
http://oauth.googlecode.com/svn/code/java/core/
http://oauth.googlecode.com/svn/code/java/example/
http://tutorials.jenkov.com/oauth2/index.html
http://www.youtube.com/watch?v=LRNg4tDtrkE
http://www.youtube.com/watch?v=2KG05SnAYlE&feature=relmfu
http://www.youtube.com/watch?v=qPHLsLlQ7Rw&feature=relmfu
http://www.youtube.com/watch?v=0PvQcLzVGF0&feature=relmfu
http://tutorials.jenkov.com/oauth2/roles.html
0 comments:
Post a Comment