system
Given the following post, respond as if you're commenting on Reddit:
human
How do Gemalto tokens work? Curious how the system knows when a numerical value off of a Gemalto token is a valid number.
gpt
The token and the authentication system share a secret key, and both have a clock. They also share additional information: a "time epoch" (a date from which the token's clock starts counting) and a "time step" (usually 30 seconds or 1 minute).

The token gets the current time in seconds since the epoch, divides it by the time step, and this way it gets a number.  For example say the epoch is 15 December 2016 midnight, now it's 16 December 2016 midnight and the time step is 30 seconds. The number is 86400 / 30 = 2880 (86400 is the number of seconds in a day).

The number is mashed with the secret key and passed through a "hashing algorithm" (this step is called HMAC). The hashing algorithm produces a small value that is then converted to 6 digits. The result is the one-time password.  The exact algorithm does not matter, as long as it's the same between the token and the authentication system. Of course the hashing algorithm should be audited by cryptologists, so that you cannot recover the secret key just by gathering a few one-time passwords. But as long as you stick with known-good HMAC algorithms, the conversion to 6 digits can be very simple (for example, if the encrypted time is a 64-bit value, you can multiply by 1000000/2^64 and keep the integer part).

Because the authentication system knows all the parameters (time, key, epoch, step) it can reproduce the same steps and it ought to get the same value. If it doesn't there are two possibilities: either the code was wrong, or the two components used slightly different time values. This is because all the other parameters never change. 

Now, the difference in time values is usually very small. Assuming that the clocks are perfectly synchronized and you use the value within one minute of the time that it was generated, the difference will be 0, -1 or -2. So the server will usually check a small number of values (e.g. the three values between -2 and 0 for a 30 second time step, or the two values -1 and 0 for a 60 second time step) and let you in if the numerical value matches any of them. For the code to be declared wrong, it must not match any of these possibilities. The possibility of a collision (i.e. of a random guess being correct) is still very low, around 1/333333 or 1/500000.

Unfortunately, sometimes the token's time is off by more than one minute, or the token's clock is fast. In order to fix this, the server has a special synchronization mode where it checks for a larger set of values, say between -10 minutes and +10 minutes.  This mode lets the server know a bit more precisely the time reported by the token's clock. After synchronization, the server remembers the value that it found, and it will use it as a skew value for further authentication (so for example if the skew was -5, corresponding to -2.5 minutes for a time step of 30 seconds, the server will check -5, -6, -7 instead of 0, -1, -2) In this case it requests two consecutive codes, to make the possibility of a collision much, much smaller, around 1 in 100 billion.

This is the description of TOTP ("time-based one-time password"), but there are other one-time password schemes based on HMAC. For example HOTP, which means simply "hash-based one-time password", uses a progressive number instead of basing the number on the current time. The first time you generate a one-time password you encrypt 1, the second time you generate a one-time password you encrypt 2, and so on. The disadvantage is that it's much easier to get out of sync, since you can increment the counter arbitrarily just by pushing the button many times. However, an interesting property of HOTP is that you can pre-generate a few dozen codes on paper, for emergency needs. This is less useful now that you can use your smartphone as a secondary TOTP generator (there are apps such as FreeOTP), but pre-generated one-time passwords were common 15 or so years ago.