How Authenticator Apps Work — Time-Based OTP Explained
This is simplified for beginners to understand and may be slightly inaccurate due to simplification.
When you log into a service and it asks you to "enter the code from your authenticator app," you're using a mechanism called TOTP — Time-Based One-Time Password. It's one of the most common second steps in two-factor authentication (2FA). Here's exactly how it works.
The Three Parties
| Term | Meaning |
|---|---|
| Backend | The service you're logging into |
| Client | The authenticator app installed on your device — Google Authenticator, Authy, Microsoft Authenticator, etc. |
| Client Service Provider | The company that builds and maintains the authenticator app — Google, Twilio, Microsoft, etc. They distribute the app and may offer cloud sync infrastructure, but do not play an active role at runtime while generating codes |
The Core Idea: A Shared Formula
The client and backend share two things:
- A secret — a unique string generated by the backend for your account
- A formula —
f(secret, current_time)
Because both sides have the same secret and use the same formula, they independently produce the same 6-digit code every 30 seconds — with no communication between them.
This is a standardised protocol, so every authenticator app and every library that implements TOTP produces the same result given the same inputs. Just like how JWT works the same way regardless of which library you use.
How the 30-Second Code Works
Every 30 seconds, a new code is generated. The client shows you this code. You type it into the backend. The backend runs the same formula and checks if it matches.
There's one practical issue: if you submit the code at the very end of a 30-second window, it might expire in transit. To handle this, the backend typically doesn't just generate the code for the current window — it also generates the code for the previous window and the next window. If your code matches any of the three, it's accepted.
No Internet Required
The client generates codes entirely on your device, locally, using the secret it stored during setup. There is no network call between the client and the client service provider's servers, nor between the client and the backend, to generate codes. This is why the authenticator app works even when your phone is offline.
How Setup Works: Sharing the Secret
The secret needs to be shared with the client exactly once — during initial setup. This is done in one of two ways:
- Scan a QR code shown by the backend
- Manually enter a code and some details if you can't scan
What you're actually scanning or entering is the secret, along with some metadata. The QR code encodes a URL in this format:
otpauth://totp/{issuer}:{account}?secret=K&issuer={issuer}
Breaking this down:
| Part | Meaning |
|---|---|
otpauth |
The protocol identifier for OTP-based auth |
totp |
The method — time-based OTP |
{issuer}:{account} |
The label — service name and your identifier (usually email) |
secret=K |
The actual secret string |
issuer={issuer} |
The service name again, as a query parameter |
This URL is not a web address. It only does something if there's an app installed that handles the otpauth:// protocol — just like https:// URLs open your browser. If no authenticator app is installed, it's just plain text. If one is installed and you scan the QR with your camera, the OS hands the URL to the authenticator app, which extracts the details and adds the entry. If you scan directly inside the authenticator app, it does the same thing internally.
What This Proves: Device Ownership
Sending an OTP to a registered phone number proves you own that phone number. TOTP works on the same principle, but instead of a phone number, it's your device.
If you can produce the correct code, it proves the secret is on your device — the same device that was registered during setup. This proves device ownership, which proves account ownership.
TOTP vs SMS OTP
| SMS OTP | TOTP | |
|---|---|---|
| Cost | Costs money per SMS | Free |
| Works offline | No — needs mobile network | Yes |
| Works abroad | Unreliable | Yes |
| Speed | Depends on network | Instant |
| Initial setup | None — SMS app already on phone | Required — must install client app and scan QR or enter secret once |
Cloud Sync: Practical Convenience vs. Original Intent
Most authenticator apps offer cloud sync. It's important to understand what gets synced: the secrets, not the codes. Codes are always generated locally on the device.
Cloud sync exists so that if you get a new phone and log into your authenticator app account, the secrets are downloaded and you can immediately generate codes again. Without sync, losing your phone means losing all your TOTP entries.
However, cloud sync changes what the code actually proves. Originally, TOTP proves device ownership — only the person with the physical device can generate the code. With cloud sync, it now proves authenticator account ownership — anyone who can log into your authenticator account can install the app, download the secrets, and generate codes.
To address this, some apps add a backup key (also called an encryption key). The secrets stored in the cloud are encrypted with this key. Even if someone gains access to your authenticator account, they cannot decrypt the secrets without knowing the backup key — something only you hold in memory.
This shifts the proof from device ownership → account ownership → personal knowledge of the backup key.
Recovery Codes: Your Last Resort
When you first set up TOTP on a service, it also gives you recovery codes — typically 5 to 10 single-use codes. You're meant to save these somewhere safe.
If you ever lose access to your authenticator app and have no way to generate codes, you can use one of these recovery codes to log in. Each code can only be used once. Once all are used, you'd typically request new ones from the backend.
Recovery codes are not part of the TOTP protocol itself — they are themselves an independent second step option (like TOTP) that services provide to ensure you are never fully locked out of your account.
Why Not a Website-Based Client?
You might wonder: why can't someone just build a website that generates and shows TOTP codes just like a mobile app? Technically, nothing in the protocol prevents this. Such a website generates and shows TOTP codes just like a mobile app — the algorithm is the same. People have built such tools, useful for developers who are tired of switching to their phone during testing.
But it defeats the purpose. If codes are generated on a website rather than on your physical device, you're no longer proving device ownership. You're proving access to a website account — which is no different from sending a verification code to an email address.
The original intent of TOTP is specifically to tie authentication to physical device possession. That's why major platforms only offer device-installed authenticator apps for this purpose.
That said, it is not forbidden — if you build your own or use a well-known trusted one, it works perfectly fine and is technically secure.
Summary
- Client and backend share a secret and a formula; both independently generate the same code every 30 seconds
- No network connection needed — neither to the client service provider nor to the backend — codes are generated entirely on your device
- The secret is shared once during setup via QR code or manual entry using the
otpauth://protocol - Providing the correct code proves you have the device where the secret was registered
- Cloud sync of secrets is a convenience feature, not original protocol intent — it shifts the proof from device ownership to account ownership
- Recovery codes are a separate backup mechanism provided by the backend, not part of TOTP itself