OAuth - Integrating web services across sites

Facilitated by Evan Henshaw-Plath, protest.net and Kellan Elliott-McCrea flickr

Description stolen from kellan's talk at xtech 2008. Hopefully by putting kellan's name on the page he'll be goaded in to joining Evan in giving the presentation.

OAuth is poised to be one of most important new standards in 2008. A simple standardization of delegated token auth, OAuth makes it straightforward to offer and consume APIs for a class of data under represented in the current set of API offerings—data about people, data that people want to keep private, and identity itself. We put the final touches on OAuth 1.0 in late 2007, and 2008 has already brought a rush of adoption of companies like MySpace, Google and Yahoo to Twitter, Pownce, and Mag.nol.ia.

So you’re interested. Now its time to take the next step.

This talk briefly cover why we designed OAuth the way we did, why it works, when it works, and when it doesn’t. Then we get to meat, twisting OAuth to work for you.

Using real world examples from our experience running OAuth predecessor Flickr Auth, the OAuth standardization process, and work on the new FireEagle API from Yahoo, the talk will cover:

   * How to use OAuth in a mobile environment.
   * How OAuth is useful for open source tools?
   * How to adapting existing APIs to use OAuth
   * Security considerations, and implications
   * How to extend and adapt the OAuth specification to your needs.

Bring your own OAuth questions, troublesome API, and architecture puzzlers, and we’ll see if we can wrangle those as well.

NOTES

OAuth Wrangling The solution to the anti-pattern that you see on the web today. You log in and it says "We'll find your friends just give us your emails and passwords and trust us not to be evil while we spam them just this one time." Turns out it is a bad thing because people have bank accounts tied to these things

Assumptions Advanced, simple and flexible (choose two) OAuth is... Oauth a protocol for passwordless APIs A way for apps to interact with API on a user's behalf without knowing the user's authentication credentials not OpenID (OID does authentication, OAuth does authorization

An emerging standard supported by the whole industry

Flickr still does API.execute($username,$password) DelegateTokenAuth

User and pass replaced with a token and token secret that are unique to the user, app and service provider

One-time usage

Love Triangle

END USER

  /			\

OAuth

OAuth flow (aka token dance)

Some quick vocab:

Service provider: website accessible via OAuth User: Consumer: Consumer key and secret: Protected resource: Authorization URL:

Consumer creates request token Requests from service provider Service app returns token to service provider which directs user to se Obtain user authorization Direct user to crequest access token grant access token access protected resources

flickr doesn't let you set preferences on what authorization grants yet

OAuth

Drupal apps should be able to interact with this You can use fire eagle to make request tokens within 24 hours but that is implementation

Authorizing a moveable type The experience for the user is

To make it all work we have to sign the request Non- base64 encoding of requests

Oauth is delegated token auth swic

the secret is the thing you store and don't pass over the wire HTTP codes when things expire

Custom authorization and encryption levels

Permissions Scope Rights Role

OAuth on the desktop You can do it for mobile and desktop apps like the flickr uploaders

You have 2 secrets! You have the application you've implemented and the user token Thou shalt not put a token and secret into the library. If you distribute it in a binary, you have to hide it.

Javascript implementations of oauth are problematic because the token and secret are public. Some use a little flash with its internal encryption to insulate the OAuth from most people.

The Ritual Coffee Attack - shoulder surfing is prevented because tokens are one-time use

make sure your authorization page is CSRF safe you need a real-time cookie verification in your forms that you check when you receive it. Otherwise you send an email you receive which has an image tag which has img src javascript request that XHTTPs a hidden iframe Open