Passportjs support for Authentication

[Rajan]

Passportjs is now standard as it allows authentication from hundreds of mobile devices. It seems like a separate auth thread isn't considering it as a possibility.

We should explore Loopback auth module and iOS/Android SDKs which support it as well. https://github.com/strongloop/loopback-component-passport

[deontologician]

This looks really interesting, I wasn't aware of the project

On Mon, Jan 11, 2016, 08:10 rajan notifications@github.com wrote:

Passportjs is now standard as it allows authentication from hundreds of mobile devices. It seems like a separate auth thread isn't considering it as a possibility.

We should explore Loopback auth module and iOS/Android SDKs which support it as well. https://github.com/strongloop/loopback-component-passport

— Reply to this email directly or view it on GitHub https://github.com/rethinkdb/fusion/issues/64.

[rosskukulinski]

I absolutely agree with supporting and/or using passport for authentication. It's the defacto auth system in NodeJS if you're using Connect based routing systems (e.g. express & restify). The HAPI framework has its own auth provider, as does Koa (I think?). I don't know of an out-of-the-box websockets (or socket.io) authentication middleware that integrates with passport - but surely there must be one.

However, I strongly disagree about using anything from the Loopback ecosystem (i.e. made by Strongloop/IBM). This also relates to the discussion here. StrongLoop (now acquired by IBM) have shown the nodejs community, multiple times, that they don't play nice with open source projects. The latest example of that is going on in this thread.

[chrisabrams]

I would strongly recommend just using the passport project directly. Using anything from loopback will cause this project to explode like a volcano :O

Passport has become the Node.js paradigm for auth, and it has a lot of pieces that could be quickly integrated into Horizon.

[Rajan]

We've to build something that's significantly better than Meteor/Loopback/Firebase/Parse to gain attention. Loopback is the first commercially supported NodeJS framework.

Firebase/Parse are extremely easy to use and integrate. Ease of use and minimum lines of code (for common tasks like Auth/Notifications/Messaging) is really important if we're hoping for a significant adoption. I'm not asking to directly use Loopback code but there can be a few learnings that will be useful.

[chrisabrams]

@Rajan Agree that much can be learned from other projects.

[danielmewes]

I should have looked at this earlier, since we have implemented some OAuth strategies ourselves by now (https://github.com/rethinkdb/horizon/tree/next/server/src/auth).

Pinging @Tryneus . Do you think passport.js or some parts of it could still be useful for us?

[Tryneus]

I would really like if we could reuse passport authentication for Horizon, but it can't be the only thing we support. I'm strongly against tying users of the Horizon server into a single middleware stack. After spending a while trying to find a way to reuse passport.js without having Connect, I just implemented the most popular auth providers myself (it didn't take that long).

I think it would be beneficial to allow a user of Express, for example, to hook up passport.js to act as the Horizon auth layer, but I haven't given much thought on how this would fit together. This way, we could provide the most common use cases without any restrictions, but if a user is willing to use a Connect-based stack, they can still get everything passport.js has to offer.

[Rajan]

As long as it's easy and pain-free to replace passport.js based app, people may switch. Some of my dev. friends prefer passport because mobile authentication is done securely and they don't have to use paid auth services.

[ericwooley]

I am brand new to horizon, but this is immediately a pain point for me. I am trying to integrate with battle.net which provides https://www.npmjs.com/package/passport-bnet

There doesn't seem to be any (documented) way to either: A) Use passport in my own server code and somehow integrate that into hz, B) Create an oauth strategy that hz understands.

I am not really an expert on Oauth either, but it seems like it may be possible to consume the passport strategies? That way the user would be tying themselves to passport, and hz could consume strategies that weren't explicitly dependent on passport.

Can anyone recommend what best path would be temporarily to hook up passport auth into hz?

[mardo]

+1