Rails 8 Authentication Generator: No Devise, Full Control

Every Rails developer faces the same question at project kickoff: Devise, or roll your own? Rails 8 eliminates that choice. The built-in authentication generator gives you a working login system in minutes - has_secure_password, timing-safe authenticate_by, and database-backed sessions - with zero gem dependencies and full control of the code.

What you get out of the box

Run:

bin/rails generate authentication

This scaffolds a minimal but complete setup: a User model with secure passwords, a Session model and controller for sign-in/sign-out, a PasswordsMailer and actions for password resets, plus a concern to require authentication in controllers. You then add your own sign-up flow.

Important notes:

• The generator focuses on login and password reset. It intentionally leaves sign-up to you, since every app’s registration differs.
• Sessions are persisted in a sessions table and tied to a signed cookie. This gives you revocation and multi-device control without third-party gems.

Rails 8 vs Devise: the honest comparison

The Rails 8 generator wins when you value owning the code and your auth needs are standard. Devise wins when you need confirmable, lockable, or invitable working on day one and don’t want to write them. Both are timing-attack safe and both are production-grade; the difference is where the code lives and how much of it you maintain.

The rest of this post fills the “DIY” rows that matter most in practice - email confirmation, listing and revoking sessions, and rate limiting - so the gap with Devise is smaller than the table suggests.

Step 1: Install and migrate

# add auth scaffolding
bin/rails generate authentication

# create users and sessions tables
bin/rails db:migrate

If you are upgrading an existing app, ensure bcrypt is available, mailer host is set, and URL options are configured so password-reset links work. The Rails security guide shows that the generator adds migrations for user and session tables.

Step 2: Review the generated models

User model highlights

• has_secure_password stores a BCrypt hash in password_digest.
• You get password and password_confirmation virtual attributes.
• authenticate_by provides safe credential checks that resist timing-based user enumeration and should be used in the Sessions controller.

Session model highlights

• Records active sessions with metadata like user agent and IP, and links them to a browser cookie. This enables forced logouts across devices later.

Step 3: Add a simple sign-up flow

The generator does not create sign-up screens. Here is a minimal implementation.

# app/controllers/users_controller.rb
class UsersController < ApplicationController
  # Let guests access sign-up
  skip_before_action :require_authentication, only: %i[new create]

  def new
    @user = User.new
  end

  def create
    @user = User.new(user_params)
    if @user.save
      Current.session = @user.sessions.create! # sign in after sign-up
      redirect_to root_path, notice: "Welcome!"
    else
      render :new, status: :unprocessable_entity
    end
  end

  private

  def user_params
    params.require(:user).permit(:email_address, :password, :password_confirmation)
  end
end

<!-- app/views/users/new.html.erb -->
<h1>Create account</h1>
<%= form_with model: @user do |f| %>
  <%= f.label :email_address %>
  <%= f.email_field :email_address, autofocus: true %>

  <%= f.label :password %>
  <%= f.password_field :password %>

  <%= f.label :password_confirmation %>
  <%= f.password_field :password_confirmation %>

  <%= f.submit "Sign up" %>
<% end %>

This mirrors a common recommendation: keep registration bespoke, let the generator handle sessions and resets.

Step 4: Login and logout with authenticate_by

Use the safer authenticate_by method. It computes a password digest even when the user record is missing, which removes timing side-channels.

# app/controllers/sessions_controller.rb
class SessionsController < ApplicationController
  skip_before_action :require_authentication, only: %i[new create]

  def new; end

  def create
    # authenticate_by avoids timing attacks
    if user = User.authenticate_by(email_address: params[:email_address], password: params[:password])
      Current.session = user.sessions.create!
      redirect_to root_path, notice: "Signed in"
    else
      flash.now[:alert] = "Invalid email or password"
      render :new, status: :unprocessable_entity
    end
  end

  def destroy
    Current.session&.destroy
    redirect_to root_path, notice: "Signed out"
  end
end

Why authenticate_by instead of find_by(...).authenticate? It standardizes timing, so attackers cannot infer whether an email exists.

Step 5: Password resets with zero custom crypto

Rails extends has_secure_password with a built-in password reset token and finder, with a default short expiry. You get a reset flow without rolling your own signing or token tables.

# app/models/user.rb
class User < ApplicationRecord
  has_secure_password
  # optionally add: generates_token_for :magic_login  # for custom tokens
end

