I was looking for a way of handling user authentication in Node. Passport.Js looked to be the forerunner via local login strategies. Social sign in caught my eye, I personally like the user experience and use of it often so I decided to explore it. Taking a look under the hood, social sign in relies on OAuth, this is a communication standard which allows a user to grant an application a particular level of access to private resource e.g. signing up to a website using the ‘sign in with facebook’ button, the website will likely obtain your name and email address once you grant permission. It’s machine to machine dialogue and OAuth is the gatekeeper.
I remember taking a look at this delegation standard when OAuth 1 was in its prime and not really understanding it; the control flow and my limited knowledge of http requests was a bad match. Since then I’ve worked with async/xhr requests so I’ve a better understanding of data sent over the wire. Whilst there’s many client libraries to abstract away the complexities of the OAuth flow, I decided to roll my own (it’s incomplete, lacks tests, doesn’t handle errors, but does handle the OAuth flow for Google, Fitbit, and Facebook), you can find it in my Core repo – this is where the big building blocks of modern web apps will live. I did this for a couple of reasons; I wanted to integrate with Fitbit (to get information on my heart rate) and saw that the Fitbit strategy supported by Passport.Js was for OAuth 1 and Fitbit drop support for OAuth 1 at the end of the year to support OAuth 2 exclusively. More than that however I wanted a concrete understanding of the OAuth 2 web server flow; from registering an app with a service provider (e.g. twitter, google, etc.), requesting an authorization code via the user, handling this authorization code via a callback and swapping it for an access and refresh token, and finally using the access token to call an API endpoint to get private user data. Google’s OAuth 2 playground was a great help to see each process step by step along with the HTTP request/response along with headers and parameters, as was the Postman REST client.
API providers implement OAuth 2 slightly differently among themselves, e.g. variations in errors in response, request headers, etc. This helps explain why Passport.Js relies on provider specific Strategies and the merit of using a library to handle inconsistencies in general.
Things I’ve learned through spending several days on the Core/OAuth 2 project:
- Registering apps with API providers
- OAuth 2 web server flow
- API calls using Request (Node) and Xhr (Client)
- MV* in Node
- Routing and injecting objects in rendered pages
- Embedded JavaScript (EJS) HTML
- Debugging Node apps (node-inspector)
- Querying and creating MongoDB docs via Mongoose
- Virtual methods on Mongoose schemas
Things I should spend time learning:
- Callback functions e.g. understanding how output objects are fed into a callback and they’re accessed. I used callbacks a lot in this project without completely understanding them
- Modular code which works with Node’s event loop i.e Middleware
- Front-end code organisation frameworks (e.g. Angular, React, etc.), everything was done server side in this project which requires page refresh
- Using the call stack to help with debugging
- Testing, understanding how the write them with e.g. Jasmine, Mocha, etc.