There are many ways to handle authentication for web apps. Many frameworks (like Ember.js) come with a neat CLI and therefore only require a few commands to set up a new method for handling it. And that’s exactly how I stumbled upon JSON Web Tokens:
In my current project, I’m using ember-simple-auth for managing authentications and everything related to them.
After setting it up, the default authentication you get is OAuth2. However, I didn’t just wanted to keep what I was given. I wanted to find out what the best method for my particular case is. So I’ve crawled the web for nearly an hour and found out that there really is a better way for me to handle those things: So-called “JWTs”.
And because it was also a lot of fun to implement them, I’d like to share with you why it might be the best solution for your app, too.
#How It Works
In contrast to OAuth2 sessions, JWT sessions are self-contained. That means all the information about current session is already part of the token itself. So instead of saving details about each running session to the DB (like OAuth does it), all the data that is required to verify such a session is already being stored on the client.
More specifically, here are all the steps of such a process:
- After the user enters his name and password, the data will be sent to the API (preferably through HTTPS).
- On there, both fields should be compared to the user’s DB entry. If the user exists and the password matches, step 3 will take effect. If not, the client will receive an error informing the user about entering different credentials.
- Username and password will be passed to a middleware of your choice (I’m using koa-jwt, since I’m using Koa for the web server). In there, the data will be encrypted with the previously mentioned private session key and converted into a single String: The so-called “token”.
- That token will now be added to the response. From now on, it’s saved on the client (either as a cookie, or in the LocalStorage).
Each time the client tries to load data from the API, it will add that token to the request’s headers. This makes it easy for the server to verify if it’s still a valid session token by decrypting the token using the private session key and comparing the obtained data to the user’s DB entry:
However, I think most middlewares don’t actually compare the token’s contents again. They simply decrypt it and if that’s not possible, it was abviously not generated using the session secret and therefore not issued by the server. In this case, the client will receive an error, the session token will get destroyed and the user will get logged out.
#Letting Sessions Expire
Since there’s no session data saved on the API-part of the app, there’s also no way to destroy it from there.
Because of this, most middlewares that support JSON Web Tokens will simply append a property called “exp” to the response when passing the token to the client (see step 4).
And this property will then be used by the client-side framework to determine when the session will expire. A few minutes/seconds (you can specifiy this, of course) before the it does, it will then send a request to the API asking for a refresh of the token.
This request also contains the old token and therefore also the user’s data and password. The server will use this data to verify the session by comparing it to the user’s entry in the database. And if the data is valid, step 3 will take effect again.
When the refresh token reaches the client, it also comes with an updated “exp” property and the whole process will start again.
“So what’s the best way to implement this into my Ember app”, you might ask now. Well, I have the perfect plugin for you then.
It extends your ember-simple-auth instance and handles all of the necessary communication between the API and the client.
So there’s only one thing left for me to say: Thank you for reading this and go, help shape the future of secure web authentication by implementing it into your own application!