Implementing authentication in your app

Episode transcript

Edit transcript

Ryan Burgess
Hey welcome to a brand new episode of the front end happier podcast. Maybe it's just me, but I've over the years have found doing authentication is it's just a difficult problem on software engineering. It's not very intuitive. And so in this episode, we're joined by Braden cod like, yes. I just wanted to make sure. Yeah, if you want to go there, yes, I need my Italian in the that is good. He's the co founder and CTO of clerk to talk with us about authentication. Great. And maybe you can say your name better than me. But can you give a brief introduction of who you are? What you do, and what your favorite happier beverages?

Braden Sidoti
Yeah, yeah. So that was a great intro. Thank you. My name is Braden. I've been a developer for since college, I guess, or even in college. I did random stuff, because Java. But yeah, for a long time, I made iPhone apps, which started in 2009, or 10, or something like that. The first iPhone app that I targeted was iPhone 3g S, which was right, there was a very, like, we're, yeah, that

Ryan Burgess
was kind of like the first or second real version after they're kind of beta. Yeah,

Braden Sidoti
it was like, Oh, 809. Yeah. And work for some, like consultant shop that like, I kind of just, they hired me, while I hadn't graduated college yet. But they hired me. And I just like, learned on that job. And it was a good experience. consultancies are a great place to like learn programming, you just get Yes, tossed apps, and you can make the worst app ever. But one month later, you're working on a new one. So you really get that that iteration. And anyway, I mean, I found out through a really, really long time, especially during that era, like, always, like people are always talking about, or asking about side projects. And I was kind of the person who always had some sort of side project. And authentication often came up and was often a pain. I think it was an extra painful experience coming from the iOS world, because you are not only your client side, it's like a, its own device. It's like a different client than like a front end client, like a web client, where you're like, kind of closer to the back, and you have to interact with it more. But anyway, it was just a whole, like the server was a whole different world. So it made standing of a back end much scarier because you can use Objective C or Swift. In the backend, you kind of can, but not really. I wouldn't recommend it. Also,

Ryan Burgess
like when you're talking, if you are dealing with authentication, like in the, you know, oh, 809, no swift at that point, you were just doing Objective C.

Braden Sidoti
You're just fighting with weak and strong and all sorts of fun things I gave

Ryan Burgess
up so quickly. Like, I just remember being like, wow, yeah, iOS apps, like, yes, I want to build that, and quickly fizzled out like I did, I've got a couple proof of concept similar to you. I was in working in like agencies and consulting where it was cool, because you would just like you could do something, kind of get it out the door, and then jump on your next thing. I think I learned every single JavaScript framework over the years as I was doing that, because like, every company would be like, Oh, we want to use dojo, we want to use, like, backbone. We want to use Angular, and you're like, Alright, I gotta figure that out. Yeah, Objective C only did a little bit of and I just, I was no good at it.

Braden Sidoti
I guess it takes time. Now I realize I misspoke before because arc, automatic reference counting came out like, right when I was starting, so I was still doing reference counting, which meant you had to like when an object was like allocated, you got to like, increase the counter by one and then decrease the counter. And if you messed it up, then your objects would live forever. And you would have memory leaks. And it was it was bad news on on whatever memory constrained device you had in 2007. But then automatic reference counting came out and then you can declare things a weak or strong and it was it's a whole different paradigm, but also for okay, I don't know, I kind of like that stuff. No, I

Ryan Burgess
think it's like, I think I just got discouraged, short and brief. And like, wish I stuck with it a little bit more. Because later on, I did a little bit more with iOS. And it was like, Yeah, I really enjoyed it. So yeah, I wish I did more. Maybe it was just the webcast. Keep giving me

Braden Sidoti
that's fair. Yeah. For me, it was like more tangible. I think, like, the thing on your phone is it's on your phone. It's like yeah, hold it and grab it and you build an app for it. Whereas the web is slightly more abstract, not too much abstract, more shocked. But also I don't know it was my first job so I just first thing I learned I dug deep and it didn't change as much like the change from Objective C to Swift was like a four or five years slow like burn of Yes, dealing with like six to seven shitty beta versions that all had their own issues. whereas the web changes so quickly, oh,

Ryan Burgess
just I swear, like, as we're talking, I probably have, like, you know, something's changed that I need to go learn. And it's like, yeah, it just constantly changes. But you're right, the ecosystem around iOS was a little bit smaller. So not the end of the world. Yeah. Cool. Well, I, yeah, a federal nation.

Braden Sidoti
At the start of my intro, I didn't even get very far. But anyway, I know one time, side projects, side projects always need authentication. Yes. Back in about 2018. I was asking my brother Colin, who was a co founder of clerk, I was asking him how to do authentication. I was like, why is this always so hard? And you know, pointed me to zero and some, he was a Rails guy. So also, like, devise and setting that up, and I hated rails, quite frankly, was very confusing to me.

