SpendWise - Budget management app (Ruby on Rails + React) - Part 4

Welcome back! I appreciate you sticking with me on this project. Today, we’re going to jump straight into user authentication and explore why I went with Devise and JWT for this feature.

In previous projects, I’ve used Devise for traditional Rails apps and found it to be simple and reliable for handling user registration, login, and password management. But when it comes to API-only apps—where you need stateless authentication—JWT (JSON Web Token) is a much better solution than session-based approaches.

By combining Devise with JWT, I get the best of both worlds: Devise makes user management (registration, login, etc.) a breeze, while JWT provides secure, stateless authentication that fits perfectly with an API setup.

Let’s dive into how it all works!

1. Add required gems

First, we need to include the necessary gems for Devise and JWT. Add these to your Gemfile:

gem 'devise'
gem 'devise-jwt'

Run bundle install to install the gems.

2. Install Devise

Next, install Devise and generate the User model:

rails generate devise:install
rails generate devise User

In your User model (app/models/user.rb), include the following Devise modules:

class User < ApplicationRecord
  # Include default devise modules. Others available are:
  # :confirmable, :lockable, :timeoutable, :trackable and :omniauthable
  devise :database_authenticatable, :registerable,
         :recoverable, :rememberable, :validatable,

end

Run migrations to update your database schema:

rails db:migrate

3. Enabling CORS

Since the API will interact with a frontend (likely running on a different domain), we must enable CORS to allow cross-origin requests. This step is critical for securely allowing your frontend (e.g., a React app) to communicate with your backend API.

First, add the rack-cors gem:

gem 'rack-cors'

Run bundle install and uncomment the contents of the file config/initializers/cors.rb and add the following code:

Rails.application.config.middleware.insert_before 0, Rack::Cors do
  allow do
    origins '*'

    resource '*',
      headers: :any,
      methods: [:get, :post, :put, :patch, :delete, :options, :head],
      expose: ["Authorization"]
  end
end

Also, ensure that Devise isn’t using navigational formats by updating config/initializers/devise.rb. uncomment and edit the following line:

config.navigational_formats = []

This will prevent devise from using flash messages which are a default feature and are not present in Rails api mode.

And lastly, add this toconfig/environments/development.rb

config.action_mailer.default_url_options = { host: 'localhost', port: 3000 }

This helps with Devise's password recovery and other mailer features.

4. Set up devise-jwt

Ensure that your config/master.key file exists so that Rails can decrypt credentials containing the secret key base. If it’s missing, you can generate it by running:

EDITOR="code --wait" bin/rails credentials:edit

Rails will generate the config/master.key when you save and close the file.

5. JWT Configuration
In config/initializers/devise.rb, configure JWT for the Rails app:

config.jwt do |jwt|
  jwt.secret = Rails.application.credentials.fetch(:secret_key_base)
  jwt.dispatch_requests = [['POST', %r{^/users/sign_in$}]]
  jwt.revocation_requests = [['DELETE', %r{^/users/sign_out$}]]
  jwt.expiration_time = 120.minutes.to_i
end

This config ensures that JWT is used for login (sign-in) and logout (sign-out), with tokens expiring after two hours.

6. Creating custom controllers

Next, we generate the devise controllers (sessions and registrations) to handle sign-ins and sign-ups

rails g devise:controllers users -c sessions registrations

Then we must override the default routes provided by devise and add route aliases.

Rails.application.routes.draw do
  devise_for :users, controllers: {
    sessions: 'users/sessions',
    registerations: 'users/registerations'
  }
end

7. Revocation Strategy

To manage token revocation and prevent the reuse of tokens after a user logs out, I used the JTIMatcher strategy. This strategy works by adding a unique identifier to each token (called a JTI) and storing it in the database. When a user logs out, the JTI is invalidated, making any token associated with it unusable.

In your User model, the jti field is used to track valid tokens:

rails g migration addJtiToUsers jti:string:index:unique

Then, update the migration file:

class AddJtiToUsers < ActiveRecord::Migration[7.0]
  def change
    add_column :users, :jti, :string, null: false
    add_index :users, :jti, unique: true
  end
end

Run the migration:

rails db:migrate

Finally, update your User model:

class User < ApplicationRecord
  include Devise::JWT::RevocationStrategies::JTIMatcher
  # Include default devise modules. Others available are:
  # :confirmable, :lockable, :timeoutable, :trackable and :omniauthable
  devise :database_authenticatable, :registerable,
         :recoverable, :rememberable, :validatable,
         :jwt_authenticatable, jwt_revocation_strategy: self

  def jwt_payload
    super
  end
end

8. Custom Devise Controllers

To handle JSON responses, we create custom controllers for user registration and session management:

We’ll leverage some Devise helper methods to define how the application behaves in specific scenarios:

respond_with: manages the response for POST requests, such as after registration or login.

respond_to_on_destroy: handles the response for DELETErequests, like when logging out.

in app/controllers/users/registrations_controller.rb:

class Users::RegistrationsController < Devise::RegistrationsController
  respond_to :json
  private

  def respond_with(current_user, _opts = {})
    if resource.persisted?
      render json: {
        status: {code: 200, message: 'Signed up successfully.'},
        data: UserSerializer.new(current_user).serializable_hash[:data][:attributes]
      }
    else
      render json: {
        status: {message: "User couldn't be created successfully. #{current_user.errors.full_messages.to_sentence}"}
      }, status: :unprocessable_entity
    end
  end
end

in app/controllers/users/sessions_controller.rb:

class Users::SessionsController < Devise::SessionsController
  respond_to :json

  private

  def respond_with(resource, _options = {})
    render json: { status: { code: 200, message: 'User signed in successfully' }, data: current_user }, status: :ok
  end

  def respond_to_on_destroy
    token = request.headers['Authorization']&.split(' ')&.last
    if token.nil?
      render json: { status: 401, message: 'Token missing or malformed' }, status: :unauthorized
    else
      begin
        jwt_payload = JWT.decode(token, Rails.application.credentials.fetch(:secret_key_base), true, algorithm: 'HS256').first
        current_user = User.find(jwt_payload['sub'])
        if current_user
          render json: { status: 200, message: 'Signed out successfully' }, status: :ok
        else
          render json: { status: 401, message: 'User has no active session' }, status: :unauthorized
        end
      rescue JWT::DecodeError
        render json: { status: 401, message: 'Invalid token' }, status: :unauthorized
      end
    end
  end
end

This configuration allows us to handle sign-in and sign-out responses in JSON format and validates JWT tokens on sign-out.

9. Updating Routes

We now define routes for Devise, pointing them to the custom controllers:

Rails.application.routes.draw do
  devise_for :users, controllers: {
    sessions: 'users/sessions',
    registrations: 'users/registrations'
  }
end

This connects the user authentication flow to the appropriate controllers.

Phew! That was quite a bit of coding. Now, the final step is to test whether all our hard work has paid off and if everything is functioning as expected

10. Testing with Postman

In application terminal, run rails s to start the server.

To test the API, use Postman to send HTTP requests to the app.

Creating a user:

Logging in:

After we log in, we can check that the authorization token was received:

Logging out:

When we log out the authorization token needs to be passed, for testing, we have to manually add it to Postman:

What’s Next?
That’s all for now! In the next post, I’ll dive into creating models and controllers, and implementing one-to-many relationships with validations. Stay tuned!