Unpacking the Current State of Authentication and Authorization with Dan Moore

Dan Moore is Principal Product Engineer for FusionAuth where he helps evangelize authentication, authorization, and security. Dan is a former CTO, AWS certification instructor, and Engineering Director and has a wealth of experience in back-end development spanning 25 years. In this conversation, we discuss the origins of Customer Identity Access Management, where it is today, and what the future may hold.

Where to find Dan
LinkedIn: https://www.linkedin.com/in/mooreds/
Twitter: https://twitter.com/mooreds
GitHub: https://github.com/mooreds
Substack: https://ciamweekly.substack.com/
Vendor neutral articles: https://fusionauth.io/articles/

Follow, Like, and Subscribe!
Podcast: https://www.thecloudgambit.com/
YouTube: https://www.youtube.com/@TheCloudGambit
LinkedIn: https://www.linkedin.com/company/thecloudgambit
Twitter: https://twitter.com/TheCloudGambit
TikTok: https://www.tiktok.com/@thecloudgambit

Transcript

Speaker 1: 0:00

Dan Moore is Principal Product Engineer for FusionAuth, where he helps evangelize authentication, authorization and security. Dan is a former CTO, aws Certification Instructor and Engineering Director and has a wealth of experience in back-end development spanning 25 years. In this conversation, we discuss the origins of customer identity access management, where it is today and what the future may hold.

Speaker 2: 0:37

So greetings from the Cloud Gambit studio, aka my home office. How are things going today?

Speaker 3: 0:44

Dan, great Thanks for having me. I'm super excited to talk about cloud stuff and authentication stuff, and maybe not the rain in Kentucky, yeah.

Speaker 2: 0:54

So this whole for the listeners. I was just talking to Dan about springtime in Kentucky. We're in this Ohio Valley, which is a sub region of Kentucky, like running somewhere in the ballpark of like 650 miles long or something like that. Needless to say, we get quite a bit of rain in the springtime, so whenever sun does peak through and it's not raining in the springtime- we try to take advantage.

Speaker 2: 1:21

Yeah, I took a walk earlier. It was really nice, got a little bit of sunshine, so, yep, holding on for dear life. So today we're going to be digging into a topic that really is just absolutely important for organizations to get right and is just also absolutely painful to execute, and one of my least favorite things to work with, which means it must be very important it right and is just also absolutely painful to execute, and one of my least favorite things to work with, which means it must be very important. You know it's hard, and that is customer identity and access management. But before we throw down the gauntlet, let's add some historical context. So, since the dawn of time, or at least since humans have been consuming technology, there's been a need to restrict access to resources to only those that need that access, for whatever reason. Um, what are, what were some of the first forms of authentication?

Speaker 3: 2:22

yeah. So I actually did a talk on this a couple of years ago for a startup week and and I pull up that slide deck to kind of review some of it and you know there were passports which you can think of as kind of written form of authentication in China. I want to say, before the common era, there's actually a passage in the Bible talking about Shibboleth which some of your users or sorry, some of your listeners may know as a SAML piece of software, but it's actually. There was a river and there were two tribes and they were fighting and one tribe wanted to shoot over the river and the other tribe said was wanted to shoot over the river and the other tribe said, you know, was trying to prevent them from doing that and they couldn't tell who was who. But one tribe said the word Shibboleth and the other ones didn't pronounce the S-H, I believe, or they had some different way of pronouncing it.

Speaker 3: 3:17

And so that's the first thing that I know of where it was like a verbal kind of way to control access to something and it was really important something. In this case, that way it was your life, because if you said it wrong they were going to kill you because you were in the wrong tribe, you know. Then we can kind of jump into like passwords and the first password I think was in 61 or 62, because before then computers didn't really have user accounts. And there's a great story in Wired talking about the first password and how it got hacked, because it didn't take very long, from the first passwords, which basically control access to computer resources, to people realizing, hey, I want more access, and then finding a way to circumvent the access that the passwords control. I can talk about that more or we can move on to kind of other pieces, whatever you want to do.

Speaker 2: 4:10

Yeah, I mean I guess we could. Yeah, everybody's familiar with, you know username password, you know, obviously, and I think from there, you know, with authentication, multi-factor sort of came along. I think that was like the net. I don't know if it was the next big thing. Besides username password, just some two forms of authentication. I guess Like what sort of drove this thing Was it? Like bank accounts getting hacked or something you know? When it has financial impact, of course it's going to get more, maybe more visibility, I don't know.

