Rodauth is a full-featured authentication framework for Ruby, built on the Roda web toolkit and the Sequel database library, and you can use it in Rails through the rodauth-rails gem. What sets it apart is how much it does out of the box: multifactor authentication, passkeys, JSON API support, password complexity rules, and account lockout are all first-class features rather than add-ons. For security-critical and enterprise Rails applications, that completeness is the whole argument.
The reason this guide exists in 2026 is that the ground shifted. Rails 8 shipped a built-in authentication generator, so the old reflex of "just use Devise" is now a three-way decision: the native Rails 8 generator, Devise, or Rodauth. Each is the right answer for a different kind of project, and choosing well matters because authentication is foundational and switching it mid-product is one of the more painful migrations a team can take on.
We have been Rails-only for over 15 years, and we use Rodauth in our own production work, so this is a practitioner's read rather than a survey. We will be specific about where Rodauth is the right call, and equally specific about where Devise or the Rails 8 generator fits better.
The 2026 Rails Authentication Landscape: Three Options
There are three credible ways to handle authentication in a modern Rails app, and they sit at different points on the spectrum from minimal to comprehensive.
The Rails 8 built-in generator is the new minimal option. Running the generator gives you a session-based login, password reset, and the supporting models, all in code you own and can read in an afternoon. It deliberately ships without registration, email confirmation, multifactor authentication, or OAuth. That restraint is a feature for straightforward apps and a limit for security-critical ones. The full picture of what Rails 8 changed is in Ruby on Rails 8 features: performance, security, and developer experience updates.
Devise is the incumbent, and it earned that position. It is comprehensive, battle-tested across more than a decade of production use, and supported by a deep ecosystem. The trade-offs are real: it adds significant code and convention, it is highly opinionated, and extending it to do MFA, passkeys, or password complexity means stacking additional gems on top.
Rodauth is the most feature-complete and security-forward of the three. Multifactor authentication, WebAuthn and passkeys, password complexity and expiration, account lockout, and standardized JSON API support are built in. Here is how the three compare.
Why Choose Rodauth Over Devise
The case for Rodauth comes down to features that are native rather than bolted on, which matters most when security and compliance are non-negotiable.
Multifactor authentication is built in, with TOTP authenticator apps, SMS codes, and recovery codes available as configuration rather than as a separate integration. WebAuthn and passkeys are supported natively, which is increasingly table stakes as the industry moves toward passwordless login. For API-first and mobile-backed applications, Rodauth provides standardized JSON and JWT support for every authentication feature, not just login, so a React frontend or a native app talks to the same auth system the same way for every flow.
The enterprise security features are where Rodauth pulls clearly ahead. Password complexity rules, disallowing password reuse, password expiration, session expiration, single-session enforcement, and account expiration are all available out of the box. Retrofitting these onto a minimal foundation after the fact is painful work, and having them as configuration flags is a genuine advantage for fintech, healthcare, and other regulated contexts.
The honest counterpoint: Devise still wins on familiarity and ecosystem. If your team already knows Devise, your app fits its conventions, and you are not blocked by its limits, the pragmatic choice is often to stay. Rodauth's advantage shows up specifically when you need the security features it provides natively. If you want senior eyes on which way to go, our free Rails code audit reviews your current setup and reports back on architecture, performance, and security in two to three days.
The Sequel Question, and Why It Is Not a Dealbreaker
The single most common reason teams dismiss Rodauth is that it uses Sequel rather than Active Record, and that objection dissolves once you understand how rodauth-rails handles it. Rodauth is built on Sequel, a different database library from the Active Record ORM that Rails uses. On its face that sounds like running two database layers, which nobody wants.
In practice, rodauth-rails configures Sequel to reuse Active Record's existing database connection. You are not opening a second connection pool or managing two sets of credentials. There is one connection, shared. You can also call Active Record code directly from inside your Rodauth configuration, so your Account model and the rest of your domain stay in Active Record exactly as they are. The Sequel dependency sits underneath Rodauth and stays out of your way. Once that clicks, the supposed dealbreaker turns out to be an implementation detail.
Getting Started: Installing Rodauth in Rails
Setup runs through the rodauth-rails gem and a generator, and the whole flow takes minutes. Add the gem to your Gemfile and run the installer.
The generator creates the core pieces: a Rodauth app that plugs into the middleware stack, a configuration file where you enable and tune features, an Account model, and a migration for the accounts and supporting tables. You run the migration as usual with bin/rails db:migrate.
You choose your session strategy at install time. The default is cookie-based sessions, which suits server-rendered Rails apps. For API-first applications you can generate a JWT-based setup instead, so tokens carry the session for mobile clients and single-page frontends. Password hashing uses bcrypt by default, and Rodauth also supports Argon2 if your security requirements call for it. Enabling features is a matter of listing them in the configuration:
ruby# app/misc/rodauth_main.rbclass RodauthMain < Rodauth::Rails::Auth
configure do
enable :create_account, :verify_account, :login, :logout,
:reset_password, :otp, :recovery_codes, :webauthn
# password rules, MFA, and session policies are configured here
end
end
If you are moving to Rails 8 and rethinking authentication at the same time, that combination is exactly the kind of modernization we scope and execute on our Rails upgrade service.
Authentication Features in Practice
Beyond login, Rodauth covers the full lifecycle of an account, and the features compose cleanly. Account creation supports email verification with a grace period, so a new user can start using the app while their verification is pending rather than hitting a wall. Password login is the default path, and passwordless or email-based authentication is available when you would rather not store passwords at all.
Multifactor setup is a configuration step rather than a project. Turn on the otp feature for authenticator apps, add recovery_codes for backup access, and sms_codes if you want SMS as a factor. Session management is where the compliance-relevant controls live: session expiration after inactivity, single-session enforcement so one account cannot be used from several places at once, and account lockout after repeated failed attempts. These are the details that come up in a security review, and having them available as settings rather than as custom code is the practical payoff.
OAuth and Social Login With rodauth-omniauth
Adding social login, signing in with Google or Facebook, is handled through the rodauth-omniauth gem, which bridges Rodauth and the established OmniAuth ecosystem. This is also where Rails OAuth fits into a Rodauth setup. Rather than treating third-party login as a separate subsystem, rodauth-omniauth lets an external provider create or authenticate a Rodauth account, so social login and password login share one account model and one set of session rules. For apps that combine an API with social sign-in, pairing this with the patterns in the ultimate guide to Ruby on Rails API development keeps the whole auth surface consistent.
JSON API and JWT for API-First Apps
For mobile backends and single-page frontends, Rodauth exposes every authentication feature over a JSON API, which is rarer than it sounds. Many authentication solutions handle API login and then leave you to build the rest, password reset, MFA enrollment, account verification, by hand. Rodauth's JSON support is standardized across every feature, so the same client talks to the same endpoints in the same shape for every flow.
Token-based authentication uses JWT, configured at install or enabled afterward, so a React or native client carries a signed token instead of a cookie. The reason standardized API support matters is consistency: when MFA enrollment and password reset work over JSON the same way login does, your mobile and web clients share one mental model and one integration, which is far less code and far fewer edge cases to get wrong.
When Rodauth Is the Right Choice, and When It Is Not
Rodauth is the right call for security-critical applications, and the wrong one for genuinely simple needs, so match the tool to the requirement honestly.
Choose Rodauth when the application handles sensitive data or operates under compliance expectations: fintech, healthcare, government-adjacent work, or any enterprise product where MFA, passkeys, password policies, and account controls are requirements rather than nice-to-haves. It is also the strongest fit for API-first products that need consistent JSON and JWT authentication across mobile and web.
Reach for something else when the requirements are modest. If a session-based login and password reset are genuinely all you need, the Rails 8 generator is the cleaner choice and you own every line. If your team already runs Devise productively and its limits are not blocking you, the cost of switching is rarely worth it. Rodauth also has a steeper learning curve than either alternative, which is a real consideration for a small team on a tight timeline. If authentication is central to your product and you want senior security judgment on the decision, our Ruby on Rails development team has a security-forward approach and has been Rails-only for over 15 years.
Migrating to Rodauth
Switching authentication frameworks is a serious migration, and it deserves a methodical plan rather than a weekend. Moving from Devise or a legacy setup to Rodauth means migrating password hashes, which Rodauth can verify on the fly so existing users are not forced to reset, mapping existing accounts to Rodauth's schema, and re-implementing flows that were customized in the old system. None of it is exotic, but all of it touches the most sensitive part of the application, the part where a mistake locks users out or, worse, lets the wrong ones in.
This is the kind of work that benefits from doing it carefully and in stages, the same way we approach version upgrades in upgrading a Rails application from 7.0 to 7.1. If you want senior security and architecture judgment on an authentication migration without adding a full-time hire, our Fractional CTO service is structured for exactly that, led by co-founders, with you owning all the code.
Frequently Asked Questions
What is Rodauth and how is it different from Devise? Rodauth is a full-featured authentication framework for Ruby, built on Roda and Sequel and usable in Rails via the rodauth-rails gem. The main difference from Devise is that security features like multifactor authentication, passkeys, password complexity, and JSON API support are built in rather than added through extra gems. Devise is more familiar and has a larger ecosystem; Rodauth is more feature-complete and security-forward.
Does Rodauth work with Active Record? Yes. Although Rodauth is built on Sequel, the rodauth-rails gem configures Sequel to reuse Active Record's existing database connection, so there is a single shared connection rather than two. Your models stay in Active Record, and you can call Active Record code directly from your Rodauth configuration.
Is Rodauth better than the Rails 8 authentication generator? It depends on the requirements. The Rails 8 generator is an excellent minimal foundation you fully own, ideal when you only need login and password reset. Rodauth is the better choice when you need multifactor authentication, passkeys, OAuth, JSON API auth, or enterprise security policies, none of which the Rails 8 generator includes out of the box.
Does Rodauth support multifactor authentication and passkeys? Yes, both natively. Rodauth includes TOTP authenticator apps, SMS codes, and recovery codes for multifactor authentication, and it supports WebAuthn and passkeys for passwordless login. These are configuration options rather than separate integrations, which is a core reason teams choose Rodauth for security-critical applications.
Can I use Rodauth for API and JWT authentication? Yes. Rodauth provides standardized JSON API support for every authentication feature, not just login, and supports JWT for token-based authentication. That makes it a strong fit for mobile backends and single-page application frontends, where consistent API behavior across login, password reset, and MFA enrollment matters.
Is Rodauth hard to learn? Rodauth has a steeper learning curve than Devise or the Rails 8 generator, mostly because it is built on Roda and Sequel and uses a configuration-driven approach that is unfamiliar at first. The payoff is that advanced security features are available as settings rather than custom code. For a small team on a tight timeline, the simpler options may be the better call.
