Coming soon: a solution for Open Source applications using OAuth with the Twitter API

[Taylor Singletary]

Hi Developers,

As has been discussed on the list recently, OAuth and Open Source applications are a difficult combination because token secrets shouldn't be embedded in widely distributed code. 

We're pleased to announce that we've devised a solution to this problem.

Next week, we plan to release a new extension to the Twitter API that will allow Open Source applications to obtain OAuth consumer keys and secrets for their users, without having to distribute an application secret.

Approved Open Source client applications will have an easy to implement ability, through dev.twitter.com, to generate new client tokens & secrets to be used specifically for each new instance of the application.

While completing the process does require the end-user to complete a few extra operations, we think this is a good compromise.

The source tag on tweets published by the child applications generated with this approach will be a variation on the originating application's name. For examples, if the name of the parent application was "AdventureTweet" and the user's screen name was @zork, then the child application's name would be "AdventureTweet (zork)". 

The work flow for these applications will be something like this:

  1. You store your API Consumer Key in your application distribution (but never your secret!).

  2. A user downloads/installs/checks out your open source application and runs it for the first time

  3. Your application builds a URL to our key exchange endpoint, using your consumer key.

      Example: http://dev.twitter.com/apps/key_exchange?oauth_consumer_key=abcdefghijklmnopqrstuvwxyz

  4. You send the user to that URL in whatever way makes sense in your environment.

  5. That user will have to login using their Twitter credentials (if they aren't already), and then approve your application's request to replicate itself on the user's behalf.

  6. The approval will require that the user agrees to our terms of service, as this process results in them having control of their own application

  7. The user is presented with a string that they are asked to paste into your application. The string will contain ah API key and secret, in addition to an access token and token secret for the member: everything that's needed to get the user up and running in your application.

  8. The user pastes the string into your application, which then consumes and stores it to begin performing API calls using OAuth.

The string containing the keys will be x-www-form-urlencoded. To keep the string brief, it will contain abbreviated key names.

An example:

ck=KIyzzZUM7KvKYOpnst2aOw&cs=4PQk1eH4MadmzzEZ1G1KdrWHIFC1IPxv1kXZg0G3E&at=542212-utEhFTv5GZZcc2R4w6thnApKtf1N1eKRedcFJthdeA&ats=FFdeOzzzzEwxOBWPPREd55dKx7AAaI8NfpK7xnibv4Yls

Where: "ck" - consumer key, "cs" - consumer secret, "at" - access token, "ats" - access token secret

This kind of key requisition service is new to the Twitter ecosystem, and we're going to be closely monitoring it for abuse. Once we announce its availability, we'll begin taking requests for Open Source applications that would like to offer the feature in their application.

We're excited to offer this solution to the open source community. Thanks everyone!

Taylor Singletary
Developer Advocate, Twitter
http://twitter.com/episod

[Dmitri Snytkine]

Interesting idea.

On Jun 11, 6:56 pm, Taylor Singletary <taylorsinglet...@twitter.com>
wrote:

>       Example:http://dev.twitter.com/apps/key_exchange?oauth_consumer_key=abcdefghi...

[alexkingorg]

This is excellent news and sounds like a much better user experience
than the previously discussed options. I would like to suggest it be
taken one step further. Could the encoded string with the keys be
returned programatically to the Open Source application instead of
asking the user to copy/paste? This way the user experience would be
very similar to a standard OAuth transaction.

Cheers,
--Alex

http://alexking.org


On Jun 11, 4:56 pm, Taylor Singletary <taylorsinglet...@twitter.com>
wrote:

> Hi Developers,
>
> As has been discussed on the list recently, OAuth and Open Source
> applications are a difficult combination because token secrets shouldn't be
> embedded in widely distributed code.
>
> We're pleased to announce that we've devised a solution to this problem.

> [...]

[Jef Poskanzer]

I don't understand why you are suggesting this only for open source
programs. Were you thinking that an attacker would be incapable of
decompiling an executable and extracting the secret?

[srikanth reddy]

If the attacker does that, the loser is only that user but not the app (parent app)  Basically this idea is to
shield the apps from being misused.

@taylor
So key exchange is done based on consumer key only.(No need to verify the signature?.Makes sense as this is distributed )So any abuse by the end user will only lead to the ban of child app ? (assuming the final auth requests are signed by the generated secrets (chid app secret and user secret only) )

[Zac Bowling]

Interesting idea. 

I didn't think it was to hard if you had user that was fiddling with your source to just have him generate his own keys and while I just compile my keys into my official binary builds but I guess for scripting based clients, this makes sense. I guess you get the attribution and client tracking on the Twitter side as well. 

Sometimes though this is not ideal, like a wordpress twitter plugin I use. I forced it to use my own keys because I want it to say "myblogsite.com" in the attribution link and not "UberWordPressTwitterPlugin" or whatever. 

If you can make it where the user can optionally edit the source attribution tag and link when they set it up the clone, then I would probably direct my users to use this approach over manually creating their own original consumer and secret. 

Zac Bowling

@zbowling

[Cameron Kaiser]

> @taylor
> So key exchange is done based on consumer key only.(No need to verify the
> signature?.Makes sense as this is distributed )So any abuse by the end user
> will only lead to the ban of child app ? (assuming the final auth requests
> are signed by the generated secrets (chid app secret and user secret only) )

IDSOWFT, but that is the way I understand it.

--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com
-- Roger Waters, public health officer: "Careful with that pox, Eugene!" ------

[Josh Roesslein]

Not sure I totally like this idea. Seems almost like double authentication to me.

The user has to still sign in via the web to replicate the app and then we have to fetch an access token

again by asking for their credentials?? So its like doing a 3-legged dance + the xAuth.

I really question the security benefits of not disclosing consumer key/secrets in the context

of desktop/phone based applications. First the xAuth step should be forced to use https which

prevents man in the middle attacks. Further all other communication can use https as well.

I think the only real security gain from oAuth secrets is for 3-legged authentication. It acts as a cheap

verification method that you know this website actually represents this particular application. With desktop/phone

applications this is already known since you have downloaded it. When I download client X I know already I am

only giving out my credentials to this application, not some attacker spoofing the site.

I do appreciate Twitter taking the time to help address these oAuth issues, but before we over complicate the

issue lets make sure there are actual gains to be had.

Josh

[Cameron Kaiser]

> Not sure I totally like this idea. Seems almost like double authentication
> to me.
> The user has to still sign in via the web to replicate the app and then we
> have to fetch an access token
> again by asking for their credentials?? So its like doing a 3-legged dance +
> the xAuth.

No. The process generates a user access token along with a new "child" app
key in one step. There is no additional xAuth step, and I suspect Twitter
won't want xAuth-enabled app keys to be "childed" in any case. Like any user
token, it does not expire until the user revokes it, which I assume in this
case will probably never occur since it can only ever be used by the app key
"child" instance they themselves generated.

--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com

-- Put down your guns, it's Weasel Stomping Day! ------------------------------

[Josh Roesslein]

Sorry over looked the access token being included. I still do not think this fits well with open source

desktop apps. I think for now just not distributing a key with the app's source, but provide it when the app

is built (hidden in the binary or such).

[Cameron Kaiser]

> Sorry over looked the access token being included. I still do not think this
> fits well with open source
> desktop apps. I think for now just not distributing a key with the app's
> source, but provide it when the app
> is built (hidden in the binary or such).

That works fine with binaries, but may not work fine with apps written in
scripting languages.

--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com

-- I went to San Francisco. I found someone's heart. Now what? ----------------

[funkatron]

A solution, maybe, for desktop folks who can C+P a large string
(although I'm willing to bet you'll have a lot of breakdown there),
but it will fail miserably on mobile apps. The string is way, way too
long. This will get screwed up badly by non-technical users.

(Yes, some people make open-source mobile apps 8)

--
Ed Finkler
http://funkatron.com
@funkatron
AIM: funka7ron / ICQ: 3922133 / XMPP:funk...@gmail.com


On Jun 11, 6:56 pm, Taylor Singletary <taylorsinglet...@twitter.com>
wrote:

>       Example:http://dev.twitter.com/apps/key_exchange?oauth_consumer_key=abcdefghi...

[funkatron]

As it was explained to me (I think the API team would do well by
discussing this stuff out in the open so we don't have to answer for
them), the concern is having keys available in plain text. with OSS,
you have that in 1, and potentially 2, situations:

1: Source code distributions/repos
2: end-user packages of non-compiled apps (like apps based on Python
or JavaScript)

The answer to #1 is to not include your keys in the source. That's
fine for me.
The answer to #2 is to either obfuscate your code (compiling, or
intentional obfuscation) or to not include any consumer keys/secrets,
and just use the above API.

