Screaming in the Cloud - Authentication Matters with Dan Moore of FusionAuth

Episode Date: September 8, 2022

About DanDan Moore is head of developer relations for FusionAuth, where he helps share information about authentication, authorization and security with developers building all kinds of applications.A former CTO, AWS certification instructor, engineering manager and a longtime developer, he's been writing software for (checks watch) over 20 years.Links Referenced:FusionAuth: https://fusionauth.ioTwitter: https://twitter.com/mooreds

Hello, and welcome to Screaming in the Cloud, with your host, Chief Cloud Economist at the Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. This episode is sponsored in part by our friends at AWS AppConfig. Engineers love to solve and occasionally create problems,

but not when it's an on-call fire drill at four in the morning. Software problems should drive innovation and collaboration, not stress and sleeplessness and threats of violence. That's why so many developers are realizing the value of AWS AppConfig feature flags. Feature flags let developers push code to production, but hide that feature from customers so that the developers can release their feature when it's ready. This practice allows for safe, fast, and convenient software development. You can seamlessly incorporate AppConfig feature flags into your AWS or cloud environment and ship your features with excitement, not trepidation and fear.

To get started, go to snark.cloud slash appconfig. That's snark.cloud slash appconfig. This episode is sponsored in part by our friends at Sysdig. Sysdig secures your cloud from source to run. They believe, as do I, that DevOps and security are inextricably linked. If you want to learn more about how they view this, check out their blog. It's definitely worth the read. To learn more about how they are absolutely getting it right from where I sit, visit sysdig.com and tell them that I sent you. That's S-Y-S-D-I-G dot com. And my thanks to them

for their continued support of this ridiculous nonsense. Welcome to Screaming in the Cloud. I'm Corey Quinn. I am joined today on this promoted episode, which is brought to us by our friends at FusionAuth, by Dan Moore, who is their head of DevRel at SAME. Dan, thank you for joining me. Corey, thank you so much for having me. So you and I have been talking for a while. I believe it predates not just you working over at FusionAuth, but me even writing the newsletter and the rest. We met on a leadership Slack many years ago. We've kept in touch ever since. And I think that I have to run the actual numbers on this, but I believe that you are at the top of the leaderboard right now for the number of responses

I have gotten to various newsletter issues that I've sent out over the years. And it's always something great. It's here's a link I found that I thought that you might appreciate. And we finally sat down and met each other in person, had a cup of coffee somewhat recently. And you asked, the first thing you asked was, is it okay that I keep doing this? And at the bottom of the newsletter, it's, hey, have you seen something interesting? Hit reply and let me know. And you'd be surprised how few people actually take me up on it. So let me start by thanking you for being as enthusiastic a contributor of the content as you have been. Well, I appreciate that.

And I remember the first time I ran across your newsletter and was super impressed by kind of the breadth of it. And I guess my way of thanking you is to just send you interesting tidbits that I run across. And it's always fun when I see one of the links that I sent go into the newsletter because what you provide is just such a service to the community. So thank you. The fun part too, is that about half the time that you send a link in, I already have it in my queue or I've seen it before, but not always.

I talked to Jeff Barr about this a while back, and apparently a big Amazonian theme that he lives by is two is better than zero. He'd rather two people tell him about a thing than no one tells him about the thing. And I've tried to embody that. It's the right answer, but it's also super tricky to figure out what people have heard or haven't heard. It leads to interesting places. But enough about my nonsense. Let's talk about your nonsense instead. So FusionAuth, what do you folks do over there? So FusionAuth is an auth provider and we offer a community edition, which is downloadable for free. We also offer premium editions, but the space we play in is really CIAM, which is Customer Identity and Access Management, very similar

to Auth0 or Cognito that some of your listeners might have heard of. If people have heard about Cognito, it's usually bracketed by profanity in one direction or another, but I'm sure we'll get there in a minute. I will say that I never considered authentication to be a differentiator between services that I used. And then one day, I was looking for a tool. I'm not going to name what it was just because I don't really want to deal with the angry letters and whatnot. But I signed up for this thing to test it out. And, oh, great. So what's my password? Oh, we don't use passwords. We just, every time you want to log in, we're going to email you a link and then you go ahead and click the link.

