TOTP and two-factor authentication
The six-digit code that changes every half minute in the authenticator app does not come from the server, it is calculated locally from a secret shared just once during setup and the current clock, following the TOTP algorithm standardized in RFC 6238.
This is the result of dynamic truncation over the HMAC-SHA-1 output for counter 56,802,240; the code changes at the next multiple of 30 seconds, when the counter advances to 56,802,241.
The last six digits match the default code exactly because both come from the same dynamic truncation over the same HMAC, only the count of retained final digits changes.
This URI format, adopted by every authenticator app even though it is not its own RFC, is what the setup QR code encodes; any app that reads this link reconstructs the exact same parameters (secret, algorithm, digits, period) used here.
TOTP is a time-based one-time password scheme defined in RFC 6238. It generates a short code from a shared secret and the current time; that code changes every period and is used in two-factor authentication.
Because TOTP's counter is the Unix time divided by the configured period, 30 seconds by default under RFC 6238; every time that counter's integer value changes, the HMAC computed over it changes, and the truncated code changes along with it, regardless of whether a login attempt is happening at that moment.
Not exactly: the base32 secret (like `JBSWY3DPEHPK3PXP`) is just the raw data used in the HMAC calculation; the QR code encodes that secret inside a full `otpauth://` URI, which also carries the account name, the issuer, the algorithm, the digit count and the period, everything the app needs to generate matching codes.
Since TOTP exchanges no messages to stay in sync, it depends entirely on both clocks matching within a tolerance window the verifier accepts, usually one or two 30-second periods forward and back; a larger drift makes even the user's correct code get rejected, a clock-synchronization problem, not a flaw in the algorithm itself.
Not at the same level: TOTP is symmetric, the server stores the same secret used to generate the code, so whoever steals that database can generate valid codes forever. A FIDO2/WebAuthn key uses an asymmetric key pair, and the private key never leaves the physical device or gets stored by the server, which removes that specific risk.
—otpauth://totp/J-Kit:user%40example.com?secret=JBSWY3DPEHPK3PXP&algorithm=SHA1&digits=6&period=30&issuer=J-KitThe secret and codes are generated only in the browser with WebCrypto. Nothing is sent to any server.