Ryan Burgess
Just, you know, hate on that. I'm like, Yeah, I didn't do so well with Rails either. Anyway, we

Braden Sidoti
just decided collectively, there should be an easier way. And that's when we set out to kind of make it easier and it kind of clerk kind of evolved from there.

Ryan Burgess
Awesome. That's not super helpful. And then I guess, yeah, favorite Happy Hour beverage.

Braden Sidoti
Might be a Moscow Mule drinking a Moscow Mule. They're very delicious. There. Yes. Probably too busy to drink. I have to calm down in mind for today. Faster, but you know,

Ryan Burgess
and you are drinking it in the proper copper mug, too, which is awesome. That helps make it stay cold. That's probably why it goes down so much easier to you

Braden Sidoti
know, I don't think it helps make it stay cold. Maybe it does. I just know. The cup is cold, right? Which probably means it's not holding. It's not retaining heat very well at all. But it's it's all about that feeling right? Like, yeah, it's cold. It feels good. I like it. Yeah, so

Ryan Burgess
that works. It's a good drink. I'm a fan as well. Along with Braden joining us clerk has been nice enough to help support front end happier podcast and sponsor this episode. With clerk you get complete user management with pre built UI components for sign in sign up user profiles and organizations. The authentication is MFA SSO magic links, SMS, and bought detection clerk provides helpful SDKs for modern frameworks such as next.js, and react. seamless integrations with popular databases, even clerks free tier offers up to 10,000 monthly active users, and you never pay for a user's first day, everything you need to authenticate and manage your users freeing you up to focus on building. So yeah, let's, you know, maybe get back to authentication. Maybe we'll start off to like, because you mentioned a few methods like Oh, auth and divide. I believe that for Rails, what are the common methods of like for software authentication used by modern applications today? Like if you were building something, what are your options?

Braden Sidoti
I think I mean, so somewhat depends on what kind of application you're building, but the options really haven't changed. And there's kind of like a theory behind authentication in general. And it's really boring. It's like not anything revolutionary. But the, as far as authentication goes, there's like three different ways to authenticate. There is something that you know, something that you have, and something that you are, those are like the three types of secrets, something that you know, is like a password. Something that you have is usually a UB key. But like, if there's like a phone is a decent proxy for something that you have, well, a phone is something that you have, however, SMS message is a decent proxy for having a phone, which is not perfect. And it's something you are is like biometrics, which is its own thing. So like when you start talking about like, those are the three ways to prove you are who you are right? Unique, right? It's one of those three things. Maybe there's a fourth that I'm there's some other one that I'm missing, but those are the standard three. And so when people talk about multifactor off, it's usually you should have to have those three categories. So it's not rocket science, but the most standard one is passwords, that's been around forever, username, password, then there's any variation of having an email address. And that basically boils down to something you know, if you follow the chain, sending yourself an email code, and then opening your email. And clicking on that and getting that code boils down to the password, you know, on your email address. Something you know, and then yeah, you mentioned OAuth. OAuth is kind of basically another proxy of something you know, depending on how it's implemented because it will especially if you sign in with Google or sign in with Facebook, it usually boils down to the weak point which is that password, it always goes usually goes back to a password unless of course you have. But yeah, I mean, that's, that's really yet those are the ways to sign in those that's like the very bare bones of it. It's funny, I think like, the reason it is so complicated and is so painful is, to me it's a lot of it's the web, the web makes things much more challenging than they need to be. It's like this weird, quasi secure environment that you need to know so much about that, we are just trying to simplify and make it so you don't, as a developer need to know all of the nonsense. You don't need to know that how cookies work, you don't need to know about browsers work, or the differences between Safari and Chrome and Firefox, like, it should just work. And you should be able to just work off of a different abstraction that is like, much, much more simple. And we hide away all the ugliness. That's at least the entire premise of cleric. And that's what drives everything we do. And often, it makes a lot of challenging work for us internally, to hide some of the ugliness especially on browsers. But yeah, I mean, it's, it's like the first thing you often have to do whenever you're making any sort of application. And it's also obnoxiously challenging when all you want to do is build your application. So

Ryan Burgess
yeah, that's not the like, fun part. Rarely, it's like, you're like, I have to do this I you know, I'm not always there's some applications, you don't need to like authenticate, but majority of them you do at some from pretty much everything. And yeah, it's just like the one thing as a developer, I'm not like, you know, what I love doing is building authentication. Like, it's like, it's not like a fun at all, you're like, I need it, I want it to work, I want it to be secure. But I think then even also, like, you've nailed it on the browser aspect, like dealing with cookies, each browser is a little bit finicky that you're having to deal with. And it's all those little nuances that add up really quickly. And you do if you can just abstract that away, have an API that kind of takes care of that for you. That's huge. And you just don't have to worry about it. But yeah, building that authentication. Also, another thing is worrying about the security. Like, I've never considered myself a security expert. I've you know, definitely worked with a lot of security engineers. Over the years, I've learned a lot building my own applications. But it's not easy. Like I remember rolling my own authentication over the years. And it's like, the amount of mistakes I made for simple hacks that I'm like, oh, yeah, yeah, I should probably prevent that injection, that probably is not a good thing. And it's like those little things. It's a lot to remember. So I love hearing about the abstraction. But yeah, like what else has been really difficult. You mentioned to like, iOS, working on that, and that you were frustrated. And almost why clerk exists is because there's got to be an easier way. Yeah,

