Julianna Lamb on Choosing Authentication Platforms Over DIY

This is Textron tv. Hey guys, thanks for the Ferro. We're here with Juliana Lamb, who's the CTO for Stitch, and we're talking about authentication and building it versus buying it because, well, historically there's been a natural bias towards building, but maybe we need to rethink that.

Juliana, welcome to the show. Thanks for having me. What goes into the thought process of people when they're building software and everything else that they want to create, that they decide that somehow or other they want to go create their own authentication schemes?

I always looked at that and said, well, it doesn't seem like it's differentiation in any meaningful way, so do we need to kind of stick, take a step back and rethink this? Yeah, I think oftentimes when it comes to authentication, when you're just getting started, you often have, um, pretty straightforward requirements. You might start out with like email, password, um, you know, maybe one OAuth integration sign in with Google, et cetera.

Uh, and so I think when you're like starting to do that sort of initial evaluation of like, should I build versus buy, uh, building can often look quite like simple on, um, on the surface. Uh, and I think as you continue to grow and, and scale your business, the complexity just really sort of like multiplies. And that's not always something that's kind of like going into that initial, um, initial decision criteria.

Um, I think auth is also a case where like the edge cases really matter. Like if there are, um, sort of like different interactions between the different login methods you have that might lead to like an account takeover, for example. Like there's so many little sort of like edge cases that when you're talking about like security and um, user identity, like those matter, you need to get that right.

And so the happy path might be very straightforward, but the like ways in which it can go wrong, uh, can sometimes be, um, almost infinite. Is there some point where I cross the proverbial Rubicon and that I, I incur that complexity and I don't really see it because there's so many developers and they all wind up doing something and then we kind of have some sort of partially adhere to standard and before you know it, um, my costs are going through the roof. Yeah, I think especially, um, when you're talking about like B2B authentication, so if you're building a product that you're selling to other businesses, um, I think there's so many different like requirements that each individual customer might have.

Like someone wants you to offer, um, you know, sign in with Okta, uh, 'cause that's what they use for their internal identity provider. Um, maybe somebody else has like some homegrown identity provider. Other people want, you know, different requirements for multifactor authentication.

Um, and so you probably are building out each one of these like over time and then you get to a point where like you're maintaining like an incredibly complex system. You have, um, a team that's, uh, maybe, you know, dozens of people that are, are maintaining authentication. And, um, none of this is, is particularly like differentiated, right?

Like, um, the use cases across different companies for auth are, um, fairly like standardized. Like yeah, you, you're not sort of like often reinventing the wheel entirely when it comes to authentication and, and often when you are, that's probably the wrong decision. Um, but you're having to maintain all of these different sort of like, um, off methods configurations, et cetera.

Um, and I think it's like not necessarily like the best use of, of your time probably to maintain, uh, a sort of like undifferentiated product like authentication when you're trying to build some other company, right? You're trying to build some other product and this is sort of like, um, a table stakes requirement obviously, but nothing that's going to maybe like, you know, make or break your company. How hard is it to rely on a product per se?

I mean, do I just call some API, what's the level of integration or how do I get it into my workflow in the first place? Yeah, so the way to integrate, uh, is typically just dropping in an SDK, um, usually that's something client side and something on your backend, uh, just to manage, um, sort of like the, the user management aspect on, on the backend. The SDK in the front end typically handles everything, um, around like error handling, edge cases, presenting all of those different, um, authentication methods.

Um, and so I think it's, it's quite easy to, to drop in and, and integrate where complexity can come from is just depending on kind of like the user model that you have as a company and how you map that to the provider that you're using. Um, re requires some, some thought often to make sure that, um, you're not, uh, yeah, sort of like trying to, um, jam your user model into, uh, the vendor's user model. As we kinda walk that through a little bit more, um, our organization's trying to figure out like, as more of the rules and ranks seem to be getting more stringent, do I need to be able to audit those authentications more and kind of prove who access what, when and where?

