Re: [Mailman-Developers] Architecture for extra profile info
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
On Sat, Apr 27, 2013 at 4:59 AM, Stephen J. Turnbull <stephen@xemacs.org>wrote:
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.
Loud and clear.
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.
Agreed.
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.
The problem is how do you "confirm ownership of the subscribed address" when a request coming with an access token. In another words, unless your are the provider, how do you validate the access token issued by a provider at the resource endpoint?
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.
I may misunderstood you, but OAuth doesn't specify the format or content of the access token. It is left to the implementation of a provider. This is true for both OAuth 1.a and OAuth 2.
To control the access of a resource, a provider have to authenticate both client and the resource owner, issue an access token if authenticated resource owner authorized the resource access for a specific client (authenticated by a client id and a secret). When the access token coming with a request at the API, only the provider or an agent of the provider knows what it is.
What I'm saying is that if OAuth is supported, mailman will be a part of provider because it holds and protects the user's data.
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.
Stev
participants (2)
-
Stephen J. Turnbull -
Xu Wang