Braden Sidoti
I mean, it's funny, it's and I, I kind of have issues with easy the word easy, because it's like, it's not, it's not hard. It's like, well, it's fair. It's not hard. It's big, right? Yes, it's just very, very big. And all the little steps compound and make it way more complicated. Then what you want to do when you're just trying to build whatever you're trying to build? And should you have a security expert who's keeping up to date on all of the weird changes in browsers and weird exploits that come up? It's like, it's like just its own kind of full time job. And I don't think like, like everyone who's a developer, I think is very, very capable of doing it and learning all of it. Like, it's so straightforward. It's just like, these basic flows. And honestly, it's like, a lot of them are outlined by the government, like a lot of what we implement, and it's just like the NIST guidelines. And they've done a ton of research. And that's what we follow, for the most part. And yeah, so it's just a lot. But things that have been hard. The things that have been hard is making it easy, quite frankly, and abstracting it. That's definitely been the hardest part of it. And it still is today. It's I mean, another hard part is keeping up with all the insane trends in the JavaScript ecosystem, the JavaScript world.

Ryan Burgess
That's constantly in the frameworks and things like that, or just literally things that need to drastically change from a security standpoint, or maybe both. Yeah,

Braden Sidoti
I mean, well, we started five years ago, like right before COVID. And so in that time, we've started browsers have started to get rid of like, third party cookies, which you shouldn't be using for authentication. Anyway. However, we have hacks around that in development to make development instances easier. But that's changed multiple times. And it's not like consistent across browsers. So like, so far, he broke it first. And then I think fire If I followed and like Google's kind of like lagging, well, there's also changes there just on the browser level and how cookies are handled, which for us, at least, we want that startup experience to be incredibly simple. We want you to be able to add authentication, multiple lines of code, and not have to worry about like cores errors and things like that, which means we are a little bit more lacks on the security, the development thing in the development ecosystem. There, I feel like we kind of had to rebuild that, just that part how how authentication works in development instances, simply like three or four times in the past five years. I guess to I should I should explain that. Like when you're starting up your application, in development, you're usually on localhost 3000. And your API is usually something else. Maybe it's localhost 3001. Your that's now immediately a cross origin system. And so if you don't set that up, or no, to set that up, immediately, you're going to run into of course error, and you're going to hit Stack Overflow and probably burned a couple hours, which is annoying. It's annoying. So how do you how do sharks but I mean, so that that, like, dealing with that is annoying, but then even in the framework level, like next, Jas has kind of like, well, it's like, we started with server side rendering with Rails. And then we went to like React and client side rendering. And there's a whole bunch of caveats there. And now we're going back to server side rendering, and react server components. And dealing like authentication is state that needs to load at the start of each of these things, and still be secure across development environments and production environments. And they work in slightly different ways. It's just a pain. That's been that's definitely been the most challenging thing. And the thing that we've spent the most time on, and we're still we're still working on that. Because yeah, there's there's just kind of a lot there. I guess. So again, these these are all like, I'm talking about all things that are not even authentication. Right, right.

Ryan Burgess
Yeah. No, those are simple. Like, even just like setting a cookie. I mean, like, we do that for many things across different browsers. But like you said, even just the cross browser or cross domain, like all those six things like yep, nodding along, going, Oh, right. Like that changed. And like, you have to like, you have to deal with that change, too. Right? The consumers using something like clerk there, you know, the developers are like, I don't want to worry about that. Like, that's something that you all are, are thinking about?

