OneTap — instant login for returning users
OneTap logs your returning users in instantly — no OTP, no code to type. After a user verifies once, QuickAuth silently trusts their device for a window you choose (1–30 days). Their next login is verified automatically, and any unrecognised device falls back to the normal OTP flow — so no one ever hits a dead end.
Why it matters
| Benefit | Impact |
|---|---|
| Faster logins | Returning users are in with zero taps — no waiting on an SMS/WhatsApp code |
| Higher conversion | Every OTP screen loses some users; OneTap removes it for trusted devices |
| Lower cost | Fewer OTPs sent on repeat logins = lower messaging spend |
| Better UX | Feels like “stay logged in”, but securely re-verified on each visit |
How it works
- First login: the user enters the OTP once → verified. QuickAuth quietly issues that device a secure, opaque trust token, stored by the SDK in the platform's secure storage.
- Next login: the SDK presents that token automatically → the backend confirms it → the user is logged in instantly, with no OTP.
- After the window (of inactivity) or on a new device → a normal OTP, which resets the clock. Every login slides the expiry forward.
First login (device not yet trusted):
initiate({phone}) ─► OTP_SENT ─► submitOtp(code) ─► VERIFIED
(SDK silently stores a trust token)
Return login (device trusted, within the window):
initiate({phone}) ─► VERIFIED ◄── no OTP, no code. Silent.Turn it on
- In your Dashboard → Merchants → OneTap, enable OneTap and pick the trust window (1–30 days; default 7).
- Make sure your app uses the latest QuickAuth SDK. No code changes are required — OneTap works through your existing login flow; returning users simply start getting verified instantly.
SDK integration
OneTap is transparent: you call initiate() as usual and handle the VERIFIED event — which now sometimes arrives without an OTP step. The SDK attaches the stored trust token on initiate and stores the new one on VERIFIED; you never touch the token yourself.
import { QuickAuth } from '@quickauth/web'
QuickAuth.init({
publicKey: 'qa_live_***',
onAuthEvent: (event) => {
switch (event.type) {
case 'OTP_SENT': showOtpInput(); break // normal path — ask for the code
case 'VERIFIED': finishLogin(event.requestId); break // OneTap OR OTP — same handler
case 'OTP_FAILED': showError(); break
}
},
})
// Same call every time. If the device is trusted → VERIFIED fires with no OTP.
await QuickAuth.auth.initiate({ phone: '+919876543210', channel: 'auto' })
// Only reached on the OTP_SENT path:
await QuickAuth.auth.submitOtp('123456')
// Logout — forget the trusted device so the next login needs a fresh OTP:
QuickAuth.auth.reset({ forgetDevice: true })Same “login succeeded” path
VERIFIED can arrive straight from initiate() (OneTap) — so treat it as your single success path and forward requestId to your backend to confirm server-to-server, exactly as with a typed OTP.
Privacy & security
- Opaque token, hashed at rest. The trust token is a random 256-bit value — not a password or personal data. Servers store only a one-way SHA-256 hash; the raw token is never persisted.
- One device at a time. Verifying on a new device automatically revokes the previous device's trust for that number — a stolen old device can't silently log in.
- Auto-expiry. Trust slides forward with use and expires after your chosen window of inactivity, forcing a fresh OTP.
- Consent-first. Optional device details (for the trusted-device record) are sent only after the user grants consent, are minimal, and are never used in the security decision — audit information only. DPDP / GDPR-safe by default.
- Same audit trail. Every login (OneTap or OTP) is recorded and reported the same way; OneTap is tagged as its own channel in analytics.
FAQ
What if the user reinstalls the app? A fresh install has no token, so they verify one OTP, then OneTap resumes.
What if a phone is lost? Logging in on the new device revokes the old one automatically. You can also disable OneTap for the account anytime in the dashboard.
Does it cost the same as an OTP? A OneTap login is billed like a standard OTP (and shown separately in analytics), but you save on the OTPs it replaces for repeat logins.
Can we control how long a device stays trusted? Yes — set the 1–30 day window in the dashboard; every login extends it.