--
Ed Finkler
http://funkatron.com
@funkatron
AIM: funka7ron / ICQ: 3922133 / XMPP:funk...@gmail.com

[Jef Poskanzer]

>obfuscate your code (compiling, or intentional obfuscation)

So OAuth's security is based on obscurity? That's pretty lame.

[Zac Bowling]

Yes, that is a problem with any app that you distribute that has any embedded keys. Unfortunately, you ultimately can't really entirely secure anything you ship that a user can run on their own machine. You can however take a few steps to make that extremely difficult by encrypting and obfuscating your consumer keys/secrets in your app package before you distribute. Nothing is impossible to reverse engineer if you can get your hands on it (look at iTunes), but you can make it take so long and be so hard that it becomes to hard and almost everyone gives up (look at iTunes 9).

One thing I wish was easier though for desktop apps and OAuth is if most API providers would make it possible to have multiple consumers and secrets out for the same app at the same time. You can then rotate new ones in constantly in your builds and if one key is discovered or extracted and abused and revoked, all the versions of your app wouldn't be affected. It's something we do with SSL client certificates against our API when we ship a new build (even each of our nightly builds has its own certificate). If someone extracts it and tries to use it, then we can blacklist that one certificate and it doesn't take down all the versions of our apps.

Zac Bowling
@zbowling

