Release status

Check which AddAuth version you can install and whether it is suitable for your app.

Where to install AddAuth

Install the add_auth gem from RubyGems through Bundler in your Rails app. The quickstart shows the Gemfile entry, generators and configuration. The GitHub repository is the source and issue tracker; an application installation does not require a repository checkout.

Which version these docs cover

0.5.1 targets Ruby 3.3+ and Rails 8.0+. It includes password, email-link and passkey sign-in, session management, reauthentication, recovery optional captcha, account lifecycle, bounded Devise migration, provider-library integration and finite native sessions. See features and roadmap for the available behavior and what your app supplies.

This is a pre-1.0 release. Review release notes and generated integration changes, then follow the upgrade rehearsal and test your app’s enabled sign-in methods. The compatibility reference describes the documented integration surface.

Version 0.5.1 is a security hardening release, and upgrading is recommended. See what changed in 0.5.1.

Configuration and signup in 0.4.0

Version 0.4.0 adds the complete initializer and optional-confirmation setup, password-only account/step-up generation and a separate unconfirmed-password-reset policy. Required confirmation remains the default. The package bounds JSON below 3.0 for compatible Rails proof deserialization. Review the additive provisioning migration before enabling immediate signup.

UUID authentication tables in 0.5.0

Full PostgreSQL UUID sessions, UUID IDs for every generated AddAuth table, and mixed integer/UUID schemas have passed local generated-host and browser acceptance on Rails 8.0 and 8.1. The implementation uses Rails’ primary_key_type generator preference and preserves existing IDs during a package upgrade.

Local upgrade and compatible-rollback rehearsals also pass from the published 0.2.1, 0.2.2, 0.3.0 and 0.4.0 packages on both Rails lines. The rehearsal keeps integer keys and checks persisted credentials, revocations, pending mail and customized files; it does not convert an application’s key schema.

Version 0.5.0 includes this feature. Use the configuration guide for a new app and the upgrade procedure for existing installations. A gem upgrade does not convert existing integer tables to UUIDs.

Security hardening in 0.5.1

Version 0.5.1 hardens account confirmation, password lockout, sign-out everywhere and rate limiting. Upgrading is recommended. It adds no migrations or new settings. Behavior changes:

• The first email confirmation of an account with a linked sign-in provider names that provider in the email and on the confirmation page. Only an explicit “Confirm and keep” choice preserves the link; any other confirmation removes it.
• Automatic password lockout blocks only password sign-in. It no longer revokes existing sessions or blocks passkey, email-link or provider sign-in. It does not count failures for accounts that cannot use a password, and a successful password reset clears it. Manual locks are unchanged.
• “Sign out everywhere” also revokes outstanding email and account proofs (such as a pending address change), passkey and provider ceremonies, and mobile handoffs.
• Rate limits check the IP budget first and charge the identifier budget only after a configured challenge passes. Passkey sign-in option requests use their own IP budget, and passkeys.anonymous_limit now applies per IPv4 address or IPv6 /64 rather than globally.

If your app ejected AddAuth’s account or passkey controllers or views, refresh them through the normal review process. The 0.5.1 upgrade steps list the affected files.

What release testing covers

The supported Ruby 3.3/3.4/4.0 and Rails 8.0/8.1 matrix covers SQLite and PostgreSQL, fresh generated hosts, Chrome virtual authenticators, Turbo, ordinary JavaScript without Turbo and permitted no-JavaScript flows. The 0.3.0 checks also rehearse upgrades from the published 0.2.1 and 0.2.2 packages with persisted sessions, passkeys, pending mail and customized ejected files. Separate local SMTP, Redis, Sidekiq and Solid Queue tests exercise temporary mail failure, queue persistence and worker restart. Solid Cache is rejected for abuse counters; measured cleanup verifies bounded work. These checks do not establish compatibility with every physical authenticator, browser, mail provider or deployment.

Migration acceptance covers the documented Devise 5.0.4 integer/UUID source profiles, retained passwords, account restrictions, interrupted backfill and compatible rollback. Actual Android/iOS consumers were exercised against an installed package over local HTTPS. Synthetic provider fixtures do not certify live provider registrations.

The 0.4.0 checks add fresh stock and adopted-host optional-confirmation journeys, SQLite/PostgreSQL races, duplicate and failed signup handling, truthful confirmation state, and existing-schema migration checks. The release package is verified against its tag and exercised in a fresh stock Rails host. These are gem integration checks; application deployment acceptance remains the host’s responsibility.

Email branding and themes are optional host presentation. The gem’s delivery checks cover recipients, secure links, expiry, retries, cancellation and privacy.

Before using it in production

For deployment planning, read the deployment checklist, including HTTPS, mail, background jobs and a shared cache. Your app’s account policies, mail provider and supported browsers need to work together before users depend on them.

Follow availability and updates

Check the RubyGems 0.5.1 package for available packages and 0.5.1 release notes for release notes. Development progress is tracked in the gem roadmap.

For help using the gem or to report a problem, see security and support.