How the server verifies an OTP it never stored

TOTP is not a row in a database. The device and the server share a secret, both compute a code from the current time, and the server checks they match.

How the server verifies an OTP it never stored

Interview version: the code is valid for 60 seconds. The server never stores that code. How does it know the user typed the right one?

It is not magic, and it is not “the server stores nothing.”

The OTP is not stored. The shared secret is.

What both sides compute

When you set up an authenticator app, the server and the phone agree on a secret (usually shown once as a QR code).

After that, the app does not wait for an SMS. Every time step (commonly 30 seconds) it computes:

code = HMAC(secret, current time step)

When you submit the six digits, the server runs the same function with the same secret and the current time step.

If they match, you are in. The server may also accept the previous or next step so a slightly slow clock still works.

No lookup of “the OTP we sent you.” There was no OTP to send. Both sides independently arrived at the same number.

This is TOTP — time-based one-time password. It is what most authenticator apps implement.

Why this design exists

- The code dies when the time window moves on. Capturing one code is a short-lived problem.
- There is no “OTP table” to leak for that login.
- The phone works offline.

What you *do* protect is the secret: treat it like a password hash. If the secret leaks, an attacker can mint codes until you rotate it.

Takeaway

The server is not remembering your last code. It is repeating the math.

Store the secret. Never treat the six digits as something you persist. Verify on a time window, not on a row.