# app/controllers/passwords_controller.rb  (simplified)
class PasswordsController < ApplicationController
  skip_before_action :require_authentication

  def create
    if (user = User.find_by(email_address: params[:email_address]))
      PasswordsMailer.reset(user, token: user.password_reset_token).deliver_later
    end
    redirect_to new_session_path, notice: "If your email exists, you will receive reset instructions"
  end

  def edit
    @user = User.find_by_password_reset_token(params[:token])
    redirect_to new_session_path, alert: "Token invalid or expired" unless @user
  end

  def update
    @user = User.find_by_password_reset_token(params[:token])
    return redirect_to new_session_path, alert: "Token invalid or expired" unless @user

    if @user.update(user_params) # includes password and confirmation
      redirect_to new_session_path, notice: "Password changed. Please sign in"
    else
      render :edit, status: :unprocessable_entity
    end
  end

  private

  def user_params
    params.require(:user).permit(:password, :password_confirmation)
  end
end

For custom purposes such as magic links or email confirmation, use generates_token_for.

Step 6: Email confirmation with generates_token_for

The generator skips email confirmation, but you don’t need Devise’s Confirmable for it. generates_token_for signs a token whose payload includes a value you choose. When that value changes, every previously issued token stops verifying. Embed confirmed_at, and the confirmation link self-destructs the moment the user clicks it.

# app/models/user.rb
class User < ApplicationRecord
  has_secure_password
  has_many :sessions, dependent: :destroy

  normalizes :email_address, with: ->(e) { e.strip.downcase }

  # The block return value is baked into the token's signature.
  # Once confirmed_at is set, the old token no longer validates,
  # so a confirmation link can't be replayed.
  generates_token_for :email_confirmation, expires_in: 1.day do
    confirmed_at
  end
end

Add the column the token reads from:

# db/migrate/xxxx_add_confirmed_at_to_users.rb
class AddConfirmedAtToUsers < ActiveRecord::Migration[8.0]
  def change
    add_column :users, :confirmed_at, :datetime
  end
end

Generate the token in a mailer and send the link:

# app/mailers/user_mailer.rb
class UserMailer < ApplicationMailer
  def email_confirmation(user)
    @token = user.generate_token_for(:email_confirmation)
    mail to: user.email_address, subject: "Confirm your email"
  end
end

<!-- app/views/user_mailer/email_confirmation.html.erb -->
<p>Welcome. Confirm your email to finish setting up your account:</p>
<%= link_to "Confirm my email", email_confirmation_url(@token) %>

The controller verifies the token with find_by_token_for, which returns nil for a tampered, expired, or already-used link:

# app/controllers/email_confirmations_controller.rb
class EmailConfirmationsController < ApplicationController
  skip_before_action :require_authentication, only: :show

  def show
    user = User.find_by_token_for(:email_confirmation, params[:token])

    if user
      user.update!(confirmed_at: Time.current)
      redirect_to root_path, notice: "Email confirmed. You're all set."
    else
      redirect_to new_session_path, alert: "That confirmation link is invalid or expired."
    end
  end
end

# config/routes.rb
resources :email_confirmations, only: :show, param: :token

Send the mail from your sign-up action with UserMailer.email_confirmation(@user).deliver_later. If you want to block unconfirmed users from sensitive areas, check Current.user.confirmed_at.present? in a before_action rather than gating sign-in itself - letting people in but limiting what they can do until they confirm is usually the better product decision.

Step 7: Protect controllers with a single concern

Your generated concern typically gives you:

# app/controllers/concerns/authentication.rb
module Authentication
  extend ActiveSupport::Concern

  included do
    before_action :require_authentication
  end

  private

  def require_authentication
    redirect_to new_session_path, alert: "Please sign in" unless Current.user
  end
end

Include it in ApplicationController, then selectively open up actions with skip_before_action.

Step 8: Routes you will likely have

# config/routes.rb
resource  :session,   only: %i[new create destroy]
resources :passwords, only: %i[new create edit update]
resources :users,     only: %i[new create]            # your sign-up
resources :email_confirmations, only: :show, param: :token
namespace :settings do
  resources :sessions, only: %i[index destroy]        # active-session management
end
root "home#index"

Step 9: API-only and SPA tips

• The Rails 8 generator can be used in API-only apps. Decide between cookie-based session auth or token-style sessions stored in the sessions table. For mobile clients and cross-domain SPAs, bearer tokens with revocation stored in sessions work well.
• For browser SPAs on the same domain, the default session cookie is simplest and secure when combined with SameSite=Lax, HTTPS only, and short idle timeouts. See the Security Guide for broader hardening.

Listing and revoking active sessions

This is where database-backed sessions earn their keep. Each sign-in is a row in the sessions table carrying user_agent and ip_address, so “see your active sessions” and “sign out this device” are a query and a destroy - no extra gem, no Redis. Devise’s default cookie sessions can’t be revoked server-side without rotating a global secret and logging everyone out.

Build a settings page that lists the current user’s sessions:

# app/controllers/settings/sessions_controller.rb
module Settings
  class SessionsController < ApplicationController
    def index
      @sessions = Current.user.sessions.order(created_at: :desc)
    end

    def destroy
      # Scope to Current.user so a user can only revoke their own sessions.
      Current.user.sessions.find(params[:id]).destroy
      redirect_to settings_sessions_path, notice: "That device was signed out."
    end
  end