Braden Sidoti
Yeah, I mean, as far as I guess back to like, what our ethos is, is this should be easy. You shouldn't need to learn about you shouldn't have to know anything about security, in order to add this, this piece of functionality to your application. Like, how many developers like it's like, almost any developer that wants to build an application has to be immediately become a security expert, even to implement, like the most basic things and like you talked about, oh, off in the beginning. It's like, why do you need to know about that protocol? Do you really care about that protocol? Or do you want it as a way to build whatever application you're building? And it's just such a huge blocker and time barrier? And, again, it's not hard, anyone can go research it and look it up. But it's like, why like, it's like, if somebody can abstract, why hasn't somebody? Well, we're trying to do it. But it's taken a long time to actually abstract that away. I mean, there's more things with OAuth, as well, like there's the simple login scenario. But there's also the sharing data across applications. You sign in with Google or Gmail, and you want this application do have access to these scopes. But basically, what that means is you want this application to be able to do something like, send an email on your behalf, or read your Google Docs or something like that. And again, that's like a whole, it's tied to this authentication authorization, like, square circle, whatever you want to say, but it's pain to learn. And it's like, there's not I mean, that's, that's even messier. Like the further you kind of get away from what's cemented the messier. It gets, like, there's, we probably have implemented like 30, or 40, like OAuth providers. And most of them are the same. Most of them follow the spec, but they don't all follow the spec. And there's, there's weird intricacies about all of them. And I don't even think we're pulling in the offense authorization piece. Like everyone handles scopes differently and stuff like that, like you try and get five multibillion dollar companies to agree on doing something and you know, they'll agree and then you'll get like SAML and you're like, Oh, well.

Ryan Burgess
It's hard to because they all have to go implement it like even you get the green on it takes the time. But then there's so much time to implement, right? That's not necessarily there like Hot priority. And so it kind of just gets kicked down the line like, Well, yeah, we'll deal with it next quarter. And they're like, Yeah, we didn't quite get there. And so like that makes sense to is, it's really hard to even just get that alignment. And that's even why browsers, you know, roll things out so differently. It's just like, really, what are those teams working on? And you know, how does it get out there? So yes, that would definitely make it harder.

Braden Sidoti
Yep. Yeah. So it's just a deceptively large problem that every application needs, that even with the existing providers, like AWS, Xero, has done a lot of things that have been amazing. They were built. Yeah, they started 1015 years ago, when, at least in my mind, a lot of this stuff wasn't nearly as cemented as it was even five years ago, or even today, like they have. It's a much more, I don't say, powerful platform, but it's a much more flexible platform. And that they give you all these building blocks. And they're like, go do it yourself, because there's no right way to do this, right clerk is like is like, no, there's a right way to do this, go look at like accounts.google.com, or like Gmail and see how they do it. And that's the right way to do it. Anyone who doesn't have that? It's like just a lesser version of that. So how do we serve besides that? And that's, that's kind of right.

Ryan Burgess
I mean, yeah. And I mean, if it's working for a large application, like Gmail, or just Google, like, all of Google accounts, it's like, yeah, we're probably pretty good. Like, most companies, if you're following that standard. That's probably pretty good. So yeah, I like that you're like, there is a right way, or at least a standard that we could be sticking towards. So that makes a ton of sense here. So you mentioned like, you know, some of the, like, security issues, and that's something that, you know, I've run into them, definitely, throughout my career, but like, you know, what are some of the best practices that you think of for securing authentication that like, you know, obviously, you all, like clerk are thinking about them, but like, even if developers are rolling their own, like, what are some of the things they should be thinking about?

Braden Sidoti
I guess, the most basic, I mean, there's, there's kind of a lot, quite frankly, I mean, the most basic is the username, password, right. But even that's not perfectly secure, give the username password, you already don't have a way to have a Forgot Password flow, because you don't write email, an email and send it to. So you kind of want that you want the email and kind of forgot password flow. Like if you're just doing you know, password, the NIST standard is like you don't like want your password to you want your password just to be, I think it's eight, maybe 10 characters or longer. And you don't want to dictate anything about that password. Like you don't want to say like special characters, and or so and so forth. Because it makes it harder to remember or it makes, you also don't want to make people change their passwords. Often. That's against NIST because again, it's just, it's like why the thing you do want to check against with those passwords is leaked tables and leaked databases, and kind of dealing with that aspect. Depending on how big you get, there will be people who like, and also depending on the kind of certainly if you're doing anything with financials or crypto like those are going to be the juicy targets. So you'll start getting people trying brute force attacks on the passwords. And it's more like brute force attacks against known leaked passwords, which is where that leaked password thing comes in. Like you shouldn't let anyone have that. Then, if you want to avoid all of that, you can just opt to use OAuth. And now you're just punting kind of your security to whatever auth providers you provide, like Google OAuth. If you want to provide more than one Auth provider, you need to know which Auth provider actually like one, you can just have separate accounts for each OAuth provider, but say like, your Gmail account, shares the password or shares an email address with your Facebook account and shares the email address with your actual email address. Do you want your user to have separate accounts for each of those things? Or do you want it to be one unified account? I guess that's less about security. But no, I mean, there's some security aspects to think about there of like, how do you want to merge these accounts, you use a gym that safely and the weakest link is going to be the weakest OAuth provider and you need to make sure that emails are verified, or you need to do a verification at the point of trying to connect these things. In this like hyper competitive world of getting people in, maybe it's your consumer app as quickly as possible. And that's a critical flow, then you need to start thinking about these things. Maybe for whatever vertical you're doing, you think phone codes would be better because everyone has phone or WhatsApp code, or Viber line depending on what country you're in. Then you need to you need to just build out that best practice which is send a code you get three tries to try it. And expires after X amount of time. I don't know if I'm answering your question. I'm just like rattling off random security things. I think you're covering

