• If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • You already know Dokkio is an AI-powered assistant to organize & manage your digital files & messages. Very soon, Dokkio will support Outlook as well as One Drive. Check it out today!

View
 

oauth desktop discussion

Page history last edited by John Ballinger 15 years, 1 month ago

Open UX and implementation discussion on OAuth for desktop Twitter clients 

Read this thread on Twitter Developer Talk for background on this discussion.

Setting this up to get the ball rolling. Feel free to alter/evolve anything and join the conversation. It feels like a discussion of the UX pros/cons of OAuth for desktop apps would be a good place to start before moving on to implementation suggestions, etc., if we agree that it can, in fact, be made more usable. 

Thoughts? 

UX concerns 

  • Switching context from app to browser is jarring. This will be magnified for clients that support multiple accounts.
  • While setting up multiple accounts will users be forced to keep logging in and out of different accounts on Twitter. Flow?  

Is OAuth the right solution for desktop apps 

  • Does oOAuth on desktop provide a false sense of security? The app could do many worse malicious things as an installed desktop app. 

Can consumer secret be kept secret in a desktop app? 

  • AIR apps have access to the system key chain.
  • Should command-line apps save the consumer key to a file? What are the security implications of this.

 

I added some thoughts on how to modify the OAuth spec to allow for a nicer UX on my blog:

blog.atebits.com/2009/02/fixing-oauth/

 

Loren, I like your ideas about an environment-agnostic authentication gateway (especially me maintaining a command line Twitter app). The problem is keys. An open source app, or an app that's a script (like mine), has no way to securely maintain a way to sign tokens because it can't maintain a private key. If I understand your scheme correctly, your auth gateway would act on behalf of an application and that is a great idea, but how does the application represent itself in a secure fashion to the auth gateway? (If this is an obtuse question flame away :) -- Cameron Kaiser

 

I think the problem you describe is a flaw in OAuth.  It needs to be fixed.  However I think it's a *separate problem*.  I don't want to confuse the two and give people the impression that we need to solve that to solve the problem of shitty UX for native apps.  I'd be happy to brainstorm ideas for fixing that, but perhaps we should set up a new page to discuss it?

- Loren Brichter

 

Crap, I can't get rid of the comment. Um, help? :-D Moving it here ...

