Transcript

Announcer: 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.

Corey: 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 4 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 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/appconfig. That’s snark.cloud/appconfig.

Corey: 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 wanna 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.com. And my thanks to them for their continued support of this ridiculous nonsense.

Corey: 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.

Dan: Corey, thank you so much for having me.

Corey: 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, I haven’t 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 the first thing you asked was, “Is it okay that I keep doing this?” And at the bottom of the newsletter is “Hey, if you’ve 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.

Dan: 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.

Corey: 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?

Dan: 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 Access Management. Very similar to Auth0 or Cognito that some of your listeners might have heard of.

Corey: 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 use. 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.

Dan: [laugh]. Yeah. So, first of all, I’ve been at FusionAuth for a couple of years. Before I came to FusionAuth, I had rolled my own authentication a couple of times. And what I’ve realized working there is that it really is—there 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 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 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.

Corey: 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 dotcom 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, and 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 more suspicious and more than a little bit frightening. Tell me more.” “No, legal won’t let me.” And it’s “Okay.” Aside from the terrible things, how do you differentiate?

Dan: I liked that. That was an oddly specific disclaimer, right? Like, whenever a company says, “Oh, yeah, no.” [laugh].

Corey: “My breakfast cereal has less arsenic than leading brands.”

Dan: 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 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 in 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 with 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. Like, there’s actually a GitHub issues list you can go look on the FusionAuth GitHub profile and it shows exactly what we have planned for the next couple of releases.

Corey: If you go to one of my test reference applications, lasttweetinaws.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 was 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, spit and polish went into it.

Dan: So, I’ve used Cognito. I’m not going to bag on Cognito, I’m going to leave that to—[laugh].

Corey: 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 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 feel 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.

Dan: 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 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 a themeability. 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 login 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 I put this politely—some of our clients have found the theming to be lacking.

Corey: 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 its 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 do 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.

Dan: I mean, here’s the thing. Like, EFS, if it looks horrible, right, or if it has, like, a toughest 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 of your application, and you just need to make sure that it shines.

Corey: For me at least, so much of what’s 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, login to the thing.” Oh, great. Now, you have to fish out your YubiKey, or you have to go check your email for a link or find a code somewhere and punch it in. It adds friction to a process. So, when you have these services or tools that 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.

Dan: That’s exactly what you want, right? It’s just like the old story about the sysadmin. 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 login experience was so amazing for that application. I’m going to come back to that application,” right? They notice when it’s friction, they noticed when it’s sand in the gears.

And our goal at FusionAuth, obviously, security is job zero because as you said, 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.

Corey: I’ll take even 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 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 you’re 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 re-prompts 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. 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 annoying. And there’s really no in between.

Dan: I don’t have anything to say to that. I mean, I a hundred percent agree that it’s something that you could 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 Fusion, 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 [laugh] 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.

Corey: 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/screaminginthecloud. Observability: it’s more than just hipster monitoring.

Corey: 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 of, 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?

Dan: 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—

Corey: And it was glorious, to the point where I felt like it was basically NDA’ed from other service teams because they couldn’t talk about it. But this was so much nicer than having to juggle IAM keys and sessions that timeout after an hour in the console. “What do you 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 feels like they’re directionally the same thing as far as what they target, as far as customer bases, and what they empower you to do.

Dan: Absolutely, absolutely. 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 lifecycle. They have complicated relationships with other employees and departments in 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, [laugh] 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 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 an eye on, so it’s just simpler to model.

Corey: 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, you know, 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 per—” 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.

Dan: 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 that 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.

Corey: 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 FusionAuth?

Dan: 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. If you are—

Corey: The hashes, not the plaintext passwords to be explicitly clear on this. [laugh].

Dan: Absolutely the hashes. And we have a number of guides that help you get hashes from other providers into ours. We have a written export guide ourselves, but it’s in the database and the schema is public. You can go download our schema right now. And if—

Corey: And I assume you’ve used an industry standard hashing algorithm for this?

Dan: 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 users’ hashes, and then we transparently re-encrypt with a more modern one. The default for us is PDK.

Corey: I assume you do the re-encryption at login time because there’s no other way for you to get that.

Dan: Exactly. Yeah yeah yeah—

Corey: Yeah.

Dan: —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—

Corey: I want to use MD5 because I’m still living in 2003.

Dan: [laugh]. Please don’t use MD5. Second takeaway: don’t roll your own and don’t use MD5. Yeah, so it’s very tweakable, but we shipped with a secured default, basically.

Corey: 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 it for a period of three months or whatnot, depending on user base, you will wind up having the plug in there, and anyone who logs in after that point will, “Ohh you need to reset your password. And your password is 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.

Dan: Yep. And the third one—which you imply it—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.

So, 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 the 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.

Corey: 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 have 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 with that. What the hell do I care about that, relatively speaking?” It’s like, “Yeah, it’s well, my credit card number was stolen.” “Yeah, but did you die, though?” “Oh, you had to make a phone call and reset some stuff.” And I’m not trivializing the importance of data security. Especially, like, 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.

Dan: 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 safe and secure is just critical. And again, not just for your employees, although that’s really important, too, but 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.

Corey: 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.

Dan: From personal experience, you mentioned at the beginning that we go back aways. 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 they’re 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 [laugh] hate to be forced to choose. But they’re comparable levels of risk, so I a hundred percent agree, Corey.

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?

Dan: Sure, you can find more about me at Twitter. I’m @mooreds, M-O-O-R-E-D-S. And you can learn more about FusionAuth and download it for free at fusionauth.io.

Corey: 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.

Dan: Corey, thank you so much for having me.

Corey: Dan Moore, Head of DevRel at FusionAuth. 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, along with an angry, insulting comment that will be attributed to someone else because they screwed up by rolling their own authentication.

Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.

Announcer: This has been a HumblePod production. Stay humble.