OAuth is a perfect solution for authentication with other web apps. The problem is, it just sucks for native apps.

You know the typical workflow for apps. Open, enter credentials, it works. Now here’s what OAuth looks:

Yes, it quit’s the app, opens Safari, and then restarts the App. Yes, this sucks. But see for yourself

Even worse, some other apps like Echofon like to play the travesty role and ask your two times.

There was a big outcry by some people, especially UX affine ones, when Twitter announced shutting down their http auth, leaving only OAuth. Twitter listened and presented xAuth. It basically hides everything from OAuth, let the user enter his credentials the old way while transparently fetching the token. hen some other people say this is a terrible, horrible, not good, very bad idea…

So what else is there?

Facebook’s new Graph API is probably the most known OAuth 2 API. They provide a full package for the iPhone that manages all authorization  in the browser, yet in a very user transparent way. Sure, this is a security risk. With some easy hacking and/or javascript injection you can steal the login data. But it’s certainly saver than letting the application store the credentials.

Problems

• Creating multiple accounts is a PITA, requiring multiple roundtrips and logging in/logging out of the service. (This is less of a problem if you make the login convenient via a optimized landing page; and you don’t have an automatic login)
• The Consumer Secret is reverse engineer-able. This nullifies the argument that oAuth is better for identifying clients when it comes to desktop/mobile apps.
• If a native app wants to get a copy of your password, it will get a copy of your password. It can create embedded browsers, hijack the authentication, add a proxy or else.

Loren Brichter proposes a solution that integrates deeply with the OS, therefore maximizing security while keeping the “native” experience.

Advantages

• From a service provider’s point of view, it’s absolutely reasonable why the want OAuth. Control. Which is a good thing.

OAuth doesn’t prevent evil folks from shipping Twitter apps that might be trojans, but it does allow us here at the Mother Ship to revoke their ability to talk to the Twitter API. That means less spam/”SEO” tools, and a short time-to-live for applications that are discovered to be malicious. [Alex Payne - API Lead, Twitter, Inc.]

• For the user this is also a good thing. You can loose your iPhone and just disable the specific token. Your password is not leaked. The App furthermore could be configured to clear all caches when it detects that the API Key has been revoked.
• It’s better than Basic access authentication, where your username and password is sent in every single request. But you have to go over SSL anyway. If your token leaks, other’s have access to your account.

My proposal

I’ll propose something similar. A optimized, secured landing page that is styled native-ish per device and runs within the native browser, but without showing the user so. So we can provide a good-known-flow

1. Open App
2. Press Login / Register
3. Wait for login page to load (this is where users may experience a little difference…)
4. enter credentials
5. wait for authorization
6. it just works!

Of course, the web service has to provide some sort of management page where current applications are listed and rights can be revoked. If a application goes wild and messes around with usernames, their token can be blocked. (which only makes sense if there’s a reasonable review in application registering)

There’s some comparison of the different techniques on the oauth wiki native apps page; but no clear winner.