Simple Authentication with Bcrypt and Warden

Marek Stanisz

However, let’s face it – Devise can be really hard to work with if you don’t follow The Rails Way™ or at least The Devise Way (not sure if this one is trademarked or I just made it up 😉 ). A lot of things happen under the hood, which can be extremely handy, but if you’re trying to escape a little from Rails framework and follow any other code principles (e.g. CQRS) or maintain sane level of code transparency, it might not be the best solution… Not exactly a pain in the back, but I felt bad committing the code I wrote having to conform to some Devise features to what I wanted to achieve.

There came a moment, when I thought “Maybe it’s time to work on another solution? Something that gives me the level of flexibility that I want and is more style-agnostic than Devise?”.

The solution

I knew that Devise is built on top of Warden – a Rack solution for authenticating requests – so I decided to try it by myself. Here’s what I wanted to achieve:

  • keeping passwords in the database in a secure manner
  • basic user signup, with password validation
  • storing session in a secure manner

So, shall we get going?

First things first, add the gems bcrypt and warden to your Gemfile. You should already have a little understanding of what the latter does. The former, though, take care of converting your passwords to a secure format, using the Bcrypt encryption algorithm (read more on the bcrypt-ruby GitHub page or here). Its usage is really simple.

Run bundle install. Now, to encrypt the password using the Bcrypt algorithm, you run

Assuming a User model with email and encrypted_password fields, the above might look like this in the scope of a command object:

class User::Register
  include Virtus.model
  include ActiveModel::Validations

  attribute :email, String
  attribute :encrypted_password, String
  attribute :password, String
  attribute :password_confirmation, String

  validates :password, confirmation: true
  validates :password, length: { minimum: 8 }

  attr_reader :user

  def call


  def encrypt_password
    @encrypted_password = BCrypt::Password.create(password)

  def save_user
    @user = User.create(attributes.except(:password, :password_confirmation)) # it’s important to store neither of those in the database

And in authentication command it might look more or less like that


class User::Authenticate
  def initialize(user, password)
    @user = user
    @password = password

  def call


  def authenticate == @password

The authenticate method here checks if the stored password matches the one provided by the user. Basically it comes down to this: == 'password'

With only a little hassle you can also expand this command to update signed_in_at or last_sign_in_ip attributes. It’s all up to you.

To sum up, Bcrypt allows us to hash passwords provided by the users and compare the ones given on authentication with the ones that are already hashed.

Now that we’ve got Bcrypt set up, let’s do some Warden magic.

Warden setup

OK, so as you might already know, Warden is a Rack-based middleware. This means it generally works “underneath” the Rails layer of the application. Its place is in the Rack stack, after the session middleware. So let’s start with actually configuring it, somewhere within the initializers:

Rails.application.config.middleware.insert_after ActionDispatch::Session::CookieStore, Warden::Manager do |manager|
  manager.default_strategies :password
  manager.failure_app = lambda { |env| SessionsController.action(:new).call(env) }

Here, we tell Rails where to insert the Warden::Manager object, and then define its config parameters. We tell it the name of the default Warden strategy (more on strategies later) and also set SessionsController as a failure app, because every Warden::Manager has to have a failure app.
 The failure app is what gets called when the authentication fails. The setup above just redirects the user to the sign in form.

Next thing we have to do is to set up serializing the data to and out of the session. The Warden wiki suggests starting with serializing the user’s id. It’s the best way to show you how it works:

Warden::Manager.serialize_into_session do |user|

Warden::Manager.serialize_from_session do |id|

But I decided to generate a unique session token for each user instead:

Warden::Manager.serialize_into_session do |user|

Warden::Manager.serialize_from_session do |session_token|
  User.find_by(session_token: session_token)

And the User::SessionTokenGenerator looks like this:

class User::SessionTokenGenerator
  def initialize(user)
    @user = user

  def call


  def generate_and_save_session_token
    @user.update(session_token: session_token)

  def session_token
    @session_token ||= Digest::SHA1.hexdigest("#{}-#{}-#{@user.updated_at}")

