We are considering not implementing OAuth in our desktop application.
The interaction seems unintuitive and redundant for users who have
already granted our application 'trust' by installing it. Are we
still to expect basic auth to go away? Is it possible to be granted a
source attribute without OAuth implementation?
--
Kevin Mesiab
CEO, Mesiab Labs L.L.C.
http://twitter.com/kmesiab
http://mesiablabs.com
http://retweet.com
The interaction seems unintuitive and redundant for users who have
already granted our application 'trust' by installing it.
Agreed. OAuth presents a standardized and centralized process, a
universal standard which users can become familiar with, rather than
any given app's arbritrary authorization mechanisms and actual levels
of trustability.
∞ Andy Badera
∞ This email is: [ ] bloggable [x] ask first [ ] private
∞ Google me: http://www.google.com/search?q=(andrew+badera)+OR+(andy+badera)
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 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
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
(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 <cbab...@asciiking.com
> <mailto:cbab...@asciiking.com>> wrote:
>
>
>
> > On Aug 17, 6:27 am, Chris Babcock <cbabc...@kolonelpanic.org
No barrier to entry there. ;-)
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com
-- "I'd love to go out with you, but I'm rethreading my toothbrush bristles." -
Joseph Cheek
@cheekdotcom
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
> @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
> <<
> 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