Speaker 3: 4:41

Yeah, I don't actually know the exact reason why mfa came about, like there was a specific incident, but I do know that the first passwords were, um, you know, stored in plain text, and then they were encrypted and then they were, uh, hashed, which is the right way to do it, and I remember in the 90s, actually working on a project at a company I was at that they were just cracking people's passwords to just check for security.

Speaker 3: 5:09

And as computing has gotten more powerful, as the network has expanded, more and more passwords are out there, and multi-factor or MFA, which is basically kind of ranges from getting a text message, you know, code, sent to you to using Google Authenticator, to having specific hardware tokens or using something like Face ID. All those, or YubiKey, all those things basically provide an additional level of assurance and that's why we do them. Everyone who uses them knows they increase user friction and people hate them. But I'll tell you what's worse than you know entering a code is getting thousands of dollars stolen from your bank account or other kind of bad things that can happen if your account is compromised.

Speaker 2: 6:01

Yeah, it's bad enough if you're an individual user and you log in and your your bank account's empty, um, but you know beyond that, if you're a large corporation, you know waking up and seeing yourself on the news can't be, um, can't be a good thing, you know it's.

Speaker 2: 6:17

Yeah, and I mean I know, like for me anyway, like I was when I was trying to learn, just see, I guess, like secrets management, like the right way to do secrets management, um, I started doing it on my local environment with all my environment variables and everything I'm using, like one password, and I have a lot of my environment variables there. So whenever my mac boots up, um, I have an api key, it goes out and it fetches all my secrets, puts them in an environment file and that's what all my automation is run from. And then when I turn my machine off, it's, you know, not persistent, it's gone, and then I just rotate the key and it's actually easier. So you might think it's hard to do that, but it actually makes it easier. It's less I have to think about and the security is kind of built in, which is, you know, a good thing, um, if you can make your life easier in certain circumstances.

Speaker 2: 7:10

But how did uh so mobile came along? Everybody has a computer basically in their pocket that they're walking around with all the time, and just mobility in general. Um, has this sort of influenced authentication and authorization in any way like how did how has it impacted things?

Speaker 3: 7:31

yeah, I would say that the big impact from my perspective around authentication authorization with mobile is just the rise of apis, because before mobile devices were really prevalent, there were still APIs, but you know, a lot of stuff could be done server side and then all of the document the HTML or whatnot sent down to the browser and the browser really just rendered things. It didn't actually like do stuff. Xml HTTP requests, which happened in the mid 2000s, was the start of that. Http request, which happened in the mid-2000s, was the start of that. But mobile devices because they were using that custom Chrome and they weren't using the browser and you weren't going to really render everything server-side really led to explosion of APIs.

Speaker 3: 8:14

And then you end up with these platforms that have this data Facebook and Google, etc. That wanted to let people use their APIs to get access to users' data. Right, so an app gets access to my data on Google on my behalf. Well, that all required authorization. So that's where the OAuth spec came from, is a way to do that delegation that didn't require me to enter my Google username and password into J random app and for me to be able to get Google's data into that application. So that's probably the biggest thing that mobile apps have done, just kind of the explosion of APIs and then the need for access control on top of that.

Speaker 2: 9:00

Yeah, so you mentioned a few good points and also I guess this probably should have come before the phone question, but just the concept of single sign-on. When single sign-on came along, I remember the first SSS system I had to work with a long time ago, but LDAP all this got introduced with the explosion of really the network and information, the exchange of data and things like that. How, like with SSO, just in general, it seems like you're putting all your trust sort of in, like you know one basket. Is there tradeoffs there to think about, or is it just something that you know? You've got to pick one that you trust and you have to deploy it right? You know what are your thoughts there? Sure.

Speaker 3: 9:48

Yeah, I mean.

Speaker 3: 9:48

So LDAP started like I think it was 1993 or something like that was kind of the first LDAP, so it's been around for a while and kind of as far as trade offs, you know, I think it depends on the context that you're in. The first SSO servers I'm aware of were really around like big centralized organizations that really needed that strict kind of top-down access control universities or big corporations and so for them LDAP was a godsend because you could say you know Dan from accounting gets access to these apps and William from engineering gets access to these apps, and have a centralized view of the system. And with LDAP, I believe LDAP lets you federate and so you could actually have delegate. You know engineering gets to control engineering's users and then accounting gets control of accounting users et cetera, and I think that's a really powerful way to help scale out access control.