[bytespider]

I may be being naive but i fail to see the fill issues with having the
key and secret public.

What are they going to do with it? the user would still have to agree
to use the app in question that is posing as a legitimate app.

The genuine app only needs to get a new secret once a vulnerability is
found. And end users need to learn to only download the app from the
official source.

I maybe completely off the mark, so please don't shoot me down.

On Jun 11, 11:56 pm, Taylor Singletary <taylorsinglet...@twitter.com>
wrote:

>       Example:http://dev.twitter.com/apps/key_exchange?oauth_consumer_key=abcdefghi...

[Taylor Singletary]

Regarding the user being able to set the source tag themselves: they will be able to -- the application created for the user is totally their application. They can change the name of the application to anything they want (within the same rules as any application name on the platform).

The WordPress use case has been thought of and we're still considering an additional delivery mechanism than just cut and paste. However, it would have to involve a callback and that would be best served with some form of verifiable identity (that you're in fact receiving a callback from Twitter and that the callback URL wasn't manipulated or pointing to an unwanted location). In that case, we'd likely have to setup some kind of public certificate exchange.

Taylor

[Taylor Singletary]

Yes, this is correct. To perform this key exchange, a consumer key (API key) with this feature enabled is all that's required to be stored in your open source app.

Some other interesting facts:

  - A parent application can only spawn 1 version of itself for a user. If the user repeats the flow, their pre-existing app will be returned.

  - xAuth will not be granted to these keys. For clarity here on why xAuth isn't allowed: having keys out in the public, or easily accessible to the public, that can perform xAuth is absolutely a bad idea. Anyone with a collection of logins and passwords can batch convert them to access tokens, giving themselves access to a member's account regardless of the login and password changing. 

(This is the other side of the coin.. on one side of the coin you have the advantage that OAuth applications keep working even if the user changes their password (YAY!) and then you have on the side of the coin that OAuth applications keep working even if the user changes their password and they have no idea that they've granted an OAuth access token without their explicit permission (BOO!) )

- Users with suspended accounts cannot create these kind of applications

- Applications with suspended status cannot have users create new applications

- The result of this process is everything an app needs to function for the user: a consumer key, a consumer secret, an access token, and a access token secret.

- We're only allowing open source applications for now. We may consider other use cases in the future.

- The user gets an application in this deal. That's actually a big thing. It's not just a row in a database.

Addressing a few other points:

This process puts the power of the application completely in the hands of the user. Because of this, it's best suited for applications that cater to users with a more advanced understanding of what they're doing. Of course, it's not terribly difficult to perform all the necessary actions, but this feature was not built with a "super-awesome seamless user experience" in mind. It also, naturally, by requiring the user to agree to the API terms of service, comes with other baggage for your users.

There are many advantages to this approach from a management perspective for us. It also better shields developers from the actions that can be taken by malicious users, should they reveal their own consumer secrets in their open source apps. We don't want you to do that, that's why we're offering this option.

Some users might screw up the copy & paste step. Code defensively. Scrub the input. Verify that it's in the format you think it should be before assuming it's correct. After you parse the tokens, do a verify_credentials API requests or something similar to test if it works. If it doesn't work, try sending the user through the process again (they'll get the same result as the first time).

Taylor

[Jef Poskanzer]

On Jun 12, 10:16 am, Taylor Singletary <taylorsinglet...@twitter.com>
wrote:

> (This is the other side of the coin.. on one side of the coin you have the
> advantage that OAuth applications keep working even if the user changes
> their password (YAY!) and then you have on the side of the coin that OAuth
> applications keep working even if the user changes their password and they
> have no idea that they've granted an OAuth access token without their
> explicit permission (BOO!) )

The apps still show up in http://twitter.com/settings/connections
don't they? And the access can be revoked there?

[Bernd Stramm]

On Sat, 12 Jun 2010 09:48:15 -0700
Zac Bowling <zbow...@gmail.com> wrote:

> Yes, that is a problem with any app that you distribute that has any
> embedded keys. Unfortunately, you ultimately can't really entirely
> secure anything you ship that a user can run on their own machine.
> You can however take a few steps to make that extremely difficult by
> encrypting and obfuscating your consumer keys/secrets in your app
> package before you distribute. Nothing is impossible to reverse
> engineer if you can get your hands on it (look at iTunes), but you
> can make it take so long and be so hard that it becomes to hard and
> almost everyone gives up (look at iTunes 9).