end

<!-- app/views/settings/sessions/index.html.erb -->
<h1>Active sessions</h1>
<ul>
  <% @sessions.each do |session| %>
    <li>
      <%= session.user_agent %> - <%= session.ip_address %>
      (started <%= time_ago_in_words(session.created_at) %> ago)
      <% if session == Current.session %>
        <strong>This device</strong>
      <% else %>
        <%= button_to "Revoke", settings_session_path(session), method: :delete %>
      <% end %>
    </li>
  <% end %>
</ul>

Revocation is immediate. The auth concern’s resume_session looks the session up by the cookie’s session_id on every request; once the row is gone, the next request from that device returns nil and the user is bounced to sign-in. A “sign out everywhere else” button - useful after a password change - is one line:

# Keep the current device, drop the rest.
Current.user.sessions.where.not(id: Current.session.id).destroy_all

Stale rows accumulate over time. The cleanest fix is a recurring background job that prunes sessions past an absolute lifetime, scheduled with Solid Queue recurring jobs:

# app/jobs/prune_stale_sessions_job.rb
class PruneStaleSessionsJob < ApplicationJob
  queue_as :maintenance

  def perform
    # Absolute max age. For idle-timeout instead, touch the session row
    # on each request and prune by updated_at.
    Session.where(created_at: ..30.days.ago).delete_all
  end
end

# config/recurring.yml
production:
  prune_stale_sessions:
    class: PruneStaleSessionsJob
    schedule: every day at 3am

Rate limiting sign-in with Rack::Attack

Rate limiting is the difference between “someone tried 10 passwords” and “someone tried 100,000.” Rails 8 ships a built-in rate_limit macro, and the generated SessionsController already uses it:

class SessionsController < ApplicationController
  rate_limit to: 10, within: 3.minutes, only: :create,
    with: -> { redirect_to new_session_url, alert: "Too many attempts. Try again later." }
end

That covers the common case, but it only throttles by IP and only on one action. For attacks that rotate IPs against a single account, or to protect password resets too, Rack::Attack gives you per-email and per-endpoint control in one place.

# Gemfile
gem "rack-attack"

# config/initializers/rack_attack.rb
class Rack::Attack
  # Back the counters with your cache store. Solid Cache works fine here.
  Rack::Attack.cache.store = Rails.cache

  # Throttle sign-in attempts per IP.
  throttle("logins/ip", limit: 10, period: 3.minutes) do |req|
    req.ip if req.path == "/session" && req.post?
  end

  # Throttle per email address, so a botnet rotating IPs still can't
  # brute-force one account.
  throttle("logins/email", limit: 6, period: 3.minutes) do |req|
    if req.path == "/session" && req.post?
      req.params.dig("email_address").to_s.downcase.presence
    end
  end

  # Password-reset requests are an enumeration and spam vector - cap them too.
  throttle("password_resets/ip", limit: 5, period: 15.minutes) do |req|
    req.ip if req.path == "/passwords" && req.post?
  end

  # Return a plain 429 instead of an exception page.
  self.throttled_responder = ->(_req) do
    [429, { "Content-Type" => "text/plain" }, ["Too many requests. Slow down.\n"]]
  end
end

One gotcha that bites in production: behind a CDN or load balancer, req.ip is the proxy’s address, not the visitor’s, so a single bucket throttles your entire user base at once. Set config.action_dispatch.trusted_proxies (or read the real client header your edge sets, like CF-Connecting-IP) so Rack::Attack keys on the actual client. The per-email throttle is your backstop here - it works regardless of how IPs are presented.

Testing sign-up, sign-in, and password reset

Authentication is the one feature where a green test suite directly maps to “attackers can’t get in,” so test the failure paths as hard as the happy ones. These are RSpec request and system specs; the Minitest equivalents are a near-mechanical translation if your app uses the default framework.

Request specs cover the controller logic - sign-up validation, credential checks, and the enumeration-safe reset flow:

# spec/requests/registrations_spec.rb
require "rails_helper"

RSpec.describe "Sign up", type: :request do
  it "creates a user and signs them in" do
    expect {
      post users_path, params: { user: {
        email_address: "[email protected]",
        password: "battery-horse-staple",
        password_confirmation: "battery-horse-staple"
      } }
    }.to change(User, :count).by(1)

    expect(response).to redirect_to(root_path)
  end

  it "rejects a mismatched password confirmation" do
    post users_path, params: { user: {
      email_address: "[email protected]",
      password: "battery-horse-staple",
      password_confirmation: "nope"
    } }

    expect(response).to have_http_status(:unprocessable_entity)
    expect(User.count).to eq(0)
  end
end

# spec/requests/sessions_spec.rb
require "rails_helper"

