You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.
The text was updated successfully, but these errors were encountered: