Hey everyone ,

In this article, let us learn about more about REST APIs. This is the second article on the topic REST API. The first article on this topic can be read by clicking on the below link :

What is a REST API ?

The Nerdy Dev Oct 8 '21 8 min read

#100daysofcode #javascript #node #webdev

This article was first published on https://the-nerdy-dev.com/.
Check the website for more interesting articles and tutorials on Web Development.

How authentication works in REST API ?

So we again have our client and server. The client in order to authenticate needs to first send the authentication data (credentials), so basically the email and the password. This password is then compared with the password that is kept in the database before granting the access to the user. Now if you are working with an Express based server, then you must have used a package called bcryptjs that helps with all of this stuff. In traditional applications, we used to check data on the server and if the data was valid and if it was valid, only then a session used to get established.

Why no sessions any more ?

Well, there is a reason for this. We do not use session any more because REST APIs are stateless. The client and the server do not share the same connection history which means that both are totally decoupled from each other. Here we don't care about the clients. Every request is treated as standalone which means that every request should have all the data it needs to authenticate itself. With session, the server has to store the information about the client that it is authenticated and this is not how REST APIs work. Therefore this approach is not what we use nowadays.

Now here in this approach we will still check the validity of the email and password combination on the server. But contrary to what we do in case of sessions, here we return a token to the client and that token is something that gets generated on the server. This token would hold some information that can be validated by the server and this token will then be stored in the client so basically in the local storage of the browser. The client can then attach this token to every subsequent request it sents to the server. Stored token is sent to authorize subsequent request and targets the resource on the server which requires authentication.
That token can only be validated by the server who created that token.

Now what if you try to change or fake the token ?

If you try to change or fake the token on the client side, then that will be detected because the server uses a special algorithm to generate the token and you simply cannot fake it since the algorithm that uses to generate the private key is not known to you.

What's that token ?

JSON data + Signature => => => JSON web token (JWT)

This JWT (json web token) is what gets returned to the client and the signature can only be verified by the server. So you cannot edit or tamper the token at the client because the server will detect and will invalidate the token. This is how authentication is done in REST APIs.
So in essence, we have a token which can be checked by the server but need not be stored by the server.

So generating the token is one thing, the server sends the token. Next we need to make sure that we can send the token back to the server/backend REST API and then we check for the existence and the validity of token before we allow the request to continue.

If no token is attached to the incoming request, we should simply block access to those routes which do require some form of proven authentication. Remember, it is for the private routes that you do need a token attached to the request so that the user can access them.

Now to basically append the token with request you could attach the token with query params of the url or you could send them inside the body of NON-GET requests. But the best solution would be to send the token along with the headers. The benefit of this is that this would keep your URL clean. Also headers makes a lot of sense for the meta information which our token is in the end.

Now with Express.js, we use the jsonwebtoken package for decoding and verifying our token on the backend.

We use jsonwebtoken.verify to both encode and verify the token on the backend. We can also use jsonwebtoken.decode at the server side as well but then it won't verify the token there.

Wrap up

The REST API server doesn't care about the client. Requests are handled in isolation which means that every request is treated as if it arrived for the first time. So here we don't use sessions. The REST APIs does not store any sessions. They don't store any client data.

Due to no involvement of sessions in REST APIs, authentication works a bit differently here. Each request needs to be able to send some data that proves the authenticity of that request. JSON Web Tokens are a common way of storing authentication information on the client and proving the authentication status.

JWTs are signed by the server and can only be validated by the server.

So this is it for this article. Thanks for reading.

If you enjoy my articles, consider following me on Twitter for more interesting stuff :

Twitter : https://twitter.com/The_Nerdy_Dev

Don't forget to leave a like if you loved the article. Also share it with your friends and colleagues.

PS - If you are looking to learn Web Development, I have curated a FREE course for you on my YouTube Channel, check the below article :

(2021) - Web Developer Full Course : HTML, CSS, JavaScript, Node.js and MongoDB

The Nerdy Dev Apr 28 '21 2 min read

#html #css #node #javascript

Looking to learn React.js with one Full Project, check this out :

Learn React with one BIG Project [NOTES included] - Demo and Video Link

The Nerdy Dev Jun 10 '21 1 min read

#100daysofcode #javascript #react #webdev