Ryan Burgess
more than I even expected. Like, I'm like, oh, yeah, like he's kind of going down like even to the UX perspective and thinking about, like, how you would even develop on like the, you know, okay, well, you need an email address or not just a user name, because like, yeah, you probably want to be able to tie it to a email just in case of the forgot password. Yeah, I love all that kind of stuff. You touched on the brute force, which is always, always a fun one to deal with. Yeah, I think you covered a lot of good ones that we need to kind of think about, I

Braden Sidoti
think the best, the best thing on the brute force is to is just locking out a customer, I think what we do well, what we do is, if somebody has attempted to get into any given email address, 100 times, then completely locked out, you needed admin to unlock that account. And also, on top of that, there is rate limiting, where you can only try three times per 10 seconds, I don't actually know what the rhythm is something like that, again, to mitigate these attacks, and then there's also IP address type blocks that you can do, but then you get sophisticated actors who can just spin up a massive pool of IP addresses. So that doesn't work perfectly. Yeah, I mean, people are creative. It's kind of a game of cat.

Ryan Burgess
I think working like, when I first started at Netflix, I did a lot of the signup flows. So I had led a team that did sign up and login for across iOS, Android, web and TV. And just some of the, like, interesting ways in which like, people do try to attempt to like brute force, or just various ways to get into even just someone's Netflix account is, is pretty creative, I'll give them that. It's like trying to like, and that was, that was always my thing, too, is I'm like, You're you're getting a free, you know, get to watch something for free. Like everyone has a Netflix account, which is not true. You know, like, it definitely is, you being a US centric view on it is like pretty much to us, a lot of people have access to, but a lot of it too was there was some countries where they would then in return, like lock people out of their account and sell it. So you could sell the Netflix account for cheaper, right? So there's weird things like that, that people were doing. I think anytime when there's some money involved, if they can make some money on it at scale, then that's what will happen. But same thing, rate limiting is very useful. You are you hit the IP address, bang on where I'm like, yeah, it works until it doesn't like it's like you can start to catch those bad actors. But people get smart, too. So it's interesting, it's not even necessarily, you know, doing something weird with passwords, it's literally just like this traffic is, is obviously doing something malicious, there's no way that a human can type the password that fast, like there's certain things that you can pick up on, and just kind of prevent that user from trying to do that attack.

Braden Sidoti
Yeah, yeah, it's something that we have implemented that clerk is that Netflix is kind of famous for is locking down their accounts to one location. And it's like, even though the IP address that they're signing in from and you know, exactly a human being can travel across the world. And so you can add that kind of protection. But um, yeah, there's no reason everyone shouldn't have that. But again, it takes it's kind of a pain to build, like, say, you build that email password flow, like, that's on one device. Now you need to be device aware. And session replication is effectively now a thing and you need to think about that. And these are just these are things we built into cleric from from day one. And it's like, again, we just looked at Google or GitHub or Facebook. I don't know if you looked at Netflix, probably not specifically, although it definitely does have cool offloads across like the TV and scanning the QR code from your phone and stuff. We haven't done that. That

Ryan Burgess
took a while though, to Yeah, it's too it's like, need that for the TV. Like, anytime you're like logging into a TV. It is painful. Netflix didn't do that for like, the longest time. And I always hated that. Like, I'm like, Oh, I don't want you don't do it often. But it's like that one time, you're like, Oh, I got a brand new TV and you're like having to do all those logins. Like it's not fun. But yeah, there's there's different ways like that. That's been cool. Slack has kind of always done that cool thing where you can like, email yourself a link and then it generates and logs in. That one's you know, not necessarily always the best but you know, there's there's definitely some creative ways out there to make like logging in easier.

Braden Sidoti
Yeah, I mean, those are magic links in there. Like that's the Yes, yes. They're kind of annoying, quite frankly, like we don't because we have so many applications using clerk we can look at general trends. and magic links are slower than OTPs for whatever reason, often and more troublesome of just like, basically taking that six digit code and copying it in, maybe it's just that people are more used to it or something like that. Or it might actually just be that this is annoying at some point. And I don't even know where we stand on it. But Gmail in particular, will delay your email by like, four minutes or something like that, if there's a link in the email, and so they do extra security scanning on it, which is a nightmare, when you're like doing these, like magic links, and you try to like, get around that. So I mean, that was like, very annoying with the magic bullet. I

Ryan Burgess
didn't know that part of it, though, too. And that makes a lot of sense, where it's like, you're waiting for it. And you're like, like, That's annoying. As like user. Yeah,