An important question:

secure against what?

Against posting tweets when the user is not who they say they are?

You can't secure against that. Desktop machines are left unattended.
Mobile phones are borrowed and stolen.

Sure you can make it harder to just grab the key/secret pair of open
source application A and implement application B, pretending to be A.

But what does that buy you? What does that protect against?

--
Bernd Stramm
<bernd....@gmail.com>

[nov]

I love this idea!
But why don't you use verifier instead of such a long string?

ck=KIyzzZUM7KvKYOpnst2aOw&cs=4PQk1eH4MadmzzEZ1G1KdrWHIFC1IPxv1kXZg0G3E&at=5
42212-
utEhFTv5GZZcc2R4w6thnApKtf1N1eKRedcFJthdeA&ats=FFdeOzzzzEwxOBWPPREd55
dKx7AAaI8NfpK7xnibv4Yls

I don't want to copy&paste such a string on my iPhone..

[Jef Poskanzer]

On Jun 12, 11:49 am, Bernd Stramm <bernd.str...@gmail.com> wrote:
> secure against what?

The threat that OAuth's security-through-obscurity fails to protect
against is rogue-app B doing something bad while using legit-app A's
stolen credentials. The author of app A gets blamed for app B's bad
behavior and app A gets shut down. In other words, it's a denial of
service attack against applications, not against users.

Application authors are being asked to devote substantial resources to
the OAuth conversion, but OAuth provides no security for application
authors!

[funkatron]

I think you're missing the point, Taylor. It's not a matter of
validation, but actually being able to copy such a long string. I have
trouble with this on mobile, and I think I'm a pretty savvy user. I
*guarantee* you the rate of failure, and giving up on the process
entirely, will be much higher than current auth.

I can't code some way to sit over the user's shoulder and tell them
"click this, now click that, now spread your fingers… a bit wider…"

--
Ed Finkler
http://funkatron.com
@funkatron
AIM: funka7ron / ICQ: 3922133 / XMPP:funk...@gmail.com

[Cameron Kaiser]

> I think you're missing the point, Taylor. It's not a matter of
> validation, but actually being able to copy such a long string. I have
> trouble with this on mobile, and I think I'm a pretty savvy user. I
> *guarantee* you the rate of failure, and giving up on the process
> entirely, will be much higher than current auth.
>
> I can't code some way to sit over the user's shoulder and tell them

> "click this, now click that, now spread your fingers_ a bit wider_"

If it's a problem with the way the credentials are transmitted, maybe a
different or alternative way of transmitting them? E-mail them at the
same time, perhaps? A callback URL?

--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com

-- If a seagull flies over the sea, what flies over the bay? ------------------

[Zac Bowling]

On Jun 12, 2010, at 11:57 AM, Jef Poskanzer wrote:
> Application authors are being asked to devote substantial resources to
> the OAuth conversion, but OAuth provides no security for application
> authors!

It does from a web app perspective which is the primary design goal of OAuth since there would be no distribution of your secret in that scenario.

With OAuth, the issue is that if you are distributing secrets out that are embedded in your app, even with all the measures you can take to encrypt and obfuscate them, they can still be extracted at some point if someone has time. The issue is compounded since the app uses the same key universally in all the versions they ship that work so you are screwed if someone does yank your key. All versions you shipped are at risk then. Your only recourse is to rev your secret and force all your users to upgrade their apps to get new keys. In practice, this isn't that bad since twitter isn't hosting credit card data or anything of major risk and you basically devolve into the same issue we had with app identify we had with basic auth and passing clear text source ids (except that maybe now all your apps are crippled).

I've been pondering how you could solve this from my experience with solving these issues with SSL/TLS. One idea is having a sort of delegation chain where I could generate a new delegated secret for each copy of my app I distribute rather then using my same static secret directly in all my apps and then the client could pass the authentication chain up when it goes to Twitter to get an access token.

This is similar to the idea of having the ability to issue multiple secrets against a single app like I was suggesting earlier which could work with the OAuth spec today. However a delegation system would be even better so I could issue delegated secrets at will without going back to Twitter, although that idea would probably require extending the OAuth spec to handle passing signed delegation chains of some kind.

I'm hoping OAuth 2\WRAP allows this somehow since it builds on SSL/TLS instead of reinventing the wheel. There is a lot OAuth could learn from SSL/TLS which I'm hoping that OAuth 2/WRAP takes full advantage of in solving. :-)

Right now though, one solution if you are ultra paranoid if you are going to distribute software, is to proxy the calls from your own software through your own web service (which would render the ease of use you get from xAuth moot but you are sacrificing usability for security).

