When using a One-Time-Token like that, you usually have at least four problems:
Time frame of validity. If the token is valid for too long, it might get compromised, if too short, the method of delivery might be too slow to allow for a good user experience.
Method of delivery. You do not want to send those tokens over an insecure channel like mail without PGP or S/MIME. If you do, the token (effectively the username and password during said timeframe from 1) might get compromised and everything breaks horribly. If you use PGP or S/MIME, that puts a heavy Burden on the users, effectively restricting the user base to about 1% of what is possible, as a rough estimate, as others do use neither technology and do not know how (and you're effectively putting the "hassle hurdle" to register quite high)
Method of requesting such a One time token. If you allow for any unauthenticated user to put in a name and have you use some (probably computationally hard and resourceful) crypto and a communication channel, there's a higher attack surface for DDoS-Attacks.
Usability. If this does not yet sound like UX hell: what about people that do not have PGP on their phones (not free on most platforms) but want to use your service while on the go? What about people using a machine at some other place, like internet Cafés? You do not want to also check mail or whatever way to send the token you come up with there.
Oh and while I'm at at: your question sounds like you're never invalidating the tokens. That's horrible for many reasons, as is the length of your example token - it should have a lot more entropy and a lot more characters.