Logging in Verification: Magic Links, 2FA, SMS Codes

Welcome to Syntex. On this Monday, hasty treat, we're gonna be talking about logging in, verification, magic links, 2FA, SMS codes, all that and more. But before we do, you're gonna wanna make sure you have a service like Sanity on your side to make sure that, well, you're covering errors because if people are logging ESLint your software, it gets a little bit mysterious sometimes what's happening. And you can attach which user is, actually having issues. That way, you can look it up later. So head on over to century.i0forward/ syntax. Sign up and get 2 months for free and solve your bugs with ease.

What's up, webs? Alright. So let's talk about the different ways that you can verify that somebody has logged in. So this is not a show about two factor authentication, but it's more about the different ways that you can log somebody in. And I I Scott got on this track talking about magic links and logging people in with magic links. And it's it's funny how much developers hate MagicLinks and how useful they are for the general public. Like, I thought, like, let's talk about the pros and cons of that as well as all the other ways that you can can log somebody in. So let's start with MagicLinks. MagicLinks are when you log in to some sort of SaaS, you put your email in, and it says, we've sent you a URL.

Go ahead and go to your email. Click that and come back, and then you're logged in. Right? You don't need to remember a password.

And another pro of that is it's a really easy sign up flow. So if you wanna get somebody to sign up for your application, what's easier? Enter your email or enter email, enter a password, make sure you remember that password, all of this hubbub and and jumble. It's just a a much lower bar to getting people on board. And then it also it it cuts down on account sharing as Wes. Because if you need to click a link in your personal email for before you can get access to it, ConvertKit does this as well. ConvertKit wants to charge you every single user that is using it. So often Wes you sign in to ConvertKit, it's like, oh, for security purposes, we want to check that it's actually you. We sent you a link. Make sure you go ahead and and enter that link in. Yeah. I that is for security, but that's also because then you're not sharing passwords amongst your whole team, and you're you're paying the extra $6 a month for every single user. Yeah. And OAuth can also do that too. I know we'll talk about that in a bit. But, like, that that specific thing is, like, one of the reasons why I'm I'm so annoyed that I chose not to

make an account with Claude before I started using it in sign up. Because with our chat g p t account, my wife and I just share a login for that. Right? But now it's like, the cloud is tied to my Gmail, which isn't a a problem. But, like, we when you log in to Google services, it's more than just like, oh, now you have access to Google services. Like, they take over everything. Right? Next time then you go to send an email or anything, it tries to send it from or your calendar tries to add it to the wrong calendar.

So for me, personally, it's like, you know, I I I do like a email password flow to be available for that reason as a user. Yeah. But as a, you know, service provider or something like that, yeah, I could see that definitely being a a pro. But, yeah, MagicLinks, I I do think this is one of the easiest ways as a developer to get up and running. It's Node of the easier ones for users. But as a developer, adding MagicLinks into your app is one of the easier means of creating a login system. You don't have to worry about that same type of salting and hashing security you do with passwords. You don't have to worry about email verification. That's one thing you didn't mention. And, like, when you log in with an email and password, you're always given that Node you have to verify your email Very good. Very good. Very good. Wes good.

A magic link itself that you then click. It's like a second step. Yeah. So And we should say the way that it works is that the magic link has a ID in the URL that you click, and that ID will then when you visit it, it will check that that ID is valid. It's been valid for a specific amount of time. And then once once you actually visit it, you do need to make sure that the person who's clicking it is actually the person because some email accounts will actually crawl the links in your URLs.

And if the if the crawler bot actually visits the URL, they could accidentally verify even if someone doesn't click on it.

Cons to magic links here are opening in the wrong browser. So you do it on an app, or you do it in your on Safari, and then you click on your your email account has an in app browser, and you click on it, it opens in the wrong browser. It doesn't necessarily work, and then you gotta figure out how to copy paste it. It's the worst. Yeah. Or Yeah. Somebody clicks on it on their phone, and and then it's trying to oh, I didn't log in on on desktop. So that that can be annoying. And probably the biggest one is this slow.