Zac Bowling
@zbowling

[funkatron]

Yeah, it's really the step of manually getting that long string of
seemingly-random characters from one app to another. a callback url
makes sense for web-based apps.

Something like PIN auth that would allow a desktop/mobile app to make
an HTTP call and recover the string programatically would be good, I
think. Typing 4-6 characters is much, much easier than copying and
pasting that long string.

--
Ed Finkler
http://funkatron.com
@funkatron
AIM: funka7ron / ICQ: 3922133 / XMPP:funk...@gmail.com

On Jun 12, 3:57 pm, Cameron Kaiser <spec...@floodgap.com> wrote:
> > I think you're missing the point, Taylor. It's not a matter of
> > validation, but actually being able to copy such a long string. I have
> > trouble with this on mobile, and I think I'm a pretty savvy user. I
> > *guarantee* you the rate of failure, and giving up on the process
> > entirely, will be much higher than current auth.
>
> > I can't code some way to sit over the user's shoulder and tell them
> > "click this, now click that, now spread your fingers_ a bit wider_"
>
> If it's a problem with the way the credentials are transmitted, maybe a
> different or alternative way of transmitting them? E-mail them at the
> same time, perhaps? A callback URL?
>
> --
> ------------------------------------ personal:http://www.cameronkaiser.com/--

>   Cameron Kaiser * Floodgap Systems *www.floodgap.com* ckai...@floodgap.com

[Cameron Kaiser]

> Yeah, it's really the step of manually getting that long string of
> seemingly-random characters from one app to another. a callback url
> makes sense for web-based apps.
>
> Something like PIN auth that would allow a desktop/mobile app to make
> an HTTP call and recover the string programatically would be good, I
> think. Typing 4-6 characters is much, much easier than copying and
> pasting that long string.

That sounds good to me too. That could also semi-automate the process.
Taylor and Raffi?

--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com

-- My Pink Floyd code: v1.2a s BO 1/0/pw tinG 0? 0 Relics 2 8 <6mar98> --------

[Bernd Stramm]

On Sat, 12 Jun 2010 13:25:44 -0700
Zac Bowling <zbow...@gmail.com> wrote:

> On Jun 12, 2010, at 11:57 AM, Jef Poskanzer wrote:
> > Application authors are being asked to devote substantial resources
> > to the OAuth conversion, but OAuth provides no security for
> > application authors!
>
> It does from a web app perspective which is the primary design goal
> of OAuth since there would be no distribution of your secret in that
> scenario.

Precisely. OAuth is designed for a 3-party security deal: Twitter
running on some host, the App running on another host, and the User
running on a third.

OAuth is pretty useless for a 2-party situation, as is present in a
desktop/mobile app on the users device. This isn't all that surprising,
since it is designed for something different.

> ... shipped are at risk then. Your only recourse is to rev your secret

> and force all your users to upgrade their apps to get new keys.

Another recourse might be to design a security approach for the
app-on-user-device scenario, rather than trying to shoehorn a 3-party
scheme into this.

> .. this isn't that bad since twitter isn't hosting credit card

> data or anything of major risk and you basically devolve into the
> same issue we had with app identify we had with basic auth and
> passing clear text source ids (except that maybe now all your apps
> are crippled).

Right. As long as the app doesn't do any side business with a third
party. If it does, then it should not use twitter's authentication for
that purpose.

> I've been pondering how you could solve this from my experience with
> solving these issues with SSL/TLS. One idea is having a sort of
> delegation chain where I could generate a new delegated secret for
> each copy of my app I distribute rather then using my same static
> secret directly in all my apps and then the client could pass the
> authentication chain up when it goes to Twitter to get an access
> token.

The question is also - why do you care which copy of your app it is?
People using your app will post silly things, engage in slander of
other people, commit crimes, plot revolutions.

Are you responsible for these things?

Is Twitter responsible for broadcasting the content?

While we're at it, let's go after the phone manucacturer, the network
bandwidth provider.

> ...

> Right now though, one solution if you are ultra paranoid if you are
> going to distribute software, is to proxy the calls from your own
> software through your own web service (which would render the ease of
> use you get from xAuth moot but you are sacrificing usability for
> security).

You mean something like Microsoft authorization codes.

Or make them download a UUID with the code, and send that code to
twitter for each individual downloaded copy. Of course once the
download count goes into the millions, twitter will love to store all
those IDs. And of course every application developer has a website that
handles all the downloads, none of them use google code, sourceforge,
github, ... oh wait.

Oh well, why bother.

--
Bernd Stramm
<bernd....@gmail.com>

[Zac Bowling]