One more thing regarding session handling – if we decide to use the session token, we need to clear it on logout. Et voilà:

Warden::Manager.before_logout scope: :user do |user, auth, opts|
  user.update(session_token: nil)

Next thing we need to do is… declare some strategies, at last! So here we go:

Warden::Strategies.add(:password) do
  def valid?
    params['email'] && params['password']

  def authenticate!
    user = User.find_by(email: params['email'])
    return success!(user) if user &&, params['password']).call
    fail 'Invalid email or password'

So now for a brief explanation of what’s going on here.

The valid? method sets the conditions to run the strategy. If the conditions are fulfilled, then the strategy can be run whenever warden.authenticate! is called. So in this case, if there are both email and password parameter in the request, this strategy can be ran.

On the other hand, the authenticate! method takes care of actually authenticating the request. Calling success! and passing it the authenticated object will treat the object as authenticated and serialize it into session as described above. The fail method halts the chain and returns the specified message. Please note that I’m calling my own Authenticate class here (shown a few paragraphs above), providing it with user we try to sign in and password provided by him.

Strategies have access to many other methods, if you want to know more, the Warden Strategies wiki is a place to go.

Accessing Warden from your controllers

To simplify things a little bit, let’s define some useful methods in ApplicationController:

def warden

def current_user
helper_method :current_user

The first one shortens our access to warden, sitting somewhere in the request environment. The second one is a shortcut to the signed in user, in a style somewhat similar to Devise. I also set it as a helper_method, to freely access it also in your views.

And now for actually using Warden for serving the request. It’s really simple, to be honest.

Call warden.authenticate! to authenticate the user and trigger the failure app if the authentication fails. You can specify which strategy to use, too – just pass the strategy name as a symbol to the function.

You also have an option to just authenticate the request and proceed if it fails – you should just use warden.authenticate.

To check if the request was authenticated – call warden.authenticated?. To log the user out, just call warden.logout.

To get the message sent to warden with the fail method you call warden.message. It’s that simple.

Have a peek into my SessionsController:

class SessionsController < ApplicationController
  def new
    render :new

  def create
    return render :new, alert: warden.message unless warden.authenticated?
    respond_to do |format|
      format.html { redirect_to root_url, notice: 'Logged in' }

  def destroy
    redirect_to root_url, notice: 'Logged out'

Pretty plain and simple, isn’t it? 🙂

The last thing left…


We’ll use the warden-rspec-rails gem. It’s actually really simple to use. Long story short it mocks Warden so that you can manipulate it in your specs. Basically, you need to tell your spec_helper.rb to include Warden ControllerHelpers in controller specs and define a helper method for signing the user in:

RSpec.configure do |c|
  c.include Warden::Test::ControllerHelpers, type: :controller
  def sign_in(user)

For more info, check this gem’s github page.

I also used rails-controller-testing gem here, to get access to some of its matchers – just so you know.

A sample sessions controller spec might look like this:

describe '#create' do
  subject { post :create, params: params }

  context 'when user is not signed in' do
    let(:params) { { email:, password: 'password' } }

    it 'redirects to root' do
      expect(response).to redirect_to('/')

describe '#logout' do
  subject { delete :destroy }

  context 'when user is signed in' do
    before do
      sign_in user

    it 'redirects to root' do
      expect(response).to redirect_to('/')

And that’s all, folks!

To sum up: Warden enables you to tailor your own authentication strategies in quite an easy way. After you get used to it, it lets you set up an authentication quick’n’easy, and also can be easily expanded, even by strategies written by someone else (see warden_strategies, for example). So… happy authenticating!

You may also be interested in...

5 secrets of Swift API design

It was a stormy afternoon somewhere in Poland. In the town center, amid heavy rain, one could see a single window with a light on. In that […]

Igor Dąbrowski

Clean up request in useEffect React Hook

Creating a React application that will communicate with an external API is a piece of the pie. However, sometimes you may get this warning message: > Warning: […]

Igor Dąbrowski

Let's bring your project to life

Request a consultation