I hate that Claude does this. Every single time you log in, it's it doesn't send you a magic link, but it sends you a a a code. And you gotta sit there on your hands, wait for their them to send the email, wait for the email to show up, wait for my email client to refresh and download it and open it and copy paste it, and it's just such a slow process. So the reason why developers hate it is because we are very good at using password managers, and that is so fast to use a password manager. But I always am amazed that developers don't seem to understand that the general public does not. The general public uses Yeah. Their dog's name, and then they add a number incrementing on the end of that every time they need to reset their password. That's how they do their passwords. And there's a reason why people get hacked all the time. It's because they use the same password across it every every single one. And as a service provider, that's annoying because now you've got support requests of people getting hacked, and then you gotta deal with the support requests amongst it. It's it's really annoying. So I understand why MagicLinks are so popular.

Yeah. Although I do I I kinda waver on this one because as a developer, they're really easy to implement. A lot of, even, like, database, ORM, Supabase, those types of things have it baked in. So it's like a one liner. Right? Let me just, shoot that email off. Click it. I like implementing this as a developer. As a user, I don't like it as much. But like you said, I think normal users probably do like it. There's also this other one called I call it magic sessions. I don't know if there's a name for this, but it's

Wes you're waiting to log in to something, like, especially if you're in, like, the terminal or, a big one is you're trying to log in to an app on the TV, the TV will send you an email, and you Scott click on that link. And you obviously can't open the link on your TV. Right? So what this does is it just checks that you've actually clicked the link, anywhere, and then it's it's authenticated you. So I off I really like that. I think I see how that can be less secure because if a hacker sends you a magic session link and you're, oh, what's this? And you click it, and then you've authenticated them, there's probably other things you can do there. Are they on the same IP address? Are you at least coming from the same city? There's a lot you could also do to to track against that. Yeah. And beyond just clicking links, there's also a code version of this too Wes it asks you,

you have to be authenticated on your phone or on the website, and that gives you a code that you can then type in on the TV as well instead of, like, clicking the link to authenticate it. I love any time. Yes.

It's called, like, like, auto login or magic login, something like that. And that's every single one. Anytime any of these TV apps makes me input my email address, and almost all of them have gone away from putting in your password on the with the remote.

But, they'll usually send you to, like, another website. You have to put the code in first and then log in, which is kind of, like, backwards. You know? But Jellyfin does that as well where you can generate a code on a signed in device and then use that code to log in to a not signed in event. So that's another huge way to log in to things is

allow access from an already trusted device. Yeah. I, yeah, I I I do think that's a great way to do it. You know, the classic email and password verification flow is you send your email, you send your password, that password gets salt and hashed, and that's a one way hash in case people people often think that when you have a password on a server, it's an TypeScript, password and that, like, encryption can be deencrypted, but that's not the case. You hash it and you salt it. And then when somebody then enters their password to verify, it runs that through the same salting and hashing algorithm and then compares those 2 to make sure that those are the same. Not not not that you you're able to ever reverse engineer that password. So, that's typically how it goes. But, again, then you have to verify the email because when you sign up with an email and a password, anybody can enter anybody else's email. So the reason email verification exists is so that it sends an email to your actual email, makes you click on a link that has a token that's stored in the database. It compares those 2 tokens. And if those are the same, then you're verified. Right? Yeah.

So it it's a lot of extra work. But The email verification, I often like when they give me, like like, 3 days to verify it, you know, where, like, you can immediately get using the application, then you have a couple days to to actually click that because that's always such an annoyance where you're like, oh, let me sit here. Like, hopefully, your queuing system isn't backed up where you it takes you 15 seconds to send the send the email, because then you're you lose people. But there is an issue there too Wes if you don't verify, the likelihood of spam is, like, massively. So the we had to add verification,

and I, like, kind of resisted it because I was like, that's an extra step. But People just sign up things, a 1,000,000,000 emails, spam them, or whatever, never verify their email. So if you if you're having spam issues, you gotta have that verification. Likewise, like, the, magic, link is the email code where, likewise, what they'll do is they'll email you a code. You enter that code to log in because that code is typically valid for a much smaller amount of time than something like even a magic link or a verification email. Those are typically like, alright. We've sent it to you. You have, like, a minute to enter this code. And if you do, you can get in. We share a a Disney plus account with my sister-in-law,

