On Auth

Authentication is how the app identifies a user, while authorization tells the app what the user can and cannot do. Both are essential to web applications to store data produced by a third-party. Authentication and authorization (auth for short) aren’t simple things, but they are easy to implement—and partly automate the coding involved—once you get the hang of how they work.

Auth can be divided into 5 main components:

• A web server to handle all the logic.
• A database to store encrypted credentials.
• A session cookie stored in a web browser to tell the web server we are still using the app.
• Short-lived JSON Web Tokens (JWT) to perform API calls from within the user interface.
• A private API key that can be exchanged against web tokens to make API calls between different domain names.

When a user needs to be authenticated to perform an action, you usually send him to a login form. The web server compares the identity and the password entered in the form to the ones stored in the database. If there is a match, the server creates a session cookie on the visitor’s computer, to tell it “Keep me logged in, I’m currently using the website!”

When the user is done doing his business, he can click on a Logout link that will eat the cookie and burn the bridge that used to stand between him and the machine.

Of course, none of this would work if the user didn’t previously subscribe by choosing at least an email address and a password to identify herself. The password is encrypted by the web server to prevent bad people from doing bad things on a user’s behalf.

The great thing about session cookies is that they can only be read by the web browser that requested one and the server that created them. But it’s also an issue when you need to communicate with other web servers through an API.

In this situation, we use a private API key to identify an unknown request. The API key is unique and can be translated into a JSON Web Token to perform tasks offered by a web service.

We also use session cookies as a currency to be exchanged against JWTs to uniformize the application programming interface, thus making it simpler to use for everyone involved. That’s how you can make secure API calls from within a user interface belonging to the same domain name.

Authorization data is stored in the database along with the corresponding user. The software simply has to retrieve the user information from the cookie session or the JWT and check that the request has the right permission levels to perform an action.

That’s basically how I do it in the new Cowriters website. I don’t use any fancy framework like passport.js, because I find it much harder to configure and way too heavy to load for my simple use case. Instead, I use a combination of smaller libraries, taking inspiration from a few tutorials: this one about JWTs, and this other one with Session Cookies. I adapted both to work with my ExpressJS + MySQL setup, and that was it! It took about 8 hours to learn and implement everything, and I can now move it to its own encapsulated web service in my webserver to improve it over time or reuse it across multiple applications.