How do I resend a confirmation token, if two different people try to register the same email address?

Question

I am designing a REST API that allows users to register and authenticate with an email address and a password. Before being able to authenticate, I want to ensure that the user owns the email address they are using, so I send them a verification email with a token. My issue is that the token can expire, so I need a way to resend the verification email, and this is where I'm having problems.

Basic Setup

I have two models: EmailAddress and EmailConfirmation. EmailAddress stores the address, the user who owns it, and a boolean indicating if it's verified. EmailConfirmation contains a key used to verify a specific email address.

---

Approach 1

When a user registers, I create a new user and an EmailAddress instance owned by that user. A confirmation is sent to the email. If the confirmation is expired, the user can request a new confirmation.

The issue with this approach is multiple users can sign up with the same email address until someone verifies that address. If there are multiple EmailAddress instances with the same address, how do I determine which of them requested the verification to be resent?

Approach 2

When a user registers, we create an EmailAddress instance for the address, but don't assign a user to it. If additional users register with the same address, we don't create new instances. Instead, the EmailConfirmation model has an attached user and we set ownership of the address based on which key is used to verify it.

The issue with this approach is how to determine which user requested a new confirmation email.

---

Further Notes

• User's shouldn't be able to prevent others from taking an email address. For example: If Fred registers with [email protected] but can't verify it, Bob should still be able to register with [email protected] and verify it.

I am happy to take a different approach than the ones described above, but those are the only ones I can think of. Any help would be greatly appreciated.

Edit: I believe the original title of my question was a little misleading. I'm more interested in solving the issues with resending a confirmation email. However, if this involves restructuring my approach to the whole system I'm happy to do that.

Edit 2: To further clarify my question, I'm talking about the case where a user registers and gets sent a verification email. For whatever reason, they don't use the token they've received in time and it expires, or they simply lose the email. They then request a new confirmation email be sent by submitting their email address.

I believe the problem boils down to determining which user requested a new email confirmation without any knowledge of the initial verification token.

Answer 1

For either approach, the easiest way to resolve this is to embed user information into the token. That way the token contains enough information on its own to validate the user and their email address.

An overly simplistic version of this might be to attach the user id to the nonce you send. For example, if Bob is user number 1234, the email might contain the token 1234000574628, where 574628 is the nonce you use to confirm that the user actually read the email.

Answer 2

I understand the question is purely about the REST API modelling, and not about how to actually generate the token, right?

Each time you generate a confirmation mail, you generate a confirmation record identifying a user, an email address, an expiration time and a unique unguessable token. When an confirmation is verified by clicking the token URL, the email address is verified for this user (and you have to check no other user verified the same email address in the meantime!).

It is not clear from you description if the same user can change email address. If the email address cannot be changed, then it is a property of the user, not the confirmation, since all confirmation for the same use would be for the same address.

As for modelling this in REST, I think you answer it yourself. The Confirmation need to be associated to a user. So you have something like /users/1234/confirmation/567 representing a confirmation mail, and you verify this by posting the token to it.

But note that you shouldn't expose this resource URL directly in the confirmation mail. The token and URL should be opaque and not reflect the resource URL of anything, since it should not be possible to guess or reverse-engineer verification URL's.