On Jun 12, 2010, at 3:05 PM, Bernd Stramm wrote:
>> I've been pondering how you could solve this from my experience with
>> solving these issues with SSL/TLS. One idea is having a sort of
>> delegation chain where I could generate a new delegated secret for
>> each copy of my app I distribute rather then using my same static
>> secret directly in all my apps and then the client could pass the
>> authentication chain up when it goes to Twitter to get an access
>> token.
>
> The question is also - why do you care which copy of your app it is?
> People using your app will post silly things, engage in slander of
> other people, commit crimes, plot revolutions.

Yes, the reason I'm worried is when a token/secret is blocked/revoked, it doesn't take down all clients using that same key in my app. Currently I get one consumer token/secret so if twitter needs to block one bad user running around using the key they reverse engineered from my compiled/obfuscated app, it may take down all my users if they block the entire token/secret (hopefully twitter investigates and warns me and blocks the offending IPs rather then the entire token/secret to give me some time to rev a new key and figure out a deployment but that is asking a lot from them).

Having the ability to issue multiple consumer token/secrets per app, or having delegated chaining (like in SSL), I have some ability to mitigate the issue a bunch and give twitter the ability to block a much smaller subset of my users if a key was extracted and used abusively.

OAuth 1.0a isn't well designed for desktop/mobile apps and it's more than just usability issues that the Twitter gang are trying tackle with things like xAuth. It wasn't designed with the thought that keys could be compromised by third parties embedded inside apps. I can only hope it's fixed OAuth 2.0.

Just ideas. :-)

Zac Bowling
@zbowling

[Jef Poskanzer]

You know, it's right there in the OAuth RFC.

http://tools.ietf.org/html/rfc5849#section-4.6

4.6. Secrecy of the Client Credentials

In many cases, the client application will be under the control of
potentially untrusted parties. For example, if the client is a
desktop application with freely available source code or an
executable binary, an attacker may be able to download a copy for
analysis. In such cases, attackers will be able to recover the
client credentials.

Accordingly, servers should not use the client credentials alone to
verify the identity of the client.

[M. Edward (Ed) Borasky]

Quoting funkatron <funk...@gmail.com>:

> Yeah, it's really the step of manually getting that long string of
> seemingly-random characters from one app to another. a callback url
> makes sense for web-based apps.
>
> Something like PIN auth that would allow a desktop/mobile app to make
> an HTTP call and recover the string programatically would be good, I
> think. Typing 4-6 characters is much, much easier than copying and
> pasting that long string.

Yes! Can we get a PIN workflow for end users? That would be perfect!
That's what I'm using now.

[Bernd Stramm]

Right, and...

But for a desktop/mobile standalone application, there is no single
client entity. What is called the "consumer" is not an entity. It is a
program running on a device, not a company.

And to re-quote them:

> For example, if the client is a
> desktop application with freely available source code or an
> executable binary, an attacker may be able to download a copy for
> analysis.

This borders on being silly - why bother with analysis, when the
attacker can just run the program.

The oauth system comes from client/server concepts and client/server
thinking. In that scenario, the authentication is between one client
and two servers. That is not the case with most desktop/mobile apps.
--
Bernd Stramm
<bernd....@gmail.com>

[Dewald Pretorius]

Perhaps I'm missing something here, but I do not see any security in
this solution, except for the user not having to enter his Twitter
credentials in an app that only he uses anyway.

Open source means, well, open (readable and modifiable by anyone)
source. Meaning, your API Consumer Key is readable to anyone, and it
is also the only piece of identity used when requesting keys and
secrets.

Let's say you have an XYZ open source project, and Twitter assigns to
it API Consumer Key "QWER".

What exactly prevents any spammer / hacker / bad person out there from
masquerading as your app by using your API Consumer Key "QWER" to
request keys and secrets? There is no way for Twitter to determine
that the request was actually made from within the code of your XYZ
project.

[segphault]

The problem here is that Twitter wants to use OAuth to identify and
block abusive applications, but the OAuth standard was not designed to
be used in that manner. Regardless of whether an application's source
code is published, the consumer secret key will always be easily
accessible in desktop and mobile applications that are distributed to
end users.

The entire idea of "best-effort" key security is deeply flawed. Any
spammer with a hex editor can trivially compromise the keys of popular
applications and use those keys to evade Twitter's abuse controls.
Even if that clear incentive didn't exist, it's likely that we would
still see malicious people compromising the keys of popular
applications just for the lulz. The security-through-obscurity model
simply doesn't work.

The OAuth standard itself clearly and explicitly says that service
providers SHOULD NOT use the consumer secret to verify the identity of
distributed applications:

"In many applications, the Consumer application will be under the
control of potentially untrusted parties. For example, if the Consumer
is a freely available desktop application, an attacker may be able to

download a copy for analysis. In such cases, attackers will be able to

