Page Comparison

...

Thus, the tokens are rotated by successful reauthentication attempts, not by an expiration time.

the user signs in, we create a session token and reauth token, create a new record in the secrets table that includes the reauth token hashed, and we return the session token and reauth token as part of the new session.
Redis expires the session after 12 hours, which renders the session token unusable. The client, on getting a 401, makes a request to the reauthentication API with the reauth token;
we load the most recent N records from the secrets table. Proceeding through each record:
we hash the reauth token according to the algorithm in the record, OR reuse a cached version of the hash;
if the hash does not match, proceed to the next recorrd
if no records match, return a 401
if the record matches, we remove the current session if it's there, then we create a new session token and reauth token, create a new record in the secrets table that includes the reauth token hashed, and we return the session token and reauth token as part of the new session. This means the oldest record in the secrets table will "drop off" on future queries to load the most recent N records from the secrets table

Let's assume in the worst case that the client does not get the session back from the reauthentication call.

the client makes the same request with the (now old) reauth token;
we load the most recent N records from the secrets table. It includes the old token, now the second oldest record in the system, and so reauthentication succeeds, as above.
again a new session is created, a new table record is created, and a session is returned to the user. We can recover from this failure as many times as we want to configure, so if N=3, we can fail 2 times and recover the third time. If that's not robust enough, we can switch to N=4 or higher.

Sign out

In addition to deleting the session and session token, we can delete all AccountSecret records for this user.

...