Braden Sidoti
getting a magic link through a corporate firewall is very annoying. And if you're building a b2b app, we just flat out like, don't don't use magic links, because you're gonna be dealing with Microsoft Outlook. And they are the most aggressive email filters. It's very annoying. So just use like, OTPs or something else, or sample or whatever, whatever those things kind of. So yeah, you kind of want to know your audience, for sure that that's

Ryan Burgess
funny, even just like you saying that. I was like, Yeah, I hadn't thought of that one too deeply. And I'm like, yeah, that actually is very annoying. So yes.

Braden Sidoti
So these are, some of those mail providers will automatically follow and click on links. So you need to be careful about that with magic links. Because now you just your email box, just click on the link automatically, potentially send somebody in. So

Ryan Burgess
Right. And so it's like, so basically, it's like a bot opening is opening it for you that user that's like opening the email, or it's actually just like checking that link. It's

Braden Sidoti
virus scanning, but effectively clicking that link to see what the email is about in order to decide whether or not it wants to filter or not. But if you're building a magic link flow, you need to, it's not hard to get around it right like you. Well, I'm the backend guy. So I'm a little fuzzy on this particular piece. But it's like a you like load an iframe or something, and then it doesn't get through the iframe, the iframe automatically redirects it something like that. Don't quote me on that.

Ryan Burgess
It's not it's cool. iframes still have their place here in there, like they really do. Yeah. I love that. Well, we touched on like, oh, auth a bit. And I wanted to maybe go in a little bit deeper on like, you know, maybe more in detail. What role does a lot play in in the authentication? And like, what are some common ways of integrating it to because I think over the years, it's gotten, like, there are some ways like some frameworks, I think around it, maybe I'm talking, you know, something I don't even know deeply about. But I, I have found that over the years that it's gotten a little bit easier to integrate, because people are just abstracting it a bit. And obviously clerk doing that now even better. But I'm curious on like, what's available out there now.

Braden Sidoti
I mean, so the basic flow is you go to some third party identity provider. And these terms are a little bit confusing. Like, there's a lot of legacy I O terms, that they just become a mouthful. But they're the they kind of provide the identity. So you go to them, and they will sign with Google, for example, you click on sign in with Google redirect to Google, if you're already signed in, you just have to like press their name or whatever. And then it redirects back, which is nice. If you're not signed in, you have to go through their authentication flow on Google. But again, that's completely removed from your logic. So the things you have to handle are sending out to the Auth provider, you usually provide some sort of state token, there's multiple different flows here. The mobile flow is different from the web flow, because now that spacing slightly I forget exactly why there's like in the mobile flow, you need to pass the state token because there's some sort of weird interception thing. I feel like I should know this stuff ahead. But I'm gonna blame the mule.

Ryan Burgess
You're muted. Now, the mule, the mule does that to you know, slows down the brain? Yeah,

Braden Sidoti
don't cut authentication with a mule. Yeah. But anyway, it's like you're just dealing with the callback, and then you need to check it. And now you basically have transferred the security credentials from that third party onto your application. And then you can sign it. I think we're off becomes, I guess to there's a layer on top of OAuth, which is Oh, IDC, Open ID Connect, which is just basically the sharing of like, the most basic login thing like oh auth as a spec is very large. And includes like five For six different flows, maybe more, even has like, like machine to machine. auth has its own OAuth flow, which is it's silly. It's like this over engineered thing, just to basically share a rotating secret key between two machines in your back end. But regardless, it's people are people who are used to the spec wants to spec, people who just want to do the thing, just want to do the thing. So it's like, you got to play a fine balance there. But yeah, with a lot, I think the more interesting thing is about sharing information and sharing rights across applications. And at that point, you're just granting scopes through Oh, and effectively allowing actions or authorization through through a lot. And, yeah, I don't know, it lets you build really cool applications on top of things like Gmail, like GitHub, obviously has a ton, especially for GitHub is huge, just because that's your code, you need to see ICD, you need to grant all these other applications rights. Google is also pretty big there, because they have so many applications and things like read your email. But I mean, a lot of those scopes are scary. It's like you click on something and you like, this thing can read your entire application, all your emails and send emails on behalf of you. And you're just like, I just wanted to, like, I don't even know, I just wanted to, like make it make an event through your GUI, like Calendly or something like that. So like, yeah, it's, it's kind of scary there. But I don't know, in particular, I don't think Oh, auth is, um, you know, is I actually I should say this one. It's, it's just one piece of the whole authentication story on I don't think any individual piece is particularly interesting about the authentication story. It's all been combined, that you need to kind of merge into this user object and then do something with that. Oh, auth does allow that not transferring that authorization aspect, which is nice. And also there's there's a relatively good standard ground but I feel like I'm missing something else that I want to say with our

Ryan Burgess
unblinking though, that mule man, it's just you know, that's, that's, that's fine. Yeah, exactly.

Braden Sidoti
I had a long day, I went to the gym, I came back because yeah, let's jump in.

Ryan Burgess
Let's talk authentication.

