O auth, OAuthAPI Access Delegation Protocol

1. URL: http://oauth.net/

2.  History
 What is OAuth
 Terminologies used for OAuth
 Working of OAuth protocol
 Flow
 Loopholes and drawbacks of Oauth
 OAuth 2.0
 Consumer Implementation (Twitter & Xero)
Contents

3. History
 OAuth started around November 2006, while Blaine Cook
was working on the Twitter OpenID implementation.
 In April 2007, a Google group was created with a small
group of implementers to write a proposal for an open
protocol.
 In July 2007 the team drafted an initial specification and the
group was opened to anyone interested in contributing.

4. What is OAuth
 Oaths is an authorization standard for API’s that does away
with logins and passwords to grant authorization to a
third-party
 Protocol that allows to share private data hosted on x web site
with y web site
 A way for an application to interact with an API on a user’s behalf
without knowing the user’s authentication
credentials.
 A protocol for developing password less APIs
 Its just a skeleton, Implementation can be vendor specific
In Short “your valet key for the Web”

5. Terminologies used for OAuth
 Consumer
Application trying to access protected resource
 Service Provider
website or web-service hosting protected resource
 User
Owner of the protected data
 Protected Resource
Images, Videos or documents hosted on web site or web-service which are protected by the
user
 Tokens
Random string of letters and numbers which is unique. Request Token, Access Token
 Scope
Set of data hosted on service provider that user wants to share with consumer

6. Working of OAuth protocol
 Web 2.0 means sharing data, through API
 Users want to access their data using many services
 Developers want to satisfy their users (and make it easy for them)
 Service providers need to keep their users data secure

7. Working of OAuth protocol
A Play in 3 Acts (to exchange authorization)
Actors on the scene
 User
 Consumer
 Service Provider

8. Working of OAuth protocol
A Play in 3 Acts (to exchange authorization)
consumer has
 Consumer key
 Consumer secret
Consumer (to Service Provider):
“give me a request token”
 oauth_consumer_key
 oauth_signature_method
 oauth_signature
 oauth_timestamp
 oauth_nonce
 oauth_version (optional)
 [additional parameters]

9. A Play in 3 Acts (to exchange authorization)
Service Provider (to consumer):
“here is the request token(you can use it only once!)”
 oauth_token (request token)
 oauth_token_secret
 [additional parameters]

10. A Play in 3 Acts (to exchange authorization)
Second Act
Where the User authorizes the Request Token
Consumer (to the User):
“Please go to the Service Provider and authorize this request”
consumer ->user ->service provider
 oauth_token (request token)
 oauth_callback
 [additional parameters]
Service Provider (to the User):
Do you authorize consumer to access your data?

11. A Play in 3 Acts (to exchange authorization)
User (to the Service Provider):
 YES!
 (or maybe NO :-) )
Service Provider (to the User):
“You can go back to the consumer”
Service Provider-> User->Consumer
 oauth_token (request token)

12. A Play in 3 Acts (to exchange authorization)
Third Act
Where the Consumer exchanges the Request Token for an Access
Token
Consumer (to the Service Provider):
“Please give me the acces token for the user”
 oauth_consumer_key
 oauth_token (request token)
 oauth_signature_method
 oauth_signature
 oauth_timestamp
 oauth_nonce
 oauth_version (optional)

13. A Play in 3 Acts (to exchange authorization)
Service Provider (to the Consumer):
“here is the access token for the user”
 oauth_token (access token)
 oauth_token_secret
 [additional parameters]
Now consumer accesses the resources
Consumer (to the Service Provider):
“Here i am again on behalf of the user”
 oauth_consumer_key
 oauth_token (access token)
 oauth_signature_method
 oauth_signature
 oauth_timestamp
 oauth_nonce
 oauth_version (optional)
 [additional parameters]

14. Flow

15. Working of OAuth protocol
 Site Y is the consumer and site X is service provider
 Site Y has consumer ID and shared secret provided by site X to all its OAuth consumers
 User accesses site Y and wants to share private data hosted on site X
 Site Y sends the request to site X with Consumer ID and shared secret and asks for Request
Token
 Site X returns Request Token to site Y
 Site Y redirects user to site X Login service with the request token
 User enters username/password or OpenID credentials to login to site X
 Site X validates the credentials, create Access token associated with the request token and
redirects the user to site Y with the request Token
 Site Y sends the request token to site X asking for Access token
 Site Y gets the access token to access protected resources hosted on site X (Access token is
valid only for limited period of time)

16. Loopholes and drawbacks of OAuth
 Trust on Consumer is key
 Consumer redirects user to the correct service provider
 Consumer uses the private only for the specific time period
 OAuth specifications Skeleton does not define resource
and signing algorithms used between consumer and
service provider
 OAuth specifications does not talk about endpoint
discovery, language support, XML-RPC support

17. OAuth 2.0
 OAuth 2.0 is the next evolution of the OAuth protocol and is
not backward compatible with OAuth 1.0, Main framework
was published in October 2012.
 Focuses on client developer simplicity
 Facebook's new Graph API only supports OAuth 2.0
 Google and Microsoft had added OAuth 2.0 experimental
support to their APIs
In July 2012, Eran Hammer resigned his role of lead author
for the OAuth 2.0. He points out that it has become
"more complex, less interoperable, less useful, more
incomplete, and most importantly, less secure"

18. Thank you