The not-so-cynic in me believes that, as a service operator, having thousands of machines out there with a server-generated token being the thing stored on them rather than a username/password pair that's create by the human. It's so much less of a risk. Clients that store passwords locally mean that user generated password content leaks, and that's much more likely to be the same password they use elsewhere.
I'm not defending the use of OAUTH as the mechanism, it's quite clunky - but to say there's no benefits to bearer tokens instead of basic auth or 'user:pass' pairs - that misses a bunch of very legitimate operational concerns.
Yes, that's what got my attention about OAUTH in the first place.
I had written an app which wanted to be able to post to people's
Facebook or Twitter feeds and I really hated having to store their
passwords in the clear. I'm pretty sure I just implemented it with
a webview which is the most obvious way to do it which is what got
me to thinking "wait a minute, I totally own everything this thing
does". When it was just for things like FB and Twitter
authorization to do things on their behalf, that was one thing but
it's now being used for single sign on all over the place. I don't
know if SSO was an original design goal as they always used the
valet key analogy for its purpose but I doubt that is the most
common use case these days. While a compromised Twitter password
may not be a big deal (I mean, Twitter itself is compromised these
days), things like your gmail password may be of great value for,
say, password recovery.
So the long and short of it is that the problem has only gotten much worse from when I originally brought it up.
Mike