Because um, I gotta generate some reports somewhere and I'm not gonna be able to do that using some custom thing I hack together. Right? Yeah, I think that's another great example of like, um, complexity you might not be thinking about when you're sort of like building that initial off system, right?

Is that like observability and monitoring? Uh, I think that's, that's really critical. You wanna be able to have that, uh, and sort of audit log of, uh, user access, who's logging in where, where those logins are coming from.

Um, I think identifying anomalous behavior is, is super critical too. Like, um, are you seeing, you know, a, a bot attack where someone's trying to do credential stuffing, account takeovers, et cetera? So, um, I think some of it is, is looking at that kind of like historical record of, of audit logs, but also important to have that like real time, uh, detection and prevention of, of threats as they're arising.

We have at least ambitions of maybe deploying more software than ever in the age of ai, and I can't help but wonder if all that's gonna overwhelm our authentication systems. Yeah, I think it's a really interesting question because one of the things that, um, I think will evolve with AI is the, um, the amount of sort of like non-human, um, users that we have on the internet, right? Both in terms of like malicious bot attacks.

AI makes it much easier to, um, to like run a, a high volume bot attack to script and, and screen scrape websites, et cetera. Um, but also in, in like sanctioned use cases, right? Where I might have like an AI agent that, um, is going off and, and acting on my behalf and needs access to the like services and accounts that, um, I am using, right?

And you wanna do that in a way that, um, is, uh, sort of, you know, locked down and doesn't give that AI agent, uh, too many permissions and, and can cause too much chaos, right? But it needs to have enough permissions that it can be useful and helpful. Um, so I definitely think that, uh, there's gonna need to be an evolution and how people think about, um, authentication in many cases because you'll need to allow, um, both these sort of like good bots and humans to log in and, um, have the right permissioning, et cetera.

Who's in charge of authentication these days? 'cause I always felt there was, it's sad somewhere in between the software development teams and the security people and the compliance people. And uh, as always, when, you know, everybody's in charge, nobody's in charge sometimes.

So how do we kinda, you know, who's in the lead here? Yeah, it's a good question. What we typically see is that it tends to be driven by engineering orgs, but security is like a pretty, um, key stakeholder.

Uh, they typically, security typically has like, you know, requirements, right? For things like, um, security standards, visibility monitoring, et cetera. Uh, the engineering teams are then having to sort of like work within, um, those requirements and then also work within like the product requirements.

And, um, even within engineering teams, you can sometimes see this like span, you know, something that might be more of like a trust and safety engineering team, but also maybe like a growth engineering team that cares about like user conversion and, and signups and whatnot, right? So I do think that is like one of, one of the challenges of auth is that, um, it's so critical to your product. It it touches a lot of things and so that means that there's a lot of different stakeholders that, um, might be involved.

But, uh, yeah, typically seeing this being sort of like a, a software engineering driven, uh, initiative and, and ownership, Are there best practices or things that organizations do well around authentication that you're seeing that you wish other people would copy? Yeah, that, that's a really good question. Um, I think, uh, the move to more sort of like single sign on integration, so sign in with Google, et cetera, um, I think that's really exciting.

Uh, just because like requiring users to manage hundreds of passwords is just like asking for something to go wrong. Like, uh, it's, it's really hard to keep track of all of that. And as we just continue to get more and more accounts, I think figuring out how to consolidate, um, login so that you don't have to have that unique account, uh, for every single site you're logging into.

Um, I think passkey is another really exciting development. Uh, I think there's still, um, sort of more proliferation that needs to happen there in terms of like devices that are passkey enabled for that to like really take off. But, um, seeing some like initial, uh, really good sort of like data on that, uh, and I think pasky is, is great because it's, it's highly secure.

It requires you to have, um, you know, uh, a hardware key or, or biometrics, uh, but super low friction for users. And I think moving towards this like sort of like lower friction for users, uh, and requiring each user to spend less time thinking about their account security is, is really great for everyone. And, um, yeah, excited to, to see sort of, I guess this is a trend towards passwordless that's, um, really starting to, uh, continue to, to grow, but I think we still have like a long ways to go, um, in terms of, of fully moving to that world.

