OAuth - Integrating web services across sites
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.
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
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
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.
The Ritual Coffee Attack - shoulder surfing is prevented because tokens are one-time use