Node Json Web Token Authentification – a mild walkthrough

So I have no school right now, and some time to explore some interests of mine. Having done some cool node development at work with the use of backbone and cordova to emulate the client on on mobile, I got interested in learning node development. I don’t have a lot of experience with back end development but I have played around with the flask web framework in python and have had other experience with php an C# and am not a complete stranger. I was interested in making a restful web service that facilitates logging in and logging out. Since this architecture is a little different than other login schemes, I figure I would write a little on the subject. By the way I feel I learned a lot, but am still learning, so please let me know of any mistakes I make.

First off, why Node? well, in short, a pure-ish javascript stack, but to be honest I am not completely convinced on it so I will save the topic of “why node?” for another blog post. Moving on, why REST? REST stands for Representational State Transfer, which has some scientific research behind it (I believe there is a popular educational paper that came out of Stanford on it, still to read. In short, it isolates resources, and in a web framework, that means the client and the server. Instead of server the user pages of html based on requests, the user gets a client app that knows how to interact with the servers api to display proper data in a quicker way. Quicker by the user will get a quicker experience because more computation occurs on their machine than the server. But more importantly than the performance shift, REST services allow for all sorts of clients to use it. That means mobile apps and web apps can share the same api. This is nice in building web services because with todays ever expanding internet of things, it is important to have a robust system that allows all kinds of clients to participate.

Hopefully that makes it clear why you want to make a rest server. Now lets talk about handling authentication. Previously developers relied on browsers cookies and sessions to create secure routes for users. In REST the concept is kinda the same in that something the client has authenticates the client, but lots differ as well. To make the REST api universal and not just for browsers, you want to make sure the credentials are sent in the requests header. This may be achieved in other ways but the header seems to be a good universal place. The way the REST auth differs from old auth that the browsers facilitated is that in rest the client must know what to do with each request and response in order to navigate the REST api correctly. So as long as you document your api for others to follow or make client apps that know how to interact with the api your web app will work fine.

Now looking into the general login protocol for rest services. Granted many differ and change, but this is my json web token based approach. Lets review the login route and what both the client and server does when a user tries to login:
– Login
     – Client sends username and password in request header to /login route
     – Server receives request, parses header and grabs username and password, encrypts info and checks for it in the db.
        – Success = make a json web token with user info, an expiration date, and the hashed secret and send it back to the user
        – Failure = send 401 back to client

So it basically makes something called a json web token, and sends it back to the user. This JWT has the user info, and expiration time, and a hashed version of your servers secret, which is the key to authentic JWT’s.

While learning this, I made a boilerplate for the login stuff, take a look to see this implemented HERE!

This is a work in progress..

Questions for next:
– how to keep user persistently logged in?
– is it okay to not be able to logout?
– Anatomy of JWT