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.