If you know exactly what’s going on and just want to grab some code and get going, here’s the gist. Otherwise, read on.
Why would I need this
In case you have a Meteor based project you have been working on for a while, chances are you came across a need to pull it apart at some point to setup a separate API server, for example, that you want to run somewhere else (e.g. a minimal express server or smth along these lines).
As part of the API refactoring, you will need to take care of the authentication layer - you want API requests authenticated against your Meteor.users collection. Below is an example of such setup using Express and Passport.js. We will be using Mongoose for data access.
What is Passport.js
From their website
Passport is authentication middleware for Node.js. Extremely flexible and modular, Passport can be unobtrusively dropped in to any Express-based web application. A comprehensive set of strategies support authentication using a username and password, Facebook, Twitter, and more.
To support authentication with our Meteor based system, we will be using Passport.js username+password strategy. Strategy (in the case of Passport.js) is a fancy word for “implementation” (which in turn is a fancy word for “getting things to work”).
Username + Password Strategy for Meteor Accounts
The first thing we need to do is map username + password to the Meteor user. Here’s what this looks like on top of Passport’s LocalStrategy:
If authentication succeeds, we return a JSON serialized Meteor.users collection record that gets attached to each request. The next step is to tell Passport how to serialize and deserialize (which basically means “look up” in this case) the user object to use in sessions (in case you need sessions). Here’s a very basic way to do this:
Connecting the dots
Now that we told Passport how to verify authentication and serialize/deserialize user, we can connect it to the express server we are running. I am going to show you 2 scenarios below: basic auth that you can use for your API endpoints and a generic session based setup with a login form.
We are gonna add an
/api endpoint requiring requests to contain authorization header with base64 encoded
username:password pair. See this for more details. Here’s what this looks like with Passport:
Let’s say we want to protect the landing page of the API server and have humans (e.g. admins) log in using their credentials. Here is a basic setup with Passport, again using our strategies from 2 minutes ago:
For a complete (although basic) boilerplate for this solution, take a look at this gist here.