TOTP 30-Second Time Window Explained
Understand why TOTP uses a 30-second time window and how it affects code validity. Learn about time step configuration, validation windows, and server-side grace periods.
Detailed Explanation
The TOTP 30-Second Time Window
The time period — typically 30 seconds — is a fundamental parameter of the TOTP algorithm. It determines how long each generated code remains valid and directly impacts both security and usability.
How the Time Step Works
TOTP divides Unix time into fixed intervals:
T = floor(unix_timestamp / time_step)
With a 30-second step, the counter T increments every 30 seconds:
| Unix Time | T Counter |
|---|---|
| 0 – 29 | 0 |
| 30 – 59 | 1 |
| 60 – 89 | 2 |
| ... | ... |
Every device sharing the same secret and clock will compute the same T value during the same 30-second window, generating identical codes.
Why 30 Seconds?
The 30-second default balances several concerns:
- Security: shorter windows reduce the time an intercepted code remains valid
- Usability: users need enough time to read the code and type it (especially on mobile)
- Clock tolerance: longer windows are more forgiving of minor clock drift
- Network latency: the code must survive the round-trip to the server
Server-Side Validation Window
Because clocks are never perfectly synchronized, servers typically accept codes from adjacent time steps in addition to the current one:
Valid codes: T-1, T, T+1 (±1 window = 90 seconds total)
Some implementations use a wider window (T-2 to T+2) at the cost of reduced security. RFC 6238 recommends validating the current step and one step in each direction.
Configuring Different Periods
While 30 seconds is standard, the TOTP specification allows any period. Common alternatives:
- 15 seconds: higher security, but codes change too fast for many users
- 60 seconds: more forgiving for slow typists, but longer attack window
- 90 seconds: used by some enterprise tokens, significant security tradeoff
The period is specified in the otpauth:// URI using the period parameter (default is 30 if omitted).
Impact on User Experience
At 30 seconds, users have roughly 15-25 seconds of usable time (accounting for display delay and the moment they view the code). Most authenticator apps show a countdown timer to indicate remaining validity.
Use Case
Developers configuring TOTP validation on their servers need to understand the time window to set appropriate acceptance tolerances. This is particularly important when users report intermittent authentication failures due to clock drift, when tuning rate limiting alongside the validation window, or when enterprise requirements demand a non-standard time period. Understanding the tradeoffs helps you balance security and user experience.