recover the Consumer Secret used to authenticate the Consumer to the
Service Provider. Accordingly, Service Providers should not use the
Consumer Secret alone to verify the identity of the Consumer."

Facebook and Google Buzz both offer desktop-appropriate OAuth
authentication flows which do not require a consumer secret key and do
not require the user to go through a complicated copy/paste process.
This is not rocket science and it's not a hard problem to solve. It's
unclear to me why Twitter continues to consistently get it wrong.

It's also extremely frustrating that Twitter is still at the stage of
discussing potential solutions for open source applications when there
is only a few more weeks left before basic auth is scheduled to be
disabled. There might not be enough time to fully beta test an
implementation and get a patch into Ubuntu before the cutoff. Am I
supposed to just disable Twitter for several hundred thousand Ubuntu
users?

--
Ryan Paul
Gwibber Project

On Jun 11, 3:56 pm, Taylor Singletary <taylorsinglet...@twitter.com>

>       Example:http://dev.twitter.com/apps/key_exchange?oauth_consumer_key=abcdefghi...

[Jef Poskanzer]

Yeah, what Ryan said.

Also,

On Jun 13, 1:40 pm, segphault <ryankp...@gmail.com> wrote:
> Facebook and Google Buzz both offer desktop-appropriate OAuth
> authentication flows which do not require a consumer secret key and do
> not require the user to go through a complicated copy/paste process.

I'm curious what they are doing. Do they give up on identifying the
application and just identify the user?

[Zac Bowling]

In facebook's desktop authflow, rather then giving you an access_token endpoint to call with a secret to exchange a callback and get an valid access_token, you instead call authorize and it will redirect the user to a login_success.html page on facebook.com with the access token in a fragment on that page. (see http://developers.facebook.com/docs/authentication/desktop )

Their idea is that if you can embed a browser and get the user to authenticate through it, you can inspect the url of the embedded browser and detect when it hits login_success.html and take the access token fragment and store it.

However, what is interesting about that is that I can embed client_ids I stole from other desktop apps (and possibly other web apps if they don't protect against it) and generate valid access_tokens against other ids in my own desktop app. The user may notice the app they authorize isn't the one they are using because because facebook identifies the app with its name and icon on the authorize page. However if I'm being evil, i could social engineer the user some how like I could name my app the same as the one I'm stealing or something similar and use the same icon, and then I can get access tokens like I'm that app.

Basically when it comes to desktop apps, Facebook can't for sure tell the difference between my desktop app and illegitimate one. If Facebook blocks entire apps or rate limits by them, then I can still DOS the app by using their client_id. It doesn't offer anymore application identity protection then just embedding a secret and using the OAuth 1.0a flow and embedding secrets.

Facebook probably realizes this. Since you can mark your app as a desktop app and not a web app in your app settings, they probably realize this issue and know that you can't always trust the desktop clients so why even bother with secrets (probably good that they ask your app type upfront for this reason and it doesn't give a false sense of security by even having a secret). From an operations perspective for FB, it gives them less options to safely blacklisting desktop apps without taking out legitimate ones though.

Zac Bowling
@zbowling

[Bernd Stramm]

Interesting details, and see below:

On Mon, 14 Jun 2010 10:51:34 -0700
Zac Bowling <zbow...@gmail.com> wrote:

> In facebook's desktop authflow, rather then giving you an

> ...

> Basically when it comes to desktop apps, Facebook can't for sure tell
> the difference between my desktop app and illegitimate one.

Not only that, they (or anyone) cannot tell a legitimate desktop from an
illegitimate one. An illegitimate person can take a desktop with a
bunch of legitimate apps and do illegitimate things with the whole
collection.

And then we should not forget that a mobile phone is a the same as a
desktop, from the point of view of the web server. Phones are usually
not protected very well, both in terms of autheticating users and in
physical terms.

What is it that makes an app illegitimate? Basically that is
impersonates the user, and does things the user doesn't want done.

Unless of course the app does business on behalf of a third party with
both the user and the server (twitter, facebook, ...). Collecting data
is "doing business" in this sense. Then the app is an agent for that
third party.

But for a lot of apps, this is not the case, they act entirely as an
agent for the user. They are no different than browsers in this respect.

--
Bernd Stramm
<bernd....@gmail.com>

[nov]

Hi, Twitter API team

Is this feature already released?
If so, how can we register key_exchange enabled consumers?

On 6月12日, 午前7:56, Taylor Singletary <taylorsinglet...@twitter.com>

[Taylor Singletary]

Hi Everyone,

We're waiting on a few minor bug fixes to be in place before rolling this out to a wider audience. I'll post a new message when things are good to go and we're ready to accept applications into the feature.

Taylor

[Decklin Foster]