Speaker 3: 10:53

In the consumer context or the customer context it's a little bit different and I would say that you know whether I trust an SSO server really depends on kind of the needs that I have, what application they're controlling access to and then what data of mine they have. In some cases you don't really have a lot of options other than kind of maybe between a couple of the big ones. As a customer, right, am I going to log in with Google or Apple or Facebook, and then obviously the developer has a say in that too. But at the end of the day, I think that the trade-off in ease of use and security is worth kind of the delegation model, even for customers, because I always say that log in with, like a Gmail account or a passwordless account, which is kind of a different way to log in, but still trust one source. You know you pay way more attention to a small number of accounts and you can secure them way better using SSO than you can if you had to create an account.

Speaker 3: 12:02

Try to be careful here because I make, speaking in generalities, the normal user, the normal customer, will probably secure their Google account or the Gmail account or the Facebook account much better than 100 different accounts they have at 100 different e-commerce sites or funny webcomic sites or whatever. Your listeners being nerds that they are probably like no, no, no, I use a password manager. Everything's arbitrary, it's great and that works great. If you're like a geek um, you know I am not married to a geek and she uses a password manager. It's kind of built into her browser, but she doesn't really get everything about it and it causes her significant pain. As opposed to if she just logged in with Google every place, she would, you know, have that more centralized source and, I think, would have a better user experience. Is that kind of what you were getting to with the question?

Speaker 2: 12:55

Absolutely. Yeah, that makes perfect sense. And I mean, even if you are a nerd or you know, you have a lot of accounts and things you test when you're managing all this stuff. You know a password manager makes it a lot easier, for sure, but the more accounts you have, the more, the more headache it is. Are you even rotating the username or the passwords? You know it's one place that could get exploited, that has all your things there. Um, you know, just, there's trade-offs to everything in security, obviously and you know we kind of you know we.

Speaker 2: 13:26

We started, you know, just like the beginning of this conversation, with verbal sort of things used for access to you know, usernames and passwords. You know that were probably like your, your last name or something in the beginning to think about how these things are now. If you thought LDAP was a giant thing and usernames and passwords were a giant thing, cloud came along and really just flipped over the kitchen table on traditional authentication and access management, things really shifted. A lot more interaction surfaces, a lot more things to secure, porous endpoints everywhere. Everything needs to be authenticated and continually authorized over time, which is kind of where your background, your expertise, even the company you work for, fusionauth comes into play. Focus on what is known as customer identity and access management. But can you get into that? What is you know? Because most people know identity and access management, but what is just throwing the customer on the beginning to change things? What does that mean?

Speaker 3: 14:39

Yeah, I mean the easiest way to think about that is it's the difference between how you treat an employee and how you treat a customer. Customers are great for businesses, right? Most businesses I know want customers. But customers have a lot of choices and you want to make things as easy as possible for a customer to interact with your business or buy from your business business. And you can contrast that with an employee where you can basically tell an employee hey, you're going to use this in such and such hardware token to use for MFA, or you're always going to use the IE6 browser Sorry anybody who's out there being forced to use an IE6 browser et cetera.

Speaker 3: 15:18

So customers pay you money, you pay employees money. Therefore, customers pay you money, you pay employees money. Therefore, a lot of the same concepts apply, from identity and access management in terms of the core concepts and some constructs like groups and accounts and credentials and even single sign-on. The bigger difference is it tends to be less complicated to map because you're dealing with you know, maybe customers or customers' customers, maybe you have an organization, but it's not quite the same level of complexity as your organization and then it has to be simple, no-transcript.

Speaker 2: 16:01

Right, yeah, totally agree. Those are great points. Why? So, just going back in my experience, especially in cloud with identity and actually looking at a lot of identity systems, this is a really hard problem to solve. I don't want to say that it's not taken seriously in the beginning, but it's one of those things where, if you're a big company, you don't really, you don't really understand that something is a big problem and still it, you know, until it starts hurting. Like I don't go to buy aspirin when I don't have a headache. You know it's just something that, okay, I have a headache, I have a. You know it's a very reactive thing. Why is identity management such a hard problem to solve?

Speaker 3: 16:49

