128 What Authentication System Should I Use For My App?

What are the pros and cons of the various authentication systems? Should I use the built-in authentication system in ASP.NET Core? Should I use a third-party system? Is Azure Active Directory the right choice? These are the questions we will answer in today's episode of Dev Questions.

Website: https://www.DevForge.com/ 
Ask Your Question: https://suggestions.iamtimcorey.com/
Sign Up to Get More Great Developer Content in Your Inbox: https://signup.iamtimcorey.com/

Transcript

Copy Transcript Copied

SPEAKER_01 0:00

Welcome to the Dev Questions Podcast with Tim Corey. Join us each episode as we tackle the questions you are asking about a career in software development, understanding the industry, and new technology. If you're just starting out or you want to grow stronger as a developer, this is the place to get your questions answered. Now, here's your host, expert developer and online educator, Tim Corey.

SPEAKER_02 0:24

What authentication system should I use for my app? This is a question that came up on the suggestion site. I thought I'd tackle it in today's episode of DevQuestions. Now, if you have a suggestion, go to suggestions.iamtimcorey.com, leave that suggestion there, and hopefully you'll see your question answered on a future episode of DevQuestions. So let's dive into what's the right authentication system for my app. Now we're specifically talking about C sharp apps, but this really applies in general to any coding application of any type. And let's start off with my philosophy on authentication. And I think this is a very important philosophy. I think it's one that you should adopt as well, but let me see what you what your thoughts are. My philosophy is don't do it yourself. That's it. That's the big one. I see a lot of people create their own authentication system, especially when they're starting out off where they say, well, it's just a username and password. No big deal. I'll just check the password, make sure it's right, and then we're good to go. There is so much more to an authentication system than that. Don't do that. Think of authentication like a bank. You know, you can have a safe in your own house. That works fine for you. Uh price shouldn't be your only way of storing money. But for small stuff, no big deal. And if you have your own personal application and you create your own authentication system just for yourself, and it's a small little thing that's just for you and doesn't have a lot of impact if you were to lose everything, no big deal. But that's kind of like that little safe in your closet or wherever in your house. But imagine if you had a business. Maybe let's say you sell cookies and you decide, you know, I'm going to store all of my customer information, all of my money, all of the credit card information for future charges, all of that I'll store in my safe in my house. Does that sound like a good idea? No, it doesn't, because there's so much more to storing and securing that besides just having it in a locked box. I mean, if you're strong enough, you can go pick that box up and walk out of the house with it. And theft does happen. So you don't want to see a business do that with your information. You wouldn't want to do that with somebody else's information. And that's why we have banks, because banks store our money and allow us to do a lot of stuff with it, transfer money and make sure that it's, you know, when you take money out that's properly recorded. And when you put money in, it's properly recorded. Who can take money out or put money in is important. And all those other things they they provide around just storing money in a safe. There's a lot more to it. And that's the same thing with authentication. There's a lot more to it than just saying, does this username match and password match? Is this the correct pair? There's a lot more to it. And so don't roll your own. Now, there are a few different authentication systems or types of systems. So let's talk about the different levels, I would say, of an authentication and authorization system. And we're gonna just call it authentication, but really authentication and authorization are two different things. They're different parts of the same thing, really. Where one says, are you who you say you are? authentication, and authorization says, do you have access to this? Okay. There's two different parts there. They really work together in a lot of ways. So we're just gonna call it the auth system or authentication system for simplicity of talking. Okay. So there's different levels of an auth system. And the first one, I'm gonna call it level zero, don't do this. And that is a self-created system, a system you built yourself that you create all of the security code for. Okay, that's the don't do this level. Then there's the self-hosted system, a system that somebody else built, but that you host. For example, if you use ASP.NET Core, you'll probably know that there's a built-in authentication system, Microsoft Identity, that's built in, but you host it in your own entity framework-generated database. That's kind of level one, okay? And that's built right in. That can be a decent system. We'll talk more about it in a minute. Now, number two, I'd say, is that same self-hosted system, but you use a third-party OAuth provider, such as Twitter, Facebook, Microsoft, GitHub, all those to authenticate the user. So they put in their Twitter credentials or their GitHub credentials, and then you know, if you put in GitHub credentials, GitHub says, yes, that is Tim. And that's the authentication part that's done by GitHub, which means you've offloaded a lot of work on the GitHub because they handle password resets and they handle verification, they handle two-factor authentication possibly, or many other things they can do, but they handle it. But then they tell you, okay, yes, Tim is who he says he is. And then you can say, okay, then I'm going to authenticate him for my system, and I'm going to authorize him to do certain things. So that's self-hosted. It's still that same entity framework database or some other local thing that you own. But you're using a third-party OAuth to authenticate a person. And then there's the next level up, uh, which would be the third party hosted. So everything is hosted by a third party, uh, Azure Active Directory or Azure Active Directory B2C, uh, Auth Zero, Okta, and there's many more out there. But these are systems where you probably pay something in order to have them do all the work. Okay. That's kind of like level three on this list. And then level four is that same thing, Azure AD or B to C or whoever else, but also using OAuth from third parties as well. So maybe you have an Azure AD B to C account, but you also allow them to authenticate using GitHub. Okay. So that's kind of the four levels that I see, plus level zero, which is don't do this. Um that's the different options you have. Which one is best? Well, it does depend on your situation. That's really the answer for most questions. It depends. But what does it depend on? And we'll talk more about that. But the big deal is to make sure that you choose what's right, not just based off finances, but also based upon what the data is and how sensitive it is. Okay. The more sensitive data, the more you should spend in making sure it's secure and safe. Okay. So you want to have, you know, an ideal for third party is storage for storage. That's the ideal. So go with third party for storage. That's probably the best option. And the reason why is because what is authentication? What is authorization? What are you doing? You're trying to secure something. Well, what's more secure? A one safe in a closet where maybe people have access even to that closet? Or if you want a safe inside of a warehouse that's guarded by security, inside of an organization that tracks and monitors who comes onto the property. Like there's different levels, right? So when it comes to your safety or data, maybe it's better, it is better, if you let somebody else do that as opposed to your one little rinky dink server, right? Um, and there may be some pushback there and say, well, but we control a server, and so no data goes outside, and so it's all inside of our walls. Cool, I get that. But that's not really how you handle finances. You don't just say, well, we're gonna handle storing all the cash in our business because it's inside our walls, because that wouldn't be safe. Well, why is it you do the same, you do that with authentication, where you say, we want it all inside of our walls. Because unless you're all internal users, if you have external users, they're coming in and out, and now you have to make sure that your walls are tall enough, that your uh walls are protected and guarded and monitored and all these other things that a third party provides. And you have to have that same level of security for one authentication system as opposed to their hundreds and thousands of authentication systems. The economy of scale says the person who has hundreds and thousands can do more for cheaper. Okay. So ideal, third party for storage. And ideal, and this is again my opinion here, ideal is that same third party for authentication instead of using OAuth. And that may blow some people's minds. They're like, wait, wait, wait, those OAuths are great because we can reuse those same credentials and let them do half the work. I get that, but there's some downsides too. Okay, let's talk through some of the downsides. For instance, if you say you can authenticate through my site or through Microsoft or GitHub or Twitter or Facebook, right? So those four options. And a person decides, you know what, I'm gonna use GitHub and they authenticate through GitHub. Well, now when they come back the next time, and maybe it's been a year since they've come back, which one did I choose? I've got all four of those things. Which one did I choose? Now, there are some systems to help you with, okay, I selected this, but I actually I do this with um sessionize, which is a way for speakers to um submit sessions for potential conferences and speaking at conferences. And they have, I think, six different authentication options besides login. And I use one of the social logins, but I always have to remember which one was it. I think it was Google. But in order to do it, I click on the wrong one and it goes, no, I think we've got an account over here. But here's a tricky bit. Not all of my socials use the same email address. So how would it know that my work email address is the same as my personal email address? It doesn't always do that. So now I have two different accounts with that same platform. So that can be tricky. But also, here's another thing. What if I use my GitHub credentials and somebody has access to those GitHub credentials? Maybe for whatever reason you shouldn't do this, but maybe I shared my GitHub credentials with someone in order to get them into my GitHub real quick to do something. Well, now they could also log in to your site. So that the the third-party OAuth systems are nice and they do offer a quick way in. I love it when people support uh the Apple login because on my phone I say, yep, Apple login, boom, done. But now we're relying on my Apple login not being stolen. So there's a lot of question marks around that where it adds to your ability to quickly get in. It reduces the number of passwords people have, it makes it easier, but does it make it safer? That's the question. And the answer is it's going to depend on your situation. So if you want the safest, you probably want to have that third party do the authentication separately from an OAuth system. That way you don't have to alert people if, hey, if your password is stole on Twitter, then you should also check to make sure you reset the password here or reset tokens, or and yes, there's a lot of systems in place to help with that already. And they've made things a lot better, so it's a lot harder to have a person who steals your credentials over here, use it over here, but it still can't happen. So ideally, I would say use a third party for your authentication system and use that same third party to do the login in, password, two-factor authentication, all the rest for that user. Don't try to separate that out if you want the most secure. And that's what we're talking about here is the most secure. You need to choose what's best for your sliding scale of risk. And that's an important part to talk about is security is a matter of risk assessment and mitigation. Okay. You need to figure out what is the risk compared to the reward. All right. So, really simple example. If you go to imtimcore.com, you don't have to log in. Well, that's because there's no reward for logging in. There's no reason to ask people to log in. What's the risk? There isn't one because there's no data being protected behind a password there. Now, if you were to put your credentials in and buy something from me, and you want to manage your subscription to the All Access Pass, well, yes, that's behind some protections because of the fact that the risk of not having it behind protections is people will steal your information. So I have to I use a third-party system to handle authentication in that case, and they protect your data. So you gotta figure that balance there between risk and reward. If you're doing a small app that uh protects basically nothing, then you can have a much lower bar for your security. Uh I used a pretty decent bar for my security for the suggestion site. So you go to suggestions.imtimcorey.com. Again, you can leave a suggestion for a future dev question. But in there, what are you gonna steal? Okay, let's just say, for whatever reason, I decide to publish your usernames and passwords. Now I can't because I don't have access to them. But let's just pretend I did and I published it. What's the worst that can happen? Someone can post a suggestion as you? Like, that's not a big deal. So the the risks are pretty low. Now that means I can be a lot more free with what things I offer as far as ease of use, um, how long I keep the token open for, and you know, what authentication systems I can allow, and if I allow third-party OAuth and all that other stuff, I can be pretty open because there's not very risk. Now, if I am storing your credit card information, your social security information, or your personally identifiable information that's sensitive, um, your health records. Those are really important things to make sure you have a high level of security on. You probably shouldn't just say, eh, whatever. Now, just to be clear, I didn't say, eh, whatever either. I use Azure Active Directory B2C in order to authenticate you on a suggestion site. That is a third-party system, and I currently do not have third-party OAuths turned on. So you can't use Twitter or Facebook or Microsoft or GitHub or any of those at this point. We're just saying, hey, you have to create an account through us and through our BFC account. That way it's totally separate, separate login and password, and it's protected. Now, that's a pretty high walled garden around not much, the suggestion site. But just kind of a future preview, we're not gonna just stop there with suggestion site. There's more things coming where you can reuse those same credentials. So that's why we want to keep the bar pretty high on that site. But it's up to you to make the right choice for your situation. So make the best possible decision for your business and your customers. All right. So when I say business and customers, sometimes people come to me and say, well, this one's free. And that's great for a small application. That's great for an application with no real stop to secure. But as soon as you have real customers, as soon as you have real data to secure, and real data can just be email addresses. It can be just, you know, your middle name or your zip code or things that you probably shouldn't just publish without permission. So once you get to that point, you need to start thinking about not just what does it cost, but how do I safely protect your customers? Because if you don't protect your customers, and let's say you have a data breach, that could be a major issue. And you want to be able to say, I did my best, not I did my cheapest. Okay. So when you're thinking about authentication, there's a wide spectrum of options. Um, again, don't choose to do your own, like build your own security system. That's really, I almost want to say never, but there is a very, very, very, very, very slight case where you're doing a personal application on your personal computer that's never going anywhere, that doesn't talk to the internet at all, and that does something little, but you want to make sure you protect it a little bit. Okay, maybe. But there is such a small percentage of cases where you would build your own authentication system. Now, Microsoft identity, that's not building your own. That's using what Microsoft has created. And you're hosting it locally, and yet the code has been built by Microsoft and is maintained and updated by Microsoft. So that's not quite the same thing. But it's still a lower level of security than, say, hosting it in Azure Active Directory and letting them handle the authentication and even authorization of your users. So figure out what works best for you, but try to think about not just the bottom line of cost, but also the bottom line of cost of what happens when this gets breached. Because security breaches happen all the time. And they're not always because this super elite hacker got crazy access and did some crazy stuff. Sometimes it's you were cheap and there's a known exploit that you didn't know about because you didn't pay attention to it. You didn't read up on your security system, you didn't know how to configure it, and someone just used the default credentials or something else like that. So be careful, know your system, and make the best choice for both your business and your customers. Okay, so that's a kind of a broad answer. I can't give you specifics because it does depend on your situation. Um, but think that through. Think through what you want to be able to say if your data was breached. Do you want to be able to say it was cheap? Or do you want to be able to say, I did my best based upon the circumstances? Okay. So that's my answer to the question: which authentication system should we use? All right. If you have a question, again, go to a suggestion sites. Thanks for listening. And as always, I am Tim Corey.

SPEAKER_00 20:21

Thank you for joining us for this episode of Def Questions. Tim is committed to making it easier for you to become a developer. If you would like to help make more content like this possible, please like, subscribe, rate, and share Deaf Questions. You can also send your questions to questions at IamTimcorey.com. Until next time, remember, you are too smart and your time too valuable to waste it making all the mistakes Tim did. When you're ready to learn to think and code like a professional developer, head over to imtimcore.com and enroll in a course.