One of the most important aspects of any web application with user-specific features is authentication and authorization. Many new and old methods existed throughout the evolution of web technologies.

In this two-part article series, we will start with the fundamentals of user authentication and authorization from the perspective of a web developer. We will then implement a full-stack system with user authentication and authorization using React and Nodejs.

Before we start though, let’s first understand the difference between authentication and authorization as those two concepts involve different processes.

To put it simply, authentication is the process that answers the question ‘Who is the user?’ and authorization answers the question ‘What can the user do?’. Since it is impossible to know what the user may access without knowing who the user is, authentication naturally comes before authorization.

A more concrete example in the context of web applications is that a user may need to provide credentials to log in to a platform (authentication), and once logged in, depending on the user’s account type e.g. admin, support etc. the user may have access to different features (authorization).

Now that we got some terminologies out of the way, let’s look at two popular authentication and authorization methods used in modern-day web applications.

First up is session-based auth, the user’s login state is stored in some persistent storage. The user initially provides a username and password, then the server validates the credentials. If valid, it generates a session for that user, stores it in a session store, and then sends the session ID back to the browser. The browser stores the session ID as a cookie, which gets sent anytime a request is made to the server. The server would attempt to find the persisted user session information and authorize the user if the session was found.

Fig.1. Session based authentication and authorization

Session-based auth is fairly easy to implement and provides stateful user login information, which improves user experience. However, it is not suitable for services that employ REST APIs as a RESTful service is inherently stateless. In addition, the stored cookies in the browser expose users to Cross-Site Request Forgery (CSRF) attacks which you can find more information about here.

The more modern auth method uses tokens to authenticate users instead of cookies. The user provides a valid username and password and the server returns a signed token once the credentials are authenticated. The returned token is stored in the browser to be used for all subsequent requests made by the user.

The most commonly used token is a JSON Web Token (JWT), which is a three-part string delimited by . and consists of the following:

Fig.2. JSON Web Token Structure

Each part of the JWT token is base64 encoded and may be decoded by any user. When the token reaches the server with user requests, the signature portion of the token is validated with a private key that was used to sign the token. In addition, an expiry time may be set when generating a token which mitigates risks of malicious usage of the token.

Fig.3. Token based authentication and authorization

It should be emphasised that tokens do not have to be stored on the server side, they are validated using their signature. This naturally makes them suitable for auth with RESTful APIs and web applications that uses those APIs due to their stateless nature.

Furthermore, due to the lack of need to persist tokens, it works well with microservices architecture as we do not need to worry about sharing tokens between different services. Since token-based auth has definitely become more popular for modern-day web applications, we will be focusing on implementing this method in the next article!

When discussing auth in web applications, Cross-Origin Resource Sharing (CORS) is an important concept to understand. It is often the cause of many headaches during development but it’s an absolute necessity when it comes to securing the transfer of data between clients and servers.

In a nutshell, CORS is a HTTP-header based mechanism for a server to indicate which client origin may access its resources. For example, a request made from https://foo.example for resources hosted on https://bar.example will only receive a valid response if the server allowed requests from the origin (in this case https://foo.example ). This is implemented by the server by including the origin URL in its response header Access-Control-Allow-Origin.

Fig.4. Cross origin requests with CORS

There are many scenarios relevant to how and when CORS is implemented, you can find out more about those details here.

In this article, we discussed the meaning of authentication and authorization for web applications. Additionally, both session-based and token-based auth methods were described with a mention on the importance of CORS for secure web data transfers between browser and server. Now that we are armed with this knowledge, we will implement a complete authentication system. Tune in for the next article in this series!

Written by Mason Hu

About the author

Mason has a Masters degree in Electrical Engineering. He loves expanding his knowledge and is into fitness and cryptocurrencies.