And I hadn't seen something like that before. And my immediate response to that was, okay, this feels like an area they've decided to innovate in. Their core business is basically information retention and returning it to you. Basically any crud app. Yay.

I don't think this is where I want them to be innovating. I want them to use the tried and true solutions, not build their own or be creative on this stuff. So it was a contributor to me wanting to go in a different direction. When you start doing things like that, there's no multi-factor authentication available. And you start to wonder how have they implemented this? What corners have they cut? Who's reviewed this? It just gave me a weird feeling. And that was sort of the day I realized that authentication, for me, is kind of like crypto, by which I mean cryptography, not cryptocurrency. I want to be very clear on here. You should not roll your own cryptography. You should not roll your own encryption. You should buy off the shelf unless you're one of maybe five companies on the planet.

Spoiler, if you're listening to this, you are almost certainly not one of them. Yeah. So first of all, I've been at FusionAuth for a couple of years. Before I came to FusionAuth, I'd rolled my own authentication a couple of times. And what I've realized working there is that it really is, there are a couple of things worth unpacking here. One is you can now buy or leverage open source libraries or other providers a lot more than you could 15 or 20 years ago. So it's become this thing that can be snapped into your architecture. The second is auth is the front door to your application. And while it isn't really that differentiated, I don't think most applications, as you kind of alluded to, should innovate there. It is kind of critical that it runs all the time, that it's safe and secure, that it's accessible, that it looks like your application. So at the

same time, it's undifferentiated, right? Like at the end of the day, people just want to get through your authentication and authorization schemes into your application. That is really the critical thing. So it's undifferentiated. It's critical. It needs to be highly available. Those are all things that make it a good candidate for outsourcing.

There are a few things to unpack there. First is that everything becomes commoditized in the fullness of time. And this is a good thing. Back in the original dot-com bubble, there were entire teams of engineers at all kinds of different e-commerce companies that were basically destroying themselves, trying to build an online shopping cart. And today you wind up implementing Shopify or something like it, which is usually Shopify, and that solves the problem for you. This is no longer a point of differentiation. If I want to start selling

physical goods on the internet, it feels like it'll take me half an hour or so to wind up with a bare-bones shopping cart thing ready to go, and then I just have to add inventory. Authentication feels like it was kind of the same thing. I mean, back in that song from early on in internet history, Code Monkey talks about building a login page as part of it. Yeah, that was a colossal pain. These days, there are a bunch of different ways to do that with folks who spend their entire careers working on this exact problem so you can go and work on something that is a lot more core and central

to the value that your business ostensibly provides. And that seems like the right path to go down. But this does lead to the obvious counter question of how is it that you differentiate other than, you know, via marketing, which again, not the worst answer in the world, but it also turns into skeezy marketing. Yes, you should use this other company's option, or you could use ours, and we don't have any intentional backdoors in our version. Hmm, that sounds a little more suspicious and more than a little bit frightening. Tell me more. No, legal won't let me.

And it's, okay. So I've done the terrible things. How do you differentiate? I like that. That was an Ali-specific disclaimer, right? Like whenever a company says, oh yeah, no. My breakfast cereal has less arsenic than leading brands. Perfect. So yeah, so FusionAuth realizes that kind of, there are a lot of options out there. And so we've chosen to niche down. And one of the things that we really focus on is the

CIAM market. And that stands for Customer Identity and Access Management. And we can dive into that a little bit later if you want to know more about that, we have a variety of deployment options, which I think differentiates us from a lot of the SaaS providers out there. You can run us as a self-hosted option with, by the way, professional-grade support. You can use us as a SaaS provider if you don't want to run it yourself. We are experts at operating this piece of software. And then thirdly, you can move between them, right? It's your data. So if you start out and you're bare bones and you want to save money, you can start out self-hosted when you grow, move to the SaaS version. Or we actually have some bigger companies that kickstart on the

