Compare Devise and custom authentication in Rails, including security, flexibility, complexity, maintenance, and when to use each.
• 23 min read
• 23 min read
Authentication is one of the first big decisions you will make on almost any Rails application. Before users can create posts, manage accounts, or access anything personal, your app needs to answer one basic question: who is this person? Get that wrong, and everything built on top of it, from authorization to data privacy, is at risk.
Two paths dominate this decision in Rails. You can reach for Devise, the long standing gem that has handled authentication for thousands of production apps, or you can build a custom authentication system using tools Rails already gives you, like has_secure_password. Both are legitimate choices, and neither is automatically right or wrong.
Before picking a side, ask a few questions. How much of Devise's feature set will you actually use? Does your app have requirements that do not fit the common case? Is your team ready to own the security responsibilities of a custom system? Is speed or control the higher priority right now?
This article walks through both approaches: how Rails authentication works conceptually, how Devise implements it, how to build a custom system with has_secure_password, and how the two compare on security, flexibility, speed, and long term maintenance. By the end, you should have a practical framework for deciding which fits your next Rails 8 project.
Authentication confirms that a user is who they claim to be, typically by checking an email and password against stored credentials, then remembering that the user is logged in for the rest of their visit.
It is worth being precise about a distinction that trips up newer developers: authentication and authorization are not the same thing. Authentication answers "who are you?" Authorization answers "what are you allowed to do?" A fully authenticated user can still be blocked from an admin dashboard because they lack the right role. Devise and most custom systems only handle authentication. Authorization is a separate concern, usually solved with Pundit, CanCanCan, or your own role checks.
A standard flow looks like this: a user submits credentials, the server looks up the matching record, and compares the submitted password against a securely hashed version in the database. If it matches, the server creates a session, usually by storing the user's ID in an encrypted, signed cookie. On every request, Rails reads that cookie and treats the request as authenticated, until the user logs out and the session is cleared.
A few concepts recur throughout this flow:
Authentication is security sensitive because nearly every other feature depends on it being correct. A flaw in password hashing, session handling, or reset tokens can expose every account in your system. That is exactly why the Devise versus custom decision matters, and why security is a recurring theme in this article. If you want a broader look at hardening a Rails app beyond authentication itself, our guide to Rails security best practices is a useful companion read.
Devise is a flexible, modular authentication solution for Rails, built on top of Warden, a general purpose Rack authentication framework. Rather than one rigid feature, Devise is composed of separate modules you mix and match based on what your app needs.
Common Devise modules include:
Out of the box, Devise gives you working registration, login, logout, and password reset flows, plus view templates you can customize. It generates a User model, wires up routes, and provides helpers like authenticate_user!, current_user, and user_signed_in? you can use immediately.
Devise is widely used because it solves a problem almost every application shares, in a way that has been battle tested across a huge number of production apps over more than a decade.
Custom authentication means building your login system yourself, using Rails and Ruby's built in tools rather than an external gem. Custom authentication does not mean writing your own cryptographic hashing, session encryption, or password security from scratch. Nobody should do that.
It means assembling the pieces yourself using secure, well established building blocks. Rails ships with has_secure_password, an Active Record method that handles password hashing and verification using bcrypt. One line gives you secure password storage without ever touching a hashing algorithm directly.
Building custom authentication typically involves a User model with an email and hashed password, password hashing via has_secure_password, login and logout logic, sessions to persist authentication state, a shared authentication concern, password reset with secure tokens, email confirmation if needed, and general account security like rate limiting.
The appeal is control: you decide exactly what fields exist and how each step behaves, without working around a gem's assumptions. The cost is that you own getting every piece right, and maintaining it as your app and Rails evolve.
Registration. A user submits an email and password. Database Authenticatable hashes the password with bcrypt before saving, so plaintext is never written to the database.
Login. Devise's sessions controller looks up the user by email and verifies the password against the stored hash, then signs the user in through Warden.
Sessions. Devise relies on Rails' standard, encrypted, signed cookie based session, the same infrastructure a custom system would use, just wired up automatically.
Logout. Calling the sign out action clears the session.
Password recovery. With Recoverable enabled, Devise generates a secure, time limited reset token, emails a link, and verifies the token before allowing a new password.
Authentication helpers.
class DashboardController < ApplicationController
before_action :authenticate_user!
def show
@user = current_user
end
end
<% if user_signed_in? %>
<p>Welcome back, <%= current_user.email %>.</p>
<% else %>
<%= link_to "Sign in", new_user_session_path %>
<% end %>
authenticate_user! redirects unauthenticated visitors, current_user gives you the logged in user, and user_signed_in? gives a boolean check. These three cover most day to day needs, a big part of why teams get productive with Devise quickly.
The User model:
# app/models/user.rb
class User < ApplicationRecord
has_secure_password
validates :email, presence: true, uniqueness: true
normalizes :email, with: ->(email) { email.strip.downcase }
end
class CreateUsers < ActiveRecord::Migration[8.0]
def change
create_table :users do |t|
t.string :email, null: false, index: { unique: true }
t.string :password_digest, null: false
t.timestamps
end
end
end
Add gem "bcrypt" to your Gemfile. has_secure_password uses it to generate and verify hashes, giving you user.authenticate(password) for free.
The sessions controller:
# app/controllers/sessions_controller.rb
class SessionsController < ApplicationController
def new
end
def create
user = User.find_by(email: params[:email]&.downcase)
if user&.authenticate(params[:password])
session[:user_id] = user.id
redirect_to root_path, notice: "Signed in successfully."
else
flash.now[:alert] = "Invalid email or password."
render :new, status: :unprocessable_entity
end
end
def destroy
session.delete(:user_id)
redirect_to root_path, notice: "Signed out successfully."
end
end
Routes:
resource :session, only: [:new, :create, :destroy]
Authenticating requests, as a shared concern:
# app/controllers/concerns/authentication.rb
module Authentication
extend ActiveSupport::Concern
included do
helper_method :current_user, :user_signed_in?
end
def current_user
@current_user ||= User.find_by(id: session[:user_id])
end
def user_signed_in?
current_user.present?
end
def authenticate_user!
redirect_to new_session_path, alert: "Please sign in first." unless user_signed_in?
end
end
Protecting controller actions:
class ApplicationController < ActionController::Base
include Authentication
end
class DashboardController < ApplicationController
before_action :authenticate_user!
def show
@user = current_user
end
end
This mirrors Devise's authenticate_user! and current_user closely, which is no coincidence. Devise is, at its core, a more feature complete and configurable version of the same pattern. Building it yourself means understanding every line, and owning its security and maintenance.
Setup. Devise needs a gem, a generator, and initializer configuration. Custom authentication needs a model, controller, routes, and concern written by hand. Devise is faster initially.
Features. Devise bundles registration, login, password recovery, confirmation, and locking. Custom authentication starts with nothing beyond what you build.
Flexibility. Custom authentication gives full control over data and flow from day one. Devise can be customized extensively, but within its conventions.
Security. Both can be equally secure or insecure depending on implementation and maintenance. Devise reduces the number of decisions you must get right yourself.
Development time. Devise is generally faster for standard needs. Custom authentication takes longer once you add resets, confirmations, and edge cases.
Maintenance. Devise maintenance means updating a gem. Custom authentication means owning every piece indefinitely.
Testing. Both need solid coverage. Devise ships test helpers; custom authentication requires writing your own from scratch.
Customization. Devise supports extensive customization within its architecture. Custom authentication has no architecture to work around, since you built it.
Learning curve. Devise has its own conventions to learn. Custom authentication requires understanding sessions, has_secure_password, and secure tokens directly.
Long term complexity. Devise's complexity mostly lives inside the gem. Custom authentication's complexity grows visibly in your own codebase.
If speed matters most, Devise has a clear edge. Installing the gem, running the generator, and adding before_action :authenticate_user! gets you a working login and registration flow quickly. Enabling confirmable emails or lockable accounts is largely a matter of configuration, not new code.
Custom authentication takes longer because every feature is something you build. A basic login and logout flow does not take long, but once you add registration validation, password reset with secure tokens, email confirmation, and remember me behavior, the time adds up. None of these are individually hard, but together they represent real hours Devise gives you nearly instantly.
For applications that only need a subset of this functionality, building just what you need can be faster than configuring a larger tool. But for the full standard feature set, Devise is generally the quicker path to production.
This is where custom authentication tends to shine. Because you control the whole implementation, you are not working within an external gem's assumptions. An unusual user model, such as authentication tied to an organization rather than an individual, or a login flow outside the typical email and password pattern, is easier to shape with a custom system.
Custom authentication also suits specialized session behavior, like expirations driven by business logic, or tight integration with an external identity provider that does not map cleanly onto Devise's module system.
That said, Devise is genuinely customizable. You can override its controllers, replace its views, add custom fields, write custom strategies, and enable or disable modules individually. Many production apps run heavily customized Devise setups that look nothing like the default generator output. Choosing Devise does not mean giving up control, it means working within a well documented extension system rather than starting from a blank slate.
Authentication touches password hashing, session security, CSRF protection, brute force protection, reset security, account enumeration, session fixation, secure cookies, and resistance to bypasses. Getting all of this right consistently is genuinely difficult, which is why authentication bugs are such a common source of real world incidents.
Here is the core point: using Devise does not automatically make an app secure, and building custom authentication does not automatically make it insecure. Security is a property of implementation and maintenance, not of which approach you chose. A misconfigured Devise setup can be just as vulnerable as a poorly built custom system. A carefully built custom system, using has_secure_password, expiring tokens, and rotated sessions, can be entirely sound.
What differs is the number of decisions you are responsible for. Devise handles hashing, CSRF protection, and secure cookie configuration by default, reducing the places a mistake can slip in. Custom authentication puts all of these decisions in your hands, which is not automatically worse, but does mean more surface area where a missed detail, like forgetting to rotate the session ID after login, can introduce a real vulnerability.
Dependency updates matter for both. Devise, actively maintained, ships security fixes you receive by updating the gem. Custom authentication has no equivalent upstream, so any improvement has to be identified and implemented by your own team.
Regardless of approach, the rule is the same: never store passwords in plain text, and never write your own hashing algorithm.
has_secure_password relies on bcrypt, a slow, salted algorithm purpose built for password storage. Its deliberate slowness makes brute force attacks against stolen hashes computationally expensive.
class User < ApplicationRecord
has_secure_password
end
With this and a password_digest column, Rails handles hashing and verification:
user = User.new(email: "[email protected]", password: "a-strong-password")
user.save
user.authenticate("a-strong-password") # returns the user
user.authenticate("wrong-password") # returns false
Devise uses the same underlying approach through Database Authenticatable, also backed by bcrypt. Whichever path you take, the mechanism should be identical: a well vetted, purpose built hashing algorithm, never anything built from scratch.
Most Rails apps, whether using Devise or custom authentication, rely on session based authentication. When a user logs in, Rails stores their ID in the session, by default an encrypted, signed cookie. Encryption prevents reading the contents, signing prevents tampering.
On each request, Rails decrypts the cookie, retrieves the ID, and your app looks up the matching user, exactly what current_user does in both examples above.
Cookies should be marked secure, so they only transmit over HTTPS, and httponly, so JavaScript cannot access them. Sessions should expire reasonably. Critically, the session ID should be regenerated after login, called session rotation, to prevent session fixation attacks.
Both approaches benefit from Rails' built in session defaults. The difference is that Devise applies them consistently internally, while custom authentication requires you to apply them deliberately.
With Devise, Recoverable handles this entirely: a secure random token is generated, a hashed version stored, and the raw token emailed. Submitting a new password with that token is verified against the hash, checked for expiration, and the token is single use.
With custom authentication, you build each piece:
class PasswordResetsController < ApplicationController
def create
user = User.find_by(email: params[:email]&.downcase)
if user
token = user.generate_token_for(:password_reset)
UserMailer.password_reset(user, token).deliver_later
end
redirect_to new_session_path, notice: "Check your email for reset instructions."
end
def update
user = User.find_by_token_for(:password_reset, params[:token])
if user&.update(password_params)
redirect_to new_session_path, notice: "Password updated successfully."
else
redirect_to new_password_reset_path, alert: "That reset link is invalid or has expired."
end
end
private
def password_params
params.permit(:password, :password_confirmation)
end
end
Rails 8's generate_token_for and find_by_token_for give you secure, expiring, purpose scoped tokens without an external gem. The requirements to get right: tokens generated securely, expiring within a reasonable window, and single use. Password reset is a feature where using a proven pattern matters more than being clever.
Devise's Confirmable module generates a confirmation token on registration, emails a link, and restricts access for unconfirmed accounts based on your configuration, handling resends and reuse prevention internally.
Custom confirmation follows a similar shape to password reset: generate a secure, expiring, single use token, email a confirmation link, and verify it when clicked. Resending a confirmation email should invalidate any previous outstanding token to avoid accumulation.
Whether you use Devise or build this yourself, email confirmation looks simple but has easy to miss edge cases, part of why Devise's Confirmable module is genuinely valuable when you need this behavior.
Authentication answers "who are you?" Authorization answers "what are you allowed to do?" Devise, despite handling authentication comprehensively, does not solve authorization. Knowing a request comes from a logged in user does not tell you whether they are an admin or should have access to the resource they are requesting.
Most Rails apps pair their authentication solution with a dedicated authorization approach. Pundit uses plain Ruby policy classes; CanCanCan defines abilities in a centralized class. Both work equally well alongside Devise or custom authentication, since authorization operates on top of whatever current_user your authentication layer provides. Mentioning them here is useful context, not a full authorization tutorial.
Whether Devise or custom, tests should cover successful login, failed login, registration, password reset, and access to protected routes.
# spec/requests/sessions_spec.rb
require "rails_helper"
RSpec.describe "Sessions", type: :request do
let!(:user) { User.create!(email: "[email protected]", password: "correct-password") }
describe "POST /session" do
it "signs in a user with valid credentials" do
post session_path, params: { email: "[email protected]", password: "correct-password" }
expect(response).to redirect_to(root_path)
expect(session[:user_id]).to eq(user.id)
end
it "rejects invalid credentials" do
post session_path, params: { email: "[email protected]", password: "wrong-password" }
expect(response).to have_http_status(:unprocessable_entity)
expect(session[:user_id]).to be_nil
end
end
describe "DELETE /session" do
it "signs out the current user" do
post session_path, params: { email: "[email protected]", password: "correct-password" }
delete session_path
expect(session[:user_id]).to be_nil
end
end
end
For Devise, test helpers make similar coverage straightforward:
# spec/requests/dashboard_spec.rb
require "rails_helper"
RSpec.describe "Dashboard", type: :request do
let(:user) { create(:user) }
it "redirects unauthenticated users to sign in" do
get dashboard_path
expect(response).to redirect_to(new_user_session_path)
end
it "allows authenticated users to view the dashboard" do
sign_in user
get dashboard_path
expect(response).to have_http_status(:ok)
end
end
If you want a deeper walkthrough of RSpec itself, our Rails API testing with RSpec guide covers the fundamentals this builds on. The setup differs, but the philosophy does not: confirm protected routes reject unauthenticated users, valid credentials succeed, invalid credentials fail cleanly, and logout actually clears state.
Choosing Devise shifts maintenance responsibilities rather than eliminating them. You are responsible for updating the gem, especially for security releases, reading release notes when configuration defaults change, and periodically reviewing settings like password minimum length. Customized views or controllers need to stay in sync as Devise evolves, and unnecessary monkey patches into internals tend to be fragile across upgrades. Rails, Ruby, and other dependencies still need to stay reasonably current. Installing Devise buys a strong starting point, not a permanent exemption from thinking about authentication security.
Custom authentication's maintenance burden is more direct, since no upstream gem absorbs security research on your behalf. Your team owns periodic security reviews, dependency updates, revisiting reset and session policies as best practices evolve, and adapting to future Rails changes around sessions and cookies. As requirements grow, so does the surface area you are personally responsible for securing. For a small, stable footprint this is manageable; for a growing app it can become a real ongoing cost.
has_secure_password or equivalent.Devise tends to be the stronger choice when you need standard features: registration, login and logout, password recovery, email confirmation, remember me, and account locking. It also fits established apps already using it, where migrating away would be costly for uncertain benefit. Teams that want a proven, actively maintained solution, particularly smaller teams without dedicated security expertise, often benefit from the reduced decision surface Devise provides, since many subtle details have already been worked through by a large community.
Custom authentication makes sense when requirements genuinely diverge from the standard case: highly specialized flows that would require heavily overriding Devise anyway, unusual user models, a deliberately small authentication surface, or teams needing full architectural control. APIs or services with their own authentication architecture, such as token based systems unlike typical browser sessions, are another common case. The important nuance is that custom authentication should be a deliberate choice made for a specific reason, not a default reached for because it seems easier or because Devise feels unfamiliar.
Devise does add real code: generated views, initializer configuration, routes, and controller logic across enabled modules. For an app that only needs basic login and logout, this can feel like more machinery than necessary. But Devise's modular design means you are not forced to use everything, and a minimal setup with just Database Authenticatable is considerably lighter than the full feature set suggests. Its complexity tends to be justified when you actually need several modules, since building the equivalent yourself involves comparable complexity spread across your own codebase instead of contained in a well tested gem.
No, and this is worth stating directly: custom authentication is not automatically more secure than Devise, and Devise is not automatically more secure than custom authentication. Security depends on implementation quality, threat modeling, ongoing maintenance, and correct configuration, not architecture. A team that builds custom authentication carefully, with strong token security, session rotation, and rate limiting, can produce a genuinely secure system. A team that configures Devise carelessly can produce a genuinely insecure one. Where a mature library like Devise offers a real advantage is reducing the total number of security sensitive decisions your team needs to make correctly, a reduction in risk surface, not a guarantee.
For developers starting a new Rails 8 project, the decision comes down to the same fundamentals. Rails 8 has continued strengthening built in tools like generate_token_for, making custom authentication meaningfully easier to build correctly than a few years ago, narrowing though not eliminating the speed gap. Applications with a significant API surface sometimes lean toward lighter, custom authentication instead of a full Devise install, especially when browser focused view generation is not needed. Security expectations remain the same regardless of version.
Application complexity and maintenance capacity remain the deciding factors. A straightforward Rails 8 app with typical user accounts is usually well served by Devise. An app with unusual requirements, or a team ready to maintain full control long term, may reasonably choose custom authentication built on has_secure_password.
Teams occasionally migrate away from Devise to reduce dependency surface or gain control over specialized requirements. This deserves careful planning, not a quick refactor. User records generally transfer without issue, since Devise's password hashes are bcrypt based, the same algorithm has_secure_password uses, though verify the exact hash format. Sessions need rebuilding around your new authentication concern, and password reset or confirmation flows need custom implementations if you relied on Devise's modules for them. A staged rollout, validated thoroughly before removing Devise, is far safer than a single cutover.
The reverse migration follows a similar shape. Existing users need mapping onto Devise's expected schema, adding columns your enabled modules require. Password handling is usually straightforward if your custom system already used bcrypt through has_secure_password, since Database Authenticatable expects the same hash format. Sessions will need invalidating during the transition, and custom authentication logic scattered across controllers should be replaced with Devise's helpers. Thorough testing and a gradual rollout remain the safer path here too.
Recommend Devise when:
Consider custom authentication when:
For most Rails applications with standard user accounts, Devise remains the practical default. Moving away from it should be a deliberate decision driven by real requirements, not a general preference for building things yourself.
Consider a Rails 8 SaaS app needing registration, login, password reset, and protected dashboard pages. With Devise, rails generate devise User produces a User model with modules included, plus sessions, registrations, and passwords controllers you can override, and devise_for :users expanding into a full route set. With custom authentication, you write the User model with has_secure_password, a SessionsController, RegistrationsController, and PasswordResetsController by hand, and define routes like resource :session explicitly.
Both ultimately rely on the same Rails session mechanism and the same bcrypt backed password hashing. Devise uses authenticate_user! as a before_action; custom authentication uses an equivalent method from a shared concern, functionally identical. Devise provides sign_in test helpers; custom authentication tests post directly to your session endpoints, as shown earlier.
The trade off is clear once you build both. Devise gets you to a fully featured system faster with less code in your own repository. Custom authentication takes longer to reach the same feature set, but leaves a smaller, fully understood codebase where every line exists because your team wrote it deliberately. If you are building an API rather than a traditional browser app, our guide on securing a Rails API covers token-based patterns that pair well with the custom approach shown here.
Is Devise still good for Rails 8? Yes. Devise continues to be actively maintained and works well with Rails 8 applications that need standard authentication features.
Is Devise better than custom authentication? Neither is universally better. Devise is generally faster for standard needs, while custom authentication offers more control for specialized requirements.
Is Devise secure? Devise uses secure practices like bcrypt hashing by default, but security also depends on configuration and maintenance. It is not automatically secure regardless of setup.
Can I build authentication without Devise? Yes. Rails' has_secure_password, combined with sessions and secure token generation, is enough to build a solid custom authentication system.
What is has_secure_password in Rails? A built in Active Record method that adds secure password hashing and authentication to a model, using bcrypt, without requiring manual hashing.
Should I use Devise for a new Rails application? If your app needs standard authentication features and you want to move quickly, Devise is a reasonable default. If your needs are specialized, custom authentication may fit better.
Is custom authentication more flexible than Devise? Often yes, since you control every part of the implementation, though Devise can also be customized significantly.
Does Devise handle authorization? No. Devise handles authentication only. Authorization requires a separate tool like Pundit or CanCanCan.
Can Devise be used with Rails APIs? Yes, though many teams building token based APIs choose a lighter custom authentication approach instead.
What is the simplest way to authenticate users in Rails? For a minimal app, a custom system built with has_secure_password and Rails sessions is often simplest. For a fuller feature set, Devise provides that with less custom code.
Devise and custom authentication are both valid, well established ways to solve the same problem. Devise gives you a fast, feature rich, actively maintained solution that fits standard needs well. Custom authentication, built on secure tools like has_secure_password, gives you full control and a codebase where every decision was made deliberately.
Neither approach is automatically more secure, and neither is automatically the right choice. For most applications with standard requirements, Devise remains the practical default, reducing development time and the number of security sensitive decisions your team must get right. Custom authentication earns its place when requirements are genuinely specialized, and your team is ready for the ongoing responsibility of owning authentication code long term.
Let security, maintainability, and your application's actual requirements drive the decision, not familiarity or a general preference for one approach over the other. Both, implemented carefully, can serve your application's foundation well.