Mohanraj - Securing Your Web Api With OAuth
Upcoming SlideShare
Loading in...5
×
 

Mohanraj - Securing Your Web Api With OAuth

on

  • 8,542 views

 

Statistics

Views

Total Views
8,542
Views on SlideShare
8,513
Embed Views
29

Actions

Likes
6
Downloads
193
Comments
1

2 Embeds 29

http://planet.foss.org.my 25
http://www.slideshare.net 4

Accessibility

Categories

Upload Details

Uploaded via as OpenOffice

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

11 of 1

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • Thanks for the slides. Wished I came fr the talk
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Mohanraj - Securing Your Web Api With OAuth Mohanraj - Securing Your Web Api With OAuth Presentation Transcript

  • Securing your Web API with OAuth
    • Mohanaraj Gopala Krishnan
    • MYOSS Meetup 4 Dec 2008
    • mohangk.org/blog
  • Questions for you
    • Experience with OAuth?
      • Developed, read spec, heard of ?
    • Application that exposes a Web API ?
      • Authentication ?
    • Experience using BBAuth, Authsub, Flickr Auth etc. ?
  • What is OAuth?
    • A simple open standard for Web API authorization
    • End Users
      • Share information between online services without disclosing passwords
    • Web service (Service providers)
      • Allow for secure access to your API in a user controlled, secure manner
    • 3rd Party application (Consumers)
      • A standard authorization scheme for the web
  • Valet key for your web http://toyotaownersclub.com/forums/index.php?showtopic=77384
  • VS
  • http://www.flickr.com/photos/leelefever/133949029/
  • OpenID vs OAuth
    • Goals are different
      • OpenID is about sharing a single identity with different consumers
      • OAuth is about sharing your data with different consumers without sharing your identity
    • Not mutually exclusive
  • OpenID vs OAuth
    • Commonality
      • Open protocols - community driven
      • Involves 3 parties
      • Involves moving the users between consumer and service provider
      • Involves laying a claim that is verified by the service/identity provider
        • OpenID - “I own this URL”
        • OAuth - “I own this resource”
  • Love triangle End user Service provider Consumer
  • WTF ?!
  • “ Passwords are not confetti. Please stop throwing them around. Especially if they’re not yours ” Chris Messina http://www.slideshare.net/carsonified/how-oauth-and-portable-data-can-revolutionize-your-web-app-chris-messina-presentation/
  • OAuth interaction demo
    • Simple demo
      • http://oauth.kg23.com /
  • OAuth dance steps http://flickr.com/photos/wigwam/2255831538/
  • 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
  • OAuth dance steps
    • http://www.googlecodesamples.com/oauth_playground/
  •  
  • OAuth roles
    • Service provider
      • Implement three service endpoints
        • Get request token
        • Authenticate request token
        • Exchange request token for access token
      • Provides a form of authentication
      • Validates following requests (post OAuth dance)
      • Provides a mechanism to maintain authorization
      • Additional API services
        • e.g. Access token lifecycle management - revocation, extension
    • Service providers need to allow for end users to manage their authorizations
  • OAuth roles
    • Consumer
      • Acquire consumer key / consumer secret
      • Communication with service provider
        • Over HTTP - header, POST, GET query
      • Signing requests
        • HMAC-SHA1,RSA-SHA1,PLAINTEXT
      • Keep track of access tokens
        • Store association of users to access token
        • Service providers have different policy as to token lifetime-e.g. Goog vs Y!
        • Must be treated as securely as passwords
  • OAuth security http://icanhascheezburger.com/2007/11/27/meh-security-system-let-me-showz-u-him/
  • OAuth security
    • Signing - allows for security beyond HTTP basic auth
      • No secret over the wire beyond the dance
      • Request is verifiable - untampered
    • Nonce & timestamps - mitigate replay attacks
    • Delegation of credentials instead of direct credentials
    • HTTPS still required for mitigating MITM - but if not too critical, request signing should suffice
  • 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
  • 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
  • OAuth usage environments
    • Web application
      • Standard case
    • Gadgets
      • contained within a larger consumer - OAuth Gadget extension
    • 2-legged OAuth
      • No user involved - the consumer has been put in a position of trust - e.g. Google domain administrator or accessing public data
      • Extension implemented by Goog - Only HMAC-SHA1, no oauth_token, additional - xoauth_requestor_id - user to imitate, must be explicitly enabled
    • Desktop apps / JS apps
      • Consumer secret can be easily compromised - trust levels
      • Doesn’t compromise authorization
  • Why bother?
    • Large adoption - Goog, Y!, MySpace
    • Interop - Leverage the services
    • Can be used as a replacement for HTTP basic auth
      • SSL might not be always necessary
    • Part of the Open web stack
      • Atompub + OpenID + OAuth + XRDS +OpenSocial
  • Why bother ? “ OpenID + OAuth is the Final Nail in the Coffin of the WS-* vs. REST Discussion” Dare Obsanjo http:// www.25hoursaday.com/weblog/2007/11/12/OpenIDOAuthIsTheFinalNailInTheCoffinOfTheWSVsRESTDiscussion.aspx
  • State of OAuth
    • OAuth Core 1.0, IETF Draft
    • Different use environments being worked out via extensions
    • Library support - extensive, but varying quality
    • OpenID + OAuth hybrid models
    • Usability funkiness
  • Implementations
    • Libraries
      • oauth.net/code
      • http://github.com/search?q=oauth&x=0&y=0
    • Server implementations
      • PHP - http://code.google.com/p/oauth-php/
      • Ruby - http://github.com/pelle/oauth/tree/master
  • Thanks