SaaS version because they want to get going with this integration problem. And then later, as they build out their capabilities, they want the option to move it in-house. So that is a really key differentiator for us. The last one I'd say is we're really dev-focused. Who isn't, right?

Everyone says they're dev-focused, but we live that in terms of our APIs, in terms of our documentation, in terms of our open development process terms of our documentation, in terms of our open development process. There's actually a GitHub issues list you can go look at on the Fusion Auth GitHub profile, and it shows exactly what we have planned for the next couple of releases. If you go to one of my test reference applications, last tweet in AWS.com, as of the time of this recording at least, it asks you to authenticate with your Twitter account. And you can do that. And it's free. I

don't charge for any of these things. And once you're authenticated, you can use it to author Twitter threads because I needed it to exist first off. And secondly, it makes a super handy test app to try out a whole bunch of different things. And one of the reasons you can just go and use it without registering an account for this thing or anything else is because I tried to set that up in an early version with Cognito and immediately gave the hell up and figured, all right, if you can find the URL, you can use this thing because the experience was that terrible. If instead I had gone down the path of using FusionAuth. What would have made that experience different other than the fact that Cognito

was pretty clearly a tech demo at best rather than something that had any care, finish, fit, and polish put into it? So I've used Cognito. I'm not going to bag on Cognito. I'm going to leave that. Oh, I will. Don't worry.

I'll do all the bagging on Cognito you'd like because the problem is, and I want to be clear on this point, is that I didn't understand what it was doing because the problem is, and I want to be clear on this point, is that I didn't understand what it was doing because the interface was arcane. And the failure mode of everything in this entire sector, when the interface is bad, the immediate takeaway is not, this thing's a piece of crap. It's, oh, I'm bad at this. I'm just not smart enough. And it's insulting, and it sets me off every time I see it. So if I sound like I'm coming across as relatively annoyed by the product,

it's because it made me feel dumb. That is one of those cardinal sins from my perspective. So if you work on that team, please reach out. I would love to give you a laundry list of feedback. I'm not here to make you feel bad about your product. I'm here to make you feel bad about making your customers feel bad. Now, please, Dan, continue. Sure. So I would just say that one of the things that we've strived to do for years and years is translate some of the arcane IAM, identity access management, jargon into what normal developers expect. And so

we don't have clients in our OAuth implementation, although they really are clients. If you're a, if you're an RFC junkie, we have applications, right? We have users, we have groups, we have all these things that are what users would expect, even though underlying them, they're based on the same standards that frankly, Cognito and Auth0 and a lot of other people use as well. But to get back to your question, I would say that if you had chosen to use FusionAuth, you would have had a couple of advantages. The first is, as I mentioned, kind of the developer friendliness and the extensive documentation, example applications. The second would be our theme ability. And this is something that we hear from our clients over and over again is Cognito is

okay if you stay within the lines in terms of your user interface, right? If you just want to log in form, if you want to stay between lines and you don't want to customize your application's login page at all, We actually provide you with HTML templates. It's actually using a language called FreeMarker, but they let you do whatever the heck you want. Now, of course, with great power comes great responsibility. Now you own that piece, right? And we do have some more simple customization you can do

if all you want to do is change the color. But most of our clients are the kind of folks who really want their application login screen to look exactly like their application. And so they're willing to take on that slightly heavier burden. Unfortunately, Cognito doesn't give you that option at all. As far as I can tell, when I've kicked the tires on it, the theming is, how do I put this politely, some of our clients have found the theming to be lacking. That's part of the issue where when I was looking at all the reference implementations I could find for Cognito, it went from, oh, you have your own app and it's branding and the rest. And bam,

suddenly you're looking right, like you're logging into an AWS console sub-console property, because of course they have those. And it felt like, oh, great. If I'm going to rip off some company's design aesthetic wholesale, I'm sorry. Amazon is nowhere near anywhere except the bottom 10% of that list. I've got to say, I'm sorry, but it is not an aesthetically pleasing site, full stop. So why impose that on customers? It feels like it's one of those things where, like so many Amazon service teams say, we're going to start by building a minimum lovable product. And it's, yeah, it's a product that only a parent could love.

