Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Discussion] Passwordless / Magic link authentication #724

Open
sergioisidoro opened this issue Apr 22, 2023 · 2 comments
Open

[Discussion] Passwordless / Magic link authentication #724

sergioisidoro opened this issue Apr 22, 2023 · 2 comments

Comments

@sergioisidoro
Copy link

sergioisidoro commented Apr 22, 2023

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.

@tomwojcik
Copy link
Contributor

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!

@sergioisidoro
Copy link
Author

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. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants