Xu Wang writes:
For OAuth <http://en.wikipedia.org/wiki/OAuth>, you need to implement token based auth in API, as well as a provider service because there is no open OAuth provider service for third party API out there :-(
No, we don't *need* to implement *anything*. We implement what we want to. That's the nature of a volunteer project.
I'm recommending against becoming a provider because I think it's too hard to provide the enterprise-strength implementation you focus on. The client side is much easier.
The provider service has to implement application registration, user auth, token validation and distribution (for oauth 1a, access token need to be pushed to or shared with API).
Yes, if I understand you correctly.
In my view, OAuth really belongs to an enterprise system, rather than a specific api or one application. It requires a existing robust web-based auth system on the provider's site.
It very much depends on how accurate the identification of the client needs to be. For an open subscription service where the only thing you really need to do is confirm ownership of the subscribed address, any provider the user trusts is good enough.
This will also make the API less "independent" because it is depending on the provider service and provider's auth system.
Why? The whole point of the OAuth protocol is that the authentication is delegated to an OAuth client, which contacts the provider, and if successful returns a token to the customer. The customer then interprets that token as it likes. The tokens have a specific, well-known form, so the authentication subsystem is completely independent of the application API.
There does need to be coupling to the UI, to provide a channel to the OAuth provider.
Only if there is a strong 3-legged auth use case, should one push to this controversy route.
I don't see 3-legged auth as the killer app for OAuth here. Rather, I see convenience for subscribers as the main feature, although it might also be useful for moderators and other admins.
Steve