Since Rails added authentication generation, which is cool, I wonder if we can add another generator to create magic link-based authentication instead of password-based authentication? Magic links have quite a lot of advantages: you don’t need to store passwords, you don’t need to create 2FA, you don’t need a ‘forgot your password’ feature, etc. I would be happy to contribute if this idea sounds valuable.
1 Like
I like this idea!
Rails Authentication generator wants to be minimal. This is good cos it clears the magic behind authN and authZ somewhat. For things like this, I would rather a gem pool of different auth generators for rails, unlocking different capabilities.
1 Like
I recently built my own magic link authentication using the ActiveRecord::TokenFor::ClassMethods - Ruby on Rails API functionality.
This worked great but I had to scrap it and replace with a emailed code.
Here’s why I replaced the magic link authentication:
-
Outlook was pre-fetching the link and invalidating the token. In general, get requests should not be making any changes because they get pre-fetched in various scenarios. I added a post-based step but encountered 2.
-
Some email systems automatically flag and quarantine long links as malicious. Especially in the enterprise world.
So, I replaced the long link with a 6-digit single use code which expires in a few minutes. Also use rack-attack to limit code entry attempts.
Hi! I actually have a hybrid approach in my app. The magic link has an embedded 6-digit code which keeps it short. When a user tries to sign in, they receive an email where they can either click the link or copy the code to enter it manually in a form that appears after entering their email and clicking sign in.
By the way, when you mention a post-based step, do you mean that when the user clicks the link, they’re taken to a page where the code is pre-entered and they must click a button? I haven’t got users struggling with prefetched links yet but I think eventually I will get some.
It is ultra-important that GET requests never change anything. Long ago, before REST was a thing in Rails, the destroy action was kind of like the edit action, in that the only difference between it and show was the presence of a URL segment. /widgets/42/delete or similar.
Yahoo came out with their toolbar extension for various browsers, which would “speed up” the Web by pre-fetching all the visible links on the page in the background. Much hilarity ensued, and many folks discovered that their fancy Web 2.0 apps didn’t have adequate database backups.
Suddenly, Rails got the REST religion, and the destroy action became a POST masquerading as a DELETE (using the _method hidden field element). Since the toolbar could not submit forms without a user click (indeed, browsers generally won’t do that at all or allow it to this day), the crisis was averted, and we all learned a bit more about network protocols.
Walter
1 Like
Alexey, in my case I removed the link - because in some corporate environments the complex anti malware systems were marking it as malicious.
The new setup sends a code and no link. The login page accepts an email address and then requests the code to be pasted in a form field and the form - submitted.
If you prefer a link make sure it requires a user interaction using a POST request. In my case the link showed a screen with the email address associated with the token in the link and a “Complete your sign in” button.
1 Like
I think people will get used to clicking a magic link in an email to authenticate once corporate makes it easier for these to get through 
I think it is possible to merge standard auth flow with login/password and passwordless authentication. On the first form, you have an email field and two buttons - “login with password” and “send magic link”. If you choose login with password, there will be a password field available; otherwise, you’ll receive an email with OTP and a link to enter. What do you think?
PS: here’s an amazing tutorial with OTP and magic links Password-less Auth with Rails | Miles Woodroffe
Hi! I think it’s better not to have both because one of the best advantages of using magic links is improved security, you don’t have to store passwords and users won’t be in danger because they tend to use same password everywhere. Also you don’t need to implement email confirmation, password recovery etc. I think having magic links + some popular OAuth providers like Google is a good alternative. Also, for login purposes Webauth is my top choice after I tried it. Most of devices already support it and it is both easiest and most secure option for signing in.
Let me explain why relying solely on magic links isn’t a wise approach. The current generation prefers messaging platforms like Telegram, WeChat, and Viber over email for almost everything. Consequently, using magic links alone will likely result in a low conversion rate for your project. Additionally, using OAuth providers isn’t a suitable option either. I’m not sure where do you live, but given your name, I suspect you’re from Russia, Ukraine, or another former Soviet country, so the next fact may be actual for you. As you maybe know, there are restrictions on using Google services in China, and there’s a growing trend to limit the use of foreign services in Russia. Most popular platforms have banned Google/Apple/Facebook authentication. Therefore, we need to adopt strategies that enhance the conversion rate from visitors to registered customers. Unfortunately, there’s no simple solution to this problem.
Webauthn isn’t a panacea either. There are numerous articles discussing Webauthn limitations. Here’s one of them: WebAuthn Capabilities and Limitations
Having login + password most often means user needs an email as well, actually I can bet there’s no active internet user without an email 
OAuth providers are indeed not as reliable as email, I also know issues where Facebook banned an application after a while so that users couldn’t login. That’s why I obtain user email when use Google OAuth so that email automatically becomes backup option.
About messengers: you can use OAuth by Telegram or WeChat as well, I think if one uses messenger it’s better to click than to send the code
My point is that generally login + password is most generally-adopted but I think the worst user-friendly (unless one uses password manager) and secure comparing to other options
Hehe, you’d better to ask young generation what do they use I’ve forced my daughter to create her own email account years ago, but she doesn’t use it, but she’s an active internet user