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!
> 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!
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.
> 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.
> [...]
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?
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) )
On Sat, Jun 12, 2010 at 2:29 PM, Jef Poskanzer <jef.poskan...@gmail.com>wrote:
> 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?
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
On Jun 11, 2010, at 3:56 PM, Taylor Singletary 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!
> @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 * ckai...@floodgap.com -- Roger Waters, public health officer: "Careful with that pox, Eugene!" ------
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
On Sat, Jun 12, 2010 at 9:12 AM, Cameron Kaiser <spec...@floodgap.com>wrote:
> > @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 * > ckai...@floodgap.com > -- Roger Waters, public health officer: "Careful with that pox, Eugene!" > ------
> 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 * ckai...@floodgap.com -- Put down your guns, it's Weasel Stomping Day! ------------------------------
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).
On Sat, Jun 12, 2010 at 10:09 AM, Cameron Kaiser <spec...@floodgap.com>wrote:
> > 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 * > ckai...@floodgap.com > -- Put down your guns, it's Weasel Stomping Day! > ------------------------------
> 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 * ckai...@floodgap.com -- I went to San Francisco. I found someone's heart. Now what? ----------------
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.
> 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!
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.
> 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?
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.
> 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?
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:
> 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!
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.
On Sat, Jun 12, 2010 at 1:31 AM, Zac Bowling <zbowl...@gmail.com> wrote: > 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
> On Jun 11, 2010, at 3:56 PM, Taylor Singletary 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!
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
On Sat, Jun 12, 2010 at 7:12 AM, Cameron Kaiser <spec...@floodgap.com>wrote:
> > @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 * > ckai...@floodgap.com > -- Roger Waters, public health officer: "Careful with that pox, Eugene!" > ------
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!) )
Zac Bowling <zbowl...@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?
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!
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…"
> 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).
> 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? ------------------
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).
