# rodauth-rails bolts Rodauth onto a Rails app as middleware

> rodauth-rails is the Rails integration for the Rodauth authentication framework, and it works by inserting a Rodauth app as middleware ahead of the Rails router, with an install generator that creates the app, the configuration and the migration. The trade is that authentication lives in a separate Roda stack rather than in Rails controllers.

**janko/rodauth-rails** — Rails integration for Rodauth authentication framework

- Repository: https://github.com/janko/rodauth-rails
- Website: https://github.com/jeremyevans/rodauth
- Stars: 758 · Forks: 48
- Language: HTML
- License: MIT
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/janko-rodauth-rails

## Authentication runs in a Roda app, not in Rails controllers

The design decision that defines this library is that Rodauth is not implemented as Rails controllers. The README states that the Rodauth app is called for each request before it reaches the Rails router, handles requests to Rodauth endpoints, and lets you call additional code before your main routes. The middleware listing shows the order, with Rodauth::Rails::Middleware calling the Rodauth app and then the application's own routes running afterwards. The consequence shows up immediately in your workflow: because the endpoints are handled by Roda, the Rodauth routes do not appear in rails routes at all. The library compensates with a rake task that prints the endpoint list for the features currently loaded, which is the tool you will use constantly instead.

## The install generator creates the app, the config and the migration

Getting started is a gem add and a generator, and the generator does most of the work. The README says it creates a Rodauth app and configuration with common authentication features enabled, a database migration with the tables those features need, and a few other files. After that you are invited to remove any features you do not want along with their corresponding tables, which is a good sign about how the library is built: features are opt-in and their schema is separable. The three commands in sequence are:```sh
$ bundle add rodauth-rails
$ rails generate rodauth:install
$ rails db:migrate
```The generator also takes options that shape the install rather than something you configure afterwards. You can pass a table name instead of the default accounts table, you can ask for JSON API exposure with either cookie-based or JWT-based authentication, and you can switch the password hashing to Argon2 instead of bcrypt. The README does not document every flag, so the generator help is the reference.

## Finding the endpoints when rails routes comes up empty

The route visibility problem has a dedicated answer, and it is the rodauth:routes rake task. The README explains that it shows the list of endpoints based on currently loaded features, and the sample output is a table of Rodauth path helpers with their HTTP verbs and named routes:```bash
Routes handled by RodauthApp:

                   login  GET|POST  /login                   rodauth.login_path
          create_account  GET|POST  /create-account          rodauth.create_account_path
   verify_account_resend  GET|POST  /verify-account-resend   rodauth.verify_account_resend_path
          verify_account  GET|POST  /verify-account          rodauth.verify_account_path
         change_password  GET|POST  /change-password         rodauth.change_password_path
            change_login  GET|POST  /change-login            rodauth.change_login_path
                  logout  GET|POST  /logout                  rodauth.logout_path
                remember  GET|POST  /remember                rodauth.remember_path
  reset_password_request  GET|POST  /reset-password-request  rodauth.reset_password_request_path
          reset_password  GET|POST  /reset-password          rodauth.reset_password_path
     verify_login_change  GET|POST  /verify-login-change     rodauth.verify_login_change_path
           close_account  GET|POST  /close-account           rodauth.close_account_path
```What that table gives you is not just a reference. It is the actual enabled feature set, because an endpoint only appears if the feature behind it was turned on during install. A login and a logout route in the list means those features are active, and an absent route means the feature was removed from the configuration. The named helpers such as rodauth.login_path and rodauth.create_account_path are the same helpers the navigation markup uses, which is why the two fit together. The pages themselves are fully functional when you visit them, and the shipped templates use Bootstrap markup, so the out-of-the-box experience is a complete login, sign up and password management flow rather than a stub.

## Wiring sign in and sign out into a Rails view

Because the routes are named, putting authentication into a layout is a matter of a small conditional in an ERB template. The README shows the shape, checking whether the Rodauth object reports a logged in session and offering a sign out button or sign in and sign up links accordingly:```erb
<% if rodauth.logged_in? %>
  <%= button_to "Sign out", rodauth.logout_path, method: :post %>
<% else %>
  <%= link_to "Sign in", rodauth.login_path %>
  <%= link_to "Sign up", rodauth.create_account_path %>
<% end %>
```The Rodauth object is the entry point for that check, and it also exposes a rails_account method that returns a model instance of the currently logged in account. The README suggests wrapping that in a helper method for easy access from controllers and views, and the sample it begins to show is a private current_account method on ApplicationController. Because the account object is a model, application code can read account attributes directly rather than going through a session hash, which is a cleaner arrangement than many Rails session-based approaches.

