Open sergioisidoro opened 1 year ago
My question is, does magic link / passwordless have a place in Djoser? If so I'm willing to take a shot at implementing it
Sounds great but I wish we had additional feedback from the community.
The implementation of passwordless auth is much less popular than the regular one, so assume it will take some time to review (once finished, ofc).
Thanks!
Hi @tomwojcik
Thanks for taking the time to answer to this. After the first attempt at this (see Draft), I've come across multiple issues trying to reuse the logic from the User fields (eg. unique validation, unique together validation, and data cleaning being done in the field cleanup, rather than the serialisers).
Also making this without dependencies for phone validation, phone number formatting and SMS sending, kind of defeats the purpose. Given that this was growing a lot in scope, and out of scope of this project, I took a shot at making this more of a djoser add-on, rather than bloating this project.
https://github.com/sergioisidoro/djoser-passwordless
There is always the chance of sometime merging it in this repo if you feel like it's a good idea. :)
I've been checking existing solutions for Magic link and passwordless authentication. I've found a couple of solutions, the most promising being https://github.com/aaronn/django-rest-framework-passwordless . However the author is not very responsive, and says he updates the lib whenever he needs something - which is understandable, but frustrating to fix bugs and implement new features.
My question is, does magic link / passwordless have a place in Djoser? If so I'm willing to take a shot at implementing it, heavily based and inspired in that last solution I mention.
Rational Right now magic link (where a short lived OTP is sent via SMS or Email) is a very common pattern in authentication, especially on mobile (with SMS autofill and Deeplinks). There are a few security problems with this method of authentication (SIM cloning, etc), but it is a very user friendly way to authenticate, and the usability tradeoff is very reasonable in many cases.
Challenges We would not be able to use the default Django challenge token, because on mobile the token needs to be short format to be usable by humans (eg 4-6 characters, usually numeric), and fit in an SMS message. This means we need to create a statefull token for this library, and have a semi-complex logic to validate it.
Another method for mitigating bruteforce is to ask clients to provide the same info (email/phone nr that requested the token) when they redeem the OTP. This makes it virtually impossible to brute force short tokens in a small lifetime of a token. However creating both "standalone" and "non standalone" otp is an additional complexity factor.
I've been drafting something, but before I put any more effort in it, I'm wonder if it's something that you are willing to accept in this repo.