And the problem is so many of them don't seem to iterate beyond that to a full featured story. And this is, again, this is not every AWS service. A lot of them are phenomenal and grow into themselves over time. One of the best rags to riches stories that I can recall is EFS, their elastic file system, for an example. But others like Cognito

just sort of seem to sit and languish for so long that I've basically given up hope. Even if they wind up eventually fixing all of these problems, the reputation has been cemented at this point. They've got to give it a different terrible name. I mean, here's the thing, like EFS, if it looks horrible, right? Or if it has like a tough user experience, guess what?

Your users are devs. And if they're forced to use it, they will. They can sometimes see the glimmers of the beauty that is kind of embedded, right? The diamond in the rough. If your users come to a login page and see something ugly, you immediately have this really negative association. And so, again, the login and authentication process is really the front door to your application. And you just need to make sure that it shines. For me, at least, so much of what a user experience

or user takeaway is going to be about a company's product starts with their process of logging into it, which is one of the reasons that I have challenges with the way that multi-factor auth can be presented. Like step one, log into the thing. Oh, great, now you have to fish out your YubiKey or you have to go check your yubiKey or you have to go check your email for a link or enter or find a code somewhere and punch it in

it adds friction to a process so when you have these services or tools at oh your session will expire every 15 minutes and you have to do that whole thing again to log back in it's ugh I'm already annoyed by the time I even look at anything beyond just the login stuff. And heaven forbid, like there are worse things. Let's be very clear here. For example, if I log in to a site and I'm suddenly looking at someone else's account, yeah, that's known as a disaster.

And I don't care how beautiful the design aesthetic is or how easy to use it is, we're done here. But that is job zero, the security aspect of these things. Then there's all the polish that makes it go from something that people tolerate because they have to into something that, in the context of a login page, I guess, just sort of fades into the background. That's exactly what you want, right? It's just like the old story about the system, and people only notice when things are going wrong. People only care about authentication when it stops them from getting into what they actually want to do, right? No one ever says, oh my gosh, that logging

experience was so amazing for that application. I'm going to come back to that application, right? They notice when it's friction, they notice when it's standing in the gears. And our goal at Fusion Auth, obviously security is job zero, because as you said, the last thing you want is for a user to have access to some other user's data or to be able to escalate their privileges. But after that, you want to fade in the background, right? No one comes to FusionAuth and builds a whole application on top of it, right? We are one component that plugs into your application and lets you get on to the fundamentals of building the features that your users really care about. And then wraps your whole application in a blanket of security, essentially.

I'll take with me one more example before we just drive this point home in a way that I hope resonates with folks. Everyone has an opinion on logging into AWS properties because, oh, what about your Amazon account? At which point it's, oh, sit down, we're going for a ride here. Are you talking about my amazon.com account? Are you talking about the root account for my AWS account? Are you

talking about an IAM user? Are you talking about the service formerly known as AWS SSO that's now IAM Identity Center users? Are you talking about their Chime user account? Are you talking about your Repost Forum account? And so on and so on and so on. I'm sure I'm missing half a dozen right now off the top of my head. Yeah, that's awful. I've been also developing lately on top of Google Cloud, and it is so far to the opposite end of that spectrum that it's suspicious and more than a little bit frightening. When I go to console.cloud.google.com, I am, boom, there. There is no login approach, which on the one hand, I definitely appreciate just from a pure perspective

of your Google. You track everything I do on the internet. Thank you for not insulting my intelligence by pretending you don't know who I am when I log into your cloud console. Counterpoint, when I log into

the admin portal for my Google Workspaces account, admin.google.com, it always reprofs for a password, which is reasonable. You'd think that stuff running production might want to do something like that. In some cases, I would not be annoyed if it asked me to just type in a password again, when I get to the expensive things that have lasting repercussions. Although given my personality, logging into Gmail can have massive career repercussions as soon as I hit send on anything. I digress. And it is such a difference from user experience and ease of use that it's one of those areas where I feel like

