OAuth Explained

OAuth Explained in PHPDev Meetup #3

Transcript

2. I am Sanjeev @sanjeevshrestha www.sanjeevshrestha.com.np
3. Plan for today  Talk about access and privacy  OAuth  Demo
4. Plethora of Services
5. Applications using Services
6. Have you ever...  Dealt with user authentication?  Used an external API in your application?  Used an Application to manage your twitter? − e.g. hottot, tweetdeck etc  Linked your facebook and twiter account?  How many applications have your password?  Do you trust them all?
7. Email and Passwords are valuable
8. How can we delegate access to obtain restricted information without giving out passwords to applications?
9. OAuth
10. OAuth is an open standard for authorization
11. Who can use it?  Service Providers offering web service or API that requires authentication to access restricted data for a number of functions / methods  Consumers who wish to access that particular API or Web Service and wish to use a standard method of authentication
12. Terminology USER CLIENT SERVER App used to access service Also known as “Consumer” e.g. your app Server where the service run Also known as “Service Provider” e.g. twitter, facebook Person using the service (on Server) Also known as “Resource Owner”
13. The Love Triangle End User Consumer Service Provider
14. Consumer Provider Asks for a request token Consumer saves the access token for the user Redirects user to provider with token in url Consumer wants to trade request token for access token Creates and returns a new request token User selects preferences and approves auth Provisional request token traded for access token Redirected back to consumer with request token Authroization Steps
15. Consumer App does not need to know user account details
16. Using OAuth in your Apps  Register your app as consumer  Obtain Consumer Key and Consumer Secret  Get the request token url − https://api.twitter.com/oauth/request_token  Get authorize url − https://api.twitter.com/oauth/authorize  Get Access token url − https://api.twitter.com/oauth/access_token
17. OAuth Objects - Consumer  Consumer Key − assigned during consumer registration − passed as a request parameter  Consumer Secret − assigned during consumer registration − used for signing (e.g. HMAC-SHA1)
18. OAuth Objects - Token  Token key − unique string granted by service provider − passed as a request parameter − same variable name (oauth_token) for − both request and access type tokens  Token Secret − also granted by service provider − same variable name (oauth_token_secret) − for both request and access type tokens
19. OAuth Parameters  oauth_consumer_key  oauth_token  oauth_signature  oauth_signature_method  oauth_timestamp  oauth_nonce  oauth_version
20. Where is this information passed?  HTTP Authorization header  HTTP POST request body (form params)  URL query string parameters
21. Timestamp and Nonce  oauth_timestamp − seconds since Unix epoch (unless otherwise specified by service provider) − must be equal or greater than previous request  oauth_nonce − random string per timestamp / request − attempt to stop replay attacks
22. Signing Requests  oauth_signature_method − HMAC-SHA1 − RSA-SHA1 − PLAINTEXT  oauth_signature − string constructed according to the chosen signature method
23. HMAC-SHA1  Construct the signature base string by joining the following with a '&' − HTTP request method (e.g. GET) − HTTP url (endpoint url) − Normalized request parameters (sorted by name)  Key − Encoded consumer secret and token secret separated by an '&'
24. PLAINTEXT  Should be used over a secure channel (SSL)  No base string  Url-encoded consumer secret and token secret separated by an '&'
25. RSA-SHA1  Sign with Consumer's RSA Private key and the signature base string  Verify with Consumer's RSA public key  Same signature base string as HMAC-SHA1  Still in development for most OAuth libraries
26. Demo http://apps.joomlaleads.com/twitter
27. Benefits of OAuth  Standard Protocol & Implemented by many providers  User has control over access and can easily revoke consumers and application privileges  Track token usage and statistics  Also there are many open source libraries available to implement both consumer and provider  No Personal information is shared
28. Where not to use OAuth?  If the application is not acting on behalf of a user, do not use oauth  Where commercial grade cryptography is required .e.g. pki
29. OAuth 1.0a and OAuth 2.0  OAuth 2.0 supports non-browser based applications better  OAuth 2.0 has dropped cryptography in favor of bearer tokens over SSL  Signatures are less complicated in OAuth2.0  Access Tokens are short lived (refresh tokens are used to get new access tokens)  Authorization Server and Service Server can be separated
30. More info  http://www.oauth.net  http://en.wikipedia.org/wiki/Public- key_infrastructure  http://en.wikipedia.org/wiki/HMAC  https://dev.twitter.com/
31. Thank you