?

Log in

No account? Create an account
entries friends calendar profile My Website Previous Previous Next Next
Mark Atwood
fallenpegasus
fallenpegasus
First public draft of OAuth spec
Something I've been working on is OAuth. We just released our first public draft of the spec.

Have you used a website that has asked for the passwords to your email and IM accounts, so it can find your friends who are also there? Or a site that asks for your Flickr password so it can print your private photos?

They shouldn't do that! You have to trust them that nobody is sniffing your password to them, nobody is sniffing your password from them, they aren't recording it accidentally or intentionally, recording it in logs, and that it's not being stolen by some wage slave working in a body shop in India. You have to trust them more than they should be trusted, even if they have the best of intentions.

Google's AuthSub, Yahoo's BBAuth, AOL's OpenAuth, and Flickr's FlickrAuth. OAuth works the same way, only better. It it surely more secure than asking people to trust joebloe.com with their email passwords. And it's no harder to use.

Now that the 1.0 spec is pretty much nailed down, software is starting to show up. We hope to soon have useful modules for clients and for servers, for libcurl and for Apache, for Python, Perl, Ruby, and PHP.

If you write mashups, you need this.

If you run a useful web service or any sort of web API, you need this. You can't avoid being built in a mashup. Your only choice is to use an auth protocol, or have your users compromise their passwords.

And if you're not an geek web developer, and just want to use the web to browse, work, play, and connect with people, all you need to do now is whenever some site asks for your password to some other site, utterly refuse, and instead send them a note asking them why they don't support OAuth instead.


Here are some blog posts about it from other people involved: (link) and (link) (link). They do pretty good jobs of explaining it as well.

Tags: ,
Current Location: Starbucks, Redmond Town Center, Redmond WA
Current Music: random Starbucks muzak

3 comments or Leave a comment
Comments
awfief From: awfief Date: September 22nd, 2007 04:40 pm (UTC) (Link)
Interesting. I utterly refuse to give a third party information like passwords to another account in general. I guess I can see the desire, though. Because the only other option is to try to use the service "everyone" uses, and then be surprised to find another person on it that I already knew.

For me, that's definitely in the way future, but I think OAuth is one thing that will convince me to go there. So, thanx for the work you're putting into it!
happypete From: happypete Date: September 25th, 2007 01:12 am (UTC) (Link)

quick question...

what distinguishes this from the existing schemes that have tried [and in some cases died] viz.:

-- MS Passport
-- Netscape's offering [so short-lived, I already forgot it's name]
-- AOL ScreenName Service
-- OpenID

I could go on, but you get the idea.
fallenpegasus From: fallenpegasus Date: September 25th, 2007 01:51 am (UTC) (Link)

Re: quick question...

First of all, it does something rather orthoginal to those. (The original impetitus was when someone noticed that you couldnt do a password authenticated API when you are OpenID enable).

Next, we don't need to sell it to the end users, we just have to sell it to the developers who develop web APIs, and to the developer who write clients to web APIs.

The people in the first group already have to do something, either put passwords into HTTP requests (security zero, and your users will start giving mashup sites their password to your site), or demand client-side certs (yeah, right, pull the other finger) or else write their own Auth API anyway, and then convience all the folks writing mashes and clients to your service to support it. (Barely doable if you are as big as Amazon, Google, Yahoo, or AOL. Not so much for everyone else.)

We have a bunch of web API providers literally right now waiting for the OAuth 1.0 final doc, at which point they will start supporting it. We hope that will cause a critical mass effect.

The folks who write clients of web APIs, they also have to already right now do something and what they have to do now is dictacted by the site, or else "scrap" HTML and store passwords (nightmare to code, hard to maintain, security less than zero).

Since everyone in this space has to do something like this already anyway, it costs them nothing and gives them a lot of value to, when they do auth anyway, do it via oauth. Why spend the time and pain when someone has given it to you for free.

We're also writing free client libraries and server libraries for lots of languages and lots of platforms. Thus making it even easier for new and small sites to decide to use it.

Notice that we don't have to sell the end users on it. They dont need to sign up for anything new, they dont have to put any software on their computer they werent going to install anyway. Tho if we can get the sophisticated end users to put pressure and shame on sites with apis who dont have an auth api, all the better.

The end users also dont have to trust anyone they weren't already trusting. No 3rd or 4th parties are involved who weren't already involved.
3 comments or Leave a comment