Braden Sidoti
Exactly. Maybe

Ryan Burgess
a more easier question to, before we dive into pics is, I'm curious. Like, obviously, we've covered some of the things that clerk does. But I'm really curious, like, what you know what to expect, as a user of clerk,

Braden Sidoti
I do you think the main thing we're going after is that feeling a bit just works, how I expect it to work. Which is more easier said than done. And I think with clerk two, it's interesting. Again, this is something that we haven't really touched on at all. But with any application, it all starts with the user, and the user in programming land originates at the signup, once you sign up, you now have a user. So with clerk, we are really trying to make things associated with the user easier, which is a lot of things. So when you so we have we have these like these components that basically match what Google has. So you get the most powerful one is like the the user profile component. Basically, as soon as that person is signed up. Now you can launch a user profile and one line of code. And that user can go in and add or change their email address, add or move or change phone numbers, add the OTP methods. I can connected accounts or Oh auth accounts, I think we've got we call them connected accounts, change the password and all of these things as so the user can just do all that through that that component, and then that component will talk directly to eclipse servers. So as a developer, you don't have to deal with the intermediary with your own server. And so Clerke makes that just a lot easier. And you get a lot of functionality right out of the box with one line of code with a a component. So we've really dove into the React World pretty big. And we're still working on Angular and Vue and some other frameworks spelt. But our sweet spot right now is react and adding that get that functionality. It's kind of a it's just a massively large problem of we have all of these authentication things that we need to deal with, like passkey is another thing that's new that we have out in beta, that, you know, there's I personally think there's pros and cons and a lot of people think it's all pros, and I think it will become good but it's not quite good yet but you You like want to give your customers that, that option. And so that's an authentication option. So that takes away from us being able to invest in like, view or sell through something like that. But yeah, I mean, that's, that's really our goal is just make it easier to build whatever you're building and not not have to worry about this stuff. Again, easier said than done. We're not perfect, we're still trying to get better. But I think that's what you can expect is the team behind it. We all really, it's a fun space to be it's a fun space to be a developer selling to other developers and trying to make other developers lives easier. You know, there's no, there's like, no nonsense there. We're not trying to game anyone's like emotions or something like that, like games or social media, which it's just, it does feel all good to some degree. Now, we obviously draw the line of like, we don't care what you're building, we just want you to build it easier. And I'm sure, in the future, there'll be some application that was like what we can't, that's obviously messed up. Like, that's, that's illegal. Like, we'll get in trouble if you do that. But but you know, like, for the most part, we're just trying to build tools such that other people can do things.

Ryan Burgess
I really liked that, too. Like, I think like, even earlier, we were talking about just that abstraction, and why it's so helpful and useful, is that it's like, I want to go build my application. That's where I'm targeted, you know, or like a startup, they want to just get going and you know, get that application out the door. And they don't want to have to deal with all these things. Or like you said, it's a full time job to keep up with some of the security things. That's why there's like, companies have massive security teams, like they're not just sitting around doing nothing like they're, you know, like they're thinking about these things, paying attention and implementing these, these changes that need to happen. So I love all that to where it's like, thinking of that if I'm going to build an application tomorrow, I'm like, I don't really want to have to deal with all those things, especially at the start. Because you do just want to get to the races, like you're like, I just want to help the door.

Braden Sidoti
Yeah, like, it kills the vibe. It's like, I'm trying to code this really cool thing. And it's like, do you start with the ugliness? Or do you build your application, they're like, Well, I can't give this to anyone, because it's just like it. I mean, I felt that as an iOS developer, I literally, like had off app ideas. I like built them. And then I was like, Oh, my God, it's gonna be months of work just to build the, like, user stack side of it. And it just stopped me from building small ideas and putting them out there. I mean, I think that's what Developer Tools is all about. And I think like, I like trying to push that forward. I think like, you know, there's definitely monopolized applications out there. But the lower the barrier to entry, the better. And it'll just allow more people to create applications and just build a better ecosystem on the internet. Yeah, I mean, so it's, it's cool. And it's odd that, like, authentication still doesn't fully feel solved, right? Like, it doesn't, nothing really feels, still feels really solved. And like, maybe it never will, too. Because you also need the competition of, of different platforms to kind of improve things and stuff like that. And, yeah, it's, I mean, it's hard. It's interesting. It's, it's what makes it easy for me to be interested in talking about authentication for an hour, and still have missed a ton of topics. And oh, it's

Ryan Burgess
a deep topic, like you could you could spend so many things, we've just scratched the high level of this stuff. And that's where I'm like, yeah, we can go very deep on it. I also think like you touched on something that I really liked, too, is it's, it's one of those problems at start, where like, nobody wants to deal with this, right? Like, we said, we just want to build the application. But I think as an engineer, that's so cool is dealing with fun problems, like challenges, and like dealing with that. And like, all around that ecosystem around authentication is super interesting. Like, that's the cool thing for you all, is you're like, we want to do this really great. We don't want you to have to think about it. But we're gonna, you know, make that easier for you. It's still like fun challenges on your side of the fence, which is kind of cool. Oh,

