Setting up authentication can be quite daunting for beginners and expert developers who set up backend APIs. There is no standardized method and each backend stack have different methods of approaching authentication. Below I will explain a simple and easy way for the flow of logic required to set up authentication which can be applied for several backend technologies. In this guide I will be using Json Web Tokens that are stored in cookies that can be sent to the front end as well as parsed on the backend.

STEP I: Login Route

The first thing that is required is to set up a login route which can be accessible to non-authenticated users. Two things will be generated, an access token and a refresh token.

Login Route Schematic
  • Access Token
    • Depends on the user id from the database as well as a secret, which will make it both unique for each user as well as secure by using the secret.
    • Expire in a short period of time (10-30 min)
  • Refresh token
    • Depends on the user id, another secret, and the user’s password which makes it unique as well as immediately invalidated if a user password changes.
    • Expire in a long period of time (7 days +)

A cookie will be generated and appended to the response with two cookies which each of these two tokens. The access token can be either a regular cookie or a http-only cookie while the refresh token must be http-only.

The reason for this is that it makes sure no Javascript can ever access the cookie from the browser which protects the user from XSS (cross site scripting)

STEP II : Server Middleware

Middleware Diagram

We need to set up middleware that will intercept the HTTP request before the endpoint logic is executed. This is called middleware and sits between the browser and the logic from the server.

Middleware Route Flow Chart

next() represents ending the middleware and continuing on to the endpoint logic to be executed. This can happen in two cases, when the access token is valid, which means it hasn’t been long since the last refresh. The second case will be explained below.

In the case that the access token is not valid or expired, the refresh token is checked. If the refresh token is still not beyond its expiration date and it is valid, another access token is generated and sent in a new cookie and the middleware next() function is continued. If both these scenarios don’t happen (i.e both tokens are invalid) then the request for the authenticated route does not pass through and the front end is notified and takes action accordingly (like redirect to login screen).

STEP III : Handle Edge Cases

The last thing in setting up authentication gotchas that can occur such as

  1. Modern browsers don’t send a cookie if it has expired, so we can skip a lot of the logic if no token is available, being equivalent to an expired or invalid token
  2. It is a good idea to set up decoding a token and retrieving the user Id to test to see if it is available in the database to make sure this is a valid user and not a tampered token.
  3. Both secrets must NOT be stored in plain text, they must be placed in environment variables for security reasons.

And there it is, three steps which can easily be used to set up a secure, deterministic, and fast method of authenticating users that can be used for any form of API like REST or graphQL etc.