RSpec.describe "Sign in", type: :request do
  let(:user) do
    User.create!(email_address: "[email protected]", password: "compiler-1947")
  end

  it "signs in with valid credentials" do
    post session_path, params: {
      email_address: user.email_address, password: "compiler-1947"
    }
    expect(response).to redirect_to(root_path)
  end

  it "rejects a wrong password without leaking which field failed" do
    post session_path, params: {
      email_address: user.email_address, password: "wrong"
    }
    expect(response).to have_http_status(:unprocessable_entity)
    expect(response.body).to include("Invalid email or password")
  end
end

The password-reset spec is the one most teams skip, and it’s the one that protects you from account enumeration - an unknown address must produce the exact same response as a known one:

# spec/requests/passwords_spec.rb
require "rails_helper"

RSpec.describe "Password reset", type: :request do
  let(:user) do
    User.create!(email_address: "[email protected]", password: "old-password")
  end

  it "emails a reset link for a known address" do
    expect {
      post passwords_path, params: { email_address: user.email_address }
    }.to have_enqueued_mail(PasswordsMailer, :reset)
    expect(response).to redirect_to(new_session_path)
  end

  it "does not reveal whether an unknown address exists" do
    post passwords_path, params: { email_address: "[email protected]" }
    # Same redirect, no mail - identical to the known-address response.
    expect(response).to redirect_to(new_session_path)
  end

  it "updates the password with a valid token" do
    patch password_path(user.password_reset_token), params: { user: {
      password: "new-password", password_confirmation: "new-password"
    } }

    expect(response).to redirect_to(new_session_path)
    expect(user.reload.authenticate("new-password")).to be_truthy
  end
end

A single system spec ties it together end to end and proves the auth concern actually guards protected pages:

# spec/system/authentication_spec.rb
require "rails_helper"

RSpec.describe "Authentication", type: :system do
  it "lets a visitor sign up, sign out, and sign back in" do
    visit new_user_path
    fill_in "Email address", with: "[email protected]"
    fill_in "Password", with: "supersecret"
    fill_in "Password confirmation", with: "supersecret"
    click_on "Sign up"
    expect(page).to have_text("Welcome")

    click_on "Sign out"

    # A guest hitting a protected page should land on the login screen.
    visit dashboard_path
    expect(page).to have_current_path(new_session_path)

    fill_in "Email address", with: "[email protected]"
    fill_in "Password", with: "supersecret"
    click_on "Sign in"
    expect(page).to have_text("Signed in")
  end
end

have_enqueued_mail needs ActiveJob’s test adapter (the rails-rspec default in test), and the system spec needs a JavaScript-capable or rack-test driver - the standard rails generate rspec:install setup covers both.

Security checklist before production

• Enforce authenticate_by everywhere you verify credentials.
• Set secure cookie flags: secure, httponly, and same_site.
• Configure mailers host and force_ssl in production.
• Add rate limits on login and password-reset endpoints.
• Rotate session records on privilege changes.
• Add background cleanup for stale sessions.

When should you still pick Devise

Devise remains a quick way to add features like confirmations, lockable, invitable, two-factor, and OmniAuth without coding them yourself. Rails 8’s generator is a starter that keeps your auth simple, understandable, and inline with modern Rails primitives. If you need confirmable, lockable, and OmniAuth on day one - and you’d rather configure a mature DSL than maintain those flows yourself - Devise can still be the faster path. The honest dividing line is invitations and 2FA: those are the rows in the comparison table where Devise saves you the most code.

What I’d reach for on a new app

For a new SaaS app, an internal tool, or a standard web product, I now start with the generator and don’t look back. The reasons are practical, not ideological. You own every line, so when something breaks at 2am you’re reading your own controllers instead of spelunking through a gem’s override chain. There are no dependencies to track through Rails upgrades. BCrypt and authenticate_by give you the same timing-attack resistance Devise does, and database-backed sessions hand you per-device revocation that Devise’s default cookies can’t.

The cost is real and worth naming: you write sign-up, email confirmation, and account lockout yourself. As this post shows, those are short, well-trodden pieces of code rather than research projects - but if your launch checklist needs confirmable, lockable, and invitable working this week, Devise will get you there with less typing. Pick the generator when control and a small dependency surface matter more than a head start on auxiliary features. Reach for Devise when you need those features more than you need to own the code.

Need help with Rails authentication or security? I help teams with authentication architecture, production hardening, and Rails 8 adoption. If you’re building auth from scratch or replacing Devise, reach out at nikita.sinenko at gmail.com.

Further Reading

• Solid Queue in Rails 8: The Complete Production Guide
• How to Deploy Rails 8 Apps with Kamal to a VPS
• My Rails 8 Features Overview
• Rails 8.0 Release Notes
• Rails Security Guide
• has_secure_password Documentation
• authenticate_by Method