Braden Sidoti
yeah, for sure. I mean, even even scaling issues like, we get to play with kind of like edge compute, to because the user signs into a specific location and cloud players a lot of pretty exciting tools about putting that information in the location where the user is more or less like, they have just tons of parts all around the world, but it adds complexity to the whole thing. And so when you are building an application, you obviously want latency to be as small as possible. We're obviously imposing this challenge on herself by trying to offer this as a service. Traditionally, like you would just host this alongside your database. But we are building the tools to both like you can serve resize it and, and still kind of have the benefit of the low latency, which hasn't ever really been possible, at least in a way for a company like clerk to provide that feature set? Like, maybe Google is very good at it or or Facebook, but they're behemoths, right? They can invest in their own servers or Netflix as well. I don't even know what the CDN, like pipeline of Netflix is probably a while. It's probably really cool. But it's

Ryan Burgess
interesting. It's a, it's a fun, one of those deep paths that you can go down. And it's interesting to see because you're right, like you're dealing with video to like specially early days of streaming like, it was not easy, right? So yes, it's, you're right, like, you can kind of just go in these down these like, deep, deep things that it's challenging and rewrite scale. Scale in itself is always a fun challenge. And it's probably a good time for us to dive into pics. In each episode, the front end happier podcast, we like to share things that we found interesting. Sometimes they're topic related, sometimes Absolutely not. Braden, to not put you on the spot, I will go first with my pick. And you know, let you choose something as well, for my pick, I just have one this episode. And it was an article I read on the New York Times I think it was, I think it was from about a month ago or so. But it was about car manufacturers, like brands selling your data, right, like now that we have more of these connected vehicles, like a lot of cars have internet in some way, shape, or form. And there's a lot of data collected on you on like, how you accelerate how you break. I don't know if it's like location based, it probably has, it would have to have that like OnStar and things like that have to have all that information. But they're selling that data to, to actual, like insurance companies. And like to me, there's so wrong now the insurance company's like, well, this person. Brandon's a bad driver, he's always accelerating stopping all that, like, there's no context to that data that's like, well, that doesn't make you a bad driver. But they're using that to to then inform decisions. I know for me, I'm very guilty of accelerating all the time. It's like, I don't think that makes me a bad driver. But it's like in their eyes, probably. Yes. So that was an interesting article that went deep on the details around this, GM was called out really hard for it. And since the article came out, they are now stopping selling your data or so they say. So this is just an interesting little article that took me down a rabbit hole. So I thought it was pretty interesting. So I will link that one in the show notes.

Braden Sidoti
Wow. Yeah, that's good. Yeah, keep my my 2009 scientists is yeah,

Ryan Burgess
if it's not connected, you're like, This is a bonus. Like we're all gonna go out and just be like, yeah, get rid of all that connected business. Yeah. Well, yeah. Cool. So yeah, so Braden, any, anything you want to share that you found interesting with our listeners,

Braden Sidoti
I like things that are, like, it's I feel like there are things that are a small benefit, like, but like make a huge impact, like that small benefit makes you use that thing a lot more. And this is like classic gamification. Like, I guess it would be the first thing like at one point, I have like the Reddit app on my phone, and I was using it way too much. And I just deleted the app. And now I go to the website, but that additional friction of having to like, type that into Safari, and then go and visit. Reddit just makes me use it less. And I'm not like stuck, like I don't get like trapped using it. So I think that's interesting. But this ties back to the thing I actually want to talk about, which is a very large tote bag. It's amazing. I have like I got this like 70 liter tote bags in Patagonia. And it's large, it's very big, but like I went skiing, and you just throw all your shit in it. You don't have to like zip it up or anything. It's just an open bag. And it made skiing so much easier. And I love it. I would recommend the 70 litre tote bag from Patagonia carry all your stuff. That's

Ryan Burgess
amazing. I love it. It's such a simple thing, like you said, but I can see how it would be very useful. So very cool. Awesome. Braden, thank you so much for coming on sharing some really good insights into authentications it really sharing how clerk works and operates. I love what you all are doing. I think that's like, just music to my ears as a developer going. Yes, thank you for taking some of the things off my plate. Awesome. If people want to learn more about clerk or authentication, where can they get in touch with you?

Braden Sidoti
So you can email me directly at Braden clark.com Or bring that court data, but you can also visit court.com and kind of learn more about the product. I guess spell my name br ad Yeah. Yeah,

Ryan Burgess
that's always that's always a good one too, is like yeah, how does that spell? Well, thank you so much, and listeners you can find us on Twitter at @frontendhhw front end happier.com on YouTube at front end hh you know all the things yeah thank you all for listening thanks for having me