Securing your Web API with OAuth


Published on

A talk given by me at

Attribution contained within the slides

Published in: Technology
1 Comment
  • Hi,
    can i get sample code for flickr authentication using Dotnetopen auth as you did for facebook authentication in

    Thanks in advance
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Securing your Web API with OAuth

    1. 1. Securing your Web API with OAuth <ul><li>Mohanaraj Gopala Krishnan </li></ul><ul><li>MYOSS Meetup 4 Dec 2008 </li></ul><ul><li> </li></ul>
    2. 2. Questions for you <ul><li>Experience with OAuth? </li></ul><ul><ul><li>Developed, read spec, heard of ? </li></ul></ul><ul><li>Application that exposes a Web API ? </li></ul><ul><ul><li>Authentication ? </li></ul></ul><ul><li>Experience using BBAuth, Authsub, Flickr Auth etc. ? </li></ul>
    3. 3. What is OAuth? <ul><li>A simple open standard for Web API authorization </li></ul><ul><li>End Users </li></ul><ul><ul><li>Share information between online services without disclosing passwords </li></ul></ul><ul><li>Web service (Service providers) </li></ul><ul><ul><li>Allow for secure access to your API in a user controlled, secure manner </li></ul></ul><ul><li>3rd Party application (Consumers) </li></ul><ul><ul><li>A standard authorization scheme for the web </li></ul></ul>
    4. 4. Valet key for your web
    5. 5. VS
    6. 6.
    7. 7. OpenID vs OAuth <ul><li>Goals are different </li></ul><ul><ul><li>OpenID is about sharing a single identity with different consumers </li></ul></ul><ul><ul><li>OAuth is about sharing your data with different consumers without sharing your identity </li></ul></ul><ul><li>Not mutually exclusive </li></ul>
    8. 8. OpenID vs OAuth <ul><li>Commonality </li></ul><ul><ul><li>Open protocols - community driven </li></ul></ul><ul><ul><li>Involves 3 parties </li></ul></ul><ul><ul><li>Involves moving the users between consumer and service provider </li></ul></ul><ul><ul><li>Involves laying a claim that is verified by the service/identity provider </li></ul></ul><ul><ul><ul><li>OpenID - “I own this URL” </li></ul></ul></ul><ul><ul><ul><li>OAuth - “I own this resource” </li></ul></ul></ul>
    9. 9. Love triangle End user Service provider Consumer
    10. 10. WTF ?!
    11. 11. “ Passwords are not confetti. Please stop throwing them around. Especially if they’re not yours ” Chris Messina
    12. 12. OAuth interaction demo <ul><li>Simple demo </li></ul><ul><ul><li> / </li></ul></ul>
    13. 13. OAuth dance steps
    14. 14. OAuth dance steps consumer key An identifier for the consumer to the service provider consumer secret Secret used to establish ownership of the consumer key request token A value that is used to obtain authorization from the user. Finally traded in for an access token. access token Value used to gain access to a protected resource on behalf of the user without requiring the users credentials token secret Secret used to establish ownership of a given token
    15. 15. OAuth dance steps <ul><li> </li></ul>
    16. 17. OAuth roles <ul><li>Service provider </li></ul><ul><ul><li>Implement three service endpoints </li></ul></ul><ul><ul><ul><li>Get request token </li></ul></ul></ul><ul><ul><ul><li>Authenticate request token </li></ul></ul></ul><ul><ul><ul><li>Exchange request token for access token </li></ul></ul></ul><ul><ul><li>Provides a form of authentication </li></ul></ul><ul><ul><li>Validates following requests (post OAuth dance) </li></ul></ul><ul><ul><li>Provides a mechanism to maintain authorization </li></ul></ul><ul><ul><li>Additional API services </li></ul></ul><ul><ul><ul><li>e.g. Access token lifecycle management - revocation, extension </li></ul></ul></ul>
    17. 18. <ul><li>Service providers need to allow for end users to manage their authorizations </li></ul>
    18. 19. OAuth roles <ul><li>Consumer </li></ul><ul><ul><li>Acquire consumer key / consumer secret </li></ul></ul><ul><ul><li>Communication with service provider </li></ul></ul><ul><ul><ul><li>Over HTTP - header, POST, GET query </li></ul></ul></ul><ul><ul><li>Signing requests </li></ul></ul><ul><ul><ul><li>HMAC-SHA1,RSA-SHA1,PLAINTEXT </li></ul></ul></ul><ul><ul><li>Keep track of access tokens </li></ul></ul><ul><ul><ul><li>Store association of users to access token </li></ul></ul></ul><ul><ul><ul><li>Service providers have different policy as to token lifetime-e.g. Goog vs Y! </li></ul></ul></ul><ul><ul><ul><li>Must be treated as securely as passwords </li></ul></ul></ul>
    19. 20. OAuth security
    20. 21. OAuth security <ul><li>Signing - allows for security beyond HTTP basic auth </li></ul><ul><ul><li>No secret over the wire beyond the dance </li></ul></ul><ul><ul><li>Request is verifiable - untampered </li></ul></ul><ul><li>Nonce & timestamps - mitigate replay attacks </li></ul><ul><li>Delegation of credentials instead of direct credentials </li></ul><ul><li>HTTPS still required for mitigating MITM - but if not too critical, request signing should suffice </li></ul>
    21. 22. Signature HMAC-SHA1 HTTP method Base URL Normalized parameters oauth parameters oauth_consumer_key, oauth_token, oauth_nonce, oauth_timestamp, oauth_signature_mothod, oauth_version request parameters param1,param2 oauth_signature = HMAC-SHA1(text,secret) consumer_secret & oauth_token_secret *also base64 encoded + urlencoded
    22. 23. Signature RSA-SHA1 HTTP method Base URL Normalized parameters oauth parameters oauth_consumer_key, oauth_token, oauth_nonce, oauth_timestamp, oauth_signature_mothod, oauth_version request parameters param1,param2 oauth_signature* = RSA-SHA1(text,secret) consumer_secret (consumer private key ) *also base64 encoded + urlencoded
    23. 24. OAuth usage environments <ul><li>Web application </li></ul><ul><ul><li>Standard case </li></ul></ul><ul><li>Gadgets </li></ul><ul><ul><li>contained within a larger consumer - OAuth Gadget extension </li></ul></ul><ul><li>2-legged OAuth </li></ul><ul><ul><li>No user involved - the consumer has been put in a position of trust - e.g. Google domain administrator or accessing public data </li></ul></ul><ul><ul><li>Extension implemented by Goog - Only HMAC-SHA1, no oauth_token, additional - xoauth_requestor_id - user to imitate, must be explicitly enabled </li></ul></ul><ul><li>Desktop apps / JS apps </li></ul><ul><ul><li>Consumer secret can be easily compromised - trust levels </li></ul></ul><ul><ul><li>Doesn’t compromise authorization </li></ul></ul>
    24. 25. Why bother? <ul><li>Large adoption - Goog, Y!, MySpace </li></ul><ul><li>Interop - Leverage the services </li></ul><ul><li>Can be used as a replacement for HTTP basic auth </li></ul><ul><ul><li>SSL might not be always necessary </li></ul></ul><ul><li>Part of the Open web stack </li></ul><ul><ul><li>Atompub + OpenID + OAuth + XRDS +OpenSocial </li></ul></ul>
    25. 26. Why bother ? “ OpenID + OAuth is the Final Nail in the Coffin of the WS-* vs. REST Discussion” Dare Obsanjo http://
    26. 27. State of OAuth <ul><li>OAuth Core 1.0, IETF Draft </li></ul><ul><li>Different use environments being worked out via extensions </li></ul><ul><li>Library support - extensive, but varying quality </li></ul><ul><li>OpenID + OAuth hybrid models </li></ul><ul><li>Usability funkiness </li></ul>
    27. 28. Implementations <ul><li>Libraries </li></ul><ul><ul><li> </li></ul></ul><ul><ul><li> </li></ul></ul><ul><li>Server implementations </li></ul><ul><ul><li>PHP - </li></ul></ul><ul><ul><li>Ruby - </li></ul></ul>
    28. 29. Thanks