117 - Authentication with Aviad Mizrachi

Programming Throwdown Episode 117: Authentication with Aviad Mizrachi Patrick Wheeler: Programming Throwdown Episode 117: Authentication with Aviad Mizrachi. Take it away, Jason. [00:00:24] Jason Gauci: Hey everybody. So when you get to your house or, or the place where you live. And you have your key. You turn it in the lock and you get in. And if someone else has a different key or if they don't show up with a key, they can't get into your house. And this seems pretty straightforward, right? And, and also if you give your key to somebody else, they can, they can get into your house, right? So, so authentication, sort of, in the real world makes a ton of sense, right? [00:00:49] But authentication over the internet where you're sending this information to all of these different computers, so it can get to its destination. That seems pretty wild. And it seems pretty unclear like how that can actually work and how that can be safe. And so it's a really interesting topic. I'm really fascinated by it. [00:01:10] And we have an expert, we have Aviad Mizrachi on the show, who's the CTO of Frontegg, to dive really deep into this and talk about authentication, how it actually works. [00:01:21] So thank you so much for coming on the show Aviad . [00:01:24] Aviad Mizrachi: Yeah. Thank you guys. Thank you for having me. [00:01:26] Jason Gauci: Cool. So yeah, before we really dive deep on the technical stuff, it'd be really great to hear your background and your experiences, and what path you took to get you where you are now working on Frontegg, which is a platform that handles authentication and a bunch of other things, but, but what's your background in computer science? [00:01:52] Aviad Mizrachi: Yeah, sure. So I been coding like professionally for the last 20 years. Been working on really exciting projects. And with the era of everything moving to the web, like I shifted my expertise. I started coding, like, as I said, professionally, when I was 20, just out of the army in Israel, started working my way up with C++ and .NET, which was really hot those days. But around, I would say five to eight years where like everything shifted around the web and product start evolving, we saw like a lot of the flows really becoming the same. So I ha I was working on few, like really interesting project, both developer, R&D leader, architect, R&D manager, actually the last two years before founding Frontegg with my co-founders Sigi. [00:03:01] We met at Check Point, which is one of the Israeli largest cybersecurity companies. And we had the privilege of leading a platform for SAS application, basically found in a platform for SAS application and leading it. And then when we passed that, all the things that we had to develop up until that point are pretty repetitive. [00:03:25] So we will touch on authentication in a bit, but you develop authentication the same flows all over again, the same multi-factor or the same security policies, the same user management invite, the same session time outs. Okay? And that's only like the tip of the iceberg because you have to develop everything in a self-serve mode. And basically everything is being very repetitive into the world. [00:03:54] And this is pretty much the reason that around two years ago, before the COVID hit us, we founded Frontegg, which our mission is basically to fight this repetitive to give back the power to develop, to focus on what really matters and to provide our expertise around everything that is very much like it's the core of the product, but it's, it's actually not the core of the product. It's something that you must have, but it's actually, it's not the reason that you founded a company for. So this, this is Frontegg. We can elaborate like later on, on what exactly we're doing. If that makes sense. [00:04:36] Jason Gauci: Yeah, that totally makes sense. Yeah. I think, I think it's, it's a really good point. I mean, very few people want to dedicate a ton of time and energy really perfecting their login, right? The login is ultimately to identify and secure people's identity and information so that then you can provide them some service, right? Which is that's the part that most companies are really interested in. But, but then they feel really compelled to pay a lot of attention to it because if someone can compromise it, I mean, we saw this with Target. And we saw this with, even the, I think Equifax or one of the people who handle the report of, your credit report. [00:05:19] And so many of these things get hacked and a lot of it is through the being able to get authenticated as, as basically anybody you want and then taking all the data. You don't hear as much about like SQL injection and these kinds of attacks. I mean, most of the attacks that, and I'm not a cybersecurity expert by any means, but most of the attacks that at least I see in the news are things where the authentication system has been compromised. [00:05:46] You know, I think that that it's something extremely, extremely important, but also something that's not central to sort of the core mission of many companies. And so it seems like a great thing to build a service around. [00:06:00] And also there's so many different intricacies to it. There's social login. There's login through a phone number. There's email and password. And then you have to verify the email and there's so many different steps to that flow and, and people could get hung up on every single step. So there needs to be a way to kick any of those steps. Send another email, send another text you know, eventually time somebody out, right? All of that stuff is, just adds so much complexity to the developer experience. [00:06:32] Aviad Mizrachi: You touch, you touch the exact point of why this is not as simple as, as you may think. So I had the privilege of managing a lot of very talented R&D developers over the years. And when you asked, like developers can be a little bit of show offs and when you ask them, okay, we want to build in a, we want to build a new product. [00:06:57] Obviously a new product always starts with the signup in the log-in as I, yeah, this is very easy. We do email, we do a password. We give them a reset password lead and yeah. And we can close it. I would say it would take me around, around the week. But then when you dig in a little bit, like deeper, you start considering, how do I send the passwords over? Where do I keep them? How do I keep them? How do I maintain these tokens? How do I maintain these email templates? Okay. What kind of MFA method should I choose? Do we go with the LTPs? Do we go with SMS? Do we go with emails? Like in Check Point, one of the things the security research team did was proven that SMS is like hijackable in no time. [00:07:48] And then you, okay. So maybe SMS is not the better. So let's, let's dive in and start identifying which, which MFA method should we use now. Today with the rise of FIDO keys, FIDO is like the new, the new thing to adopt. And then which SSO would you choose? How do you handle overflow? How do you handle SAML flow? How do you handle open ID connect flow? How do you audit all of these for the compliance and regulations? How do you handle multitenancy? How do you handle security policies? [00:08:27] And then it becomes like this project that it started with, with the developers, say. Yeah, it's going to take me a week. And then you find yourself three months later in a tech debt that you started and then you don't know when it's gonna, it's gonna be finished. And then, yeah, this is the reason I think that like authentication has become a little bit of, there are great companies out there that are doing that. [00:08:58] We need to become a little bit of commodity because like the simple stuff is simple to solve. And today, a lot of companies that are working around that education, there are nice open sources around it. And, and you, you really need to know your way when you're choosing these tools to see what exactly is the difference, which method do you want to go with and to provide a perfect user experience for your customers. Because today user experience is as important as the security aspect of the product. [00:09:35] Jason Gauci: Yeah. Yeah. That makes sense. Yeah. I think I've seen, I think it was LinkedIn posted that basically every step someone has to take to create a LinkedIn account, every single step churn's something like 10 or 20% of the people. [00:09:50] Now, like maybe, at least to the first step maybe, or a lot of those are bots. Right. But, but I mean, at some point you get to like, yeah, we're a lot of real people say, oh, well, if I have to give my phone number and I have to give it again, and then they have to text me and I have to answer a text, like the more of these steps you have, the fewer people are going to be on your platform. [00:10:09] But at the same time you need to have a platform that's secure. Otherwise then once it's compromised, it's very hard to build the brand back. Yeah, we should, we should unpack a lot of this, so, well, I definitely want to put a bookmark in MFA multi-factor authentication, or we should talk about that. [00:10:26] But first let's just talk about when someone types a password on the internet. How does that password get to the server without somebody just seeing it along the way, and then just having your login information like, like how does, how does that work? How do you basically give your keys to a hundred other computers without someone just being able to get into your house? [00:10:50] Aviad Mizrachi: Yeah. So if we touch in on that, so there are several ways to let's talk about the flow. So there are two main methods to send data to the server. So it's either query param, or if you are doing a post it's through a POST body. [00:11:09] So the query param, not the good way to go with basically two reasons here. Like your rails are going. And there are been transients around the way and they are being cached, which is really, really bad. [00:11:26] Jason Gauci: Just to give a bit more background here. So the query param is when you type a URL into your browser, sometimes you'll see this, you'll see like question mark item equals 13 or question mark foo equals bar, right? And that, what that is, is actually it's sending, in addition to the URL, like google.com, anything after that question mark, it goes to the same URL, but it's like extra data. So you could say my website.com/login. You know, question mark a whole bunch of things, A equals B, C equals D equals F just, I think they're separated by commas or something. [00:12:03] And then, and then it'll still go to log in end point, but it'll get all of those things, those query parameters, the problem is everyone on the way can just see all of those in plain text. Yeah. [00:12:18] Aviad Mizrachi: That's one problem. And the second problem is that the browsers are maintaining our history. So that means that every URL that you're pushing basically is being sent, saved on histories. Especially if you are typing that on the quote on the, on the browser, on the browser bar. So that's, that means it's automatically saved on the cache of the, of the browser. And that's, that's really bad. [00:12:46] So I would say that there are two major points that you want to pay attention to when you're sending passwords to the internet. So first of all, I would recommend always using POST body. Okay. POST normally are not cached. This is good. So always use as a POST body and always make sure that you're, when you are sending data to your endpoint, it's an HTTPS SSL with a legitimate, legitimate certificate, because that means that unless you have, you're less prompt for many in the middle of decks with SSL certificates. So if you, if you have to send passwords to the, through the internet, POST body and SSL is mandatory. [00:13:37] Jason Gauci: Yeah, I'm gonna, I'm going to take a crack at this, and then you definitely fill in the gaps here, cause I'm sure I'm going to, I'm going to mess this up. But I think the way SSO works is the browser itself has some type of, of key or something like that from a bunch of registrars. And so when you download the browser, you get sort of ways to encrypt data. And then when you go to an HTTPS site, the browser encrypts the data and sends it to the server. And then the server is able to, using these same services like Let's Encrypt or these other ones is able to decrypt that data. [00:14:20] And I think it has something to do with the fact that the you downloaded the browser and the browser has some special information. That's what allows you to encrypt something without having to basically ask for permission over the internet, which there's sort of a chicken and an egg there, right? And so the HTTPS gets around that through the browser. Is that, did I get that right? [00:14:44] Aviad Mizrachi: Yeah, that's correct. So the browser is responsible for the encryption and the endpoint, which is basically the servers responsible for the SSL termination, which basically means get an encrypted data decrypted, make sure that it's valid and basically handle it. [00:15:05] Jason Gauci: Yes. So, so it's like someone, to use the key analogy, it's like you let someone into your house, this is the browser that you downloaded. You let someone into your house, they give you like a special encryption tool, right? And then now if you want to send a key to somebody through the mail or something like that, you would somehow like the letter, the envelope needs that tool to open. [00:15:32] And so you might give a letter to the postman who gives it to someone else to give it to someone else, but none of them have that tool that person came into your house and gave you. And so they can't open that letter, even though they have it. And so then eventually it gets to the server. [00:15:48] The server can also talk to that person who went into your house and gave you the tool and the server can decrypt it. And so in this way you know, even though you're going over the internet and so many people are seeing your password, they're seeing an encrypted version of it that they can't, they can't untangle [00:16:06] Aviad Mizrachi: That's 100% correct. So yeah, the use of private, private public keys, asymmetric encryption along the internet basically changed the way that we are processing data. Makes it much more trustable. Even along with, with the we'll touch base a little bit on the way that we are handling, eh, authentication and what are the methods do we use session-based? Do we use JWTs? But like jumping few minutes before that when we are sign in authentication keys, normally that's, that's the way that we are doing it way sign in with some private key that only the server has, and we are giving the public key to everyone just so they can verify the authentication of the server. [00:16:59] Jason Gauci: Cool. That makes sense. Yeah. So let's unpack some more of this. So you know, we talked about, you talked about MFA multi-factor authentication. What is that all about? [00:17:11] Aviad Mizrachi: Yeah, so passwords are easily hackable. Okay? So. Most of us do not get our browsers, advise us on breached passwords or, so we are using the same password for all of the websites. [00:17:29] So if password, and then basically that means that we are trusting the server or the endpoint or the service that we're using to maintain our password security. Most of them do. Okay. But some of the, you just mentioned SQL injection. Some of them do not store our password securely. And storing it securely means at least hashing and salting them, on the database. So they are not easily, I would say reversely engineered. [00:18:03] So if the service that we're using and we sent our password to didn't maintain it properly, that means that it's easily hackable. And once one service is hacked. That means that if we reuse the same password all over again, and the other services, for example, I were banking account our LinkedIn account or Facebook account, our Twitter account, et cetera, et cetera. That means that the attacker can potentially go and hack all the other accounts by a very simple operation, by going on a breached passwords database and go in and trying. [00:18:47] So this is where MSA comes into place, where basically there is another level of authentication that you have to prove that you are actually the originator of the request by proving another, we call it possession on the authenticity. So for example, I try. I onboarded MSA on my account. And let's say that my password was breached. So we have an attacker on the other hand who is trying to login to my bank. Okay. So he has my email and he has my password and he types it in and they're correct. [00:19:26] But now he is facing another level of challenge where he has to prove a code which has been sent, let's say, we'll take the easy, but not secure way of SMS. So now he has to type an SMS number that he sent to my phone. Okay. So first of all, I got this SMS. I immediately know that someone is trying to look into my account and I'm probably going to change your password after that, but that blocks the attacker from actually logging into my account because I have another level of authentication that needs to prove it basically who is trying to log in is actually me. [00:20:11] So that, we have several methods of multifactor authentication. I mentioned the TOTP, which is one of the most popular today before the FIDOs came into place. TOTP basically means use of either Google authenticator or Microsoft authenticator, or there are tons of authenticator apps available for download for any app from any app store. [00:20:38] And the idea is that you are being assigned with a number, six-digit number for 30 seconds. It's based on a seed. And the idea is that it's based on the same seed that is running on the server. Okay. Based on times and right after the authentication, you have to type in another. A number that is available only form your authenticator application. [00:21:10] So that's a TOTP. There are several other methods such as SMS, which is the same. If you're sending an SMS to the phone number that you, that you signed up with, you just mentioned the phone numbers are not information that we likely want to share with the services that we're using. We feel more comfortable by installing an app on our device and not sharing the phone number with the services. This is why SMS is not that popular and it's easily hackable suggest, like, just go into your favorite search engine and search for SMS hijacking and then SMS MFA. [00:21:57] Jason Gauci: Yeah, I think the one I remember I'm sure is a ton of them, but the one I remember was when Jack Dorsey, who is the CEO of Twitter, correct me know, feel free to look up the article. But I think what happened is somebody called Verizon and said that they needed to transfer a number. And they were actually able to with very little proof, transfer Jack Dorsey's personal cell phone to their cell phone. So they had Jack Dorsey's phone number. [00:22:25] And so I'm assuming they started just getting calls. People were trying to call the CEO of Twitter were now calling this random person. And what they did with that is they kicked into the MFA. They tried to log in as Jack, and then when they couldn't, they said, oh, I forgot my password. You know, send me a text with like a reset. And so Twitter did that. [00:22:45] They clicked the link, they changed the password, and now they have the CEO of Twitter's Twitter account. And and so they posted all these things. I remember where they post some show was terrible. Or I think they asked for Bitcoin or something. I don't remember, but yeah, so that you can see how that's a massive, massive problem. And so with SMS, you're relying on the phone company being able to secure your phone number and it hasn't been that good about that. [00:23:09] Aviad Mizrachi: Yeah, exactly it, but you know, when, when we are discussing MFA and when, when we are discussing security and authentication and utilization, there is a constant tension between product and security, right? [00:23:24] So security, the security guys wants everything to be as secure as possible. And no one can log in. No one can sign up without verifying their email address. MFA, they must use a Google authenticator, et cetera, et cetera. But you know, sometimes product defined by the security level, because, I'll give you a certain example with my mother, which is a very technologist person, but I couldn't get her to install an authenticator app on her phone. [00:24:04] She's she feels much more easy with SMS. Although I explained several times that SMS is not good for her, but even the bank account requires her SMS because they say, well, we, the type of people that are going into the bank, you cannot expect everyone to know what an authenticator app is. So you have to do some compromise in order for the product to be usable. So that's, that's always the tension with MFA, MFA is just the beginning of it. Session time outs. It's just another center of it. There's always a tension between product guys and security guys. And the is probably somewhere in the middle. Now it's more towards the security today with PLG is for example, I just mentioned it with PLG is you're not required to verify your email anymore. You sign up, you type in your password. I can sign up as Jason. Okay. With your email, you'll get an email, but I'll be able to log in because I tapped in my password. Obviously after three days, if I didn't verify my account, my account will be deleted by, but that's, you just mentioned with the LinkedIn research. There's constant tension on providing the best user experience. And sometimes security is just another hassle on the way. So this is, this is something that we are constantly facing from the product side and from the security side. [00:25:41] Jason Gauci: Yeah. Actually it just hit me when you, when you were saying it. Yeah. So I have a email that's totally available. Anyone can get, can get access to it. And so, because of that and, and, and show I, I tend to get a lot of strange emails and yeah. I have gotten emails that were effectively from products I've never used, but they sounded like they knew me and yeah, I think what's going on there is, yeah, people are using my email and then logging into some type of product, and then they're able to do things while they're unverified. Of course. I never verify, that would be crazy, but like, I I get the email asking me to verify and then, yeah, it's a really good point and I never really connected all the dots, but, but yeah, wait until you're verified, many products will let you do things, but, but maybe not everything. [00:26:32] And, and, and there's very good reason for that because yeah, there's definitely people have used my email address and I guess done as much as they could unverified before maybe their accounts finally get banned or I don't know what happens. [00:26:47] Aviad Mizrachi: Yeah. There, I think there is a main reason why email verification today with the PLG world, email verification is not that, that popular. So first of all, Yeah, we, we seen, we seen it ourselves. There was a drop of convergence when we requested people to verify the email address. Okay. And there are tons of research about it. But even if we do ask them to verify their email with, with so many services around temp email, and that stuff, you never know who the user really is because everyone can go on the internet type in 10 minute email, 10 email address. They can set up an email address for one day. Okay. They can work with this email address for one day and experiment any product. So it's not that it's on the contrary or security, but you know, even verification is not that mandatory in the PLG board. [00:27:53] Jason Gauci: Yeah. Yeah, that makes sense. I guess it only becomes an issue if then I wanted to use that service and someone else is already using it with my email address. [00:28:02] And I guess at that point I'd have to call in or something like that. [00:28:05] Aviad Mizrachi: So this is exactly where single sign on step into the play, because let's say that someone is using your, I don't know, your Gmail address. So this is where they will never be able to login with your credential through SSO, because you're the only one that can log into the address itself. [00:28:30] Jason Gauci: Yeah. Can you dive into that, I actually don't know what SSO is. I've heard the name, but I don't know much about it. Can you, can you dive into that? Yeah, [00:28:37] Aviad Mizrachi: Sure. So SSO stands for Single Sign-on. And there are several methods of single sign-on where ours is by far the most popular one. We refer to a social initiated login, and that goes all the way to much more complex protocols like in other subset of our, which is open ID connect and obviously summit, which is a, we call it the enterprise single sign on. [00:29:09] And the idea of single sign-on stands for, you have one identity. Okay. And that can be your Google identity or Microsoft identity. You'll GitHub identity, or your Okta identity. Okay. As an, as an enterprise organization. And on each product that you are using on each service that you are using, you should be able to login with the same identity. [00:29:38] And that, that's good for several reasons. So first of all, the set, the first reason is that you have one password to remember, one MFA to set up. Okay. And all the other services are basically relying on the same identity provider. So it stands for you have one identity provider. If you are doing login with Google, Google is your identity provider. [00:30:00] If you are doing login with Microsoft, Microsoft is the identity provider. And basically you can see every application what's is using for your service, et cetera. And so that's from the identity standpoint. And from the organization standpoint, before I take it one step farther for protocols like and organizational single sign on, the IP administrator of the account can basically, once you decide to leave the organization. So it's very popular in a B2B applications. Once you leave the organization, the IT administrator of the organization needs to delete you for one repository. And that's the identity provider repository, whether the G-Suite, they delete you once and then you lose basically access to all of the other products you logged into as the employee of this organization. That's basically the whole idea around single sign on and enterprise single sign-on, which basically gives the power back to the IT administrator and to the identity provider to, to maintain all, all of the authentication flows. [00:31:23] Jason Gauci: Got it. Okay. I think I get it. So the idea is effectively from a developer standpoint, it's a, it's a handoff type thing where someone types in a password. I don't know if you do it on the client side or on the server side, but you get someone's. I actually probably don't get someone's password, but you get, you somehow are able to show somebody content from Google and Google ask them for the password. And then Google tells you yeah, this person, this person is good to go. And then you trust that Google has done the right thing. And so once Google tells you this person's logged in and they are, they are this email address, then they're in at that point. [00:32:02] Aviad Mizrachi: Correct. So the way it actually walks is that you are clicking, so we can, we can type dive into depth. You click on the login with, let's say Google, for example, you click on the login with Google button on the application that you are trying to go into. Then you are being redirected to the Google authentication, you're being taken out of the application. Okay. So you're being redirected with the client ID of the, of the application, which asked for this identity, but you are being redirected to Google. You type your password in Google. Okay. Not in the application. The application has no idea what is your password. It knows only your email. And then basically once you are redirected back to the application, the application is doing some token exchange with Google to get your actual identity with. And that would be the email and most, most of the times your entire profile. [00:33:06] And then basically that means that you are logged in to this application using google. Okay. So that means still the application is the one that generates the authentication token for you, but the identity provider that has been responsible to provide it, the multifactor authentication for you or the identity provider that is being responsible for the password maintenance is Google, not the application [00:33:38] Patrick Wheeler: Today's sponsor for Programming Throwdown is SignalWire. SignalWire is a pretty awesome company that allows developers to use multiple languages to call their APIs and deliver low latency video and audio technology. So imagine if you're building an application or a website and you want to host an interactive event, like a charity event that they supported for the American Cancer Society, where they're able to have multiple rooms, people interacting in the rooms like a video conference call, but like way more tailored to your specifications, and so much more flexibility in the APIs that enable you to do that. [00:34:15] They're already being used by large TV studios, film companies, Fortune 500. These are all things that are definitely been battle tested. And today we are happy to have them as a sponsor of Programming Throwdown. [00:34:29] Jason Gauci: Yeah. SignalWire provides expert support from the real OGs of software-defined telecom. These are the original geeks of that technology. SignalWire's complete unified platform for integrating videos as well as voice and messaging capabilities into any app. You could try it today at SignalWire.com, and use code THROWDOWN for $25 in developer credit. [00:34:52] So you go to SignalWire.com and use the code THROWDOWN at SignalWire.com today to receive $25 in developer credit. [00:35:00] Patrick Wheeler: Now back to our episode. [00:35:03] Jason Gauci: Got it. Okay. That makes sense. Yeah. And I think people are starting to nail these. I'm starting to understand now why you need, you need session tokens. So we should talk about, you talked about session timeout. [00:35:14] And so all of this that we're talking about, there's a lot of steps to this. There's a lot of complexity. There's reaching out to Google and coming back. And so you don't want to do this every single time. Someone wants to access anything on your website. And so that's where the session token comes in. So you basically, and please fill in the gap here, but I think basically the way it works is once you've all agreed on something, then you can create this, this token, which is good enough. Like once you have this session token, that's all you need to be authenticated. [00:35:49] And so in that sense, it's vulnerable, right? Like if I can go to your computer and get on your browser and start copying the session tokens out of there, then I can be you, right? And so, because it's insecure, they, it has a timeout, so maybe it only lasts for a day. So at most I can masquer- if I stole your laptop or something, at most I can masquerade as you for a day. If I sold a laptop, that's different. If I, if I somehow just stole the browser, the browser cookies from your laptop, then I can masquerade as you for a day. [00:36:21] But eventually that session token will expire. And so you'll have to go through this process again, of authenticating. And at that point, at that point, then, then you wouldn't be able to be as that person. Is that, is that how the session stuff works? [00:36:36] Aviad Mizrachi: Yeah. So that's, that's correct. So the most days they're almost top 10, which is the best security practices for, you can take the best security practices from there of how to maintain the best security for your website. And XSS, I don't remember the exact number, but I believe it's number three. We can check it out, but XSS can be easy, but normally what you can do with XSS, what you want to do with XSS, XSS stands for cross site scripting. You want to hijack your victims, access token. And this is why whenever, whenever I speak with someone about how to maintain access tokens, how to, how to create like the most secure authentication mechanism around it, XSS always comes into play as you don't want to play around XSS. [00:37:40] So I've seen a lot of developers and there are usually the same developers that say, yeah, I can do it in a week. That would keep the access tokens on the local storage and that's like rule number one of do's and don't dos. That's the rule number one in the don't dos. (laughter) Yeah, because that means that every attacker which gets access to your application can just hijack your local storage, gets the access token and then yeah, totally, it can be used. [00:38:17] So usually there are several guidelines around it, but the idea is to have stall the access tokens in memory for the application. So the, they are less likely to be stolen. Install the, so normally JWTs are made off access tokens and refreshed tokens. So normally for web application or for modern web application, what we recommend, installing, installing, the refresh tokens. It's HTTP only cookies. So HTTP only cookies are cookies that cannot be accessible to any JavaScript, which makes it very hard for the attacker to get them because the browser protects them and do not give access to potential attackers and then pro protecting true cost, which is costs, costs of regional air protection to the other part of of the refresh tokens that usually makes up, eh, legitimate protection for any web application. [00:39:24] And that means that your access token is likely to be safe on the application. And yeah, I did mention JWT. JWTs is one of the most common ways of maintaining tokens today. So up until a few years ago, we use what we just called session tokens. There is a central token repository, which was a single point of failure. And everyone needed to basically talk with, in order to validate token. But today with the rise of microservices and the asymmetric encryptions and world has shifted around to JSON web tokens, which is the JWTs, which basically means that you get a JSON, which is normally the user data. You sign it using a private key, and you give the public key to any microservice around it. And then basically you take off the responsibility from the, from the central talking repository and you provide the services with the way of validating the request and that basically as all was pretty much changed the world of integration between companies, because once you can shift the same authorization header and the same JWT token between different services, you can shift it between different application that can verify the same JWT token without any specific integration. Okay. Just by using a publicly that's, that's the, I think that's really changed the world of how we do, how we are doing integrations between applications and teams by simply sharing public keys. And that's, that's a major change in the authentication. [00:41:24] Jason Gauci: Yeah. That makes sense. What is the difference between a session token and a refresh token? Like why does the session token exist? Why not just have one token? [00:41:33] Aviad Mizrachi: So the idea is that you wanna, you wanna maintain the session tokens as short as possible, and the refresh tokens as long as possible, because session tokens basically give you or give the attacker access to your account. They can do actions on behalf of the victims. [00:41:55] And that's why you want to keep an extra level of basically extra level of protection by just having the access tokens as short one. I don't know you said a day, I think it's too much, an hour or something. [00:42:13] Jason Gauci: I just made that up. Don't take that as technical advice, please. (laughter) [00:42:17] Aviad Mizrachi: No, no. Now but you know, keeping them as short as possible and the refresh token's the one that will be in used all the time to maintain the session active and with the method, I just we just discussed the access tokens live in memory. You're not saving them on any, on any local storage or something like that. That means that once you hit the page refresh, your session is gone. So the token is gone. So you have to refresh it in order to keep the session alive. And you don't want the user to reauthentic skate. Every time he's doing a page refresh and the refresh token takes care of the session longevity. Okay. So that's the general idea of refresh tokens. [00:43:08] Jason Gauci: I guess the thing I don't understand is how is the refresh token more secure? Like what's to stop someone from just stealing the refresh token instead of stealing the session token. [00:43:18] Aviad Mizrachi: So down to two reasons here. First of all, on the website. Okay. On the single page application side, what we normally suggest is having the refresh token as part of an HTTP only cookie. Okay. So HTTP only cookie, cannot be stolen through an assess. Okay. Are usually protected. And if you add the cost mechanism, so you're protected with costs as well, so they cannot be stolen. And on the backend side for overflows. Okay. So refresh tokens basically will be installed on the backend side, which is less likely to be stolen form any local database around there. [00:44:07] Jason Gauci: Oh, I think I get it. So. I'm going to say it a little differently. Tell me if I understand it. I'm paraphrasing or if I don't understand it. So, so the refresh token, you pass that around once when you log in and then after that, the server is the only person who has it. And so the attacker would have to grab it right when you're logging in, which is hard to do. And so, and so now the server has the refresh token, not you. And so, and so that now it can't be stolen. Did I get that right? Or no? [00:44:38] Aviad Mizrachi: Yeah. That's part of it. So first of all, this, the service tells it and yeah, you get it only when you get the access token. So you get a pair. You get The access token to the refresh token. And the only way to get the new access token is by using the refresh token, which has been installed down there in the server. And if you're working on a browser side, so if you chose to put the refresh token as part of your application, as an HTTP only cookie or something like that, it cannot be stolen as well, because if you're using the best practices around, because it will only be sent to your endpoint for the refresh token purposes. [00:45:17] Jason Gauci: So, so I guess if you have the refresh token as an HTTP only cookie then is the session token like adding any value or is it just like a legacy thing at that point? [00:45:30] Aviad Mizrachi: No, not at all. Obviously you don't want to refurbish the token on every action. Okay. So as I just mentioned, usually the refresh token will be sent only to the refresh endpoint. Okay. And you'll get a new access token. The old access token will be invalidated and the new access token would be generated. And as I mentioned, the access token should be used around your, I don't know, tens of microservices around tens of different services that they are using. And sometimes with different applications that you are using. And the idea is that access tokens are signed. So every microservice can basically validate them. And yet the idea of access tokens is here to stay because the, they provide an easy way for microservices to validate them with the lack of API gateways or something. [00:46:28] Jason Gauci: Now I get it now yet. So basically if you didn't have access tokens, you would have to go to Google, every single request. Like you would, you would show up with, with a refresh token, every time someone visited any part of your page, you have to go back to Google and say, Hey, is this person legit? Is this person legit? [00:46:45] And so that, that route that's just too, it's just too expensive to keep doing that. And so the session token saves you from having to keep going to the SSO provider all the time, and you can define how long that duration is. And then once that expires, then you go back to Google or whoever and say, Hey, I need another one of these tokens. [00:47:04] Aviad Mizrachi: That's correct. [00:47:06] Jason Gauci: Cool. Wow. Yeah, I think I think we, yeah, we covered a ton of really, really good information here. So we covered encryption. We covered tokens. We covered login. Yeah, I think this has been really, really great. I have a lot of these questions honestly, are just come straight from the heart. I mean, they're things I've always wondered and, and you had an amazing answers. So thank you so much. I actually, I'm a little bit exhausted of questions here. I mean, I actually feel like I have a 360 view. I mean, I'm one of the things too is I think I'm now in a state of conscious ignorance as opposed to unconscious ignorance where I realize that there's absolutely no circumstance by which I'm going to build my own authentication if I ever made a product. [00:47:50] Aviad Mizrachi: Yeah. I mean, it's like this world is going much more deeper than we just covered. And it's amazing that you know, attackers are getting smarter every day. The authentications mechanism needs to keep up with that. So this is why we keep talking about federations and SSLs and, and, and multifactor, and different types of multifactor. [00:48:18] And how do you recover the device? How do you store this recovery codes? You know, there's so many staff around these that you kinda, when I just started, I, I was a bit lost on the stuff that we had to cover in order to make like a decent solution. And that's, that's so many staff like, and talking about five, six years ago, so many stuff to take care of. [00:48:50] And yeah, that's, that's the reason that I would never, now with Frontegg, it's easy, but like even on my next journey, I would never build this stuff alone again, although it's, it's fun because that's what we do now. (laughter) [00:49:06] Jason Gauci: Yeah. Yeah. I think yeah. I guess I, I, there is a caveat. Yeah. I mean, if, if the next project I work on was an authentication project, that'd be totally different. And so I think it's fascinating, but, but I also think that yeah, if you, if your goal is to, I don't know, build a taxi app or something like that, definitely don't say I can have authentication done in a week unless you're, unless you're, you're using a third party library, then maybe you can get it done in a week. [00:49:33] So is it actually, let's dive a little bit into that. So tell us a bit about Frontegg and you know, how it helps with authentication and, and other sort of services that y'all provide and how that works. [00:49:43] Aviad Mizrachi: Sure. So, as I mentioned, Frontegg is a two years old startup and when we founded the company, the idea was to allow developers to basically use services such as authentication. Some other stuff that we're doing. So they don't have to deal with these questions that we just discussed for the past hour. And authentication today is pretty much a commodity. There are tons of great companies that are doing it and still, I see some questions around how to do it, what should I, should I need to do. And I see a lot of developers that are trying to do it on themselves, and then they are failing because of that. But still, I mean, because it's nice that it's now a commodity, the terms of different services. And companies today, they want to focus on the go-to market. They want to get to market faster. And that's, that's why they're trying to build. When you think about build versus buy, authentication is the first one to basically buy. [00:50:54] What we took, what we took is a different approach because yeah, authentication is very important. But when you talk about B2B companies, it's a bit different because authentication is good. And then you want to make sure that your users are safe, but there are tons of requirements from the end user side, from the companies that you are selling to in terms of different experiences they want to have with the product and mostly around self service, that brings it to more than just authentication. [00:51:28] Okay. For example, Well, we have one customer that wants MFA multifactor to be forced on whole all his accounts and all his users and the other one doesn't want it. And one organization requires that kind password policy and the other, the other one wants a different kind of personal policy. And one organization requires social SSO and the other one requires Okta. And the third one requires OpenID Connect, and then you have so many stuff to go in and walk around it. [00:52:02] So what we took upon ourselves is to provide and to enable developers to integrate such security features around authentication enterprises. So social SSO, MFA, the entire user management capabilities, password complexity, and all of these. And we try to keep it to as much as five lines of code. And I swear it's five lines of code. You can check our website. (laughter) Yeah. You can check our websites. Later the react, the react integration is five lines of code. We then go to bite a little bit more, but that's okay. [00:52:39] And the idea is that we think about the end user. Okay. So all of the authentication libraries companies nowadays, they think about the infrastructure we took upon ourselves to think about the end users. Okay. And to provide the end users of the company, the great companies that we are, we are serving with a great self service approach to enable them to basically use all of these features and to customize them to their needs. [00:53:09] For example, we provide user management, admin portal where the end user, for example, the organization that our company, that our customers sells to can invite users, provide them with roles, onboard these SSO, see audit logs on board machine to machine tokens, et cetera, et cetera, because we had so many times about the pain that was involved in implementing SSO and onboarding SSO, and an inviting a user in build the perfect profile and build the perfect MFA on boarding dialogues and build a perfect puzzle complexity dialogue. [00:53:51] So we give them extra layer or we call it the full stack APIs, where basically it's all starts with the login, but the login is only the start. It comes with a perfect admin portal on top of that to serve basically the end users of the companies that we are serving. And that's basically, what's, what's special about Frontegg. [00:54:14] Jason Gauci: Yeah, that makes a lot of sense. I was thinking about, yeah, about a week ago. I remember thinking about you know, there was a SQL injection attack that hits some website a while back and they ended up downloading their entire database. So hackers ended up downloading. So just a really quick thing on SQL injection attack. The way it works is, is SQL is code, but when you make a SQL query you typically pass, it's interpreted. So you pass your code as a string over to the SQL server. And that server executes that code and then passes you back the result. And because it's a string, there's nothing to stop you from just using basic string operations, like things we all learned in high school, like take this string, add it to that string. [00:55:00] But the problem is those strings, when they're being constructed if there's user input, that's deciding the content of that string, then someone can end up basically adding a string. Like maybe they make their username something that closes a comment or something that. SQL that everything that just happened was a comment. And my actual username is "deletethedatabase" or something like that. And if you just pass that straight to the server, you lose everything. So, so there was a SQL injection attack where someone was able to download the entire contents of the database. [00:55:37] And that is where auditing would be really important. Right? So, so I mean also having not, not making that error is important, but, but even if you have a developer makes that error, you're going to see 40 gigabytes of eg-- hopefully a lot less than you're going to see a high velocity, a lot of egress when someone makes a single query for the entire database and you can catch that and downloading 40 gigabytes doesn't happen that quickly. So you could catch that. And hopefully maybe the person only gets 10% of the database, right? [00:56:11] And so, so having audit logs. Is really, really important. And it's another thing there's an even stronger incentive not to do it, right? So like, it's like, people don't want to concern themselves with login. They really don't want to concern themselves with auditing the login. Like it's, it's another layer that is even further away from building the social media website you want to build, right? And so, yeah, I think, I think adding auditing is a really nice add on. [00:56:38] Aviad Mizrachi: Yeah. You know, you know what we say about auditing. So when, when we use audit logs, when something really goes wrong, that's when we'd use audit logs because normally, I mean, it just sits there, but when something happens, you start going over the audit logs to see who changed what, how the heck, I mean, someone is being able to login and touch this configuration. [00:57:03] And who changed this configuration? We saw it a lot over the previous years with checkpoint where everything was had to be audited for who changed to allow any, any traffic to that firewall. And yet audits for a login, pretty necessities. But that's only the start because you want to make sure that you audit any change of configuration that is being made because that's a critical necessity as well. [00:57:36] Especially for cybersecurity companies, especially for highly regulated companies. Okay. Audit logs is like the essence of the business. And you want to make sure that you are 100% compliant with all of these changes because when, when something goes wrong, you better, you better have this information in hand. [00:57:58] Jason Gauci: Yeah. Yeah. Totally makes sense. And yeah, as soon as you have an audit log or a really a log of any form, then you can start doing monitoring either manual monitoring, automated monitoring, and you want to have that stuff early. It's much harder to build it in later. [00:58:14] Aviad Mizrachi: Totally. Totally. Yeah. And usually that's what, out of this position in Frontegg, I had the privilege of talking with a lot of CEOs, VP R&Ds, in these in multiple roles, and even talking with several CSOs. And the CSO's perspective is always the one that fascinates me the most because I've met some CSOs that told me, I rather sometimes pick uh, in larger companies with CSOs, with acting CSOs, they have to review any product that the company is using. And some, and I've heard several times that CSOs would say, I rather use the product, which is not the best one, but it's covering my checklist because then I can sleep well at night. [00:59:13] And we see a lot of companies facing these because it's like, it's like kind of a struggle because on one hand you want to make sure that you develop the product because product is God and the product is what that's going to bring you into these meetings. But on the other hand, if you don't develop these necessities, So you want to pass the CSO certification. So in startups, you don't know what to focus on. That's a really struggle for a lot of companies I talk with. [00:59:42] Jason Gauci: Yeah. That makes sense. What's the relationship between actually wait before I ask that question, another question, how does this work on mobile? So we talked a lot about web and with web it's easy because you can send the person to Google, but if you're an app how can a person then just be typing their password to Google while it's in the middle of an app? Or how, how does Frontegg handle that? [01:00:04] Aviad Mizrachi: So what I always say is an hour is an hour. So there are several, today with the Electron apps, you hardly see any difference between between web application and electron applications. So you get pretty much the same experience. Frontegg handles it through, are web native, but for the mobile applications who handled a true reach set of rest APIs that basically take care of these and access tokens and refresh tokens. And that's the, that's the idea. Yeah. MFA is a different issue in, in a mobile application because we get it from different places, but yeah. It's like it's different world. [01:00:50]Jason Gauci: Yeah, that makes sense. So what about Frontegg as a company? What is a day like a Frontegg, what's something you do? That's unique that really makes, makes working at Frontegg different than working at another startup or, or another, another big company or something like that? And then also after talking about that, it'd be good to see, oh, are you guys hiring? And, and is it sort of interns, full time? So, so what does that whole thing look like? [01:01:19] Aviad Mizrachi: Yeah, sure. So, uh, I have to say that this team in Frontegg of there are the second family here. Looking at these two years and thinking about the team that we built is amazing. And the company is really growing where we were around 25 employees, 22 of them in Israel. In Tel Aviv, great team splitting up to full stack teams with amazing collaboration between the teams. We have a very lively WhatsApp and Slack channels where everyone is given it to the, to the CTO for choosing JavaScript as the, as the preferred language. And we have guys-- [01:02:06] Jason Gauci: Okay. I have to interject here. Why not [01:02:07] Aviad Mizrachi: TypeScript. Yeah. Yeah. Obviously we are using TypeScript. Everything is, [01:02:13] Jason Gauci: Oh, okay. (laughter) [01:02:14] Aviad Mizrachi: But we have several .NET And Java sticking up to the CTO. Why did you choose TypeScript? (laughter ) Let's do stuff in Java. And then we have the Javascript guys will say, no, JavaScript is the best. And then yeah, most of the jokes goes around it. And it's really like a great atmosphere and funny atmosphere to work in. And it's like a great feeling of wanting who wants to change the life of developers, building these generic stuff and providing the great service for developers. [01:02:50] And yeah, we are hiring, we are hiring several full stack developers, full time in Tel Aviv. We are looking for products as well and product marketing. So yeah, that's, that's usually a day in Frontegg, which concludes usually on Thursday with bunch of ice cream and whiskeys to conclude the week. [01:03:13] Jason Gauci: Oh, nice. Yeah. The yeah, I love having an outlet for funny memes. I remember we I used to work on, on MapReduce a long time ago. I used to, I was at Google and I was working on MapReduce and you know, we would write everything in C and C++, and at one point, somebody put this picture up in the office of someone. It was one of these kinds of America's Got Talent or Britain's Got Talent- type shows and it was somebody who could shoot a bow and arrow and hit a bullseye with their foot. And that's what coding and C++ really felt like. And yeah, I think, I think maybe in Java it would be the same thing except much longer. Like you'd have to have a, a bow factory and a foot factory and then a bulls-eye factory and... (laughter) [01:03:58] Aviad Mizrachi: yeah. So whenever something doesn't go, well, it would never happened in Java, I would say. Yeah, it would. And then when something didn't work in Java, where, because we have SDKs in Java as well. So when something new, ah, yeah, it would never happened in Javascript and then yeah. All the offices like around it. Uh, it's pretty funny. [01:04:19] Jason Gauci: Cool. That's awesome. And so, so there are, you said you're looking for like product marketing and these type of roles and just to recap, so their internship or is it full-time only, or both, or what's the deal there? [01:04:31] Aviad Mizrachi: So we are currently looking for full time. We have a lot of our shoulders on our shoulders and we want to get as much done as possible. So we are currently looking for full times, both on the R&D, for full stack development. Our main stack is now just TypeScript and React TypeScript for the front end. We have several because we are, we have developed a platform. So we have several, Angular view, Python. The main like 90%, 85% would be around React and JavaScript and on the product marketing and product roles there is like moving these ideas forward and support R&D and the entire company for building up this, this great platform. [01:05:22] Jason Gauci: Yeah. That makes sense. One thing we didn't cover, I want to go back to just to wrap this up to conclude it is what are your offerings, product offerings. And so just to give a bit of background here we have two main sort of, of, of factions of listeners, right? There's folks who are in, in either high school or college or their post-college or, but they're just getting into the industry, they're becoming professional developers. [01:05:51] And so what do you have for them? Let's say hobbyists and, and then also what you have for, you know enterprise customers. And, and how would people get started in, in either of those roles? [01:06:03] Aviad Mizrachi: Yeah. So first of all, because we believe in product-led world, we believe in bottom up. So that means that we have a very generous freemium plan and a very active Slack community. So basically what you get from Frontegg is, out of the box, fully customizable, the login box and our admin portal, which covers basically everything you need around authentication and single sign on. And that includes all the social logins, login at Google login, login with GitHub, profile management, et cetera, et cetera. [01:06:38] And basically for the enterprise customers, we have an offering, which is based on audit logs and a fully customizable organization splits. So that means that if you are integrating Frontegg, basically you provide your customers with an ability to, to define their own security policies without you needing to do it for them. [01:07:01] That's the PLG motion that we strongly believe in, in the self-serving is that we strongly believe in providing your end users with the ability to customize and control everything on their own. On the audit lock side, on customized security policy side, on boarding, MFA on boarding enterprise SSL, such as Okta and that stuff, and even enjoy so most, most of our offering is as a service. And we have a dedicated deployments, which are available on our enterprise plan as well, which can be covered as hand charts or local compose. So that depends like most of our, we call it a garage best startups, we'll start with either our freemium plan or with our startup program. And then they will evolve to what we call it a plan which is more sophisticated, which includes the audit terms and all the other advanced capabilities as well. [01:08:01] Jason Gauci: Cool. That makes sense. So, so if you're listening to this and you're building your first web app, Or, or you are prototyping something and you want to send it to a friend and it's a web or a mobile app, or even an electron desktop app. You know, you can, you can use Frontegg. It's totally free to use, to get started with. But then you'll say your app really takes off. You hit the front page of New York Times or something. And now all of a sudden everyone's hitting your site and you really need to start keeping track. You have attackers are attacking your site, then you can upgrade to the, to the premium plan without having to rewrite the whole API or anything like that and get all those extra features that become really important to you. [01:08:45] Aviad Mizrachi: That's correct. Yeah. And usually we don't limit anything to get started, like everything is open and then we just, we make sure that you have everything that you need before we start talking about commercial side of business. [01:09:02] Jason Gauci: Cool. Yeah, that's awesome. Yeah, that parallels a lot of the the folks that we've talked to, I think it's a really, really good business model. I think the magic there, we talked about this in prior shows, but, but there's always fascinates me. So I'll bring it up again. Is the, the magic is figuring out where to draw the line. [01:09:19] I think for this particular product drawing the line at the audit logs and all of that I think is very, very natural and it fits nicely. Because at the end of the day, like it's a, it's a, you're providing a valuable service and, and at some point you need to charge it. And I think, yeah, I think that's the right place to be. Because by that time, somebody has gotten so much value out of it that, that I think that they would be happy to contribute back. [01:09:44] Aviad Mizrachi: Yeah. I agree. Most of the time it would be around the audit logs and the enterprise SSO, which means that you're probably selling to enterprises. But yeah, I mean we are talking with so many founders and around the default here of your business, you're probably after 10 different versions of pricing, if you're really good at it. So the pricing is the one thing that for me as an engineer, it's so hard to get it right. And so many experts, and there are so many advisors, especially for a sophisticated platform like ours. So yeah. [01:10:26] Jason Gauci: That makes sense. Cool. So yeah, we covered a lot of really good, we've covered technical. We covered product. We covered Frontegg as a company. I definitely encourage folks to check it out. The strongest encouragement from both of us is to not build your own login. Don't do it. I actually I'm guilty of this many, many years ago, I made a trivia app. [01:10:48] People are, have, have gone through the archives. If they're new listeners, you've probably seen this episode where I talked about it. And yeah, I actually just passed the token as a query parameter. (laughter ) And when I was, when I was sending the app to somebody, the website to somebody to try out, all of a sudden they were me, I sent it to someone to try out and all of a sudden my scores started going up and I couldn't really figure it out. [01:11:09] And, and so thankfully it wasn't, I wasn't making a bank app or anything like that, but yeah, I mean, I totally flubbed that and, and you really don't want to be playing around with people's passwords. People did put in passwords to my trivia app that that they've used in their bank, and I didn't leak the password or anything, but, but still, I mean that I, when I realized what was going on, it made me very nervous thinking about passwords. [01:11:36] So, so don't make the same mistake. You know, it sounds like Frontegg is a really awesome service. I'm going to check it out. I actually have, I'm always kicking around new projects, so I have one. Thinking about now, I'm going to try for an egg with it and we'll see how it goes. [01:11:48] But thank you so much Aviad or coming on the show. We learned a ton. I love episodes like this. I personally learned a lot and I'm sure listeners learned a lot too. And, and folks in feel free to go to the show notes where we have an entire transcript of the show and our producers will transcribe the entire show, which is, which is awesome. So if there's any key words, anything you didn't understand, you can go through that and then Google anything that, that wasn't totally clear. [01:12:16] But, but I think Aviad, you did an amazing job of really breaking it down for us. And, and thank you again for coming on the show. [01:12:23] Aviad Mizrachi: Thanks Jason, for having me. Thank you guys. [01:12:26] Jason Gauci: Cool. And thanks to all listeners. Yeah. We've been doing two shows a month for a few months, as you may have noticed. If you're a Patreon subscriber, I sent a special thank you to all of you folks for continuing to support us. [01:12:38] Yeah, definitely. We'll post Aviad's Twitter and other stuff in the show notes. So if you want to reach out to him directly, we'll provide a way to do that. We'll also have links to Frontegg, so you can check that out and everyone have a great couple of weeks and we'll see you later on in the month. [01:13:02] Patrick Wheeler: Music by Eric Barndollar [01:13:12] Jason Gauci: Programming Throwdown is distributed under Creative Commons, Attribution ShareAlike 2.0 license. You're free to share, copy, distribute, transmit the work, to remix and adapt the work, but you must provide attribution to Patrick and I, and sharealike in kind.