Give people more ways to sign in, manage their devices, and confirm sensitive changes. AddAuth adds these tools to the authentication code Rails already generates.
The features below describe 0.2.0.dev. Install add_auth from RubyGems through your Rails app’s Gemfile. Version 0.2.0.dev is not yet published, so installation will be available after that release. See release status before installing.
More ways to sign in
Passwords
Keep the login you have
Use the password on your app’s existing user account. AddAuth builds on Rails’ generated User and Session models.
Email links
Open an email, then confirm
Send a short-lived, single-use sign-in link. A person confirms the sign-in; a mail scanner opening the link does not use it up.
Passkeys
Sign in with a device or key
Use a passkey unlocked by a fingerprint, face, device PIN, or security key. The browser handles the prompt; AddAuth verifies the result.
Passkey management
Add, name, and remove keys
Let people recognize their saved passkeys and remove ones they no longer use. Checks prevent removal of the last usable sign-in method under the account’s policy.
For the first working example, follow the password and email quickstart. Passkeys need a supported browser and JavaScript. Password and email flows support ordinary page navigation without JavaScript when the account’s policy and configured bot checks allow it.
More control over an account
Sessions
See and end sign-ins
A session is one signed-in browser. List sessions, sign out another browser, or end them all after confirming identity; also set idle and total time limits.
Explore sessions →Reauthentication
Confirm it is still you
Ask people to verify again with their password, an email link, or a passkey before a sensitive action. This “step-up” check applies to a named action, such as managing passkeys, and your app checks it again before saving the change.
Recovery
Replace a lost passkey
Default recovery uses an email address your app has verified to authorize a replacement passkey. An optional strict account policy disables email and password fallback, so recovery needs a remaining passkey or your app’s support process.
Security emails
Tell people what changed
Send notices for passkey, recovery, and policy changes. Your app supplies mail delivery; AddAuth records pending messages and supports retries.
Recovery codes are a future consideration, not an extra fallback in the current strict policy. A recent sign-in also does not automatically authorize every sensitive action.
Tools for the app you are building
- Optional bot checks. Connect Cloudflare Turnstile or Google reCAPTCHA. A failed check and a provider outage have distinct results. Configure captcha.
- Pages you can change. Use the included styles, map your own CSS classes, or copy views, controllers, JavaScript, and email templates into your app. This copying is called ejection. Customize the pages.
- Upgrade checks. Run
add_auth:doctorto find missing setup and differences between copied templates and a newer gem. It reports changes for you to review; it does not overwrite your work. - Test helpers. Exercise delivered email links and passkey flows with a virtual authenticator—a test device simulated by the browser.
Your app still creates accounts, decides who may sign in, checks permissions, and runs its database, mail, cache, and job queue. AddAuth does not supply a signup flow, social login, or API access tokens.
Release and upgrade information
The first RubyGems prerelease is pending. Check release status for installation availability and release notes. A stable release date has not been announced.
Future features under consideration
These are the roadmap’s topics to reassess after v1 usage. They are not available now or promised for a particular release.
- More account-management flows
- AddAuth-owned signup, password reset, email confirmation, lockout, and password rules. Today your host app supplies these, including Rails’ existing reset flow.
- Recovery codes
- Single-use backup codes to save before losing access to a device.
- Separate login areas
- Different authentication setups for groups such as customers and staff. The roadmap calls these “realms” or routing scopes.
- A password-hashing adapter
- A defined way to swap how password hashes are created and checked, following the Rails support available at the time.
API/token authentication may be revisited after v1; it is outside the current scope. The gem roadmap remains the progress checklist.