> Is OAuth sensible to use when the user account info (user id's,
> passwords, roles, etc) is going to be maintained in our own back-end
> and when there will not be any sharing of resources with other sites?
> Or is sharing the whole point of using OAuth?
The point of OAuth is not exactly "sharing," though that can be a subset of it.
The primary point of OAuth is extending limited subsets of your rights with a first entity to some other entity. The "rights" might be the right to see data, or to change data, or to execute code, or pretty much anything else you might think of. The "other entity" might be another site that wants these rights in order to serve as a proxy for the user (the parade example), or some subsystem on your same site, such as a periodic maintenance task. The key notion is to identify some subset of rights and capabilities, and some entity or context in which these (and no other) rights/capabilities should be granted, repeatedly, without human involvement (such as repeatedly typing a password).
So, in the parade example:
1. You might have a Twitter account, which includes rights like "send tweets," "read tweets," "edit the profile," and "subscribe to other tweeples." Twitter is the first entity.
2. You might find a site that does something useful, like OpenTable making dinner reservations for you.
3. The second site (OpenTable) might ask for your permission to tweet from your account every time you use the service.
4. Assuming you agree, you, OpenTable, and Twitter perform the OAuth dance, and in the end Twitter is willing to accept tweets from OpenTable as if they came from you, conceivably even if you don't happen to be at any keyboard at all at the moment OpenTable sends the tweet (though I don't think OpenTable actually exercises that particular right).
A secondary use of OAuth is for "Single Sign On": the first entity knows how to confirm the person at the keyboard really is you. The second entity wants such assurance as well. The "right" in this case might only be "the right to be recognized as yourself," or basically no rights at all (so far as the first entity is concerned). The three of you execute the OAuth protocol, and if the first entity grants the protocol, then it has demonstrated that it's satisfied as to your identity; the second entity merely trusts the successful OAuth transaction as proof of identity.
Commonly, you find the two uses combined: when you first register with the second entity (OpenTable, to continue the above example), it offers you the option of using your Twitter account for login at OpenTable. Upon completion of the "allow OpenTable to tweet" protocol, OpenTable also has the SSO assurance. OpenTable sets up various structures of its own, such as profile info, dining history, and so on -- stuff Twitter knows nothing of -- and secures it behind the Twitter-certified identity "you."
If you only have one access point (say, one log-in page), then I don't think OAuth buys you anything. But if you deploy multiple web apps off the same database, each with its own login page, and if there's any chance that some users might use several in the same day, then OAuthing among the apps might still get you the SSO benefit.
Jack Repenning
I'm very keen to hear this too, although perhaps rather than focusing on "when", it might make sense to also ask "what's still in a state of flux in OAuth2"? It doesn't help clarify the timeframes necessarily, but it at least gives draft implementers a chance to ponder which parts are most likely to change between now and ratification.
Cheers,
(another) Peter