you're fighting something of a losing battle. Just because when it works well, it's glorious to the point where you don't notice it. When authentication doesn't work well, it's glorious to the point where you don't notice it. When authentication doesn't work well, it's annoying. And there's really no in between. I don't have anything to say to that. I mean, I 100% agree that it's something that you have to get right and no one cares except for when you get it wrong. And if your listeners can take one thing away from this call, right? I know it's we're sponsored by FusionAuth. I want to rep FusionAuth. I want people to be aware of FusionAuth, but don't roll your own, right? There are a lot of solutions out there. I hope you evaluate FusionAuth. I hope you evaluate some other solutions, but this is such a critical thing. And Corey has laid out in multiple different

ways, the ways it can ruin your user experience and your reputation. So look at something that you can build or a library that you can build on top of. Don't roll your own. Please, please don't. This episode is sponsored in part by Honeycomb. When production is running slow, it's hard to know where problems originate. Is it your application code, users,

or the underlying systems? I've got five bucks on DNS, personally. Why scroll through endless dashboards while dealing with alert floods, going from tool to tool to tool that you employ, guessing at which puzzle pieces matter? Context switching and tool sprawl are slowly killing both your team and your business. You should care more about one of those than the other. Which one is up to you? Drop the separate pillars and enter a world of getting one unified understanding of the one thing driving your business, production.

With Honeycomb, you guess less and know more. Try it for free at honeycomb.io slash screaming in the cloud. Observability. It's more than just hipster monitoring. So tell me a little bit more about how it is that you folks think about yourselves in just in terms of the market space, for example, the idea of CIAM, customer IAM. It does feel viscerally different than traditional IAM in the context, you know, AWS, which I use all the time, but I don't think I have the vocabulary to describe it without

sounding like a buffoon. What is the definition between the two, please? Or the divergence, at least? Yeah. So, I mean, not to go back to AWS services, but I'm sure a lot of your listeners are familiar with them. AWS SSO, or the artist formerly known as AWS SSO, is IAM, right? So it's workforce, right? And workforce. And it was glorious to the point where I felt like it was basically NDA'd from other service teams because they couldn't talk about it. But it was, this was so much nicer than having to juggle IAM keys and sessions that time out after an hour in the console. What do you use doing in the console? I'm doing ClickOps, Jeremy, leave me alone. It's just, I want to make sure

that I'm talking about this the right way. It feels like AWS SSO, Creature formerly known as, and traditional IAM feel like the direction of the same thing as far as what they target, as far as customer bases and what they empower you to do. Absolutely. Absolutely. And there are other players in that same market, right? And that's the market that grew up originally. It's for employees. So employees have this very fixed life cycle. They have complicated relationships with other employees and departments and organizations.

You can tell them what to do, right? You can say you have to enroll your MFA key or you are no longer employed with us. Customers have a different set of requirements, and yet they're crucial to businesses because customers are who pay you money, right? And so things that customers do that employees don't. They choose to register. They pick you. You don't pick them.

They have a wide variety of devices and expectations. They also have a higher expectation of UX polish. Again, with an IAM solution, you can kind of dictate to your employees because you're paying them money. With a customer identity access management solution, it is part of your product. In the same way, you can't really dictate features unless you have something that the customer absolutely has to have and there are no substitutes for it. You have to adjust to the customer demands. CIAM is more responsive to those demands and is a smoother experience. The other thing I would say is that CIAM also, frankly, has a simpler model.

Most customers have access to applications. Maybe they have a couple of roles that, you know, an admin role, an editor role, a viewer role, if you're kind of a media conglomerate, for an example, but they don't have necessarily the thicket of complexity that you might have to have in IAM. So it's just simpler to model. Here's an area that feels like it's on the boundary between them. I distinctly remember being actively annoyed a while back that I had to roll my marketing person, her own entire AWS IAM account, solely so that she could upload assets into an S3 bucket that was driving some other stuff. It feels very much like that is a better use case for something that is a customer IAM