Yeah, I think there's a couple of reasons. One is and you kind of hit on this you know it's a non-functional requirement in a lot of ways, the same way that performance or security in general is, and those only become problems. When they become problems, um, it's kind of cross-cutting. And I think another kind of reason why identity is hard thing to solve is that it is, um, risky. Uh, because it really is the keys to your application, especially as more and more things have moved online and it evolves over time. Now I'm not going to say that identity moves as fast as, say, javascript frameworks or something like that, but there has been changes in best practices around algorithms and even the OAuth stuff we talked about I kind of alluded to earlier like that standard has moved and improved over time. And so the combination of the risk, the movement of the technology and the underlying algorithms, and then the fact that it is this side thing that every application needs and most applications can get by with you know one of a couple of different kind of models, but it doesn't again, it's just not something your customers are paying for Like, and so, as an engineer, when you get started, you're really thinking about you know what's my differentiating feature? Why are people going to want to sign up or use my application at all? And I've never and I work in an identity company, I've never met anybody who's like.

Speaker 3: 18:24

The key thing, the reason why I signed up for your application, is because of the way you let me log in. No one ever says that. It's always a barrier to be got through and you want to raise it up high enough where the bad people can Bad people, that's the wrong way to put it when attackers are discouraged from coming in and you get the kind of folks that you want in your application. But you want to be lower, simple enough that, um, that as many of your users as you can get can come in. So it's like this real tension and that is, I guess, that kind of plays into the risk factor as well, and it's not something that someone who's just banging out features, um, or is used to like kind of selling existing things, is going to be as comfortable yeah, yeah, barrier to entry is a huge thing, especially nowadays when so many things we use are just very easy, like I can sign up for.

Speaker 2: 19:19

If it's a software product, usually there's a free trial or just an open source variant that I can use and design myself, you know. So the barrier to entry is pretty simple for a lot of products these days. But, um, when you, when you think about like brownfield environments and coming retroactively and trying to fix some of these things, that's where it kind of can be challenging sometimes. And I guess next thing is like why, why do folks you know, many developers are now building on cloud exclusively, many startups or they're started on cloud out of the gate. Um, so why, why should these developers or why should these folks care about, uh, customer identity and access management? Like, how does it help them, does it make their job easier and get the product out faster, that they can sort of offload these responsibilities to maybe another product? Or what are your thoughts there?

Speaker 3: 20:15

Yeah. So I just want to address the brownfield thing real quick, because we see a lot of people that are coming in homegrown and they're talking to us FusionAuth and they're talking to other vendors which is totally fine, that's expected and they want standards-based ability to add things to their application, or not even standards-based, they want a standards-based interface. And then they want the ability to add additional features to their application in a brownfield environment, which, if your listeners don't know what that is, that basically means it's opposite of greenfield. There's an existing application. You need to kind of bolt some new functionality on, which kind of plays into your question about what people in cloud could care about.

Speaker 3: 20:56

I think that the two main reasons we see people can consider an identity provider or an outsourced authentication server are basically well, maybe there's three reasons. The first is taking care of that risk and moving that risk off their plate. So, whether you use again a solution like FusionAuth or a solution like Cognito that's more integrated with the cloud providers, in either case you're taking this kind of risky thing which is making sure the users who they say they are, and you're pushing off to somebody else to maintain it could include their profile data and other things that would be really bad if they got out in the wild. So security is one reason, speed of development is another, and I would say that is, you know, if you have implemented, let's say, multi-factor authentication multiple times, then you use a product that has that built in and you click a button, or you use Terraform to configure it or whatever the right way to enable that feature is, and then it just works. And it doesn't just work right then, but it is guaranteed to work in the future because you have a dedicated team pushing that forward.

Speaker 3: 22:21

The third thing I would say is a little bit different, but it's kind of similar. The idea is, if you use an outsourced authentication server and you have your applications one or more delegate to that, then you can see improvements in application security without ever modifying your applications. So let's just take Cognito right, if I am building cloud applications and I delegate to Cognito, then later I can realize, oh, I need to turn on MFA or Cognito might improve in a way that says you know, we're going to start blocking more bots or whatnot, and my applications all benefit from Cognito improving without changing a line of application code. And that is one of the benefits of cloud in general, right? Is that like? If you build on top of cloud, you can get improvements from the hyperscalers without much effort on your part. Maybe you pay a little more money, maybe you have to press a button to migrate from you know EC2 Classic to EC vpc or whatever the thing is, but it's much less effort in general and you can get some of the same benefits from an identity provider right.

