Re: Absurd Misunderstanding of Open Anything (Was: [twitter-dev] Re: Open Auth)
I'm sorry, I was talking about distributing source code. However, I wasn't thinking of Open Source (even though I wrote that), I was thinking of things like interpreted languages (like PHP) where you would distribute an application that can't be compiled in to a binary, as, even if you don't release the project as open source, if you can download, you have the source code. For example, there is a PHP project out there called eyeOS, which does what it sounds like it does: creates an Operating System like application that runs in your browser. If I were to write a Twitter client for that using OAuth, and put that up for download for a user to install, even though I am not making it open source, I am still releasing the source code because I cannot compile the code into a binary. What would you suggest I do, then, to try to hide my consumer key and secret to prevent people from using it to spam twitter and (possibly) getting my app shut down? - Jason On Aug 17, 2009, at 4:55 PM, Chris Babcock wrote: Silly me. I thought someone was talking about distributing source code. Building an enduser distribution is somewhat to entirely different. First, there really isn't any point to using OAuth for a client unless the client code lives on the network. The whole advantage of the scheme is that the user does not have to disclose credentials to one or more third parties. An application that doesn't access a third party network should use basic authentication over HTTPS. If Twitter decides to eliminate basic auth then the correct way (from a security stand point) to implement OAuth would be to obtain a separate key for each client. I don't see the current OAuth spec as being set up to handle bulk key assignments, but you can't distribute a single key to multiple clients outside of your network. Whether or not the app is Open Source is a non-issue; It's complete FUD-rucking to imply that it is any diffent distributing a secret key in a close source app than it would be to do so in an open source app. What happens if you try to use a screwdriver as a hammer? It's the same thing here only someone had to drag Open Source into as if that made any kind of a difference. To top it off, the OP had a complete misunderstanding of the consequences of key disclosure. A Spammer could use it and get your app banned... as if that's of any consequence compared to the users' accounts getting hijacked by apps impersonating your client. And what's with keeping score as if Open Auth and basic were a couple of talking tools on Disney Channel having some sort of ludicrous rivalry? Chris Babcock This is interesting Chris, as I have had the same question. How would you propose to distribute a usable FLOSS twitter app that uses Oauth to authenticate itself but doesn't include the app's consumer key and consumer secret? fetch the key and secret at runtime from a secure server somewhere? that could be trivially intercepted. Joseph Cheek @cheekdotcom Chris Babcock wrote: On Sun, 16 Aug 2009 18:49:49 -0400 Jason Martin legos.j...@gmail.com wrote: On another note, how Open Source friendly is OAuth? I'm not sure if people who write open source software want to be giving out their Consumer Secret key in their source code Reasoning from a faulty premise. When you know your code is going to be seen you either avoid doing stupid things like hard coding credentials or you learn fast that configuration data is not code. (Now where I did leave my virtual haddock?) Chris Babcock
Re: Absurd Misunderstanding of Open Anything (Was: [twitter-dev] Re: Open Auth)
nor can oauth assure the provider that a desktop app is legitimate when the app authenticates itself to the provider. John Kristian wrote: An OAuth Consumer that's deployed to users' desktops or mobile devices can't keep a secret. One should assume its consumer key and consumer secret will be known to attackers. Consequently, OAuth doesn't really assure the user that he's authorizing a legitimate copy of the Consumer software.
[twitter-dev] Re: Open Auth
I don't feel that OAuth is a good solution for desktop applications. If a user doesn't want the application to access their Twitter account, why'd they download it in the first place? It seems very redundant. But the real problem is for mobile devices, especially for devices that don't have Copy and Paste functions (like the iPhone, up until recently). Twitter doesn't have a login page for OAuth that really is made for mobile phones, so the user has to perform extra actions (zooming, panning, etc.) to be able to login. The PIN method of verification doesn't work well for phones that don't have Copy and Paste (like pre-3.0 iPhone, if you plan on supporting that), but then neither does the Browser option work, because you can't really launch an app from a URL (with the exception of the iPhone, but Twitter doesn't allow non-standard URL schemes). OAuth on mobile devices doesn't work. Let's go back to the iPhone (which I use as an example because I am a developer for it). You can't be contaminated with viruses, you can't get malware, and you can't get spyware. The only way you can get software at all (legally) is to get it from Apple, through the App Store, and Apple already does filtering, and strips out malicious apps. Since the App Store is the only medium to get apps, you have to want and then go download them. There is no third-party here putting malicious code on your device, and stealing your credentials. There is only the users, who wants to use your app, downloads it, and then is asked if wants to allow this app to access Twitter. If he doesn't want to let it access Twitter, why the heck did the user download the app in the first place? Sure, I chose the iPhone, but from what I understand, other phones have app stores of their own: Android has their Marketplace, Blackberry has one, Palm will soon get one if they don't already have one. People want to use Twitter on these devices, even full clients. But trying to login to OAuth on that tiny screen, with a PIN that you may or may not be able to copy and paste (depending on your device capabilities), is just a big hassle. For my Twitter client, I've gone ahead and done all the OAuth authentication behind the scenes. I'll ask them for a username and password, and log them into OAuh myself without them having to ever see a web browser. Wait! You shouldn't do that! Whatever! I'm selling this Twitter client on the App Store for two dollars. If a user doesn't want to let my app access Twitter, why is he wasting two bucks to download an app he will not use? It does not make sense! I understand that OAuth is implemented to give the user an extra net of security, but I'm not sure that the OAuth system is the best one to use. What would be best is a system that can be used on any platform, with any device, mobile or desktop. Modifying the login to do something different for mobile clients, like a different way of authenticating (such as choosing a picture. Show a picture in the web browser, send possible images to the client, then have the user choose the correct picture they saw), would be fantastic! At the very least, mobile versions of OAuth login and authentication should be implemented. On another note, how Open Source friendly is OAuth? I'm not sure if people who write open source software want to be giving out their Consumer Secret key in their source code for spammers to possible get a hold of, build a bot using that key and secret, and then spam Twitter using that key, which Twitter might block, thus, completely disabling your app for all your users. This is terrible for people who might write open source iPhone clients, as the approval process for these apps takes 2 weeks: 2 weeks your users can't use your app, and might switch over to another client. - Jason On Aug 16, 2009, at 7:18 AM, Andrew Badera wrote: On Sun, Aug 16, 2009 at 7:08 AM, Nicole Simonnee...@gmail.com wrote: On Sat, Aug 15, 2009 at 22:26, Kevin Mesiab ke...@mesiablabs.com wrote: The interaction seems unintuitive and redundant for users who have already granted our application 'trust' by installing it. I can't understand this notion. Every single day users are sheep enough to do stupid things - they just need to be guided to do so. And then they will follow. Every single day (especially the normal users) install dozens of apps on facebook without even thinking about that box in the middle nor reading it. And 'the experienced ones' who teach the sheeps make sure that never use your password gets drilled into their heads. Before there was no alternative. Now there is a better way.From now it is password? BAD. Using without password and authorize with twitter: good! Yes, they have granted you the trust of installing it, but could you please set the mindset to the goal? as part of our x step installation step, this is what is
Absurd Misunderstanding of Open Anything (Was: [twitter-dev] Re: Open Auth)
On Sun, 16 Aug 2009 18:49:49 -0400 Jason Martin legos.j...@gmail.com wrote: On another note, how Open Source friendly is OAuth? I'm not sure if people who write open source software want to be giving out their Consumer Secret key in their source code Reasoning from a faulty premise. When you know your code is going to be seen you either avoid doing stupid things like hard coding credentials or you learn fast that configuration data is not code. (Now where I did leave my virtual haddock?) Chris Babcock
Re: Absurd Misunderstanding of Open Anything (Was: [twitter-dev] Re: Open Auth)
On Aug 17, 6:27 am, Chris Babcock cbabc...@kolonelpanic.org wrote: When you know your code is going to be seen you either avoid doing stupid things like hard coding credentials or you learn fast that configuration data is not code. Fair enough. So how do you do it? How do I distribute a desktop or mobile device application - open source or closed - that uses my OAuth credentials in such a way as to protect my credentials from being discovered? Seriously, how do you do that? You don't distribute your credentials with the App. You include a README file that tells implementors how to get and install their own keys. Chris Babcock
Re: Absurd Misunderstanding of Open Anything (Was: [twitter-dev] Re: Open Auth)
Which eliminates one of the biggest features of OAuth for a lot of app-writers -- the ability to put their app in the source parameter, thus eliminating the biggest piece of marketing they have. On Mon, Aug 17, 2009 at 08:59, Chris Babcock cbabc...@asciiking.com wrote: On Aug 17, 6:27 am, Chris Babcock cbabc...@kolonelpanic.org wrote: When you know your code is going to be seen you either avoid doing stupid things like hard coding credentials or you learn fast that configuration data is not code. Fair enough. So how do you do it? How do I distribute a desktop or mobile device application - open source or closed - that uses my OAuth credentials in such a way as to protect my credentials from being discovered? Seriously, how do you do that? You don't distribute your credentials with the App. You include a README file that tells implementors how to get and install their own keys. Chris Babcock -- Internets. Serious business.
Re: Absurd Misunderstanding of Open Anything (Was: [twitter-dev] Re: Open Auth)
exactly. and for those who think their closed-source oauth app hides their app key and secret, have you ever run strings on your binary? (for those keeping score, it's basic auth: 2, oauth: 0) thanks! Joseph Cheek @cheekdotcom JDG wrote: Which eliminates one of the biggest features of OAuth for a lot of app-writers -- the ability to put their app in the source parameter, thus eliminating the biggest piece of marketing they have. On Mon, Aug 17, 2009 at 08:59, Chris Babcock cbabc...@asciiking.com mailto:cbabc...@asciiking.com wrote: On Aug 17, 6:27 am, Chris Babcock cbabc...@kolonelpanic.org mailto:cbabc...@kolonelpanic.org wrote: When you know your code is going to be seen you either avoid doing stupid things like hard coding credentials or you learn fast that configuration data is not code. Fair enough. So how do you do it? How do I distribute a desktop or mobile device application - open source or closed - that uses my OAuth credentials in such a way as to protect my credentials from being discovered? Seriously, how do you do that? You don't distribute your credentials with the App. You include a README file that tells implementors how to get and install their own keys. Chris Babcock -- Internets. Serious business.
Re: Absurd Misunderstanding of Open Anything (Was: [twitter-dev] Re: Open Auth)
When you know your code is going to be seen you either avoid doing stupid things like hard coding credentials or you learn fast that configuration data is not code. Fair enough. So how do you do it? How do I distribute a desktop or mobile device application - open source or closed - that uses my OAuth credentials in such a way as to protect my credentials from being discovered? Seriously, how do you do that? You don't distribute your credentials with the App. You include a README file that tells implementors how to get and install their own keys. No barrier to entry there. ;-) -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- I'd love to go out with you, but I'm rethreading my toothbrush bristles. -
Re: Absurd Misunderstanding of Open Anything (Was: [twitter-dev] Re: Open Auth)
This is interesting Chris, as I have had the same question. How would you propose to distribute a usable FLOSS twitter app that uses Oauth to authenticate itself but doesn't include the app's consumer key and consumer secret? fetch the key and secret at runtime from a secure server somewhere? that could be trivially intercepted. Joseph Cheek @cheekdotcom Chris Babcock wrote: On Sun, 16 Aug 2009 18:49:49 -0400 Jason Martin legos.j...@gmail.com wrote: On another note, how Open Source friendly is OAuth? I'm not sure if people who write open source software want to be giving out their Consumer Secret key in their source code Reasoning from a faulty premise. When you know your code is going to be seen you either avoid doing stupid things like hard coding credentials or you learn fast that configuration data is not code. (Now where I did leave my virtual haddock?) Chris Babcock
Re: Absurd Misunderstanding of Open Anything (Was: [twitter-dev] Re: Open Auth)
@chris You cannot ask every user to get new consumer token/secret. There is no way you can protect a consumer secret. @Joseph fetch the key and secret at runtime from a secure server somewhere? that could be trivially intercepted. As far as i know this is the best way to hide the consumer secret. This will not stop a determined user who try to intercept the keys but you have the option of changing your key/secret values( for a consumer) periodically. Other options are obfuscating/encrypting secrets at client side (again it will not stop a determined user). But the key management is difficult here as you have to download the app everytime(or whenever the risk of keys being compromised is high) Srikanth On Mon, Aug 17, 2009 at 6:31 PM, Joseph Cheek jos...@cheek.com wrote: This is interesting Chris, as I have had the same question. How would you propose to distribute a usable FLOSS twitter app that uses Oauth to authenticate itself but doesn't include the app's consumer key and consumer secret? fetch the key and secret at runtime from a secure server somewhere? that could be trivially intercepted. Joseph Cheek @cheekdotcom Chris Babcock wrote: On Sun, 16 Aug 2009 18:49:49 -0400 Jason Martin legos.j...@gmail.com wrote: On another note, how Open Source friendly is OAuth? I'm not sure if people who write open source software want to be giving out their Consumer Secret key in their source code Reasoning from a faulty premise. When you know your code is going to be seen you either avoid doing stupid things like hard coding credentials or you learn fast that configuration data is not code. (Now where I did leave my virtual haddock?) Chris Babcock
Re: Absurd Misunderstanding of Open Anything (Was: [twitter-dev] Re: Open Auth)
This is a good discussion - I've yet to find a canonical answer for how this *should* be done for client-side/consumer apps. If you are distributing a server application, then putting the application registration instructions in a README is perhaps not such a big deal. Desktop/mobile apps are another matter though. It's also worth saying that even if you could find a secure way of distributing a consumer key, you gotta ask if its even the right thing to be doing. I think not. Definitely not. Once the code is out there, I don't want everyone authenticating with _my_ application registration and consumer key (at this point, I have no way of knowing that the app hasn't been modified in some way that I do not approve of. I risk one rogue instance getting me blacklisted and in turn disabling every other instance. Great, DoS by design). Since the README approach is such a big no-no for client-side/consumer apps, the question I'd be asking is: where is the API for performing an initial application registration/bootstrap? i.e. an example of the scenario I have in mind (considering a desktop app): - user installs the app - on first use, directs the user through online login to twitter and automatic oauth client app request - newly registered application credentials transparently returned to the application (securely; somehow) - application saves the (instance specific) application key and consumer secret; uses these for standard oauth in subsequent sessions. Does anything along these lines already exist? If so, I haven't stumbled upon it yet. Regards, Paul http://tardate.com On Mon, Aug 17, 2009 at 9:01 PM, Joseph Cheek jos...@cheek.com wrote: This is interesting Chris, as I have had the same question. How would you propose to distribute a usable FLOSS twitter app that uses Oauth to authenticate itself but doesn't include the app's consumer key and consumer secret? fetch the key and secret at runtime from a secure server somewhere? that could be trivially intercepted. Joseph Cheek @cheekdotcom Chris Babcock wrote: On Sun, 16 Aug 2009 18:49:49 -0400 Jason Martin legos.j...@gmail.com wrote: On another note, how Open Source friendly is OAuth? I'm not sure if people who write open source software want to be giving out their Consumer Secret key in their source code Reasoning from a faulty premise. When you know your code is going to be seen you either avoid doing stupid things like hard coding credentials or you learn fast that configuration data is not code. (Now where I did leave my virtual haddock?) Chris Babcock
Re: Absurd Misunderstanding of Open Anything (Was: [twitter-dev] Re: Open Auth)
Silly me. I thought someone was talking about distributing source code. Building an enduser distribution is somewhat to entirely different. First, there really isn't any point to using OAuth for a client unless the client code lives on the network. The whole advantage of the scheme is that the user does not have to disclose credentials to one or more third parties. An application that doesn't access a third party network should use basic authentication over HTTPS. If Twitter decides to eliminate basic auth then the correct way (from a security stand point) to implement OAuth would be to obtain a separate key for each client. I don't see the current OAuth spec as being set up to handle bulk key assignments, but you can't distribute a single key to multiple clients outside of your network. Whether or not the app is Open Source is a non-issue; It's complete FUD-rucking to imply that it is any diffent distributing a secret key in a close source app than it would be to do so in an open source app. What happens if you try to use a screwdriver as a hammer? It's the same thing here only someone had to drag Open Source into as if that made any kind of a difference. To top it off, the OP had a complete misunderstanding of the consequences of key disclosure. A Spammer could use it and get your app banned... as if that's of any consequence compared to the users' accounts getting hijacked by apps impersonating your client. And what's with keeping score as if Open Auth and basic were a couple of talking tools on Disney Channel having some sort of ludicrous rivalry? Chris Babcock This is interesting Chris, as I have had the same question. How would you propose to distribute a usable FLOSS twitter app that uses Oauth to authenticate itself but doesn't include the app's consumer key and consumer secret? fetch the key and secret at runtime from a secure server somewhere? that could be trivially intercepted. Joseph Cheek @cheekdotcom Chris Babcock wrote: On Sun, 16 Aug 2009 18:49:49 -0400 Jason Martin legos.j...@gmail.com wrote: On another note, how Open Source friendly is OAuth? I'm not sure if people who write open source software want to be giving out their Consumer Secret key in their source code Reasoning from a faulty premise. When you know your code is going to be seen you either avoid doing stupid things like hard coding credentials or you learn fast that configuration data is not code. (Now where I did leave my virtual haddock?) Chris Babcock
Re: Absurd Misunderstanding of Open Anything (Was: [twitter-dev] Re: Open Auth)
On Mon, 17 Aug 2009 23:32:58 +0530 srikanth reddy srikanth.yara...@gmail.com wrote: @chris You cannot ask every user to get new consumer token/secret. There is no way you can protect a consumer secret. I did have a blind spot operating here. When someone says, Open Source, I'm usually thinking server software not Joe's ShareWare. Since we were talking about source code distribution, I wasn't even thinking about user binaries. @Joseph fetch the key and secret at runtime from a secure server somewhere? that could be trivially intercepted. As far as i know this is the best way to hide the consumer secret. This will not stop a determined user who try to intercept the keys but you have the option of changing your key/secret values( for a consumer) periodically. Other options are obfuscating/encrypting secrets at client side (again it will not stop a determined user). But the key management is difficult here as you have to download the app everytime(or whenever the risk of keys being compromised is high) It's worse than that. You don't even have to intercept the key, just use the application itself to obtain tokens for other users' accounts. How are they going to tell the difference between their copy of TweetX and someone elses' in their auth dialogs? Chris Babcock
Re: Absurd Misunderstanding of Open Anything (Was: [twitter-dev] Re: Open Auth)
It's worse than that. You don't even have to intercept the key, just use the application itself to obtain tokens for other users' accounts. How are they going to tell the difference between their copy of TweetX and someone elses' in their auth dialogs? Sorry. I didn't get this. How are you going to obtain tokens for *other * users? The worst you can do is use the key/secrets to trap *new *users. Even if you assume the app is storing tokens locally, it does only for that desktop user.True there is a risk if some one steals his access tokens but he is not completely wiped out as he still has the option of revoking the access to the app. Srikanth On Tue, Aug 18, 2009 at 2:39 AM, Chris Babcock cbabc...@kolonelpanic.orgwrote: On Mon, 17 Aug 2009 23:32:58 +0530 srikanth reddy srikanth.yara...@gmail.com wrote: @chris You cannot ask every user to get new consumer token/secret. There is no way you can protect a consumer secret. I did have a blind spot operating here. When someone says, Open Source, I'm usually thinking server software not Joe's ShareWare. Since we were talking about source code distribution, I wasn't even thinking about user binaries. @Joseph fetch the key and secret at runtime from a secure server somewhere? that could be trivially intercepted. As far as i know this is the best way to hide the consumer secret. This will not stop a determined user who try to intercept the keys but you have the option of changing your key/secret values( for a consumer) periodically. Other options are obfuscating/encrypting secrets at client side (again it will not stop a determined user). But the key management is difficult here as you have to download the app everytime(or whenever the risk of keys being compromised is high) It's worse than that. You don't even have to intercept the key, just use the application itself to obtain tokens for other users' accounts. How are they going to tell the difference between their copy of TweetX and someone elses' in their auth dialogs? Chris Babcock
Re: Absurd Misunderstanding of Open Anything (Was: [twitter-dev] Re: Open Auth)
On Tue, 18 Aug 2009 02:52:24 +0530 srikanth reddy srikanth.yara...@gmail.com wrote: It's worse than that. You don't even have to intercept the key, just use the application itself to obtain tokens for other users' accounts. How are they going to tell the difference between their copy of TweetX and someone elses' in their auth dialogs? Sorry. I didn't get this. How are you going to obtain tokens for *other * users? It's a social engineering attack. If the app contains code to authorize new accounts and all the copies of the app use the same secret key then Twitter will not be able to tell the difference between a legitimate token request and a spoofed request. Send out enough requests and eventually a user will approve your token giving you complete access to their account. Chris Babcock
Re: Absurd Misunderstanding of Open Anything (Was: [twitter-dev] Re: Open Auth)
On Aug 17, 4:55 pm, Chris Babcock cbabc...@kolonelpanic.org wrote: Silly me. I thought someone was talking about distributing source code. Building an enduser distribution is somewhat to entirely different. That's what I was getting at when I said a desktop or mobile device application - open source or closed. I think you're seeing the same challenge now that many of the rest of us are. Distributing an OSS server-side app is a cinch; as you said, you put Go get yourself some Twitter OAuth credentials in the README for developers who are using your code as the basis for their app. The hard part is distributing an end-user ready desktop app. OAuth's out-of-band auth flow is intended to solve this for non- browser based applications, but I think how the developer of such an app protects their client credentials was sort of left as an exercise for the reader. The trouble is, it's pretty much impossible. The problem we were left to solve appears unsolvable. This means someone has to go back to the drawing board. This is a really big, fatal flaw in OAuth that's going to have to be fixed somehow.
Re: Absurd Misunderstanding of Open Anything (Was: [twitter-dev] Re: Open Auth)
I still didnt get this Just to make my question clear How are you going to obtain tokens for *other *users using the application itself? The worst you can do is use the key/secrets to trap *new *users by building a brand new app (with the stolen consumer key/secrets. And new clients have to trust this app before downloading) I am just trying to understand why this approach(of getting consumer secrets/tokens from a server which changes the values periodically)is worse than storing the keys at the client itself. If the app contains code to authorize new accounts and all the copies of the app use the same secret key then Twitter will not be able to tell the difference between a legitimate token request and a spoofed request Agreed on this part. Send out enough requests and eventually a user will approve your token giving you complete access to their account This is not clear. Sending what kind of requests? User will only approve the requests coming directly from twitter . But before that twitter will verify the app credentials (which will pass as they are stoled ones). But the user will have to trust this app even before he starts using (by downloading that app he shows some level of trust). Just need clarification on this statement You don't even have to intercept the key, just use the *application itself *to obtain tokens for other users' accounts On Tue, Aug 18, 2009 at 3:08 AM, Chris Babcock cbabc...@kolonelpanic.orgwrote: On Tue, 18 Aug 2009 02:52:24 +0530 srikanth reddy srikanth.yara...@gmail.com wrote: It's worse than that. You don't even have to intercept the key, just use the application itself to obtain tokens for other users' accounts. How are they going to tell the difference between their copy of TweetX and someone elses' in their auth dialogs? Sorry. I didn't get this. How are you going to obtain tokens for *other * users? It's a social engineering attack. If the app contains code to authorize new accounts and all the copies of the app use the same secret key then Twitter will not be able to tell the difference between a legitimate token request and a spoofed request. Send out enough requests and eventually a user will approve your token giving you complete access to their account. Chris Babcock
[twitter-dev] Re: Open Auth
On Sat, Aug 15, 2009 at 22:26, Kevin Mesiab ke...@mesiablabs.com wrote: The interaction seems unintuitive and redundant for users who have already granted our application 'trust' by installing it. I can't understand this notion. Every single day users are sheep enough to do stupid things - they just need to be guided to do so. And then they will follow. Every single day (especially the normal users) install dozens of apps on facebook without even thinking about that box in the middle nor reading it. And 'the experienced ones' who teach the sheeps make sure that never use your password gets drilled into their heads. Before there was no alternative. Now there is a better way.From now it is password? BAD. Using without password and authorize with twitter: good! Yes, they have granted you the trust of installing it, but could you please set the mindset to the goal? as part of our x step installation step, this is what is going to happen: - download app - install app - test app - now the fun part: making sure you get the best ou tof this experience and connect it with twitter itself, and this is how it looks. We are using the secure process where you do not need to enter anywhere your password. we never ask for your password, because we are the good guys! - do this - do that and tada! you can start using our app! thanks for trusting us! Where is the problem? It only is unintuitve when you make it as such. of course the above is too complicated, so the real steps only should be 3 easy steps to go - download, install, connect, use! or something like it. But as long as you treat it as the ugly way you don't want to use, you will not make it easy on you. Nicole -- Jetzt im Buchhandel: Twitter - Mit 140 Zeichen zum Web 2.0 Amazon: http://tinyurl.com/6at9c5 http://mit140zeichen.de - http://twitter.com/m140z Kontakt: http://twitter.com/NicoleSimon https://www.xing.com/profile/Nicole_Simon skype: nicole.simon / mailto:nicole.si...@mit140zeichen.de phone: +49 451 899 75 03 / mobile: +49 179 499 7076
[twitter-dev] Re: Open Auth
When a user signs up at TwitPic, for instance, the same credentials they used for Twitter are now valid for use in uploading media. This lets users enjoy a bit of a mash-up with a single sign-on. Is this also true when authorized via openAuth? -- Kevin Mesiab CEO, Mesiab Labs L.L.C. http://twitter.com/kmesiab http://mesiablabs.com http://retweet.com
[twitter-dev] Re: Open Auth
Hi Kevin, With basic auth, its nice because you can use those credentials anywhere. I *was* working on a collaboration site, until I heard basic auth was going away, because I was able to use credentials for dozens of services around a single profile. I asked the same question about oAuth, i.e. can I validate with oAuth and then allow these users to show tokens to other oAuth enabled services and let them proceed. The answer I got *then* was no. Hopefully this will change, as the other path presented so many cool options. Anyway, retweet.com looks very cool. Peter On Sun, Aug 16, 2009 at 6:07 AM, Kevin Mesiab ke...@mesiablabs.com wrote: When a user signs up at TwitPic, for instance, the same credentials they used for Twitter are now valid for use in uploading media. This lets users enjoy a bit of a mash-up with a single sign-on. Is this also true when authorized via openAuth? -- Kevin Mesiab CEO, Mesiab Labs L.L.C. http://twitter.com/kmesiab http://mesiablabs.com http://retweet.com
[twitter-dev] Re: Open Auth
Looks nice. Seems like a Digg for twitter almost. Look forward to seeing it in action. On Sat, Aug 15, 2009 at 9:18 PM, Kevin Mesiab ke...@mesiablabs.com wrote: Thanks, here's a little sneak preview (attached). On Sat, Aug 15, 2009 at 3:13 PM, Jesse Stayje...@staynalive.com wrote: Considering Twitter's recent move, you guys have a GREAT URL ( retweet.com). Can't wait to see what you guys do with that. Jesse -- Josh
