Building API in Rails - Part 4

Hi there, welcome to the fourth part of Building API with Rails series. In this part we are going to discuss how we can secure our API.

Business vector created by jcomp - www.freepik.com

Normally when it comes to securing API or web application its done through the process of authentication and authoriztion..

There are a mainly two ways for doing the authentication part which is Session based Authentication and Token Based Authentication and one of the best and renown one in Rails for session based authentication is Devise.

For token based authentication we can also ues Devise Token Auth. Simillary, other ones are Knock, Doorkeeper as Oauth provider and so on. I will be using JWT for the token based authentication for this application.

Now if you are not familiar with what session and token based authentication is I will try to describe the process of both.

Session Based Authentication

In the session based authentication the processes is as follows:

1. User fills the login form with their credentials and submits the request to the server.
2. Server then validates the request and then creates a session and stores it in the database.
3. The session id is then send as a response to the browser.
4. The browser then needs to store this session_id somewhere. We know that HTML is a stateless protocol so how can the browser store it and the answer is with cookies
5. Now when the logged in user needs to make another request to the server to get some protected resources let’s say fetch all the super cats then it attaches the session_id in the request header and sends the request.
6. Finally, server matches the session_id with the one stored in the database and response backs with all the super cats ​ .

Token Based Authentication

The authentication process for token based authentication is somewhat similar to that of session based authentication

1. User fills the login form with their credentials and submits the request to the server.
2. Server then validates the request and then creates a encoded token with the help of private key and some hashing algorithim and this token is known as JWT.
3. The encoded jwt is then send back as a response.
4. This endocoded jwt is generally stored in the local storage.
5. Now when the logged in user needs to make another request to the server to get some protected resources let’s say fetch all the super cats available in the server then it attaches the encoded jwt in the request header with Authorization as key and also adds a Bearer prefix to the token.

   Request Headers
   Authorization: Bearer <token>
   

6. Finally, server matches the encoded jwt by decoding it and response backs with all the available cats ​ .

Thanks for reading till the end we have come to the end of part 4 of the Building API with Rails series. In the next part, we will continue the process of securing our API by using JWT.

The code base is available here.