Speaker 2: 23:33

Right. So you brought up cognito and you know there's, of course. I guess it would be pertinent to get into the landscape a little bit like what are you know who would be some of? Uh, I guess fusion ops competitor? What are the vendors in the space? And furthermore, like is, who would be some of, I guess, fusionauth's competitors? What are the vendors in the space? And furthermore, what does Gartner view this as? Is there a magic quadrant and what's going on there?

Speaker 3: 23:58

Sure. So I know there's an IAM magic quadrant. I'll be honest, I haven't looked to see if there's a IAM magic quadrant. I'll be honest, I haven't looked to see if there's a CIAM magic quadrant. But there's three or four groups of vendors in this area. So the first, I would say, are the Okta's, ping's, forgerock's, and they started out in IAM and they're moving into customer identity and access management because they're looking for more growth and because it's a related kind of field. Those tend to be more standards compliant, they tend to be more expensive, they tend to be more talk to sales to get going in an organization and you can obviously you know, sorry, if they are embedded in your organization, that might be a good fit for your SCIAM needs.

Speaker 3: 24:50

Then there's open source solutions. Key Cloak is one of those. There are others out there that I think are good, but, just like any other open source solution, you tend to be responsible for maintenance and running them and operating them. Then there's the hyperscaler solutions, which are basically Google has one, aws has Cognito, google is called Google Identity Platform, but it used to be called Firebase. And then Microsoft Azure has one too. It used to be called Azureure ad b2c, but I think it might be called entra now they've done some rebranding but um, and those are good if you are again embedded with the cloud. Um, cognito, in particular, has some interesting abilities to issue uh credentials or basically uh, I think they're called SSO tokens or session tokens. Basically, you can assume a role for a short period of time to access AWS resources directly, like an S3 bucket or DynamoDB table. Again, with Incognito's case, they actually can leverage IAM to do that.

Speaker 3: 26:04

And then there's a bunch of. Then there's some developer-focused ones. I have, I think, two more categories the developer-focused ones, which Auth0 is kind of the big gorilla in the building and that's where I kind of would place FusionAuth. Kind of super developer-focused, maybe SaaS, maybe downloadable. Fusionauth is both. And then there's kind of after Auth0 got built no, sorry, auth0 got bought in 2021 by Okta, which probably none of your listeners cared about and I wouldn't have cared about it if I hadn't worked for an authentication company, but it really sent shockwaves through the identity industry. And there have been a ton of smaller startups, some of whom raised $100 million in the last couple of years, who are kind of rushing into that space that Auth0. I won't say they vacated, because obviously they're still in business and they're still trying to make money. But the Okta Auth0 integration did not go as smoothly as I think either side had hoped, and so there have been some opportunities in the market from that. Does that give you kind of a good idea of the landscape?

Speaker 2: 27:09

Yeah, yeah, absolutely, and that actually pivots perfectly into my next question.

Speaker 1: 27:15

So I'm going to.

Speaker 2: 27:17

I'm going to sort of frame the question and then I'm going to sort of give you the way I think about it, which is from someone that's outside of this space, but then I'll let you sort of give some input. But I guess my question is when you're thinking about these products, usually a big enterprise or a big organization, they're going to do some kind of bake-off. They're going to be looking at functionality and just, you know, just meeting the business requirements by balancing cost and really operations like, can we deploy this, can we manage it? You know, what does day two look like? All these things? So what? What should you think about when deciding on these products?

Speaker 2: 27:56

As far as functionality and like a fit and I guess my so, in a lot of the big environments I worked in before I came to the startup space, there were a lot of them ended up being like multi cloud.

Speaker 2: 28:08

So we had to make that decision of do we want to use the cloud native form of a thing where they're going to really go all in with what is going to enable and simplify their specific cloud platform, but they're not going to try to make things super easy, integrated and smooth for other cloud platforms? So then you have to make that decision. Do I want numerous identity platforms that I have to work with and then I need some sort of integration layer between them, or do we look outside for a product maybe like FusionAuth or one of these other products that's going to work across all these different platforms and give us uh, you know, maybe you don't have every single detail in a specific cloud platform, but you have a pretty good common um platform that'll solve for the majority of your use cases. So that's the way I sort of think about it. But what? What would you?