I agree it's an OAuth flaw primarily but then so are the UX issues as they have currently codified them. The reason why I think it's especially relevant to Twitter is Twitter's desire to phase Basic Auth completely. For tweetie, I could see you maintaining a key internally (although even that could be ripped off) because you have a signed, compiled app package. I don't see TTYtter or Spaz, to take two examples, having that luxury. Without that step, how the request is communicated to the authenticating server is moot because the request was never secured in the first place no matter how the UX problem is dealt with. (Please correct me if I'm mistaken.) -CK

 

Actually I'm not sure I even understand why there is an issue with consumer keys being public. The OAuth spec states: 

"Service Providers SHOULD NOT rely on the Consumer Secret as a method to verify the Consumer identity, unless the Consumer Secret is known to be inaccessible to anyone other than the Consumer and the Service Provider. The Consumer Secret MAY be an empty string (for example when no Consumer verification is needed, or when verification is achieved through other means such as RSA)."

Seems to cover the case well enough.  Again, I think this is a different problem. - Loren

 

Perhaps I should have been explicit: I'm talking about, specifically, the private key that is used to sign the request (section 9). That has to be secure or the whole thing falls apart (ok, Twitter could use PLAINTEXT but that would be dumb).

 

But with all due respect, how is that not relevant? The original prompt didn't limit itself to UX issues, and specifically mentioned the key issue as well. Twitter wants to go 100% OAuth and there are other ways in which OAuth is not reasonable, possible or useful than UX (even though UX is clearly important). If you're going to limit this to UX, it's going to be a losing proposition because the usual answer is 'deal with it' (a terrible answer, clearly, but the typical answer). It has to be demonstrated to Twitter that for a certain set of applications, OAuth is literally not possible, and for those apps Twitter has to decide whether cutting them off is worth it or not. UX gets the 'fugly but possible but you won't like it' angle, and I don't think that's going to be enough to justify maintaining an alternative access method to them. -- CK

 

(And I should add, lest I be misunderstood, that the UX issues are clearly valid. I just think there are a lot of people who will dismiss them out of hand, at their peril, but we can't fix those people.)

 

Alright, if we want to discuss here: perhaps the solution is to relax the requirement for a "fixed" consumer key.  They could be generated at runtime by the application.  Though the provider would lose the ability to revoke an entire class of applications, they could only revoke individual instances of a particular application. Haven't quite thought this through. - Loren

 

I agree with everything Loren's written, but I think a distinction has to be made between classes of apps. A rough cut would be:

 

  • browser (which can be further split into classic html or ajax)
  • standalone desktop
  • command-line
  • mobile (no browser)
  • smart-mobile (access to browser or webkit-like component)

 

In browser-based apps -- the main beneficiaries of the current OAuth flow -- it's not as jarring to open a browser window on the sign-in page. In all other classes of apps the UX and flow goes from horrible to impossible. At the very least I'd suggest all presentation/styling information be stripped and kept out of the authorization scheme -- by offering some sort of simple UI-neutral presentation (i.e. xml) for the auth phase. - Ramin

Comments (6)

ckaiser said

at 4:38 pm on Feb 18, 2009

I agree it's an OAuth flaw primarily but then so are the UX issues as they have currently codified them. The reason why I think it's especially relevant to Twitter is Twitter's desire to phase Basic Auth completely. For tweetie, I could see you maintaining a key internally (although even that could be ripped off) because you have a signed, compiled app package. I don't see TTYtter or Spaz, to take two examples, having that luxury. Without that step, how the request is communicated to the authenticating server is moot because the request was never secured in the first place no matter how the UX problem is dealt with. (Please correct me if I'm mistaken.) -CK

John Ballinger said

at 3:04 pm on Feb 19, 2009

Hi,

To clear up some points.
1. AIR apps have access to secure and encrypted storage managed by the operating system. On mac this is saved to your keychain and somewhere safe on PC.
2. Nearly all Twitter clients are AIR based apps (and for native ones there are some great solutions for more next point flow.).

QUESTION.
Will OAuth break the desktop experience for Twitter clients? 1. Open client, go to twitter, approve app, twitter redirects, you close browser, open app. App works?

POSSIBLE ANSWER.
1. Open app, goto twitter approve. Now here is the key. When the browser redirects to a web page. Here is what you need to do.

2. On the final web page you need to offer the user a BIG BUTTON, saying "Return to [your app].
With AIR you can launch apps from a button (well a flash button). http://www.hurl.ws/qmw this link shows you how to create you app so it can be launched from the browser and how to create a button. This allows you to create a more seamless user experience.

For native apps say twitterific you can do what itunes does and create links like itms://link_to_data (note the app name, itms) clicking this links launches iTunes from the browser. So you can make the experience a lot more seemless.
So for Twitterific, it can acutaually register with the OS so if you hit a link that says, twitteriffic://somedate_token etc.

This means you can create a continuos flow, and all the user has to do is click the "next" button.

Lastly I dont see any issue with using multiple accounts. Since its only the app just has to changed the token its using.

atebits said

at 4:47 pm on Feb 19, 2009

John: the point is that being directed to a browser *at all* is a terrible user-experience, and flat-out doesn't work in environments that don't have the ability to display webpages. (Command-line apps are an obvious example of this).

Shannon Whitley said

at 11:18 pm on Feb 20, 2009

I have a suggestion for a process that may be more familiar to end users and doesn't require an application to interact with a browser. Everyone has registered on a site, waited for a confirmation email, and then clicked on a confirmation link in the email. Standard stuff, right?

How about this?

1) The app requires an email addres on a setup page or in a configuration file.
2) If a Twitter oAuth user token isn't present, the app must contact a website (a website would be required for all apps -- could be shared with multiple apps).
3) The app generates a unique request token and stores it locally along with the email address.
4) The request token and email address are posted to the website.
5) The app explains to the user that a request has been made and the user will receive an email with further instructions.
6) The website (consumer) makes the standard oAuth connection and requests the auth link from Twitter. The link is sent in an email to the user.
7) The user opens the email, clicks on the link, and authorizes the app. The website receives the oAuth user token and stores it with the email address and original request token.
8) The user restarts the application (or continues from a dialog). The application contacts the website using the original request token and email address to retrieve the Twitter auth token.

It's an easy way for apps to maintain some control via email verification, and it's a familiar (non-jarring) process for end users.

Shannon Whitley said

at 11:43 am on Feb 21, 2009

Another thought; what if a user authorized an application *before* the download. The consumer would provide an authorization link to Twitter on the download page. Twitter is going to provide a tab to show each user the apps they've authorized, right? The user auth token could be displayed there and the user could copy that token into the setup page of the app after it's been downloaded.

atebits said

at 5:20 pm on Feb 21, 2009

Hey Shannon,

I really appreciate the creative ideas - keep 'em coming.

To critique: solution 1 (authenticate via email) still requires a browser to authenticate (when the user clicks the special link in the email itself).

Solution 2: would be clever, but only for certain kinds of apps. It wouldn't work for iPhone apps because distribution is handled through the App Store.

You don't have permission to comment on this page.