For the case of a dedicated application on a rich mobile platform like
iPhone, I agree that OAuth does not offer a particularly different user
experience. It does, however, provide us at Twitter the information we need
to provide detailed usage analytics back to developers, as well as the data
we need to better understand our platform and help it grow.
OAuth also provides a mechanism for users to revoke access to applications
that aren't behaving as they expected; on the iPhone, removing a misbehaving
application is as simple as deleting it, but for some non-technical users it
may be helpful for them to visit their Twitter settings and see the list of
applications they've authorized.

We're working with our mobile team on improving the iPhone-optimized version
of the OAuth workflow. It may not be an enormous improvement over
password-based authentication, but once it's done, it certainly won't be a
hinderance. Twitter is one of many companies moving to OAuth, and you can
already find iPhone applications like TripIt that rely solely on OAuth for
authentication.

On Mon, Aug 10, 2009 at 14:16, Bradley S. O'Hearne
<brad.ohea...@gmail.com>wrote:

>
> All,
>
> I don't want to kick this subject to death, as there was a lengthy thread
> on general OAuth vs. Basic auth -- I want to restrict this question strictly
> to the scope of iPhone apps. Having pored over the OAuth vs. Basic
> authentication process, I have a question, given the following assumptions:
>
> - The iPhone app is communicating directly with Twitter, i.e. not through
> some third-party means.
>
> - The iPhone app requires authentication at the beginning of each
> application runtime (i.e. each time the app is run the user has to type in
> their password).
>
> - The password is cached only in memory, for the life of that specific
> runtime (i.e. when the user quits the app, the password is released).
>
> - The password is NEVER persisted anywhere, i.e. never stored to disk.
>
> - All network communication with Twitter takes place over HTTPS.
>
> If all of those things are true in an iPhone app, how is OAuth superior in
> any way to basic authentication from a security standpoint? Furthermore,
> given having to introduce a foreign UI element and extra authentication
> steps over the web, could OAuth even be considered inferior when evaluated
> as a whole as an authentication means for the iPhone, when app branding,
> integration, and ease of use are considered?
>
> Mind you, the purpose of this post is not in any way to incite a religious
> war or stir the pot, it is to definitively establish the true pros and cons
> of each authentication means within the specific use case of the iPhone
> only. Many of the other OAuth / Basic auth threads are somewhat overridden
> with personally charged statements that I'd rather ignore them.
>
> Anyway, your constructive views are most appreciated.
>
> Regards,
>
> Brad
>
>
>


-- 
Alex Payne - Platform Lead, Twitter, Inc.
http://twitter.com/al3x

Reply via email to