So I guess there are two ways OAuth can be used: 1) For the hub to auth with the subscriber 2) For the hub to auth with the publisher
And it sounds like you're talking about #1, right? Perhaps I'm ignorant of OAuth details, but most implementations I've seen require a UI approval step. Would that be the case here? On Mon, Oct 26, 2009 at 2:10 AM, Teemu Harju <[email protected]> wrote: > > Hello everyone, > > I've been following this PubSubHubbub thing for a while now and > thought that it could be a good time finally to start contributing to > this work since I find it very interesting. I've noticed that there > has been some activity in the area of OAuth on this list before, but > not too much activity on that lately. What I'm asking is that is > someone already working on it and could I help somehow? > > I've implemented a "hackish" OAuth support for the reference hub > implementation and here are some of my ideas for commenting. Feel free > to shoot them down. ;) > > 1) Hub acts as a consumer and holds a access token for every > subscription i.e., topic + callback. Problem here is naturally how to > get the required consumer information to the hub (consumer key+secret > and the needed URLs). Maybe OAuth Discovery (http://oauth.net/ > discovery/1.0 <http://oauth.net/%0Adiscovery/1.0>) could help here. Or > inserting the information manually > to the hub (this is what I did). > > 2) Subscriptions would be created the same way as is now described in > 0.2 spec. Maybe the verification process should be changed a bit so > that the subscription is not verified until the hub has a valid access > token for that subscription. When the hub for the first time processes > the feed and gets back a 401 Unauthorized response it uses the Www- > Authenticate header to see which authentication methods are supported. > Unfortunately e.g., Twitter or Brightktite didn't seem to advertise > OAuth support in the Www-Authenticate header (which kinda sucks big > time). Anyways, in a perfect world the OAuth method should be in > place. > > 3) Hub checks if it has the required consumer information for the > service in question and fetches the unauthorized request token from > the service. If it does not have the needed information it could use > the OAuth Discovery here. However, I guess there are not that many > services supporting it. Maybe there has not been a real need for it > before. I would say that now there is. > > 4) The request token should be authorized by the subscriber. The hub > generates the URL to which the subscriber should go to. We cannot > really redirect the subscriber to the URL so the hub should send the > URL to the callback URL of the subscription in question. Maybe a HTTP > GET with query string arguments like hub.mode="authorize", > hub.topic="http://topic.com/feed.xml";, hub.auth_method="oauth", > hub.auth_realm="some realm", hub.oauth_authorize_url="http:// > service.com?oauth_token=sometoken" etc... > > 5) The user authorizes the request token and the service provider > redirects the request to the oauth callback URL on the hub and the hub > exchanges the authorized request token to an access token. > > 6) Then the hub can fetch the private feed when it uses the access > token. > > In this case there would not be need to authenticate the user to the > hub anymore (which would make using the hub more difficult since user > accounts would have to be created to the hub) since the subscription > should not be made unless the hub has a valid access token. Maybe > HTTPS should be used for the content distribution. > > Thoughts on this? :) Anyways, this should follow relatively well the > design principles of PubSubHubbub. That is, keep the complexity in the > hub. The subscription would work pretty much the same way as it is > now. Also, it should be relatively well bootstrappable. Altghough, > there are definitely issues in getting the consumer info to the hub. > > Br, > > Teemu > -- Jeff Lindsay http://webhooks.org -- Make the web more programmable http://shdh.org -- A party for hackers and thinkers http://tigdb.com -- Discover indie games http://progrium.com -- More interesting things
