OAuth Documentation Preview
Matt Sanford
We launched our OAuth code to production yesterday with employee-
only access to check for any problems that didn't show up during our
testing. We've been running it through it's paces and fully plan to
have it open to the closed beta group by next week. If you didn't hear
back from Alex and I don't worry, we're working to expand the beta
once things are a bit more stable. As part of a company meeting today
I presented OAuth to the people who haven't been working on it via a
demo app I wrote … it was exciting times to see this run on
production. I think of the application developers on this list as an
extension of our team so I don't want to wait until next week to send
you the documentation. I wrote up a quick how-to sort of thing on the
wiki about writing a very simple OAuth app for Ruby on Rals. Check it
out at http://bit.ly/api-oauth-ruby.
With any luck we can add some more examples and things during this
beta period, most notably in PHP since that seems to be the majority
of the questions on the list.
Thanks;
— Matt Sanford
Ivan
I'll try to post some Python / Django code as we get things working
for Tipjoy.
Ivan
http://tipjoy.com
On Feb 7, 12:52 am, Matt Sanford <m...@twitter.com> wrote:
> Hi all,
>
> We launched our OAuth code to production yesterday with employee-
> only access to check for any problems that didn't show up during our
> testing. We've been running it through it's paces and fully plan to
> have it open to the closed beta group by next week. If you didn't hear
> back from Alex and I don't worry, we're working to expand the beta
> once things are a bit more stable. As part of a company meeting today
> I presented OAuth to the people who haven't been working on it via a
> demo app I wrote … it was exciting times to see this run on
> production. I think of the application developers on this list as an
> extension of our team so I don't want to wait until next week to send
> you the documentation. I wrote up a quick how-to sort of thing on the
> wiki about writing a very simple OAuth app for Ruby on Rals. Check it
Jesse Stay
dean.j.robinson
in Hahlo. A PHP example, even a very basic one, would be very much
appreciated as I've never worked with OAuth before. Looking forward to
hearing more details in the next week or so.
thanks
Dean
Matt Sanford
Shannon Whitley
author need to maintain a website to perform the authentication? I
don't see how it can be done otherwise.
On Feb 6, 9:52 pm, Matt Sanford <m...@twitter.com> wrote:
> Hi all,
>
> We launched our OAuth code to production yesterday with employee-
> only access to check for any problems that didn't show up during our
> testing. We've been running it through it's paces and fully plan to
> have it open to the closed beta group by next week. If you didn't hear
> back from Alex and I don't worry, we're working to expand the beta
> once things are a bit more stable. As part of a company meeting today
> I presented OAuth to the people who haven't been working on it via a
> demo app I wrote … it was exciting times to see this run on
> production. I think of the application developers on this list as an
> extension of our team so I don't want to wait until next week to send
> you the documentation. I wrote up a quick how-to sort of thing on the
> wiki about writing a very simple OAuth app for Ruby on Rals. Check it
Cameron Kaiser
> author need to maintain a website to perform the authentication? I
> don't see how it can be done otherwise.
Certain apps that have a web view potential could do it by redirecting to
the provider, but yes, this is the point that Ed and I were making that
desktop apps have a big problem navigating the workflow (first going to the
provider with a browser, and second, looking for the credentials; most apps
will be constrained, and some apps can't start a browser at all).
However, Alex stated in a previous message that they are considering some
legacy options for desktop applications; I imagine we'll hear more about
that as the OAuth formal rollout becomes imminent.
Usual "I don't speak or work for Twitter" applies.
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com
-- Quote me as saying I was misquoted. -- Groucho Marx ------------------------
Blaine Cook
> It's not clear to me how desktop apps will authenticate. Will each
> author need to maintain a website to perform the authentication? I
> don't see how it can be done otherwise.
To see how it works in practice, try using a desktop Flickr Uploader
or iMovie's YouTube integration.
Normally your app will open a browser window (all modern environments
do this seamlessly) and ask the user to authorize the application.
Once they've done that, they should be told to go back to the
application (close the browser window) and continue the setup process
(usually by just clicking "Continue" or OK so that the desktop app
knows that it's OK to exchange the request token for the access
token).
b.
Cameron Kaiser
> > author need to maintain a website to perform the authentication? _I
> > don't see how it can be done otherwise.
>
> OAuth was designed with explicit desktop application support in mind.
> To see how it works in practice, try using a desktop Flickr Uploader
> or iMovie's YouTube integration.
>
> Normally your app will open a browser window (all modern environments
> do this seamlessly) and ask the user to authorize the application.
> Once they've done that, they should be told to go back to the
> application (close the browser window) and continue the setup process
> (usually by just clicking "Continue" or OK so that the desktop app
> knows that it's OK to exchange the request token for the access
> token).
With all due respect, *not* all modern environments do this seamlessly. How
would a script in somebody's cron job do that? Or a text-mode client? They
all have to authenticate and they are not in an environment where a browser
is easily available, if it is available at all.
Even for those apps that do have the ability to open a browser, which I grant
will be many and possibly even most, it does present a UX problem with
differing interfaces and it may be hard for some apps to *find* the generated
credentials to use.
Noteworthy things on this topic, from Google of all companies:
http://sites.google.com/site/oauthgoog/UXFedLogin/nobrowser
"Authorizing rich-client devices without a web browser"
http://sites.google.com/site/oauthgoog/UXFedLogin/desktopapps
"UX research on desktop apps using federated login and/or OAuth"
These are not easy problems to solve, and even Google does not have a
seamless solution.
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com
-- With a rubber duck, one's never alone. -- Douglas Adams, "HGTTG" -----------
funkatron
(who seem to be the people who get excited about OAuth), but *will*
confuse users who don't understand the tech involved, and/or aren't
comfortable jumping between apps. In addition, the process becomes
even more problematic with apps that don't run on a modern windowing
platform (like CLIs, mobile devices, and the like).
If you have hard numbers from usability studies that prove my
suspicions unfounded, that would be *great*. I'd love to be wrong.
--
Ed Finkler
http://funkatron.com
AIM: funka7ron
ICQ: 3922133
Skype: funka7ron
Nicholas Moline
funkatron
non-technical users. However, none of what I'd have to say is
different than what I've already said on the topic, and I'm sure
things will work out fine in time.
> Assuming Twitter keeps to a long/no expiration model for the OAuth tokens
> (as I understand it, it currently is set to not expire in the beta), or
> better yet, have a choice method for how long the token will last, for users
> accessing a site that accesses twitter, have a short expiration (an hour or
> a day), but have the option to create a token for client side applications
> that don't expire, then there shouldn't be a problem. You have your client
> program check to see if your token is valid, if it is not, spit out the url
> to get a new token, then you just paste your token back into your app's
> information and it's good for another 6 months or forever or whatever.
> It should even be possible to have your script get the token for you, for
> your own purposes if you store your login information, you can have your
> script access the url, get the token, and save it.
>
> There should be no real reason to save end user's login information, they
> should grant you access for the time periods that they access the site, it's
> much more secure that way overall, and if Twitter keeps to a long expiration
> model, saving those tokens to act for a period of time should be fine.
>
Nicholas Moline
Cameron Kaiser
> every application type, iPhone, desktop, or web.
Citation please :)
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com
-- The less we know, the better we feel. -- David Bowie, "Miracle Goodnight" --
Shannon Whitley
conversation with Twitter. How can this be handled with a desktop app
unless the app talks to a web proxy? You wouldn't embed the key/
secret in the code (especially if it's open source).
atebits
> every application type, iPhone, desktop, or web.
web apps*. OAuth anywhere else, desktop, iPhone, laundry machine,
makes me want to chip away a hole in my skull with a dull screwdriver,
jab a straw into my head, and drink my own brain matter.
No, seriously. When I launch a desktop app, I want to type in my
username and password. That's it. If I launch a Twitter client on my
iPhone, I don't want to have to quit the frickin' app to authenticate
in Safari, then go *back* to the app when I'm done. Sure I could
bring up an embedded web view, but UIWebView is a flakey hunk of junk,
and it's no more secure than letting the user type the password into a
native field directly because I would *own the web view and can get at
any info the users types in anyway*.
Hell, it's not even any more secure on the desktop... I just install a
key listener and wait for you to type in a password into your browser.
Ok, I'm holding myself back from ranting. I guess my point is this:
OAuth sucks hardcore for everything except other web apps.
Oh, and Twitter guys: I can't thank you guys enough for keeping around
basic auth. Thank you thank you thank you.
Chris Scott
On Feb 9, 2009, at 10:07 PM, atebits wrote:
>
>> For an end user, OAuth is generally speaking much friendlier for
>> pretty much
>> every application type, iPhone, desktop, or web.
>
> From my chair, OAuth is a fantastic solution to authenticate *other
> web apps*. OAuth anywhere else, desktop, iPhone, laundry machine,
> makes me want to chip away a hole in my skull with a dull screwdriver,
> jab a straw into my head, and drink my own brain matter.
>
> No, seriously. When I launch a desktop app, I want to type in my
> username and password. That's it. If I launch a Twitter client on my
> iPhone, I don't want to have to quit the frickin' app to authenticate
> in Safari, then go *back* to the app when I'm done. Sure I could
> bring up an embedded web view, but UIWebView is a flakey hunk of junk,
> and it's no more secure than letting the user type the password into a
> native field directly because I would *own the web view and can get at
> any info the users types in anyway*.
See the Darkslide iPhone app for a nice implementation of this. When
you touch the log in button it opens mobile Safari where you log in
and authorize the app. Mobile Safari then closes and you are taken
back to Darkslide where you are now logged in.
I have no idea how this is done from a programming perspective,
however, from a user perspective it works well IMHO.
> Hell, it's not even any more secure on the desktop... I just install a
> key listener and wait for you to type in a password into your browser.
>
> Ok, I'm holding myself back from ranting. I guess my point is this:
> OAuth sucks hardcore for everything except other web apps.
>
> Oh, and Twitter guys: I can't thank you guys enough for keeping around
> basic auth. Thank you thank you thank you.
--
Chris Scott
http://iamzed.com/
http://hailtheale.com/
Cameron Kaiser
> > username and password. That's it. If I launch a Twitter client on my
> > iPhone, I don't want to have to quit the frickin' app to authenticate
> > in Safari, then go *back* to the app when I'm done. Sure I could
> > bring up an embedded web view, but UIWebView is a flakey hunk of junk,
> > and it's no more secure than letting the user type the password into a
> > native field directly because I would *own the web view and can get at
> > any info the users types in anyway*.
>
> See the Darkslide iPhone app for a nice implementation of this. When
> you touch the log in button it opens mobile Safari where you log in
> and authorize the app. Mobile Safari then closes and you are taken
> back to Darkslide where you are now logged in.
>
> I have no idea how this is done from a programming perspective,
> however, from a user perspective it works well IMHO.
>
> > Hell, it's not even any more secure on the desktop... I just install a
> > key listener and wait for you to type in a password into your browser.
But Loren's security points still hold -- an allegedly OAuth-compliant app
doesn't have to do it that way, and as he says, he still owns any control his
code puts on the screen.
Besides, if you've already got your code running on their local system,
who cares about OAuth? Let's riffle their files! :)
My other objections are the same, so I won't repeat them.
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com
-- I use my C128 because I am an ornery, stubborn, retro grouch. -- Bob Masse -
Christopher St John
>
> See the Darkslide iPhone app for a nice implementation of this. When
> you touch the log in button it opens mobile Safari where you log in
> and authorize the app. Mobile Safari then closes and you are taken
> back to Darkslide where you are now logged in.
>
> I have no idea how this is done from a programming perspective,
> however, from a user perspective it works well IMHO.
>
From a user perspective I find it confusing and awful. I
second the "chip hole in skull" comment. I'd love to see
some research on the topic, though, maybe it's just me.[1]
Popping up a browser control inside the app (on the iPhone
WebKit allows you to do this) appears to be a superior (but still
kinda weak) solution, with no loss in actual security.
I too am thankful that plain-old-password-based auth is
sticking around for when it's appropriate.
-cks
[1] Well, there was that link Cameron Kaiser posted:
http://sites.google.com/site/oauthgoog/UXFedLogin/desktopapps
but I mean some research that supports the idea that it's
all fine and ok, not research that suggests it's an ugly hack
that ruins usability. I especially liked the quote "The flow
makes some security people happy because the user
never enters their password into the client application.
However it makes usability much much worse, and any
evil client application on most operating systems can do
other evil things to the user's computer anyways such
as installing malware.". Well, duh. Thanks for the link,
Cameron.
--
Christopher St. John
http://artofsystems.blogspot.com
Aral Balkan
> web apps*. OAuth anywhere else, desktop, iPhone, laundry machine,
> makes me want to chip away a hole in my skull with a dull screwdriver,
> jab a straw into my head, and drink my own brain matter.
> Hell, it's not even any more secure on the desktop... I just install a
> key listener and wait for you to type in a password into your browser.
> Oh, and Twitter guys: I can't thank you guys enough for keeping around
> basic auth. Thank you thank you thank you.
http://apiwiki.twitter.com/FAQ#WhenwillTwittersupportOAuth
Does that mean that all apps, including desktop, will be required to
use oAuth?
Thanks,
Aral
Aral Balkan
> Popping up a browser control inside the app (on the iPhone
> WebKit allows you to do this) appears to be a superior (but still
> kinda weak) solution, with no loss in actual security.
actually seeing the Twitter/consumer's site or whether it's a phishing
attempt. They have no way of independently verifying that the
connection is secure either.
But, as Loren states, on a desktop app, you can fake/phish/etc. to
your heart's delight and, as Cameron mentioned, there are _far_ worse
things an installed desktop app can do.
Not sure if pushing oAuth for desktop is actually a Good Thing (tm) or
an exercise in purity for purity's sake, UX be damned.
Aral
atebits
Someone is going to have a fucking hissy fit...
GRRRRRRRRRRRRRRAAAAAAAAAAAAAAAAAAAAAAAAAAAAHHHHHHHHHHHHHHHHHHHRRRRRRRRRRRRRRRRRRRRRGGGGGGGGGGGGGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHMMMMMMMMMMMMMMMMMMOOOOOOOOOOOTTTTTTTTTTTTTTHHHHHHHHHHHHHHHEEEEEEEEEEEEERRRRRRRRRRRRRRRFFFFFFFFFFFFUUUUUUUUUUUUCCCCCCCCCCCCCKKKKKKKKKKKKKKKKKEEEEEEEEEEEEEEEEEEEEEEERRRRRRRRRRRRRRRRRRRRRRRYYYYYYYYYYOOOOOOOOUUUUUUUUBBBBBBBBBBBBAAAAAAAAAAAAAAASSSSSSSSSSSSSTTTTTTTTTTAAAAAAAAAAAAAAARRRRRRRRRRDDDDDDDDDDDDDDDSSSSSSSSSSIIIIIIIIIIIIIIIHHHHHHHHHHHHHHHAAAAAAAAAAAAATTTTTTTTTTTTTTTTTEEEEEEEEEEEEEEOOOOOOOOOOOOOAAAAAAAAAAAAAAAAUUUUUUUUUUUUUUUTTTTTTTTTTTTTTTTHHHHHHHHHHHHHHHHHHHHFFFFFFFFFFFFFFUUUUUUUUUUUUUUUUUUUUUUCCCCCCCCCCCCCCCCCCKKKKKKKKKKKKKKKKKKK
Alex Payne
good solutions for common use cases, we'll punt a bit.
--
Alex Payne - API Lead, Twitter, Inc.
http://twitter.com/al3x
atebits
> an exercise in purity for purity's sake, UX be damned.
before. I love you Twitter.
I'm happy to jump through hoops on the client side and invent some new
standard "OAuth for native clients that don't want to suck". You
know, exchange fancy tokens or whatever bla bla bla. So you guys can
revoke client access at any point. As long as the process remains
smooth for the user. By that I mean: username+password into a native
field, magic happens behind the scenes, that's it.
Thank you Alex for being open to this:
http://groups.google.com/group/twitter-development-talk/browse_thread/thread/629b03475a3d78a1/655a8425e1e5e045?show_docid=655a8425e1e5e045
Love,
Loren