OAuth Documentation Preview

2 views
Skip to first unread message

Matt Sanford

unread,
Feb 7, 2009, 12:52:47 AM2/7/09
to Twitter Development Talk
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
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

unread,
Feb 7, 2009, 11:14:34 AM2/7/09
to Twitter Development Talk
Awesome, thanks!

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
> out athttp://bit.ly/api-oauth-ruby.

Jesse Stay

unread,
Feb 8, 2009, 1:20:26 AM2/8/09
to twitter-deve...@googlegroups.com
How long do the access tokens last?  Are they permanent, or do they have an expiration after which we'll have to re-authenticate the user?

Thanks,

Jesse

dean.j.robinson

unread,
Feb 8, 2009, 7:55:43 PM2/8/09
to Twitter Development Talk
Great news, can't wait to start learning about it, and implementing it
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

unread,
Feb 9, 2009, 10:47:31 AM2/9/09
to twitter-deve...@googlegroups.com
Hi Jesse,

    Currently we don't have any plans to expire access tokens. That may change in the future but even if it does I suspect it will be a long duration.

Thanks;
  — Matt Sanford

Shannon Whitley

unread,
Feb 9, 2009, 10:37:05 AM2/9/09
to Twitter Development Talk
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.


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
> out athttp://bit.ly/api-oauth-ruby.

Cameron Kaiser

unread,
Feb 9, 2009, 10:55:23 AM2/9/09
to twitter-deve...@googlegroups.com
> 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.

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

unread,
Feb 9, 2009, 4:12:47 PM2/9/09
to Twitter Development Talk
On Feb 9, 4:37 pm, Shannon Whitley <shannon.whit...@gmail.com> wrote:
> 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.

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).

b.

Cameron Kaiser

unread,
Feb 9, 2009, 4:51:29 PM2/9/09
to twitter-deve...@googlegroups.com
> > 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.
>
> 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

unread,
Feb 9, 2009, 5:03:49 PM2/9/09
to Twitter Development Talk
I still maintain that this works fine for knowledgeable web dev folks
(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

unread,
Feb 9, 2009, 5:11:55 PM2/9/09
to twitter-deve...@googlegroups.com
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.

funkatron

unread,
Feb 9, 2009, 6:30:16 PM2/9/09
to Twitter Development Talk
Those are all technical issues. I'm talking about usability issues for
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.

--
Ed Finkler
http://funkatron.com
AIM: funka7ron
ICQ: 3922133
Skype: funka7ron


On Feb 9, 5:11 pm, Nicholas Moline <portal...@gmail.com> wrote:
> 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

unread,
Feb 9, 2009, 9:00:01 PM2/9/09
to twitter-deve...@googlegroups.com
For an end user, OAuth is generally speaking much friendlier for pretty much every application type, iPhone, desktop, or web.  The only applications that might possibly have a usability barrier (and as I said before, a quite slight one if you just make your own workaround as I just suggested) are command line applications, and because it's only really feasible to use command line applications with a single user, the curl login for you method I mentioned should work just fine.

Cameron Kaiser

unread,
Feb 9, 2009, 9:30:59 PM2/9/09
to twitter-deve...@googlegroups.com
> For an end user, OAuth is generally speaking much friendlier for pretty much
> 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

unread,
Feb 9, 2009, 9:36:59 PM2/9/09
to Twitter Development Talk
The consumer key and consumer secret are required to open the
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

unread,
Feb 9, 2009, 10:07:41 PM2/9/09
to Twitter Development Talk
> 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*.

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

unread,
Feb 10, 2009, 8:10:56 AM2/10/09
to twitter-deve...@googlegroups.com

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

unread,
Feb 10, 2009, 8:52:48 AM2/10/09
to twitter-deve...@googlegroups.com
> > 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.

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

unread,
Feb 10, 2009, 10:22:23 AM2/10/09
to twitter-deve...@googlegroups.com
On Tue, Feb 10, 2009 at 7:10 AM, Chris Scott <cjsc...@gmail.com> wrote:
>
> 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

unread,
Feb 17, 2009, 2:58:10 PM2/17/09
to Twitter Development Talk
> 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.

Agree!

> 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.

Good point.

> Oh, and Twitter guys: I can't thank you guys enough for keeping around
> basic auth.  Thank you thank you thank you.

According to the FAQ, it's going to be deprecated after six months:
http://apiwiki.twitter.com/FAQ#WhenwillTwittersupportOAuth

Does that mean that all apps, including desktop, will be required to
use oAuth?

Thanks,
Aral

Aral Balkan

unread,
Feb 17, 2009, 3:01:31 PM2/17/09
to Twitter Development Talk
Hey Chris,

> 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.

The loss in security is that the user has no way of knowing if they're
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

unread,
Feb 17, 2009, 4:12:53 PM2/17/09
to Twitter Development Talk
> According to the FAQ, it's going to be deprecated after six months:http://apiwiki.twitter.com/FAQ#WhenwillTwittersupportOAuth

No. That's a joke, right?

Someone is going to have a fucking hissy fit...

GRRRRRRRRRRRRRRAAAAAAAAAAAAAAAAAAAAAAAAAAAAHHHHHHHHHHHHHHHHHHHRRRRRRRRRRRRRRRRRRRRRGGGGGGGGGGGGGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHMMMMMMMMMMMMMMMMMMOOOOOOOOOOOTTTTTTTTTTTTTTHHHHHHHHHHHHHHHEEEEEEEEEEEEERRRRRRRRRRRRRRRFFFFFFFFFFFFUUUUUUUUUUUUCCCCCCCCCCCCCKKKKKKKKKKKKKKKKKEEEEEEEEEEEEEEEEEEEEEEERRRRRRRRRRRRRRRRRRRRRRRYYYYYYYYYYOOOOOOOOUUUUUUUUBBBBBBBBBBBBAAAAAAAAAAAAAAASSSSSSSSSSSSSTTTTTTTTTTAAAAAAAAAAAAAAARRRRRRRRRRDDDDDDDDDDDDDDDSSSSSSSSSSIIIIIIIIIIIIIIIHHHHHHHHHHHHHHHAAAAAAAAAAAAATTTTTTTTTTTTTTTTTEEEEEEEEEEEEEEOOOOOOOOOOOOOAAAAAAAAAAAAAAAAUUUUUUUUUUUUUUUTTTTTTTTTTTTTTTTHHHHHHHHHHHHHHHHHHHHFFFFFFFFFFFFFFUUUUUUUUUUUUUUUUUUUUUUCCCCCCCCCCCCCCCCCCKKKKKKKKKKKKKKKKKKK

Alex Payne

unread,
Feb 17, 2009, 5:03:01 PM2/17/09
to twitter-deve...@googlegroups.com
We were thinking six months, but we'll be flexible. If there aren't
good solutions for common use cases, we'll punt a bit.

--
Alex Payne - API Lead, Twitter, Inc.
http://twitter.com/al3x

atebits

unread,
Feb 17, 2009, 4:26:54 PM2/17/09
to Twitter Development Talk
> 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.

I think you hit the nail on the head. Sorry for that outburst
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

Reply all
Reply to author
Forward
0 new messages