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.
> > 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
> -- If a seagull flies over the sea, what flies over the bay? ------------------
> 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 * ckai...@floodgap.com -- My Pink Floyd code: v1.2a s BO 1/0/pw tinG 0? 0 Relics 2 8 <6mar98> --------
Zac Bowling <zbowl...@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.
>> 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.
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.
> 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.
> 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.
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.str...@gmail.com>
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.
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>
wrote:
> 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=abcdefghi...
> 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=5 42212-utEhFTv5GZZcc2R4w6thnApKtf1N1eKRedcFJthdeA&ats=FFdeOzzzzEwxOBWPPREd55 dKx7AAaI8NfpK7xnibv4Yls
> 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!
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?
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
On Jun 14, 2010, at 10:00 AM, Jef Poskanzer wrote:
> 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 <zbowl...@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.
> 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=abcdefghi...
> 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=5 42212-utEhFTv5GZZcc2R4w6thnApKtf1N1eKRedcFJthdeA&ats=FFdeOzzzzEwxOBWPPREd55 dKx7AAaI8NfpK7xnibv4Yls
> 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!
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.
On Sun, Jun 20, 2010 at 1:30 AM, nov <mat...@gmail.com> wrote: > 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> > 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.
> > 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=abcdefghi... > > 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.
> > 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 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"?)
> 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"?)
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
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?
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>
wrote:
> 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=abcdefghi...
> 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=5 42212-utEhFTv5GZZcc2R4w6thnApKtf1N1eKRedcFJthdeA&ats=FFdeOzzzzEwxOBWPPREd55 dKx7AAaI8NfpK7xnibv4Yls
> 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!
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.
On Mon, Aug 9, 2010 at 1:50 PM, Meepnix <moonix...@gmail.com> wrote: > 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.
On another thread, Taylor said "No". So, basically, you will have to let your secret "leak" so your users can use your app.
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?
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.
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.
On Aug 19, 10:26 am, BigglesZX <biggle...@gmail.com> wrote:
> 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.
> 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.
And that assumes that you distribute the consumerkey and consumersecret with the app. Nothing about Open Source requires this. You could just as easily just distribute the source and require that users obtain their own ConsumerKey combos.
