Securing your Web API with OAuth Mohanaraj Gopala Krishnan MYOSS Meetup 4 Dec 2008 mohangk.org/blog

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. ?

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

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

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”

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 /

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/

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 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

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

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

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

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

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

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

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