Yeah, I mean, to your point, I think we've been using passwords since the first gay man grunted who goes there, but, um, how do we kind of make that migration? 'cause what I've seen so far, to your point, it seems a little uneven, is that need to be just driven by the software development team, or are we waiting for some larger end user awareness to take hold before we go more whole hog? Yeah, I think it's very much the latter.

Um, we, so we offer passwords as, as part of our platform and the data we're seeing is that when you give people the option of, um, passwords, uh, an email based login, like email magic links or Google, um, uh, typically the majority are choosing to go with those passwordless methods. It's, it's in the, the low single digits often that are choosing passwords. Um, but it's, it's not 1%, it's, it's closer to 10% often.

Uh, so that's still a good like, chunk of your user base that when given the option, like still prefers to use a password. Um, so I think there's a lot of just sort of like, um, user, um, education that needs to happen. I think we spent the past like 20 years like trying to drill password security into everyone.

And so, um, now people are like, oh, is like email based authentication secure, right? They don't sort of like understand necessarily, um, the like different trade-offs with, with those different options. So I think it will be a gradual shift over time and just like exposing people to those options, giving them, um, the choice too I think is, is how we're gonna, um, continue to progress towards that.

Right. Although there's still more legacy applications using passwords than there are new ones that are not, but that may take time to replace all those. Right, Exactly.

You know, we hear a lot about secrets management and I believe this area is kinda, you know, ortho mentally related, but, um, how do I kind of manage all these passwords that people are creating or passwordless keys or whatever it is, um, you know, is authentication and secrets management joined at the hip? Are they gonna converge or how does that all come together? Yeah, I think, um, you, you need to have sort of like a good process for secrets management if you're going to especially be storing like passwords, um, within your application.

Uh, and so I think that's a, a reason that people will sometimes choose a vendor, right? Is that trying to, uh, make sure that you're managing, um, your secrets that you're salting and hashing passwords and, uh, you know, making sure that you're walking down access, uh, to those databases, et cetera. There's, there's just a bunch that you need to be thinking about.

Um, if you're gonna be storing something like passwords, uh, and offloading that burden, that stress too, uh, can be really valuable. Um, so I think, uh, in all of these cases, like definitely not trying to like reinvent the wheel and, and build your own sort of like, um, custom protocols or, or cryptography et cetera, is, is super important. There's, um, great standards out there, open source libraries, um, a lot of the, the cloud vendors have a great secret management, uh, tooling as well.

And so I think the, the theme when it comes to, to anything I think around kind of like authentication and security is just like, don't try and reinvent the wheel and like invent your own standards necessarily. There, there's great open standards, um, and they have, you know, been battle tested over many years and um, typically are, are gonna be the better choice. We've also seen in recent times anyway, more progress around the whole DevSecOps workflow and the adoption of those best practices.

Is that pulling authentication along? Is that kind becoming part of that conversation? I think to some degree I think they're, they're definitely related, but, but probably not super like intertwined.

Um, I think general sort of like visibility and, and I think just like focus on um, sort of best practices when it comes to that like software development life cycle, um, is, is probably influencing too how people think about like maybe the build versus buy decision, right? Where I think people are like, um, sort of interrogating in, in more depth like the decisions that they are making where they can like, um, offload some of the, those security concerns to a vendor instead of having to like own that themselves. I think, um, being sort of intentional about, um, those bill versus buy can, can help you to offload some and so I think this trend of like, um, just generally, uh, more sort of like emphasis on um, security and also, um, leveraging vendors is is part of the conversation.

Alright folks, you heard it here. You know, just 'cause you can do something on your own doesn't mean you should, right? That's a standard kind of thing over time and there's probably a lot better things you could be doing with your time than trying to figure out how to make authentication work.

Hey Juliana, thanks for being on the show. Thank you for having me. All right, back to you guys in the studio.