I can understand inelegant but I doubt it being inneficient.
It also plays an important security feature. Otherwise someone can do this:
- Create an account for i_own@example.com
- Receive the confirmation token
- Swap my email to i_dont_own@example.com
- Now confirm as i_dont_own@example.com
So tokens must be tied to an email and having the column there is a helpful reminder. If you don’t do it on your Phoenix.Token approach, then it is vulnerable.
In any case, I would go with your approach if we didn’t have the table. Otherwise having both will be more confusing. At the same time, I worry that providing those facilities and telling people to roll their own auth features will be full of pitfalls like above.






