Speaker 3: 29:00

say yeah, I mean, there's a. There's a ton of different ways to evaluate this right. Like you know, you can think of this as I mean. I think it's an interesting question and you could actually kind of step back and forget that it's about identity providers in general. Right, it's like about a piece of software that you are thinking about integrating into your application and what would you do to do that? Right, about a piece of software that you are thinking about integrating into your application and what would you do to do that right? Like what would? What steps would you take in? A large enterprise is going to have different needs than a startup, and so they'll be better served by different products. The other thing I would say is you know, I would not treat this evaluation process the same way that I would treat like evaluation evaluation process for like a marketing widget. This is going to be a core piece of functionality in your application, so I would treat it with the same respect you would for picking a database or even picking a cloud vendor. Right, like, this is something that you can move off of a cloud vendor, you can move off of a different identity provider, but it's going to be a pain in the butt and you're going to end up with exactly the same functionality probably that you had when you started. So it's it is a long-term commitment.

Speaker 3: 30:11

So the things that you know I've heard people talk about are documentation, um, frictionless kind of um, how easy is it going with something? Um, and then you know, is there documentation kind of past that? Right, like the one-on-one documentation is great, but do you have other kinds of documentation? How accurate is it? Like, nothing as a developer causes me to lose more trust than when I bang my head against a problem for, like you know, an hour or three hours and then the documentation was wrong. One thing as you kind of alluded to is do you want to kind of be all in on a single cloud or do you want to go with something that's multi-cloud? Another kind of dimension of that is do you want a SaaS solution or something that's self-hosted? Those have different trade-offs. Do you want to operate a piece of software yourself or do you want to just have it be out there and basically have your SLAs be at the mercy of that other provider?

Speaker 3: 31:11

The answer I can't give you that answer. You need to kind of make that decision for yourself, kind of diving into kind of more developer-focused things. I think there's a term called mouth fill, which is like the way something feels as you eat it, and there's also this concept of the mouth feel of an api. Is an api consistent? Does it, you know? Do you need to constantly consult the documentation? Does it work the way you expect it to? And I think that's important again, because this is no one ever used an identity product, identity provider, like by themselves. They're always integrating with applications, so that kind of consistency is important.

Speaker 3: 31:50

Obviously, there's functionality out there and I'm not going to pretend that FusionAuth is 100% complete, so you always need to be like well, do I need this particular thing? That can be a deciding point. The three other things I would say are one how extensible is this product? If you need extensibility and again it's hard to kind of future proof, that kind of thing but at least thinking like hey, we pretty much just need login and mfa and that's really all we want is a different kind of product and we want to be able to have user administration and we want fine-gra's. Really all we want is a different kind of product and we want to be able to have user administration and we want fine grain permissions and we want to do, you know, some other things.

Speaker 3: 32:29

The final two things would be finding out customers of a proposed solution and seeing whether they map to your space, because if someone has served people like you in the past, they're probably going to be well served by them and they'll ask to be just. You know, what kind of road mapping communication are there around these, around this product? Like I talked about how authentication doesn't move super fast, but it definitely evolves over time. Are you seeing progress? How do they communicate to customers? Those are all you know. I gave you like 10 things to think about, but I think those are all things that I would consider. And then which one, which one you want to emphasize more than the other, usually based on kind of who you are and where you're coming yeah, those are all great points and those honestly map perfectly back to like the decision making process.

Speaker 2: 33:16

You know, I would. You know I've went through in the past with teams, you know, and sort of a cloud center of excellence is worth thinking through, these things, um, and I would say sorry, real quick, I would also say don't trust vendors.

Speaker 3: 33:29

Like do it yourself, right. Like we have plenty of people who go through pocs with us. Some of them choose to proceed with us, some of them choose not to. But like is a world of difference between like seeing a demo presentation or like a slide deck versus like downloading the code and like doing integration yourself, doing that spike. That is going to be tremendously more valuable for you to evaluate things sorry, go ahead 100.

Speaker 2: 33:50