and we know her we know the username and password. But now when you try sign in, it says we've sent you a code. So now you Scott, like when you wanna sign in to Disney plus, you gotta, like, have them on the phone and be like, alright. We're doing this. You know? And I know I told you never to send these single time codes over SMS, but this time, it's fine.

Yeah.

But yeah. I know. It's, it makes you feel like a secret agent, and I like that. Yes. Yeah. And then, like, I just went through Gmail. I was like, how many different ways are there to sign into a Gmail account even once you know you're using a password? Because often, though, there's there's 2 factor to this. Right? So passkey is is obviously a popular one. SMS code. Backup code is another one. Like, when you sign up, you get backup codes, and you can print those off or or store them somewhere safe. And then, of course, there's your your standard two factor authentication using any of the apps. Or, big with Gmail is just like you open it on you if you have the Gmail app on your phone, it will, like, ask you to approve it on a different device. So that's kinda similar to the having a trusted device approve that. Yeah. Trusted device. I I do love how GitHub does that. Anytime I wanna do something on GitHub, it sends it to my phone, enter the two digit code. Yeah. And it's just, like, 29. You know? It's just 2 codes or two numbers.

YouTube does that or even Google does that. It often sends something to my YouTube app. It just pops up in a little Node. I click yes. It usually works. I almost, like, never have issues with it. If it does work, then it's, like, kind of an annoyance, if it's if it's not working.

But, you know, we also we didn't we briefly mentioned OAuth, but how that's working is, again, it's you have, like, a a token.

You're sending that token to a third party service, whether that is Gmail or or or Google or GitHub or something like that, GitHub says, oh, yeah. This person's logged in because you already have a session currently going over at GitHub. And then says, do you approve of this other application using your software? If you say, yes. I do. Then it sends a, a session token their way that they can use to be authenticated via the API as a session with that service.

And if you're authenticated with another service with a session token, that's almost as good as being authenticated as an email or whatever because it's saying you are you you're you are this person. You're tied to some other resource.

And oftentimes, like GitHub, you get a username. You get a photo along with that. You get a whole bunch of stuff along with that. So,

you know, a lot of security with it as well because Yes. Getting a GitHub or Gmail or or Google account, like, is very tricky, and people are not people generally do not have multiples or and spammers, it's it's much harder for a spammer to get a a Gmail or a Twitter account. Well, maybe not Twitter, but, and and then that stops people from having multiple accounts or spammers being able to just create these hollow accounts that can they they can use for abuse.

Yeah. Totally. Yeah. A lot of this stuff is either preventing abuse of your system or keeping your users safe. So user authentication is one of those things. And and by all means, if you wanna roll your own, email and password authentication session system, it's not that tough. A lot of these things aren't that tough when you get into them. Even doing a magic link or a magic code or any of this type of stuff is not hard when you dive into the the fundamentals of it. So you don't always have to use a service for this stuff. You can certainly implement some of it on your own if you'd like.

Alright. I think that's it for today. I thought it was interesting to talk about this. I don't even know what you call this, but, like, 2nd step verification. It's not all two factor authentication, but it's, hey. We wanna double check who we think you are, and these are some nice ways to to go about that. If you're out there and you have an adversion to any of these, let us know. Do you like magic links? Do you hate magic links? Which of these authentication methods are your favorite?

If you if you approach a site and it only has Gmail OAuth, are you not going to use it? So let us know what you think. I I'm down to hear exactly, like because I'm in my bubble of what I like, but I would love to to know what other people like and dislike, especially because I build a lot of auth systems.

I've been noticing a lot of companies not giving you username password recently. It's you can only sign in with OAuth.

Or a phone number. Just a phone number. Yeah. Yeah. Phone number as well, which I I see that as well because they can market they can text message you and and get good marketing out of that. You know? No one reads their email anymore, so sending a text is where it's at. Yeah. For sure. Wow, world. Alright. Thanks, everybody, for tuning in. We will catch you later. Peace.