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.5.1. AddAuth 0.5.1 is available on RubyGems. Install the add_auth gem through your Rails app’s Gemfile. 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 records a signed-in browser or enabled native client. 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 decides who may sign in, checks resource permissions, and runs its database, mail, cache and job queue. Optional account lifecycle supplies signup and account forms; provider and native integrations share the same account policy.
Release and upgrade information
Check release status for installation availability and release notes. Review generated integration changes when upgrading a pre-1.0 release.
Optional integrations
Account lifecycle adds registration, confirmation, password reset, lock recovery and account changes. Confirmation is required by default; optional password signup can sign users in immediately while keeping their email unverified. Existing Devise apps can use the bounded migration procedure to preserve verified account and password contracts.
Provider sign-in uses maintained OAuth, OpenID Connect and JWT libraries. Your app retains provider registration, credentials, scopes, CSRF protection, middleware and failure handling. AddAuth binds verified identities to accounts without taking over unrelated provider routes or API credentials.
Android and iOS login includes finite device sessions, revocation, secure browser handoffs and optional native Apple challenges. The verified profile uses 30-day absolute and 14-day idle expiry, followed by fresh sign-in.
UUID and integer primary keys
Version 0.5.0 supports PostgreSQL UUID sessions and authentication tables through Rails’ primary-key generator preference. Existing integer and mixed schemas keep their IDs. Follow the upgrade guide for the additive migration and customized-controller review.
Future work
The gem roadmap tracks deferred capabilities and the separate 1.0 support commitment. Refresh-token families, multiple realms and general API-key management are not part of this release.