## Why the feature list is longer than Devise's

The README sets out the case for Rodauth by naming the alternatives it is meant to replace, Devise, Sorcery, Clearance and Authlogic, and then listing what it claims as advantages. Multifactor authentication appears first, with TOTP, SMS codes, recovery codes and passkeys all supported. Then there is standardized JSON API support for every feature including JWT, so an API client and a browser client get the same endpoints rather than a separate API controller set. The enterprise security block covers password complexity, disallowing password reuse, password expiration, session expiration, single session and account expiration. Passwordless authentication by email and by passkey is there too, along with audit logging for any action. The one worth dwelling on is the ability to protect password hashes even in the case of SQL injection, which is a structural property rather than a setting.

## Sequel underneath, with Active Record's connection reused

The most common objection, and the README raises it first among the concerns, is that Rodauth uses Sequel for database interaction rather than Active Record. The answer given is that rodauth-rails configures Sequel to reuse the Active Record database connection, which makes it run smoothly alongside Active Record and even allows calling Active Record code from within Rodauth configuration. The conclusion the README draws is that Sequel can be treated as an implementation detail. That is a fair position for an application that stays inside Rodauth for its authentication concerns. The place to press on it is a mixed codebase that has its own Sequel models, or a team that wants one query layer everywhere, because the documentation here covers the Active Record case rather than the reverse arrangement. The configuration DSL is described as uniform, with before and after hooks around everything, which is what makes the individual features composable.

## Wider coverage for the API side, and where the gaps are

Rodauth itself is a framework, and this repository is only the Rails adapter, so the coverage question has two layers. For the framework, the README points to the Rodauth documentation, a Rails demo application, a JSON API guide and an OmniAuth guide in the project wiki, plus a Postman collection for JSON requests. There are also screencasts on Rails authentication with Rodauth, multifactor authentication by TOTP and by recovery codes, adding admin accounts, and integrating passkeys into Rails, and a set of long-form articles covering the same ground in text. For the adapter, the README documents installation, the middleware position, the route listing, the account helper and the JSON and JWT install options, and it does not document a rollback procedure, a version compatibility matrix between the gem and Rodauth itself, or how to migrate existing user accounts into a Rodauth accounts table. Those are the questions to raise before committing to it, and the CHANGELOG.md at the root of the repository is where version-level answers will be.

## Conclusion

rodauth-rails suits a Rails application that needs features the mainstream Rails authentication gems tend to leave out, in particular multifactor authentication, standardized JSON API support and audit logging, and it suits teams that accept Rodauth running as a separate Roda app in front of the router. It does not suit a codebase that wants authentication expressed as ordinary Rails controllers, because the endpoints are handled by Roda and never appear in rails routes. Before adopting, run the rodauth:routes rake task to see the endpoints your enabled features actually expose, decide between the cookie-based and JWT install options, and read the CHANGELOG.md before upgrading, since the last push to the repository was on 2026-10-11 and the current release is v2.2.3.

## FAQ

### How do I install rodauth-rails in a Rails app?

Add the gem with `bundle add rodauth-rails`, run the install generator with `rails generate rodauth:install`, then run the migration with `rails db:migrate`. The generator creates the Rodauth app, the configuration with common features enabled, and a database migration for the tables those features need.

### Why do the Rodauth routes not appear in rails routes?

The Rodauth endpoints are handled by Roda before the request reaches the Rails router, so they are not Rails routes. Use the `rails rodauth:routes` rake task to list the endpoints for the features currently loaded.

### Can rodauth-rails expose authentication over a JSON API?

Yes. The install generator has a --json option for cookie-based authentication and a --jwt option for token-based authentication, and the README states that every feature has standardized JSON API support including JWT.

### Does rodauth-rails require Sequel instead of Active Record?

No. rodauth-rails configures Sequel to reuse Active Record's database connection, so the two run alongside each other and you can call Active Record code from within Rodauth configuration. The README frames Sequel as an implementation detail of Rodauth.

### Which multifactor authentication methods does Rodauth support in Rails?

The README lists TOTP, SMS codes, recovery codes and passkeys under multifactor authentication, plus passwordless sign-in by email and by passkey. There are screencasts and articles covering TOTP and recovery codes in particular.

## Sources

- [janko/rodauth-rails on GitHub](https://github.com/janko/rodauth-rails)
- [License: MIT](https://github.com/janko/rodauth-rails/blob/main/LICENSE)
- [Project website](https://github.com/jeremyevans/rodauth)
- [README](https://github.com/janko/rodauth-rails/blob/main/README.md)
- [Releases](https://github.com/janko/rodauth-rails/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/janko-rodauth-rails