OAuth wed & desktop feedback
Ryan Sarver
I wanted to email the list to start gathering some feedback on how we
can improve the OAuth workflow. As we have discussed in the past,
Basic Auth is going to be deprecated at some point in the future for
OAuth and we want to make sure we improve the experience to meet
everyone's needs. I am interested in capturing feedback for both the
web and desktop workflows.
1. What can be improved about the web workflow?
2. What can be improved about the desktop workflow?
3. What other models of distributed auth do you think we could learn
from and what specifically about them?
4. What could we improve around the materials for integrating OAuth
into your application?
We really appreciate your feedback.
Best, Ryan
Cameron Kaiser
> 2. What can be improved about the desktop workflow?
I think the biggest improvement that can be made is not making the assumption
people are in a web browser environment. Yes, there are workarounds, but they
are kludgey by definition.
If nothing else, the login pages need to be made as *basic* as possible so
that devices such as basic mobile browsers can access them. For example, you
can't sign in to Twitter with Lynx. That sounds dumb, but if Lynx can sign
in, then *anything* can. That's not a problem with OAuth per se, that's a
problem with Twitter's UX. If you can swing that, I bet a lot of problems
can then be easily worked around.
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com
-- Greek tailor shop: "Euripedes?" "Yes -- Eumenides?" ------------------------
Chad Etzel
On Mon, Oct 12, 2009 at 1:01 PM, Ryan Sarver <rsa...@twitter.com> wrote:
>
> 1. What can be improved about the web workflow?
The desktop OAuth flow is pretty good, but the mobile device OAuth
flow is terribly painful. Since Twitter is very mobile focused, having
smooth OAuth flows on as many mobile devices as possible is a win-win
for devs and Twitter. This issue has a lot of interest from other devs
as well:
http://code.google.com/p/twitter-api/issues/detail?id=395 (I
completely forgot that I submitted that issue).
I know there are many mobile app developers that want to stay as far
away from OAuth as possible at the moment. Many are still begging for
Basic Auth source app keys citing that "mobile OAuth provides
unacceptable UX for my app."
> 2. What can be improved about the desktop workflow?
n/a (for me)
> 3. What other models of distributed auth do you think we could learn
> from and what specifically about them?
I am happy to see username/password Basic Auth go away, but I would be
sad to see all methods of Basic Auth unavailable. Lots of other APIs
have "api keys" that users can use to allow access to an api on their
behalf (FriendFeed, Prowl, TweetHook, and some others come to mind
immediately). Each user gets an API Key which allows manipulation of
some aspects of their accounts, but as much as knowing the actual
account password combo. This has a couple of advantages of Basic Auth
and OAuth:
a) If an app starts acting up, the user can revoke/change their
account API key and just update the services that are still relevant
to them to continue working. This isn't quite as nice as "per app"
revokation that OAuth provides, but less "painful" from a user
point-of-view as changing their account login password.
b) Basic Auth is still possible. This means that simple use-cases like
command-line curls, cron jobs, embedded systems, web-browser-less
systems, etc can still interact with the API without having to jump
through the OAuth hoops.
I would suggest that "API Key Auth" should be required to use HTTPS
and disable HTTP access.
my 2 cents,
-Chad
Chad Etzel
"Each user gets an API Key which allows manipulation of
some aspects of their accounts, but *NOT* as much as knowing the actual
account password combo."
-chad
Amicus
into your application?
specific implementation isn't documented and I've implemented code
based on current Twitter OAuth behavior, but this isn't a good way to
develop code.
Can you please provide documentation to address the question in
http://groups.google.com/group/twitter-development-talk/browse_thread/thread/853c4b6b839568b7/da1999e3ec8383e7#da1999e3ec8383e7
The question was: How to detect the "denied" condition on the Twitter
OAuth page (and is Twitter guaranteed to keep the current
implementation where the redirect app url has the word "denied" in it)
--------------
The OAuth page for mobile is extremely user-unfriendly and it is also
buggy.
Here are some of the bugs that hurt OAuth adoption among developers
(and will hurt users who use mobile twitter apps with OAuth)
#1050 is a trivial bug fix - (The "Allow" button is in bold, but the
page defaults to "Deny")
#1045 is an even more trivial bug fix - (The "Signup" link redirects
to the "Login" page )
#395 addresses the larger issue of the OAuth page being mobile-
unfriendly.
Andy Freeman
for debugging purposes. I mention that because using curl with oauth
is very painful.
I'm not sure what you can do about that.
Perhaps calls using basic authentication could have very stringent
rate restrictions. This would address two issues because it would let
us provoke rate-limits to test our responses without having to
generate lots of load.
Jesse Stay
1. What can be improved about the web workflow?
2. What can be improved about the desktop workflow?
3. What other models of distributed auth do you think we could learn
from and what specifically about them?
4. What could we improve around the materials for integrating OAuth
into your application?
Chad Etzel
> On Mon, Oct 12, 2009 at 11:01 AM, Ryan Sarver <rsa...@twitter.com> wrote:
>>
>> 1. What can be improved about the web workflow?
>> 2. What can be improved about the desktop workflow?
>> 3. What other models of distributed auth do you think we could learn
>> from and what specifically about them?
>> 4. What could we improve around the materials for integrating OAuth
>> into your application?
>>
>
> This is a given coming from me (I wrote O'Reilly's FBML Essentials), but I
> strongly recommend looking at the way Facebook is doing it with Facebook
> Connect - if you're logged into Facebook and have authorized the app, no
> further auth is necessary - you click the "Connect with Facebook" button,
> Facebook tells your app it's already authorized (without sending the user
> through the authentication or authorization process again), and you can then
> give the user a session in your app. It's a simple one-click workflow that
> only turns into a more-than-one-click workflow when absolutely necessary.
Twitter already has something similar (one-click login):
http://apiwiki.twitter.com/Sign-in-with-Twitter
Some devs like this for the simplicity, some don't because it will
automatically use the "already logged in account" w/o giving the
option to use another account. Whereas most facebook users probably
have only one account, I would guess that a larger percentage of
Twitter users (while still a small percentage) are managing multiple
accounts.
-Chad
Jesse Stay
Twitter already has something similar (one-click login):
http://apiwiki.twitter.com/Sign-in-with-Twitter
Some devs like this for the simplicity, some don't because it will
automatically use the "already logged in account" w/o giving the
option to use another account. Whereas most facebook users probably
have only one account, I would guess that a larger percentage of
Twitter users (while still a small percentage) are managing multiple
accounts.
-Chad
Isaiah
1. What can be improved about the web workflow?
2. What can be improved about the desktop workflow?
3. What other models of distributed auth do you think we could learn
from and what specifically about them?
4. What could we improve around the materials for integrating OAuth
into your application?
Duane Roelands
authentication for desktop applications is a nightmare. You have to
programatically interact with the browser and it's an enormous hassle.
I think that the OAuth flow for desktop applications is fine as-is.
Mobile apps need some love, no question, but for desktop apps, I don't
think anything is all that broken.
Abraham Williams
Abraham Williams | Community Evangelist | http://web608.org
Hacker | http://abrah.am | http://twitter.com/abraham
http://web608.org/geeks/abraham/blogs/2009/10/03/win-google-wave-invite
This email is: [ ] blogable [x] ask first [ ] private.
Craig Hockenberry
> 2. What can be improved about the desktop workflow?
the Mac and iPhone:
<http://blog.atebits.com/2009/02/fixing-oauth/>
Until that happens, no user or developer is going to be happy with
OAuth in a desktop or mobile application. Sorry to be blunt, but the
user experience sucks when you're using OAuth outside the confines of
a web browser.
Switching between web pages is acceptable, switching between
applications is not. It's really that simple. Until that user
experience problem is addressed, you're going to see resistance with
adoption of OAuth or any other mechanism.
Also, from a debugging/testing point-of-view, HTTP basic
authentication needs to be maintained -- curl is an essential part of
the Twitter tool chain. (If you doubt this, read the new issue
submission form: <http://code.google.com/p/twitter-api/issues/entry>.)
It's a variation on the same problem on the desktop: you don't want to
leave the command line to perform the API request.
-ch
Amitab
gives a "Twitter is busy, too many people are tweeting" response. For
websites/ applications that are pretty small, each person who is
willing to try out is immensely valuable. I hate it when I loose that
person (probably permanently) just because twitter couldn't support
the log in process.
I saw this happening a lot of times today morning. It is a problem
that keeps recurring.
This is what I would want to improve in OAuth:
1) Get the login process working 99.999% time. I can cache the
remaining things but ic annot cache the login process.
2) Please integrate the OAuth authntication with my branding. At the
moment it is just the logo. I would like to have the whole background
be of my branding.
/Amitabh
Follow Twaller.com @mytwaller
On Oct 12, 1:20 pm, Abraham Williams <4bra...@gmail.com> wrote:
> A number of older threads for reference:http://groups.google.com/group/twitter-development-talk/browse_thread...http://groups.google.com/group/twitter-development-talk/browse_thread...http://groups.google.com/group/twitter-development-talk/browse_thread...
> <http://groups.google.com/group/twitter-development-talk/browse_thread...>http://groups.google.com/group/twitter-development-talk/browse_thread...http://groups.google.com/group/twitter-development-talk/browse_thread...
> <http://groups.google.com/group/twitter-development-talk/browse_thread...>
Cameron Kaiser
> > from and what specifically about them?
>
> I am happy to see username/password Basic Auth go away, but I would be
> sad to see all methods of Basic Auth unavailable. Lots of other APIs
> have "api keys" that users can use to allow access to an api on their
> behalf (FriendFeed, Prowl, TweetHook, and some others come to mind
> immediately). Each user gets an API Key which allows manipulation of
> some aspects of their accounts, but as much as knowing the actual
> account password combo. This has a couple of advantages of Basic Auth
> and OAuth:
>
> a) If an app starts acting up, the user can revoke/change their
> account API key and just update the services that are still relevant
> to them to continue working. This isn't quite as nice as "per app"
> revokation that OAuth provides, but less "painful" from a user
> point-of-view as changing their account login password.
>
> b) Basic Auth is still possible. This means that simple use-cases like
> command-line curls, cron jobs, embedded systems, web-browser-less
> systems, etc can still interact with the API without having to jump
> through the OAuth hoops.
>
> I would suggest that "API Key Auth" should be required to use HTTPS
> and disable HTTP access.
+1.
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com
-- Po-Ching Lives! ------------------------------------------------------------
Scott Haneda
in credentials for another website into that other website?
By rebranding the twitter oauth page it gets to a point where you may
as well just ask their user/pass on your own site, and never have them
leave your site/app.
I don't look at oauth as real time over the wire security, though it
helps in that area. I look at it as user education with the goal to
get users to understand not to cross polinate user/pass data to other
sites.
It would come down to users understanding to look at the URL,
something many just do not understand enough to do.
I do not understand all the details of oauth at this point. What I do
know is I've learned when I auth an app I should be looking for a
distinct look and feel at a specific URL.
If that look and feel changes, red flags are raised on my part. I'd
look to the URL, but wonder if I was not being tricked from
TWITTER.COM TO TWlTTER.COM. (those look identical to me, lowercase L
looks a lot like an uppercase I.
From my perspective, oauth needs to go after the OS vendors.
Integration with their underlying systems and API's is the only way
this will gain widespread use that is as secure as it can be for an
end user.
Right now, integration is not tight enough for a user to even
understand what they are gaining from this procedure. I can find 5
Twitter sites right now that ask for me to store a login and pass into
my account, they are not using oauth, and could do what they want with
my account. This just proves users are not understanding this.
Heck, twitters own account settings ask for raw login and password
data to gmail, yahoo, and I believe aol, last I looked.
--
Scott
Iphone says hello.
Sebastian
Allow the app to act as the user agent when authenticating with
Twitter when requesting the token and authorizing the app.
Let me rewrite this in plain english: let the app ask for login/
password and pass it to twitter.
Users don't seem to be worried about providing their credentials to a
"local" app. They do it all the time when configuring basic auth
clients, and they do it with 99% of the other client apps they use.
Developers are (barely, in most cases) worried about having to store
the password, but if they only need it during the initial handshake,
then there is nothing to store.
All we need is a simple API call where we can trade a login and
password for an oauth access token, bypassing the browser.
And if you think this will make it less secure, think about a desktop
app that, using the current workflow, launches a browser to get the
user to approve the app. That browser can be configured to use local
proxies, or JS callbacks or any number of mechanisms that let the app
capture the authentication credentials. Getting rid of the browser has
no negative impact on safety, while giving developers better control
of the UX, which gives them more reasons to implement oauth, which
does have a positive impact.
Anyway, just my two cents.
PS: There is nothing right now preventing a mobile or desktop app from
bypassing the browser as I'm describing, by "acting as a browser" and
calling the same pages a browser would have presented to the user.
Isaiah
Zhami
On Oct 12, 5:44 pm, Sebastian <sdelm...@gmail.com> wrote:
> The solution for OAuth on Mobile and Desktop is easy:
> password and pass it to twitter.
> password for an oauth access token, bypassing the browser.
This solution removes the password from being bandied about endlessly
with Basic Auth, but is appropriate for the world of desktop apps
where users are comfortable providing their password because
applications often ask for access restricted information.
JDG
Internets. Serious business.
Brian Smith
> 1. What can be improved about the web workflow?
* On many mobile platforms--even some of the newest ones--copy & paste is
unavailable, and/or users simply do not know how to do it.
* A 7-digit PIN is too long for most users to remember long enough to switch
apps and type it in. I tested 10 people when there was a 6-digit PIN and 6
of them could not remember the PIN long enough to type it in. Only 2 of 10
people tried to write the PIN down before closing the browser the first
time. That means they had to repeat the authorization process. 3 of the 10
people gave up and handed the phone back to me before completing the OAuth
sign-in pricess.
* *All* the users I tested described the OAuth-related parts as the worst
part of my app.
* It is very tempting to embed a browser control into the app and then use
that browser control to allow the user to do the OAuth flow, because often
it isn't easy for users to switch between the standalone web browser and the
Twitter app. However, any app that does this can act as a keylogger and grab
the user's username and password. So, OAuth isn't adding significant
security in this situation.
* OAuth doesn't work well when the user has multiple devices running the
same Twitter client. For example, Nokia smartphone owners often have
multiple Nokia smartphones (often a "work phone" and a "play phone"). If
they install the app on two phones, then whenever they log in on one phone,
they get logged off of the other phone. This wouldn't be so bad, but see
above: these users then have to go through the most-hated part of the
experience all over again. The only way I have found to overcome this:
create a bunch of different "apps," one for each model Nokia releases. But,
this is a poor solution because (a) all apps have to have a unique name, and
(b) I read here that Twitter may limit the number of apps that a developer
can register. Note that the people who review mobile twitter apps are the
ones most likely to have this problem, which sucks, because usually we want
to optimize their experience so they write good reviews. Ideally, there
would be a way for a single app to have multiple tokens at once.
Please feel free to contact me directly if you want any more detailed
feedback.
Regards,
Brian
Brian Smith
Letting a mobile/desktop app grab an OAuth token using the user’s username/password is still helpful because then they can store the token instead of the username/password, which is a big deal when there’s no really secure way to store it. Also, if your mobile phone/laptop gets stolen, you can still log in via the Twitter website and revoke access from the apps installed on your phone/laptop. If the app just used basic auth then the only way to revoke access would be to change your password. But, whoever stole your phone/laptop could have changed your password first (if the app was using Basic auth), and you’re locked out of your account.
So, a way to log in with basic auth and grab a OAuth token would can still be useful.
JDG
Internets. Serious business.
Arnaud Meunier
old rendering browsers is a must. Something as simple as using the
useragent to display a nice, working and adapted login page would be a
great start.
Another point would be reliability. Is there a way that you "priorize"
oAuth requests in order to prevent any 5xx errors, for example?
Arnaud.
Twitoaster - http://twitoaster.com
Isaiah
Brian Smith
It is even more likely that a malicious app would direct you to a phishing site during the OAuth flow and you wouldn’t even notice since many mobile browsers do not show you the URL and do not implement any anti-phishing UI whatsoever.
In fact, on some phones (especially ones a few years old), you will not even get a warning if the TLS certificate doesn’t match the domain to which you connected. So, you could see the “all secure” and still be getting phished.
Regards,
Brian
Josh Roesslein
token would be a nice solution, but I can see it
getting abused. An attacker could bombard this endpoint trying to
guess an account's password. Protection can be placed to limit calls
to this endpoint by IP which might be enough to prevent this kind of
brute attack.
This has been brought up before on the oauth mailing list, but a lot
of security folks cringe at the idea. I feel there is not
much of a security loss here since the application running on the
user's computer can already do harm.
I'd like to hear from the Twitter API team on their thoughts of this
idea. It might not be part of the spec, but OAuth
is pretty open to service providers extending it.
Josh
--
Josh
Jesse Stay
Ram
>>OAuth in a desktop or mobile application. Sorry to be blunt, but the
>>user experience sucks when you're using OAuth outside the confines of
>>a web browser.
A UIWebView (in an iPhone app) can provide a good user experience for
OAuth login
Right now, the OAuth UI is pretty bad (see bug 395). However, if that
bug is fixed, the user experience should be fairly good.
>>>It is even more likely that a malicious app would direct you to a phishing site during the OAuth flow
of the attack tactics that a malicious app can use.
A malicious app can do malicious things and OAuth wouldn't protect the
user against every possible attack.
However, OAuth can help in some other circumstances (with non-
malicious apps, that may have insecure code).
For instance, a popular iPhone Twitter client used to save the user's
(unencrypted) password on the device (NSUserDefaults).
Presumably, some Windows and Mac Twitter clients also do similar
things and save the unencrypted password on the machine. Some
probably send the unencrypted password over HTTP for every user post.
OAuth can help protect the user's password in these scenarios.
Obviously, the user (of an app with insecure code) is still at some
risk because the access token may be easily retrievable from the
machine, but it is far more difficult to exploit an access token
The bottomline is that it is possible to write good secure code with
basic auth, but several developers don't do that.
OAuth mitigates the risks, but it doesn't eliminate all risks.
So there is some value to OAuth.
Ram
http://blog.CascadeSoft.net
Zhami
and Web sites "theirs." I am sure that this is the mindset of most
people. We "visit" Web sites, and we "give" information to them. Yes,
they do things for us in return. Even when providing SaaS, I am still
on "their" site. On the other hand, when "I" use a desktop app, I am
using "my" software on my computer and it is likely that "I" have
other desktop apps to which I have given passwords and keys. In fact,
"I" may even have "my" Browser remember passwords for Web sites I
frequent as well as keep other personal information.
As a consequence of this distinction, while I consider OAuth a fine
architecture in the context of Web workflow, it is (presently) not
optimally suited for the desktop experience. As a user, I control my
apps (well, presuming they are not malicious), and can turn them off
or uninstall them at my discretion. A Web site is (very) different in
that I have no real authority over it.
btw: I think it is quite important to realize just how atypical/novel
Twitter is in assessing the needs of a desktop solution: Twitter isn't
really a Web site (though it has a Web site) -- Twitter is a messaging
infrastructure, and client apps are end-points. In this regard, think
of it more like email.
The UX I want for users of my app is what I want when they use an
email client: they'll use a Preferences/Wizard approach to add account
(s), and thereafter the app provides functionality. Although users
have the option of visiting Twitter's Web site to interact with
Twitter, it is my goal (as I suspect it is for most clients), to over
time obviate the need for users to go there.
In this context, I see the needs for a desktop solution as:
1) don't ever send the user's password in the "clear" over an
unencrypted transaction, even if obfuscated (e.g., Base64).
2) in spite of #1, don't require use of SSL/TLS for every transaction
(that requires user authentication).
3) client apps should be uniquely identified, and Twitter should have
the control to withdraw a client's access to Twitter's service.
4) empower a user to terminate an issued "token" (whether because the
app turns out to be malicious, or because the token has been
compromised).
Sebastian
On Oct 12, 11:44 pm, Josh Roesslein <jroessl...@gmail.com> wrote:
> Providing an API endpoint for basic auth credential exchange for a
> token would be a nice solution, but I can see it
> getting abused. An attacker could bombard this endpoint trying to
> guess an account's password. Protection can be placed to limit calls
> to this endpoint by IP which might be enough to prevent this kind of
> brute attack.
regular login page that can be abused just like you describe. It
already has protection. Even regular API calls have to be protected
because Basic Auth can be used for brute force attacks.
Adding an api call to exchange login/password pairs for oauth tokens
doesn't add any new security issues.
It does open the possibility for web sites to use this call instead of
the regular workflow, but, again, that possibility has always been
there, doing automated calls to the regular login and auth pages.
The only way to close that door is to offer web apps a way to do
password-less authentication, which is what oauth does, and to train
users to never ever give their password to a web site.
But for non-browser, native apps (mobile, desktop, etc), forcing the
use of a browser to authenticate to a separate website provides no
security at all. The native app can easily intercept the http calls,
the browser JS callbacks and many other ways to get that information.
So there is no point in forcing this workflow. We're better off not
giving users a false sense of security.
Craig Hockenberry
mobile app, please go read this:
<http://fireeagle.yahoo.net/developer/documentation/
oauth_best_practice>
Specifically, "... we insist that you must not use embedded rendering
controls to present the OAuth process ...".
Phishing in a web view is incredibly easy with a little bit of
JavaScript. From a user's point-of-view, entering their credentials
into that built-in web browser is MUCH less secure than sending HTTP
basic authentication over SSL.
-ch
Sebastian
a regular browser to the point a user cannot tell the difference.
Training users to expect security because it looks like a browser is
even worse than telling them to give their passwords to native apps
but be careful as to which apps they use.
Native apps can do many things browser-based apps cannot. Trying to
extend the OAuth metaphor to native apps only works when you give up
the idea of not having to give passwords (or you give up the idea of
having decent UX by saying that the user has to open a separate
browser manually).
OAuth on native apps is useful for:
- a way to provide fast-but-secure connections (https on small devices
has a significant performance impact)
- a way to help native apps not have to save passwords locally.
- a way for the service provider to identify (and block) apps.
- a way for the user to revoke authorization on a per-app basis.
Forget about using OAuth on native apps as a password-less
authorization mechanism, because no matter how hard you try, the
security holes are to big to close properly.
Because, as that Fire Eagle document proves, the only way to prevent
app developers from intercepting browser calls is to beg developers
not to intercept browser calls.
On Oct 13, 11:49 am, Craig Hockenberry <craig.hockenbe...@gmail.com>
wrote:
Ram
attacks that a malicious app can use with OAuth.
With these attacks, a malicious app can get the password.
Of course, in the case of basic auth, every app (malicious or good)
will always get the password.
However, as I also mentioned, OAuth offers significant security/
privacy benefits over basic auth - when it comes to non-malicious
apps.
I'm surprised that many OAuth opponents are unwilling to acknowledge
(or even discuss) this basic fact.
Ram
http://blog.CascadeSoft.net
On Oct 13, 8:49 am, Craig Hockenberry <craig.hockenbe...@gmail.com>
wrote:
>
> - Show quoted text -
BlueSkies
When my application requests an OAuth token on behalf of a user trying
to login, I have been seeing some errors:
Frequently: "/oauth/access_token Invalid / expired Token"
What is the length of time that a token is supposed to be valid for?
Is this documented and can it be extended? I'm sure that I probably
lose quite a few first time users when this happens. I imagine that
they probably bring up my login page, get distracted and then run into
this problem when they eventually try to log in.
Occasionally: "Twitter is over capacity."
Would it make any sense to prioritize token handling when Twitter is
at capacity? This is also an issue with wanting to allow my new users
to login easily, even if they can't tweet right away (to avoid user
conversion loss). My existing users probably never experience this
issue with tokens when Twitter is at capacity, since my application
caches credentials (as most other apps are probably also doing), so
they don't normally go through my OAuth login flow very often.
Not often: "Unknown SSL protocol error in connection to twitter.com:
443"
I'm not sure what causes this? I don't see it too often.
- Scott
