The OAuth / App Anti-Pattern

13 thoughts on “The OAuth / App Anti-Pattern”

1. 2012-04-21 22:21

   

   Andrew Coulton says:

   Though not a direct solution to showing the user the URL and SSL status, one way to prove authenticity would be if OAuth providers allowed users to set a secret word or phrase that is shown to them once they've provided their username but before they enter a password - as in some 3DSecure implementations - so the user knows to look for that before completing signin. Although again in an app that would be fairly easy to intercept without the user's knowledge. Otherwise, the only thing I can think of is a native OAuth implementation on each platform (like the Windows User Account Control overlay pop-up) that apps can/must call as a trusted intermediary rather than handling the process directly.

   Reply
2. 2012-04-22 08:45

   

   artesea says:

   As I tweeted, it's the same with Draw Something and Facebook, a popup within the app with no signs of the url. I was under the impression that at least with twitter you could send people to the oAuth page via their default browser and then get twitter to return them to a url which the app can capture via an intent eg http://templerun.com/androidauth or templerun://signedin but as I've not bother to get past page one in Android Coding 101 I couldn't confirm.

   Reply
3. 2012-04-22 09:06

   

   Paul Todd says:

   Maybe the the oauth provider (fb other twitter) could txt a code to the registered mobile on the service that could be used instead

   Reply
   1. 2012-04-22 09:27

      

      Terence Eden says:

      True - but not every device can receive SMS. An email may be better. But, again, not every device can receive email. I think that it needs to be self contained.

      Reply
4. 2012-04-22 09:22

   

   Tom Morris says:

   If only we had some kind of browser that could open, with a standard set of chrome to indicate the URL and the HTTPS status. Oh wait, the UX people will object. Because security is so much less important than UX. Silly me. I keep forgetting.

   Reply
   1. 2012-04-22 09:24

      

      Terence Eden says:

      We do have that - but how do we get back to the app?

      Reply
5. 2012-04-22 09:25

   

   Daniel Appelquist says:

   Indeed, this is the elephant in the Oauth room (at least when it comes to mobile). It's not just limited to apps, either, because in many mobile browsers (notably ios) its not possible to verify the authenticity of the certificate used to secure the https session. On desktop browsers, you can click on the lock icon and see some indication that, yes, this is actually my bank I am talking to. Not so on mobile browsers. And as you rightly point out, when this session is happening in a Web view in an App, all bets are off. The page could be from anywhere and there's no way for the user to know if it's secure or not, let alone validate the certificate. I think we need a standard "chrome" for these chromeless web views that can reliably display security information, including allowing the user to drill down to view information on the certificate. Is this something being discussed in the w3c coremob community group? http://www.w3.org/community/coremob/ If not, it should be. Paging @jamespearce.

   Reply
   1. 2012-04-22 09:35

      

      Terence Eden says:

      Interesting. I know on Android, you can see the padlock (and check the cert if you want). The issue on a chromeless web views is that a malicious app could fake the chrome.

      Reply
6. 2012-04-22 10:19

   

   Craig Heath says:

   Andrew is correct that the conventional way to address this problem is to present the user with something that malicious code trying to impersonate the legitimate server cannot know (e.g. Yahoo's sign-in-seal, 3D-Secure's "personal assurance message"). There is a specific problem on mobile devices though, due to the inability for the user to distinguish between a browser instance and a malicious app: the app can create a pixel-perfect image of a browser window by writing to the full screen, connect to the legitimate site using its own HTTP(S) code, and become an undetectable man-in-the-middle. To get round that, the secret sign must not be held on and delivered by the server, it must be in a trusted app on the phone which takes over the screen, shows the secret sign to the user, handles the OAuth exchanges, and then returns the token to the untrusted app. I proposed this in my talk at OTA last year (slide 18).

   Reply
7. 2012-04-22 10:24

   

   Dermot Daly says:

   Furthermore, there's a couple of other problems with oauth: 1. If the web view is embedded, there are delegate callbacks available to the developer. This means it's trivial for the developer to intercept and examine the request; I.e. read the credentials; embedded web views essentially dont provide what they are attempting to do 2. Every oauth enabled app has a concept of their app key - this is why the provider can say "Application x wants your permission to log in" (and obviously, identify the application for security reasons). When your app is web based, you can secure you app key relatively easily (by encryption, local file permissions, etc.). If you're on mobile, it needs to be embedded in you app (I.e. every copy of your app). You can obfuscate it, but it is _very_ difficult to actually secure it. The first problem is one of user education (never gonna happen), whilst the latter requires operating system capabilities to do right. Incidentally, both iOS and android support URL handling mechanisms to launch apps, so natively jumping out to the browser for oauth does actually work. It is a terrible user experience though

   Reply
8. 2012-04-22 13:15

   

   Jan Ole Suhr says:

   You are really asking the wrong question 🙂 OAuth isn't primarily used for protecting the user, but for protecting the service provider (access to the API.) OAuth is actually making the situation worse by fooling users that their "password" is secure. Users might be tempted to use the same password for multiple services - because a password is "secure" - and that's basically a bad idea. If you really want to improve the security, just use a separate password for API / 3rd party access. Make sure that this API access password is different from the normal login password. An age old technique ... If you need to keep the manageability of the API, combine it with xAuth or OAuth. This will make passwords more secure and the login process for 3rd party apps more seamless (when using xAuth) - and even offer access for non-browser devices (home appliances, whatever.) The most important thing is to use as many passwords as possible and to encourage users and support them to do so. Using the same password for Twitter, Facebook, GMail and the Playstation Network and maybe even your banking site might have horrible consequences :-}

   Reply
9. 2012-04-25 19:40

   

   Blaine Cook says:

   The solution to this has been built into the spec since day one. The "correct" approach is to send the user to the website of the OAuth provider, using the default "http" handler on the device (i.e., the user's browser). The OAuth provider should then display a mobile-friendly sign-in / authorise page within the browser so that the user can authorise the application's request. Once they've clicked the authorise button, the OAuth provider should redirect back to the app using a custom protocol handler (e.g., x-templerun://authorize) that the app can register on the device. Once the app receives the redirect, it's able to obtain the token for future requests. It's a shame that Twitter et. al. haven't done a better job documenting this (or maybe they have?), because it really is supported in the design of the protocol. Native-app clients (desktop originally, not on the phone, since iPhone/Android apps didn't yet exist) were one of the motivating use-cases for OAuth.

   Reply
10. 2012-04-26 07:28

    

    Nick Sloan says:

    One area where Android clearly outdoes iOS is in this very regard: http://developer.android.com/reference/android/accounts/AccountManager.html Apps, such as Twitter, Dropbox, Endomondo, Microsoft Exchange and formerly Facebook, can register account types and authenticator modules with the operating system. The OS can then provide a standardized interface to the user when an app requests account access. The user provides their password once, and any app that needs access gets it from the OS, rather than the website. This is a simple and elegant solution that protects the user. Unfortunately, due to the popularity of iOS, most Android developers aren't aware of these options, or for some reason simply choose not to use them. If iOS could get on board with a similar approach, we could really make some progress in terms of mobile security. One flaw of this approach is that it requires the app for the service to be installed, but I think this is an acceptable sacrifice, the question is how to implement a graceful fallback.

    Reply