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