No, that's a. That's a great point. I yeah, you've got a prototype that you have to go into poc. You have to get hands-on or you're not doing due diligence these days and you know to that point like products are so easy. You know, back in the day when everything in the world was hardware based, you had to have things shipped on site. You had to have a team, you know, maybe cable some things up, do a whole bunch of stuff. Maybe you had to order servers. You had to do so much to try something. You don't have to do that anymore. It's so much quicker, you know, and a lot of times a POC is going to be paid by the vendor that's, you know, trying to sell to you. So all it is is your time a little bit and you can really go through and pick maybe your top three, really evaluate those solutions, see what's going to work best for you. So that's a great point.

Speaker 3: 34:53

So that's a great point. Is there any sort of a use case? You know where? You know customer identity and access management is like not case, because there's basically kind of four categories I put applications into. The first would be an application that doesn't need, doesn't have any concept of users. This would be like a brochure website or maybe a data-facing application, a data processing application that just pulls from an S3 bucket, does some processing, pushes to the other S3 bucket, doesn't really have any concept of customers, so that we can kind of say SIAM is a bad fit for that right. Just in general, because if you don't have users, you don't need SIAM. Then there's people that build their own homegrown systems. In that case it can kind of be bespoke and I would say that a SIAM system is probably a good replacement for those folks. Once they get to a certain size and they feel that pain, as you alluded to, plenty of people don't feel that pain and can just kind of get by with what they have.

Speaker 3: 35:56

Third option is using a open source library or something that's built into your framework and that handles your users, and I think that's great as long as you have one application.

Speaker 3: 36:08

As soon as you start to get multiple applications, you have silos of different users and people have different passwords across different applications or different permissions are not kind of synced up. You don't have any central view of who has access to which of your applications. So that's where I would say go to the fourth level, which is you know you have a single source of identity, or in any real large enterprise you're going to have multiple sources, but at least for a given suite of applications you have a single source. And there I think about SIAM as like normalizing user identity. Right, the same benefits and trade-offs for normalizing data in a relational database apply to normalizing user identity. So the places where SIAM don't make sense are you have no concept of users or, and again, maybe in that case this is a SCIAM server outside of your application. If you only have one application, it's going to be simpler to deploy and bundle your user-facing code with that same application than it will be to introduce a third or, sorry, another architectural component.

Speaker 2: 37:18

Does that make sense? Yeah, it makes perfect sense. Yeah, great point point. So what about? What about businesses? You know I, I would think that siam is just really important. As far as you know, businesses meeting like gdpr, uh, c, c, cpa, I think, and like hippa, like I came from health care, hip is just gigantic. Your data, your intellectual property is so critical. Um is siam like a really good fit if you're trying to really sure up these areas and make sure your intellectual property and customer data is secure and everything is is. Does this play a part in that?

Speaker 3: 37:58

yeah, the main way we see that.

Speaker 3: 38:00

Well, there are two ways we see that kind of play a role. The first is people may already have kind of existing solutions that resolve these things and so they just want to like throw like a solid authentication layer on top of it. The second is where they actually want to use the SCI-AMP system as a system of record for profile data and to delete or to be a place where, if someone comes in with a GDPR request and says, hey, I want to delete, I want to be forgotten, the SIAMS system can be the starting point right. First we delete their profile, but some SIAMS systems have the ability to kind of fire off integrations around, like someone's account has been deleted into all these other systems that may have PII around that user right, maybe preference data or order history or whatnot. So SIAM can kind of be the hub of that.

Speaker 3: 38:57

Spoke of deletion. And that's not to say that you couldn't implement all this stuff without Siam. You absolutely could. But having a centralized place where, hey, this is where our customer's data lives, does make it easier to reason about that kind of request.

Speaker 2: 39:14

Yeah, yeah, that makes a lot of sense. And even back to your point about you know, you sort of talked about how much of the product you want to own and manage versus like looking just purely at like a SaaS play. And I mean, one example of that, just dating back to some of my older experience, was, you know, you only have you really want to optimize your developers. You want them to be working on things that are going to be valuable to your business, them to be working on things that are going to be valuable to your business. So a lot of times what we would do is we'd first evaluate, like, okay, is there any SaaS-based solutions that really solve our problem? And if there wasn't, we would like go down a layer, like, okay, is this something we would want to do with like a platform as a service? You know, use cloud-native data bit. You know, really just go all in with a really cloud-native focus. And then some of these solutions, all that's available, at least at that time, was IaaS or, you know, rolling it in your own data center. So we just sort of go down that hierarchy until we got something that would fit there.

