Give people more ways to sign in, manage their devices, and confirm sensitive changes. Latchkey adds these tools to the authentication code Rails already generates.
This page describes 0.2.0.dev. The features below have implementation and local test coverage; release checks and real deployment validation are still open. The documented development changes are not yet published as a gem or fully available in the public repository. Setup requires a development checkout containing this work. See release status before trying it.
More ways to sign in
Keep the login you have
Use the password on your app’s existing user account. Latchkey builds on Rails’ generated User and Session models.
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.
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; Latchkey verifies the result.
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
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 →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.
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.
Tell people what changed
Send notices for passkey, recovery, and policy changes. Your app supplies mail delivery; Latchkey 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
latchkey: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. Latchkey does not supply a signup flow, social login, or API access tokens.
Next: prove the release in real use
The next work is release validation for the implemented features. It includes checking actual mail and captcha providers, more real devices and browsers, keyboard and accessibility behavior, deployment operations, and all enabled journeys in an adopter’s app.
Remote CI and security checks, release notes, and a successful RubyGems publication must also pass. Local tests do not establish those results. There is no committed release date.
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
- Latchkey-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. Public source updates may lag this unreleased development snapshot.