Re: [fluiddb-discuss] Designing a Fluidinfo backend for the Annotator project

[Kartik Subbarao]

[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
> fluidd...@googlegroups.com
>
> Thanks for the mail & for the pointers. Your links look good! :-)
>
> Terry
>