Speaker 2: 40:12

So I guess you know, kind of to wrap this up, I mean I think the future is bright. You know security. I mean there is a lot of. I think the AI stuff, machine learning and all the chatbots of the world are making it hard on security out there and you know they're finding new ways to do things. But there's also a lot of really bright minds that are, you know, working on products like, you know, FusionAuth, just many others. Do you sort of have a crystal ball that you want to pull out and kind of peer into the future? You know what do you think's coming? You know, if Dan Moore had to guess, you know what do you think?

Speaker 3: 40:49

Yeah, so I think that I'd probably pick a couple of things. I think that the first is there's a technology called PassKeys, which is something that your listeners may have heard of, but it's basically a way for you to have true, passwordless authentication based on public-private key cryptography, and it addresses some of the concerns that are often raised around. You know, is something more secure going to be more of a pain in the butt for your users? We talked about MFA way back at the beginning and passkeys, once they reach kind of a critical stage of adoption, I think will help with that because they are unfishable, because it's not like the user is getting a code and they could be, you know, repeating that code back to an attacker who's calling them. It's actually a piece of hardware that is interacting with the stuff and the user is interacting with that hardware. So, as long as I trust my Android phone, then the passkey is going to be secure and it's also because it's kind of built on later stage technologies, like it matches to the origin and again, I can't type in an incorrect origin or be sent an email with an incorrect origin and enter my PASC.

Speaker 3: 42:14

So PASCs are kind of the first piece and I think the second piece is more and more of our lives are going to move online, and so I just don't see us moving away from having to log in to access important things, whether that's interacting with the government, interacting with utilities, interacting with schools if you have children, children like and so I think that, um, anything we can do, like pass keys but I think there's some other things in the works too um anything we do to make that a more secure, sane, um. Easy is maybe too hard a word, but like easier process is is gonna have kind of massive adoption in the in the world, because I don't know about you, but like I don't see us going away from more online communication, more online applications. It seems like we're heading towards more of them and more of our lives being uh run through those uh situation yeah, a hundred percent.

Speaker 2: 43:15

Yeah, more things, more of our lives, are online than many, many know. Seems like everything's up there now. Um, yeah, well, I, I want to, you know, just say thanks for coming on, thanks for talking to me. Um, where can the audience find you? Are you on social anywhere?

Speaker 3: 43:33

yeah, so I'm on linkedin. If you search for dan moore, you'll find a lot of dan moore's, but you can search for dan moore, boulder, and I'll probably pop up. Or Dan Moore, fusion Auth I'm on Twitter still, or X, whatever they call it nowadays. I have a GitHub account which is githubcommoreds. Sorry, the Twitter account is twittercommoreds M-O-R-E-D-S. And then I have a substack where I write about siam stuff um, coming up in a year actually and that's at siamweeklysubstackcom. And finally, if you want to learn more about fusion off, either fusion off the actual product, that's fusion dot io. And then we have a large library of articles that talk about identity in the abstract, like identity basics, oauth, authentication, siam, and that's all at fusionauthio. So I fight very hard to keep any mention of the word fusionauth out of those vendor-neutral articles, and I feel like they're really good for someone who just wants to get an idea of how to get started with authentication, either from an implementation or a kind of a purchase standpoint.

Speaker 2: 44:46

That's a great point. I want to second the value to actually just going out and educating yourself. So think of it in terms of, okay, like, oh, we have to buy a product, so I have to learn about the product, Instead of doing that like, look at the. You know, what is this outcropping of products meant to solve? Like, what is the actual problem you're trying to solve? What are the options of solving that problem? You know, get familiar with the technology by reading. You know articles like this, and I'll link all these in the show notes.

Speaker 3: 45:15

There's this like tension here, right, like, which is why would I listen to Dan? He's selling me something and I want you all to understand that. I know and acknowledge that and I deal with that. Every time I have a plumber come to my house, I'm like, yes, you can help me solve my problem, but you're also incented to sell me more plumbing services, and so visit FusionAuthsio articles. But there's lots of other stuff out there and I think if you spend some time researching and don't just like go to the vendor website, you're going to have a better way to triangulate, kind of getting you the solution that you really need awesome.

Speaker 2: 45:54

Yeah, totally agreed there, all right, well, thanks again, appreciate your time. Thank you so much.

Speaker 3: 46:01

Really appreciate the conversation.