Is OAuth really a good replacement for Basic Authentication?

Recently I have spend some time to check out Twitter and figure out whether or not it is feasible work on some kind of integration within the Coalevo Project (see my recent development entry Twittering ...from the Terminal!). Digging into the API one of the first things that struck me was the exclusive (i.e. no other supported) use of Basic HTTP Authentication. Digging a bit deeper, I realized that Twitter is planning to switch to OAuth as a replacement for this Basic Authentication mechanism:

[...]
Once the rest of the bugs are ironed out, OAuth will become the supported authentication system for Twitter, and HTTP Basic Auth will be deprecated after six months.
[...]

My understanding of OAuth so far was very much tied to a 3-tier use case: A user that is using a service (Service 1) that wants to enable a third-party service (Service 2) to access certain resources at the first service. The classical example being the printing service being authorized to access photos at the user’s photo sharing site (see Hueniverse.com Beginners Guide to OAuth, Part II).

Also I stick to my opinion that OAuth is about authorization, not authentication (read Appendix B. Security Considerations of the OAuth Specification, and see my entry OAuth is NOT about authentication).

I am really confused about the fact that Twitter chose OAuth (for their API):
1) for authentication; and
2) to replace HTTP Basic Authentication; and
3) to make it exclusive in the near future.

Especially when reading what Alex Payne has to say about himself:
[...]
I’ve done information security work for a military and intelligence contractor
[...]
[...]
my professional expertise has been in web application development and computer security
[...]

Obviously I am not the only one with doubts: Should Twitter discontinue their Basic Auth API?

Logically they are looking for a replacement, because Basic Authentication isn’t secure over non-SSL connections (which many client libraries won’t use, or even allow to configure), and SSL is a big overhead if it is just used to conceal the Basic Authentication information; however, maybe they should turn elsewhere for better ideas......

Identity, authentication and the web

Over the last months I have been investigating a little bit about identity and authentication mechanisms for the web.

First of all, and given the fact that authentication is confused with/not separated from authorization (even the folks at Google seem to be confused about it, see a recent blog entry of mine about: OAuth is not about Authentication), let's clearly define what we are talking about
(taken from the Wikipedia entry on authentication):

Authentication (from Greek αυθεντικός; real or genuine, from authentes; author) is the act of establishing or confirming something (or someone) as authentic, that is, that claims made by or about the thing are true. Authenticating an object may mean confirming its provenance, whereas authenticating a person often consists of verifying their identity. Authentication depends upon one or more authentication factors.

Apart from technical concerns, there is this one important aspect to authentication that deserves special attention: Identity, which represents the something (or someone) that should be confirmed as authentic through an authentication mechanism.

Probably the buzzword web identity rings a bell, or maybe you have read about OpenID or all the fuzz on Open Social. Or you may have stumbled over a blog named Identity 2.0.

I don't know how you perceive it, but for me, the top priority question these days is Who should provide my identity? and not How should the mechanism work?, because that comes second, and that it has to be sufficiently secure is out of question.

I really ask you to ponder it; there are many implications related to all possible answers of this question. Just think that governments are as well moving towards the E. Given the scale of the E movements nowadays, this is not likely an easy problem to solve and will take some more careful considerations if the identity is to be used beyond simple social networking activities: maybe for a blog comment it does not matter, but once you are voting or paying bills with it, you will for sure be more alert about your identity.

The truth is that most of the users of the web suffer from a multiple identity syndrome, and in many cases this may involve quite some cost and inconvenience for the user. I don't know about you, but I have a growing number of "identities" that involve me to carry tokens in different form factors (and certainly pay for those that are supposed to Internet banking secure for me).

So: How many of these tokens are you willing to pay and carry arround with you?

Taking identity into account, I think that OpenID is based on the right idea:

An end user can freely choose which [OpenID] Provider to use, and can preserve their Identifier if they switch [OpenID] Providers.

However, when it comes to security, OpenID has it's weak points; just read about How secure is OpenID? and The Problems with OpenID.

It think that it's time to dvelve into the web authentication problem, and will hopefully find some time to distill my ideas and brainstorming of the last months into further posts on HTTP Authentication mechanisms, SSL/PKI and the Trusted Third Party issue, and probably an idea for a new mechanism for security that won't depend on SSL.

Kitten Yoga (don't try this at home ;)