[annotator-dev] [fluiddb-discuss] Designing a Fluidinfo backend for the Annotator project

Fri Sep 14 13:14:38 UTC 2012

[I'm crossposting this to both fluiddb-users and annotator-dev since 
there has been interest independently expressed by both teams in working 
together, and I think it would be good to make both communities aware of 
this. If there is a preference to continue the discussion in just one 
place, we can do that instead.]

Hi Terry,

Thanks very much for your response. I would definitely like to take you 
up on your offer on the Oauth2-API-twitter-token method. As long as 
there is some secure way for the application to act as the user on 
fluidinfo without having to know the user's fluidinfo password, that's 
all I need for now. It'll definitely help move the prototype forward.

Regarding the additional refinement to the authentication strategy, I'll 
defer to Randall Leeds for comment on that. He is redesigning the 
annotator-store authentication interface and would be the best person to 
comment on requirements/preferences. Randall, can you take a look at 
this when you get a chance and respond with your thoughts?

I'm eager to improve the annotator-fluidinfo prototype and facilitate 
collaboration between the annotator and fluidinfo projects, so everyone 
feel free to chime in with your comments.

Regards,

     -Kartik

On 08/31/2012 05:12 PM, Terry Jones wrote:
> Hi Kartik
>
> Sorry for the slow reply, Google Groups is being particularly
> unfriendly (and
> seems to have silently eaten the last 2 attempts I made to post this).
>
> This is a preliminary reply just to let you know we've seen your mail and
> are thinking about it. I wasn't aware of the JWT work, and would like to
> spend some time reading up on it & looking at the links you posted.
>
> > Annotator uses an oauth-like mechanism for authentication on its
> backends:
> > https://github.com/okfn/annotator/wiki/Authentication
> >
> > The challenge here is that fluidinfo at the moment doesn't appear to
> > support a delegated authentication mechanism (just username/password).
> > Are there any oauth-like authentication mechanisms in the works for
> > fluidinfo?
>
> We currently have an undocumented way to allow for OAuth2 API calls. It
> works following Twitter's OAuthEcho login [1], which is basically just
> plain OAuth followed by a proxied (by Fluidinfo) call to Twitter's user
> verify endpoint.  The payload comes back from Fluidinfo with the normal
> details from Twitter's verify endpoint plus a token that an
> application can
> use to make Fluidinfo calls on behalf of the user.  If that's of interest,
> we could pretty easily let you use it too. We've not announced it because
> we wanted to make sure it worked robustly etc., before giving it any kind
> of official support.
>
> What we don't have (yet) is the provision of an OAuth-like service wherein
> you can register an app as a consumer to get a consumer secret & key,
> register your callback endpoint, and use a Fluidinfo endpoint to redirect
> your users to to log in, etc.  That's quite a lot of work to set up
> properly, and we've never had a call to do it (*many* developers really
> hate OAuth).
>
> I.e., we're not set up as an OAuth service provider, but we can field
> OAuth2 API calls if you get a token via the Twitter oauthecho call.
>
> I'm interested in exploring whether we can set something up to help you
> here. A further intermediate step we could take is just to manually
> provide
> a consumer key/secret to those who want it, and then just the
> login/redirect endpoint that could result in your app getting a token.
> That
> would be much less work than the full-blown OAuth service provider work,
> but would be a step on the way to a more fully-fledged OAuth-like
> offering.
>
> We should probably discuss implementation in
> fluiddb-users at googlegroups.com
>
> Thanks for the mail & for the pointers. Your links look good! :-)
>
> Terry
>