How to authenticate users with a Ruby on Rails API

In the fourth phase of Flatiron coding Bootcamp we have learned how to authenticate users with usernames and passwords. We also learned how to use authorization to only send back certain data if a user is signed in.

To authenticate users we need to use the sessions hash(very similar to a hash, but not actually a hash) which is a cookie. Cookies are small pieces of information that are sent from the server to the client. They are then stored on the client (in the browser) and sent back to the server with each subsequent request. Cookies help make HTTP stateful so that you can send additional information with each request. Using cookies we make it so a user does not have to login in on each separate page to view their specific data. To identify a user’s session information, Rails stores a special secure and tamper-proof cookie on the user’s browser that contains their entire session hash and it expires when the browser is closed.

When you create a new application in API mode with rails new appname — api, the code needed for working with sessions and cookies in the controller is excluded by default. To add session and cookie support we need to add some middleware. Middleware refers to any software component/library which assists with but is not directly involved in the execution of some task. (in config/application.rb):

The last line adds some additional security to our cookies by also configuring the SameSite policy for our cookies as strict, which means that the browser will only send these cookies in requests to websites that are on the same domain.

To access the cookies hash in our controllers, we also need to include the ActionController::Cookies module in our ApplicationController

Next we need to add the bcrypt gem to our gemfile and has_secure_password to the User model. When using has_secure_password, Rails will use the bcrypt gem to hash and salt all passwords on the User model. The has_secure_password method also provides two new instance methods on the User model: password and password_confirmation. These methods, however, don’t correspond to database columns. Instead, to make these methods work, your users table must have a password_digest column.

Now that we are setup we need to create our routes for signing up, logging in, staying logged in, and logging out. Here are what those routes look like:

We will need controllers to handle these routes. Because of separation of concerns, we want our users controller to handle anything with creating and using user data and the sessions controller to handle anything regarding the session data.

We add the [:user_id] key to the session hash when creating a new user to avoid the redundancy of having to log in right after signing up.

I am also using the rescue_from method to handle invalid requests as well as a filter to authorize users for specific actions.

Once our users can sign up and stay logged in we also want them to be able to log out and log back in so we need those actions in the sessions controller.

With this, you have everything you need to authenticate and authorize users on your backend. These code snippets were taking from my phase 4 project which you can clone down here: https://github.com/Zio-4/one-journal-api. It was a great deal of fun learning all of this and it now allows me to create the apps I want with users.