Taylor Singletary wrote:
> We're waiting on a few minor bug fixes to be in place before rolling this
> out to a wider audience. I'll post a new message when things are good to go
> and we're ready to accept applications into the feature.

Any update or ETA on this? I have an app that I'm eager to test out.
(I notice that if you open http://dev.twitter.com/apps/key_exchange
with a valid oauth_consumer_key, instead of a 404 there is a page that
says "Sorry, key exchange is not permitted for this application." Does
this mean the answer is "soon"?)

--
things change.
dec...@red-bean.com

[Taylor Singletary]

The answer is soon! :) We hope to roll this out more widely this week.

[Johnson Earls]

Any further news on this? It's been three weeks since you were
"hoping to roll [it] out more widely this week". I've got an app
registered and am starting to code it up, but would like to use the
key_exchange method instead, since there's no way at all to hide the
consumer secret in a python script.

Thanks,
- Johnson

On Jun 28, 8:02 am, Taylor Singletary <taylorsinglet...@twitter.com>
wrote:

> The answer is soon! :) We hope to roll this out more widely this week.
>

> On Mon, Jun 28, 2010 at 7:56 AM, Decklin Foster <deck...@red-bean.com>wrote:
>
> > Taylor Singletary wrote:
> > > We're waiting on a few minor bug fixes to be in place before rolling this
> > > out to a wider audience. I'll post a new message when things are good to
> > go
> > > and we're ready to accept applications into the feature.
>
> > Any update or ETA on this? I have an app that I'm eager to test out.

> > (I notice that if you openhttp://dev.twitter.com/apps/key_exchange

> > with a valid oauth_consumer_key, instead of a 404 there is a page that
> > says "Sorry, key exchange is not permitted for this application." Does
> > this mean the answer is "soon"?)
>
> > --
> > things change.

> > deck...@red-bean.com

[Ryan Westphal]

I think this solution works for my open-source C++ app. Here is my
initial thought/plan for it, let me know if I'm way off base.

1. My app complies down to native code, which is hackable but
obfuscated enough assuming I don't add my consumer secret as a string
resource into the binary :/
2. Source code online will build but will not have any of my personal
key information.
3. However, I would like to build all of my consumer info including
secrets into compiled versions of the app that users can download and
run without hassle.
4. I have no problem with supplying other developers a URL and
describing to them how to copy and paste their new information into
the public code before building /their/ version of the app.

Does this work? I understand that my situation is not the same as a
script-based app. I cannot think of the correct way to handle that
environment.

If my personal app key (or app itself) is abused & banned, can I get a
new set of keys for my parent application and release a new version of
my pre-compiled app to the public?

Thanks,
Ryan

[jimisaacs]

Sounds kind of like GData workflow, is that what you are going for?

Source application installation must connect to registered API
application though an application authentication URL.
API application author has full control over expiring any application
tokens at any given point causing all source applications to have to
reconnect.

So in my mind, to simplify things, I see two levels of authentication.
First the source application must be authenticated before it can be
used (key).
Then once the source application is ready, it can be used for to
authenticate specific users' accounts once allowed by the user
(token).

Does this also mean it requires more levels of checking on the logic
side?
First check the if keys have expired, then check if tokens have
expired?

As a fan of the GData workflow, I think this sounds very good, but I
would still love see a request/response oriented workflow example.

Thanks


On Jun 11, 3:56 pm, Taylor Singletary <taylorsinglet...@twitter.com>

[Meepnix]

Has this solution for Open Source applications using OAuth with the
Twitter API been implemented yet? As the deadline for Basic
authentication removal is looming very close; 16th August, end of this
week.

[Julio Biason]

On another thread, Taylor said "No". So, basically, you will have to
let your secret "leak" so your users can use your app.

--
Julio Biason <julio....@gmail.com>
Twitter: http://twitter.com/juliobiason

[DaveH]

Strange that this was stated to be ready weeks ago and now we hear
nothing about the progress. Any one that is actually involved in
testing this able to weigh in and provide an update?

[BigglesZX]

Is there any news on this? The deadline is now passed and I'm looking
to implement OAuth immediately in an open-source web app with exactly
this use-case. Having this feature would be very useful. Thanks.

[briandunnington]

as Julio stated above, the official response from Taylor (in another
thread) was that this solution will *not* be rolled out. there is
currently no other alternative being offered other.

and just to repeat what has already been said a few time in this
thread - this is not just a problem with open source apps. any app
that is distributed (ie: not running on your own web server) has this
problem. i read on Daring Fireball the other day about a new Twitter
app called Hibari, so i downloaded it and got the consumer key and
secret within a couple of minutes. others apps are just as susceptible
- any time the user has the code, the secret must be considered
unsecure.

i dont know how oAuth can be considered a solution for non-web apps,
but i hold out hope that an alternative will be offered.