solution. Because if I screw up those permissions even slightly, well, congratulations, now I've inadvertently given someone access to wind up taking production down. It feels like it is way too close to things that are going to leave a mark. Whereas the idea of a customer authentication story for something like that is awesome. And no, please, if you're listening to this, don't email me with this thing you built and put on the marketplace that, oh, it uses signed URLs and whatnot to wind up automatically federating an identity just for this one person. Yes, I don't want to build something ridiculous and overwrought so a single person can update assets within S3. I promise, I don't want to do that.

It just ends badly. Well, that was the promise of Cognito, right? And that is actually one of the reasons you should stick with Cognito if you have super detailed requirements that are all about AWS and permissions to things inside AWS. Cognito has that tight integration. And I assume, I haven't looked at some of the other big cloud providers, but I assume that some of the other ones have that similar level of integration. So yeah, so my answer there would be Cognito is the CIAM solution that AWS has. So that is what I would expect it to be able to handle relatively smoothly. A question I have for you about the product itself is based on a frustration I originally

had with Cognito, which is that once you're in there and you are using that for authentication and you have users, there's no way for me to get access to the credentials of my users. I can't really do an export in any traditional sense. Is that possible with Fusion Auth? Absolutely. So your data is your data and because

we're a self-hosted or SaaS solution, if you're running it self-hosted, obviously you have access to the password hashes in your database. The hashes, not the plain text passwords, to be explicitly clear on this. Absolutely the hashes. And we have a number of guides

that help you get hashes from other providers into ours. We haven't written an export guide ourselves, but it's in the database and the schema is public. You can go download our schema right now. And I assume you've used an industry standard hashing algorithm for this. Yeah, we have a number of different options. You can bring your own actually if you want. And we've had people bring their own options because they have either special needs or they have an older thing that's not as secure. And so they still want their users to be able to log in.

So they write a plugin and then they import the user's hashes. And then we transparently re-encrypt with a more modern one. The default for us is PBK. I assume you do the re-encryption at login time, since there's no other way for you to get there. Exactly, yeah, yeah, yeah. Because that's the only time we see the password, right? Like, we don't see it any other time.

But we support bcrypt and other modern algorithms. And it's entirely configurable. If you want to set a factor, which basically is how many... I want to use MD5, because I'm still living in 2003. Please don't use MD5. Second takeaway, don't roll your own in. Don't use MD5. Yeah, so it's very tweakable,

but we ship with a secure default, basically. I just want to clarify as well why this is actively important. I don't think people quite understand that in many cases, picking an authentication provider is one of those lasting decisions where migrations take an awful lot of work,

and they probably should. There should be no mechanism by which I can export the clear text passwords. If any authentication provider advertises or offers such a thing, don't use that one. I'm going to be very direct on that point. The downside to this is that if you are going to migrate from any other provider to any other provider, it has to happen either slowly, as in every time people log in, it'll check with the old system and then migrate that user to the new one, or you have to force password resets for your entire customer base. And the problem with that is I don't care what story you tell me. If I get an email from one of my vendors saying, you now have to reset your password because we're

migrating to their auth thing or whatnot, there's no way around it. There's no messaging that solves this. People will think that you suffered a data breach that you are not disclosing. And that is a heavy, heavy lift. Another pattern I've seen is that for a period of three months or whatnot, depending on user base, you'll wind up having the plug-in there. And anyone who logs in after that point, well, you need to reset your password. And your password's expired. Click here to reset. That tends to be a little bit better when it's not the proactive outreach announcement. But it's still a difficult lift and it adds, again, friction to the customer experience. Yep. And the third one, which you

implied is, is you have access to your password hashes. They're hashed in a secure manner. And trust me, even though they're hashed securely, like if you contact FusionAuth and say, hey, I want to move off FusionAuth, we will arrange a way to get you your database in a secure manner, right? It's going to be encrypted. We're going to have a separate password that we communicate with you out of band because this is, even if it is hashed and salted and handled correctly, it's still very, very sensitive data because credentials are the keys to the kingdom. But those are the three options, right? The slow migration, which is operationally expensive.

