It does use the 'do fancy things with HMAC signed tokens' to handle password reset though, which (as a general scheme) has been criticised vs the 'store random dumb token, details in the DB' method, for being difficult to do right and open to subtle flaws.
Obviously I'm not aware of any Django-specific issues with it (or I'd have reported them already), but it's a design decision I've wondered about.
There was some discussion in a thread a few days back[1] in which I asked a similar question.
It boils down to "possible, but very easy to screw up, and for what is probably relatively small benefit."
The only benefits I can think of for the info-in-token approach are:
* Less database hits to validate a token. Given that password resets are probably only a small part of your site load, I'm dubious as to the utility of this optimisation.
* No server-stored tokens to secure - If an attacker manages to dump or partially break your database (SQLi, logic bug, whatever), they could extract the reset tokens and use them to gain access. Obviously, a full db exploit would make this unnecessary, and a proper reset implementation (that expires the tokens after use, sends confirm emails on use, etc) means unauthorised use would hopefully be detected.
In the info-hash-token, the only place it's ever actually stored is in the user's mail-box (and every email server involved in the process along the way, potentially), which might reduce the risk of disclosure, especially bulk (server dump) disclosure.
Any other advantages I might have missed? It's possible to do things like token expiry, invalidate on use, invalidate outstanding tokens using hashed tokens, but all of those things are fraught with danger.
Obviously I'm not aware of any Django-specific issues with it (or I'd have reported them already), but it's a design decision I've wondered about.