Use case
Device authentication: skip the second factor on a trusted device
Asking every user for a second factor on every sign-in is safe and tiring. Device authentication asks only when the context changes. FingerPrint Checker gives each browser and app install a visitor ID, so your server can tell a device this account has used before from a new one, and add the network and app evidence that says when to ask for more.
The problem
A second factor on every login costs you completed sign-ins and support tickets, and users learn to approve prompts without reading them. A cookie that says “remember this device” is lost when the cookie is cleared and can be copied along with a stolen session.
What you can recognise
The visitor ID points at a browser or an app install, not at a person. Treat it as one piece of evidence about the device.
- A returning device: the visitor ID is the same as one you have already tied to this account.
- A new device for this account, even if the password is right.
- A risky network for the visit: VPN, proxy, Tor or a hosting network.
- A browser that was altered to hide the visitor, or a bot driving the sign-in.
- In your own app: a rooted or jailbroken device, or a hooking tool attached. These are recorded and returned but not scored yet, so they act only through your own code and rules.
How to build it
- Identify on the sign-in page and set your user ID as linkedId, then send the event ID to your backend with the credentials.
- Read the event with your secret key (GET /v1/events/{eventId}) to get the visitor ID and the signals. Browsers and apps never see the signals.
- Keep your own table of visitor IDs seen per user. After a successful step-up, add the new visitor ID to it.
- Look up a device later with GET /v1/visitors/{visitorId}, or search events by linkedId to review a user’s devices.
- Receive the same events as signed webhooks, and write custom rules for what your project should always ask or refuse.
Keep the friction where it belongs
Most sign-ins come from a known device on an ordinary network and need nothing extra. Ask for a second factor on a new device or a risky combination, and prefer a step-up to a refusal: many honest users travel or use a VPN.
Skip the second factor on a trusted device
// Server side, after the password check passed
if (!/^ev_[0-9A-HJKMNP-TV-Z]{20}$/.test(eventId)) throw new Error('bad eventId'); // fail closed: ask for the second factor
const r = await (await fetch(`https://api.fpchecker.com/v1/events/${eventId}`, {
headers: { 'X-Secret-Key': process.env.FPCHECKER_SECRET_KEY },
})).json();
if (!r.visitorId) throw new Error(r.error ?? r.reason); // fail closed: ask for the second factor
if (r.eventId !== eventId || !(Date.now() - Date.parse(r.createdAt) <= 5 * 60_000)) throw new Error('stale or reused event');
if (!(await markEventUsed(eventId))) throw new Error('stale or reused event'); // your store: true only the first time
const s = r.signals ?? {};
const trusted = await db.hasDevice(user.id, r.visitorId); // your own table of visitor IDs per user
const risky = s.vpn?.result === true || s.proxy?.result === true || s.ip?.tor === true || s.bot?.result === 'bad' ||
s.mobile?.rooted === true || s.mobile?.hooked === true; // mobile fields are evidence only, null means unknown
if (trusted && !risky) return finishLogin(user); // skip the second factor
await requireSecondFactor(user);
await db.addDevice(user.id, r.visitorId); // only after the second factor passedFrequently asked questions
How is this different from MFA?
MFA proves that the person has another factor. Device authentication tells you whether this is a device the account has used before and in what context, so you can decide when to ask for that factor. It lowers how often you ask; it does not replace the factor.
What does it change for real users?
A user on a known device signs in with no extra step. The extra step appears on a new device or a risky combination, and once the user passes it the device is remembered by your server.
What if an attacker has the correct password?
Then the attacker is on a device the account has never used, so your server asks for the second factor. An attacker who also controls a device you already trust is not stopped by this alone, which is why a high-risk action should still ask again.
Does it work for the whole session or only at login?
You choose. Read the event at login, and again before sensitive actions such as changing a password or withdrawing money, by identifying again and comparing the visitor ID with the one the session started with.
Does it replace my authentication provider?
No. Your provider still checks passwords and factors and issues the session. FingerPrint Checker adds device and network evidence that your server uses to decide when to ask.
Try it on your own sign-up flow
Every new account gets 2,000 free checks. No card required.