I'm generally a fan of this method and have picked it for a couple of projects in the past. With relatively long session lifetimes, the UX is acceptable for man

I'm generally a fan of this method and have picked it for a couple of projects in the past. With relatively long session lifetimes, the UX is acceptable for many use-cases. One thing worth pointing out is that the algorithm as described allows for a timing attack on the sign-in token. A common mitigation to this would be to do the database lookup using a different key (the email address, primary key or any other unique value that's not related to the actual token) and then use a constant time string comparison algorithm to compare the tokens. Another best-practice would be to store a hash of the token rather than the token itself. This reduces the impact of a leaked database dump, where a copy of the database is stolen (think: public S3 bucket), but no (write) access to the database is gained. This is a relatively low-priority issue, but it's an easy fix, so probably worth considering.