What is the idiomatic way of handling "ephemeral" state in a database?

I know that "best practices" type of questions are frowned upon in the StackOverflow community, but I am not sure how else to word this.

My "big picture" question is this:

What is a good practice when it comes to handling "session" state in a stateless server (like one that provides a REST api)?

Quick details

Using nodeJS on backend, MongoDB for database.

Example 1: Login state

In version 1 of the admin panel, I had a simple login that asks for an email and password. If the credentials are correct, user is returned a token, otherwise an error.

In version 2, I added a two-factor authentication for users who activate it. Deciding to keep things simple, I have now two endpoints. The flow is this:

• /admin/verifyPassword:

Receive email and password;
if(Credentials are correct) {
  if(Admin requires 2fa) {
    return {nextStep: 2fa};
  } else {
    return tokenCode;
  }
} else {
  return error;
}

• /admin/verifyTotpToken:

Receive email and TOTP token;
Get admin with corresponding email
if(Admin has verified password) {
  return tokenCode
} else {
  return error;
}

At the verifyTotpToken step, it needs to know if the admin has already verified password. To do that I decided to attach a 'temporary' field to the Admin document called hasVerifiedPassword which gets set to true in verifyPassword step.

Not only that, but I also set a passwordVerificationExpirationDate temporary field in the verifyPassword endpoint so that they have a short window within which they must complete the whole login process.

The problem with my approach is that:

• It bloats the admin document with ephemeral, temporary state that has nothing to do with an admin itself. In my mind, resource and session are two separate things.
• It gives way for stale data to stay alive and attached to the admin document, which at best is a slight nuisance when looking through the admin collection in a database explorer, and at worst can lead to hard to detect bugs because the garbage data is not properly cleaned.

Example 2: 2FA activation confirmation by email

When an admin decides to activate 2fa, for security purposes, I first send them an email to confirm that it is truly them (and not someone who hijacked their session) who wanted to activate 2fa. To do that I need to pass in a hash of someway and store it in the database.

My current approach is this:

1) I generate a hash on the server side, store it in their admin document as well as an expiration date.

2) I generate a url containing the hash as a query parameter and send it in the email.

3) The admin clicks on the email

4) The frontend code picks up the hash from the query parameter and asks the server to verify it

5) The server looks up the admin document and checks for a hash match. If it does, great. Return ok and clean up the data. If not, return an error. If expired, clean up the data.

Here also, I had to use some temporary state (the two fields hash and expirationDate). It is also fragile for the same problems mentioned above.

My main point

Through these two examples I tried to illustrate the problem I am facing. Although these solutions are working "fine", I am curious about what better programmers think of my approaches and if there is a better, more idiomatic way of doing this.

Please keep in mind that the purpose of my question is not a get a specific solution to my specific problem. I am looking for advice for the more general problem of storing session data in a clever, maintainable, way that does not mix resource state and ephemeral state.