The requiring the user to reset their password, which is horribly expensive from a user interface perspective, right? And a customer service perspective, or export your password hashes. And we think that the third option is the least of the evils because guess what? It's your data, right? It's your user data. We will help you be careful with it, but you own it.

I think that there's a lot of seriously important nuance to the whole world of authentication. And the fact that this is such a difficult area to even talk about with folks who are not deeply steeped in that ecosystem should be an indication alone that this is the sort of thing

that you definitely want to outsource to a company that knows what the hell they're doing. And it's not like other areas of tech where you can basically stumble your way through something. It's like, well, I'm going to write a Lambda to go ahead and post some nonsense on Twitter. Okay, are you good at programming? Not even slightly, but I am persistent and brute force is a viable strategy. So we're going to go with that one. Great. Okay, that's awesome. But authentication is one of those areas where mistakes will show.

The reputational impact of losing data goes from merely embarrassing to potentially life-ruining for folks. The most stressful job I've ever had from a data security position wasn't when I was dealing with money, because that's only money, which sounds like a weird thing to say. It was when I did a brief stint at Grindr, where people weren't out. In some countries, users could have wound up in jail or been killed if their sexuality became known. And that was the stuff that kept me up at night compared to that. Okay. You got some credit card numbers. What the hell do I care about that? Relatively speaking? It's like, yeah, well, my credit card number was stolen. Yeah. But did you die though? Oh, you had to make a phone call

and resent some stuff. I'm not trivializing the importance of data security. If you're a bank and you're listening to this and you're terrified, yeah, that's not what I'm saying at all. I'm just saying there are worse things. Sure. Yeah, I mean, I think that, unfortunately, the pandemic showed us that we're living more and more of our lives online. And the identity online and making sure that's safe and secure is just critical. And again, not just for your employees, although that's certainly important too, but more and more of your customer interactions are going to be taking place online because it's scalable, because it makes people money, because it allows for capabilities

that weren't previously there. And you have to take that seriously. So take care of your users' data. Please, please do that. And one of the best ways you can do that is by not touching the things that are commoditized in your effort to apply differentiation. That's why I will never again write my own auth system with a couple of asterisks next to it, because some of what I do is objectively horrifying, intentionally so. But if I care about the authentication piece, I have the good sense

to pay someone else to do it for me. From personal experience, you mentioned at the beginning that we go back a ways. I remember when I first discovered RDS and I thought, oh my God, I can outsource all this scut work, all of the database backups, all of the upgrades, all of the availability checking, right? Like I can outsource this to somebody else who will take this off my plate. And I was so thankful. And I don't, outside of, again, with some asterisks, right, there are places where I could consider running a database, but there are very few and far between. I feel like auth has entered that category. There are great providers like FusionAuth out there that are happy to take this off your plate and let you move forward. And in some ways, I'm not really sure which is more dangerous, like

not running a database properly or not running an auth system properly. they both give me shivers and I would hate to be forced to choose, but they're comparable levels of risk. So I 100% agree, Corey. Dan, I really want to thank you for taking so much time to talk to me about your view of the world. If people want to learn more because you're not in their inboxes responding to newsletters every week, where's the best place to find you? Sure. You can find more about me at Twitter. I'm moreds, M-O-O-R-E-D-S.

And you can learn more about FusionAuth and download it for free at fusionauth.io. And we will put links to all of that in the show notes. I really want to thank you again for just being so generous with your time. It's deeply appreciated. Corey, thank you so much for having me. Dan Moore, head of DevRel at FusionOff. I'm cloud economist Corey Quinn. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice. Whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice. Whereas if you've hated this podcast, please leave a five-star review

on your podcast platform of choice, along with an angry, insulting comment that'll be attributed to someone else because they screwed up by rolling their own authentication. If your AWS bill keeps rising and your blood pressure is doing the same, then you need the Duck Bill Group.

We help companies fix their AWS bill by making it smaller and less horrifying. The Duck Bill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started. This has been a HumblePod production. Stay humble.