[Mailman-Developers] Architecture for extra profile info
Stephen J. Turnbull
stephen at xemacs.org
Sun Apr 28 09:15:19 CEST 2013
Xu Wang writes:
> The problem is how do you "confirm ownership of the subscribed address"
> when a request coming with an access token.
You don't. That was done when the OAuth ID was linked to the address,
using the usual 3-step handshake (submit the association, receive an
email containing a secret, confirm ownership by replying with the secret).
> In another words, unless your are the provider, how do you validate
> the access token issued by a provider at the resource endpoint?
I'm not sure what you mean. In the security context (as others),
"validate" means mostly "check the syntax". But a valid token is
assumed to be authentic (otherwise the provided has been suborned).
Remember, a provider does not *authorize* anything. A provider offers
a channel of communication to the resource owner, who does the
authorization. Ie, provider tells owner "client tells me consumer
wants to access the X Files", and on success returns a token to the
client indicating "I've confirmed that you are indeed talking to the
owner, and by the way, *she* says it's OK to let consumer look at
them."
> > 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.
I'd have to look again to be 100% sure, but I'm pretty sure that what
the provider returns is well-defined. What the client gives to the
application is application-defined.
> 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.
Again IIRC, the provider doesn't know what the token is. The *client*
does. The provider just passes a message saying "Access to the X
Files, which you own, have been requested. Is that OK?"
In practice, the common case is that consumer == owner, so effectively
the message boils down to, "Click OK if you are you".
> 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.
OAuth providers don't know about the protected data. OAuth consumers
do. The provider-client combination only offers a communication
channel. That's what is so elegant about the OAuth concept.
Steve
More information about the Mailman-Developers
mailing list