EPISODE 1744

[INTRODUCTION]

[0:00:00] ANNOUNCER: Authentication is a key requirement for any B2B software application, especially if software vendors are selling to enterprise clients who are likely to have strict authentication requirements for the vendors they use. However, building authentication for a B2B application is typically complex and resource-intensive due to the data models required, the provisioning, and managing accounts, and additional security, and scale concerns.

Julianna Lamb is the co-founder and CTO of Stytch, which is building an all-in-one platform for identity and access management. She joins the podcast with Gregor Vand to talk about the platform. Gregor Vand is a security-focused technologist and is the founder and CTO of Mailpass. Previously, Gregor was a CTO across cybersecurity, cyber -insurance, and general software engineering companies. He has been based in Asia Pacific for almost a decade and can be found via his profile at vand.hk.

[EPISODE]

[0:01:08] GV: Hi, Julianna. Welcome to Software Engineering Daily.

[0:01:10] JL: Hi, thanks so much for having me on. 

[0:01:12] GV: Yes. So, you are one of the co-founders of Stytch. We're going to get into Stytch in a moment. But I think, it would be kind of interesting just to hear what did you do before Stytch. I think, one aspect of this is that you and your co-founder, Reed were working together somewhere else. I think it was Plaid or Plaid. I never know how to say that. I'm Scottish, so I would say Plaid, or would I? I don't know. So yes, tell us about your history.

[0:01:41] JL: Yes. My background is in engineering. I started my career working at Strava. I was on their growth engineering team. I am a huge runner, do triathlons. So, Strava was kind of a dream job coming out of school and getting to work on something that still use every day. Then, I ended up joining Plaid in 2017. Reed, my co-founder joined shortly after I did. I was on their backend engineering team and spend the bulk of my time working on problems related to fraud and authentication.

So, built out a fraud engine that was helping protect against things like credential stuffing, account takeover attacks. Plaid has one API to connect to 10,000 different banks, made it a little too easy for attackers to see if stolen credentials might land any of those 10,000 different banks that we integrated with. So, we saw a lot of this sort of like pass-through fraud to the banks and built a bunch of things to help identify, block, and protect against these attacks.

When we're working on this, we found that a good number of those banks didn't have any two-factor authentication. This is back in 2018, and so, my stats are old, and I hope they're much better now. I'm guessing they are. But at the time, two-factor was still something that wasn't like 100% adoption across the board. So, those banks would tend to get sort of more of these attacks targeted at them, just because you can do a lot of damage if a user has reused the same password from some random website that got breached with their bank account, you can get full access. 

One of the things we ended up building out was our own two factor to help layer on top of that bank username password flow, help protect those accounts where we could. When we were going to build this out, we were kind of expecting to find a super easy to integrate API for authentication, drop it into our product, get this all built out super quickly, and get back to doing the million other things we had on our roadmap. But we didn't end up finding that, and so we spent a bunch of time building this all out in-house.

I then went to another company called VGS as one of their first product hires. One of the things I worked on while I was there was ripping out Auth0 and replacing it with an in-house auth solution. Some of the frustration that we were running into there with Auth0 around sort of flexibility, ease of integration. We were trying to build experiences that was basically going to take like more time to try and build workarounds with Auth0 than just rebuild our Auth and sort of be able to have that control.

Those were some of the frustrations that we'd had when we were evaluating vendors at Plaid. So, it's like, okay, there's like a common thread here where there's experiences that we want to be building and we're looking for a vendor, but we're just like not finding the right vendor that is flexible enough. Let us sort of have building blocks to build these experiences, but still does the heavy lifting when it comes to building out authentication. So, that's weird. Like, why is there not something better? There's going to be something out there. 

I was catching up with Reed after I'd left Plaid. Basically, we would get coffee like once a month after I'd left just to talk about random things. One of the times we got coffee, I was complaining about this auth migration and how frustrating it was. He was complaining about how it was really hard to get more sort of auth features on the road map at Plaid, because each one had to be built out, custom in-house. If we'd had a vendor, we could have just couple lines of code, extend those auth experiences. So, we were basically just like frustrated and confused why there wasn't something better.

Ended up spending kind of the next six months just here and there talking to people and trying to understand like if we were missing something, if there was a really awesome vendor out there, and just kept hearing frustration over and over again. So, that all sort of culminated in us starting the company in June of 2020, so a little over four years ago now, basically to tackle this problem, build tooling that our previous selves would have appreciated. I like to say, I built auth twice and decided that I would build it for a third and final time, so other people didn't have to suffer through what I did.

[0:05:46] GV: Yes, okay. That makes a ton of sense. I'm curious. So, it sounds like you put a lot of thought into like why you were going to start this company. On your side, I guess you kind of validated that on the basis of, well, I've had to build this thing twice, it sounded like, before you like dive into the product itself. How did you, I guess, go about going from zero to kind of, did you run pilots or how did you kind of get that into the hands of customers, I guess?

[0:06:12] JL: Yes. In the early days, we were really focused on kind of figuring out what the frustration and pain points were with existing solutions. I think we had this idea that sort of API first was a big differentiator, that some of the frustration limitations with existing solutions like Auth0 were the heavy-handed approach that they took, and that the more sort of building block approach would be powerful. So, that was one piece that we were trying to validate. Then, understanding kind of like how deep are these frustrations, would this be something that people would be willing to migrate to a new solution. I think that's something that, yes, it's important to kind of suss out of like, are you just like mildly unhappy or is this something that maybe is even like rising up to exact level, kind of problems that you're facing.

So, we're really trying to kind of understand like, what is the pain point, what are the frustrations, is the way that we're thinking about building this aligned in a way that would help solve those problems for people, and would it be something that they'd be excited about. I think that was kind of as far as we went in terms of getting commitments from people. We didn't try and kind of have LOIs or anything like that before we started the company. I think our idea was that, okay, Auth0 is a massive company, has gone after this. They've succeeded, but we see an opportunity to kind of build a next gen more modern solution. So, we don't think that there's like a ton of market risk.

What we think is risky is like, are we going to build the best product here that people are going to be excited about? So, really tried to hone in on kind of what is that vision of our differentiators, what we're building. Then, we knew that it was going to be like a big-time commitment because auth is like a pretty broad space. There's a lot of different things you have to build to have sort of a platform that can fit different people's needs. We were intentional about kind of how we ordered building products in order to try and capture as much as we could with the smallest number of products, and then layer on from there.

But we kind of did our initial diligence, figured out, okay, do we believe that we have a unique perspective here, that there's opportunity to build something. Then, let's like build it, and build it to a state where we think we have like a good kind of first version of this product, and then continue to kind of like iterate from there. We kind of went heads down and spent nine months or so really focused on just building the platform after we kind of made the leap and decided that this was actually something worth exploring. Then, from there, did kind of our initial launch, and then continue to build products, and do more marketing, and all of that from there.

[0:08:51] GV: Awesome. Yes, I think you kind of alluded to the Perkins law. It was a market problem or technology problem Yes, personally, I love working on technology problems. I still think there's always areas where actually if it was just a better mechanism or a way of doing something, then it will find the market. I know tons people will probably disagree with me, but I think that's the interesting way to look at things as an engineer. Yes. So, I've got more questions there, but I'd love to just - let's dive more into the product for now. There's still probably quite a few listeners at the moment kind of say, "Well, I use X, I use Y." Throw some names out, Auth0, maybe Firebase for quite a few, maybe at the start of their projects, for example. To those, how do you - you've touched on Auth0 already, but I'm sure that's maybe the one that most people are familiar with. How do you say that you sort of compete there in terms of features, and flexibility, and DevEx, obviously, is a big one.

[0:09:45] JL: Yes. So, I think there's kind of two categories of where we differentiate. I'll start with the first, which is more kind of around core auth product and what that looks like. The second is more around fraud detection and prevention. So, I'll get into that in a minute. But on the first sort of category, I think we're really focused on building kind of precision tooling for authentication. So, having the right balance of like flexibility and customization, but also making it simple to get started, and giving you the right building blocks so that you're able to build the experience that makes sense for your users, your use case. But we save you a lot of time and effort compared to building that in-house.

One of the things I like to say to kind of describe how we think about building our product is like, if you could hire the best authentication team in-house and work with them, they write great documentation, they build clean APIs. That's what working with Stytch feels like. So, it feels like something that you're able to use in a way that feels native to your product gives you customization and flexibility, but you're not the one that has to go and like figure out what all of that looks like. We think about that from how we sort of architect our APIs and data models

One thing that's quite different compared to any of our competitors is that we have separate B2B and B2C products. The big difference there is around the data model. So, in B2C, your user is kind of the primary object that you're dealing with. You own your account as an end user. You can have like your own settings, things like that. In B2B, it's the customer, the organization that is sort of the primary entity. They own the account, and then there's members within that organization that have access. But the organization might want to have specific auth settings or they might want to have different roles and permissions for the different members. We find that having those sort of really intentional data models just gives you a lot more power out of the box. It's just one example of how we like think through kind of the edge cases and like foundation that you want to be building your authentication on top of.

We try and be kind of intentional about where we're making decisions to help you not have to deal with a million different auth requirements, or edge cases, or account takeover vulnerabilities, whatever it might be, but still give you then customization of like, what does this look like? What does this feel like? Can I embed this on my homepage? Or, is this a full-page redirect? What does that feel like?

The other category of fraud detection prevention is something that we've built out kind of over the past year and a half, two years or so. We've basically built out sort of independent fraud detection prevention suite that you can either get that standalone or you can get it combined with authentication, which I think is really powerful. Especially, I think in the world we're in today with all of the generative AI stuff, there's just so much more fraud and abuse happening on the internet.

I think when you're thinking about building authentication, yes, it's important that you have good sort of authentication methods. You're enforcing good complex password requirements, you have two-factor, you have all of those things. But you also want to make sure, is this a bot that's like scraping your website, and trying to do a credential stuffing attack, or maybe it's a bot that's trying to create a bunch of burner sort of free accounts and take advantage of your free tier or whatever it might be. There's so much more that goes into kind of figuring out who is this person or entity that's trying to log in. Should I let them log in? Should I let them create an account? 

If you're using an existing solution, you typically have to go to another vendor for this fraud detection and prevention stuff, and sort of like piece that all together, figure out how am I going to make these decisions? When do I decide if someone can log in or not? We're able to offer that out of the box, so that you just don't have to think about it. I think there's kind of this common theme of, we take care of the things that you just don't really want to spend the time to become an expert in, but then give you the flexibility to make that look and feel like your application in the ways that you want it to.

[0:13:52] GV: Yes. If I understand correctly, when you talk about the B2C product, does that mean, if two completely different platforms are using Stytch, that the user actually has some kind of agency over settings that applies to both platforms? Or, how does that work?

[0:14:09] JL: No, that would be independent. So, it would basically be like, each customer would have sort of their distinct user pool. But then, within that, you as the user own your account. Whereas, in B2B, it's the organization that sort of owns the parent account. Then, you, as a user of that B2B SaaS tool or like a sub entity of that organization. So, no sort of cross customer interactions there, but just sort of distinct in terms of what that entity looks like that you're primarily concerned with in each of those cases.

[0:14:41] GV: Got it. I mean, slightly maybe jumping ahead to kind of how people use this, but I feel there might be quite a few questions popping up on listeners' heads right now. In terms of security generally, as well as login, like login especially, people, I think today are getting very frustrated with the steps that are being put in front of them, myself included. I can imagine Stytch is dealing with this pretty well, so I just love to hear, how are you able to maintain the highest level of security whilst also making the user experience. If the user experience for the end user is great, well, that's fantastic for the platform. The platform doesn't want to have to put more hoops and hurdles in front of the user, but they end up often doing it because they're like, "Well, we've got no option." So, yes, how does Stytch deal with that?

[0:15:31] JL: Yes, it's a really good question. It's one of the reasons that I think we're really excited about passwordless authentication. I think passwords tend to be just a really common attack vector. People reuse passwords. There's good adoption of password managers, but it's really not as widespread as I think us in tech sometimes think it is, because you probably use a password manager, your friends probably use password managers. I've been trying to get my mom to use a password manager for 10 years, and I have not succeeded. People still just reuse passwords across so many different accounts and that leads to so many of these vulnerabilities.

Some of the Snowflake stuff from not too long ago, people had reused passwords, and that enabled people to get into some of their Snowflake instances. So, it's just a huge vulnerability. Removing passwords, I think creates a lot more simplicity for the user as well. You don't have to deal with managing all of those different passwords. You have to think about maybe a few accounts now that you need to be really intentional with. Your email is already super important, because in many cases, it can reset a password today. So, it's already a single point of failure. But I think as we're moving more towards passwordless, making sure that that is locked down is super important.

I think there's stuff like passkeys too, that is still pretty nascent in adoption, and I think it'll take time for that to be really widespread just because of the hardware component to it. You have to have a device that has passkey's capabilities on it. So, I think that's going to be really exciting though because it's low friction, you tap your touch ID, you do your face ID, whatever it might be. So easy for you as a user, and really great from a security perspective as well, because it's now sort of tied to that device. So, someone has to compromise your device in order to take over your account.

I think we're going to see a move towards more things like passkeys and away from things like one-time passcodes because of the rise of phishing. I think you see so many people getting compromised by giving up a one-time passcode, because they get called and it's like, "Oh, this is your bank's customer support, you need to give us your one-time passcode to verify your identity, and then we'll help you unlock your account," or whatever it might be. It's just too easy to run super sophisticated phishing attacks now. So, I think that's something that's it's going to continue to sort of go by the wayside in favor of these more un-phishable methods like passkeys.

I think the hard thing about all of this though is that, there is not quite a one-size-fits-all solution the same way that passwords are one-size-fits-all solution. No matter who you are, what device you have, you can create a password. That's not the case when it comes to things like OAuth, or passkeys, or whatever it might be. Now, you need to have something specific to be able to engage with this. So, offering some options for users is going to be increasingly important, so that no matter who they are, they can create an account, they can do so in a secure way. So, I think we're just going to continue to see the auth landscape get even more complex than it is today. And making sure that you're being intentional about the options that you're giving to users, not giving them footguns so that they can run into trouble by reusing those passwords. But then, also, give them options that will work for whoever they are. 

[0:18:56] GV: Yes. On the passwordless point, passkeys we could talk about for our listeners to know, I really like them. But admittedly, I have run quite a few episodes on passkey specifically. So, we're going to dive too far that way today, but on the basis of Stytch, obviously, being able to support them makes so much sense. As you say, it's how the hardware and the other site deal with it, that obviously needs more of that standardization and password managers themselves are all now getting into that space, where they're being the device. I had an interesting case today. I won't say which names, but I had one installed, and then had another installed, and then one was canceling out the other, and stopping my whole passkey flow from working at all. So yes, there's a little way to go on that one.

I think Magic Links is an interesting one on the product I'm working on at the moment. I've dived a bit more into Magic Links and actually more on the receiving side. I think Stytch mentions that it has what's called protected Magic Links. I'd love to just sort of hear more about that and what have been some of the - because I think maybe some people think, well, Magic Links are Magic Link. It's just a link to log in, right? But there's a bit more to it than that, right?

[0:20:01] JL: Yes. One of the big challenges with Magic Links is email deliverability is really hard and people have different email clients, different email providers. There's so many different edge cases. So, one of the challenges that we see with Magic Links is just getting that into the user's primary inbox sounds way easier than it actually is. Then, once you get it in the inbox, are they able to click that link and do that in a way that works and is secure? So, there's a few things that go into this. One of them is giving people the option depending on kind of what their use case is, what type of product it is, to basically tie the browser to that magic link session, so that you're requesting the magic link from the same device and same browser that you're actually clicking the link from. That can be a really good security protection. One of the other challenges with email deliverability is a lot of email clients will have a software that they run to check for malicious links.

The way that that works often is that they'll click the link and follow it. So, if you're using Magic Links, it's like best practice to invalidate the token after one use. So, what you run into is these email clients clicking the link and invalidating that token. When the user goes to click the token, they're unable to log in. No matter how many links they send themselves, they're never going to be able to click that link because their email client is going to keep invalidating it. 

One of the things that we do on our email Magic Links is basically check to see if it's a bot or a human that's clicking the link. If it's a bot, we don't actually authenticate it, and invalidate that token. It has to be a human that clicks those links. So, there's a few different things that we've done here to both improve security, but then also the usability of Magic Links. There's a lot that we do as well behind the scenes, just on email deliverability, making sure that time to inbox is good, that it's landing in your primary inbox and not in spam. It's like a constantly moving target. Yes, email clients are changing all the time. And so, making sure that we're staying on top of that so that the user can get their link, find it easily, and when they click it, it actually logs them in.

[0:22:17] GV: Yes. I'm curious, what kind of, I guess, adoption are you seeing. I guess, the developer for a given platform using Stytch, they can still choose what they want to offer. So, I guess you probably get a good insight into what are people most likely to offer and what, I guess, something like passkeys and Magic Links. What would you say the adoption from the platform side, given it can sounds like just kind of turn it on. So, why might they not turn it on, I guess? Or, what have you heard so far as to why they're hesitant, for example?

[0:22:47] JL: Yes. I think we hear a lot of people wanting to make sure that we support pass keys, but they don't necessarily turn it on. I think people know that it's coming, but they don't necessarily want to enable it today, until they feel like there's enough user demand. It can vary in the space too. If you're selling to, if you're like a B2B company selling more to developers, for example, you're probably more likely to have past keys then, versus if you're selling to a more mainstream audience. The support for it is just not quite worth the effort today, because users run into so many challenges with it. Figuring some of that out, I think, both in terms of like how the technology works, but also just like educating users more about it. I think people will start to adopt it more. It's commonly asked about those, so I think people are like, they know they want to do it, but they just maybe don't have quite the incentive to do it quite yet.

In terms of the other methods, I think we see pretty solid adoption of Magic Links. That's something that I think has become pretty widespread, and especially if you're more like desktop-focused versus mobile, it can be great. Sometimes on mobile, people are a little worried about it, just because of having to do redirects to mobile app, and making sure that they have mobile app installed, or doing all of that can just add more complexity. And doing something like an SMS one-time passcode for example on mobile with the SMS autofill, it's so nice. So, sometimes people will skew towards that.

I think OAuth, Google by far, just has the most adoption. So, people will sometimes implement a few different options. If they're in B2B, maybe it's Google Microsoft, if it's a B2C company, maybe it's Google Facebook. Google by far we see is the sort of biggest player there. The other interesting stat that we see is that people who offer passwords, if they have another option, whether that be like email Magic Links or the different OAuth providers. Usually, about 90% to 95% of users are choosing to use one of the password list methods and not have a password. So, sometimes, people come to us and be so adamant like, "We must have passwords. Our users want it." Then, they launch with us, and we see the data, and we're like, "Okay, yes. A few of your users want it, but like, you maybe would have been okay without it."

I think depending on the demographics, sometimes people are worried to say, "No, those 5% of users, you have to change your ways." That that might cause them to abandon the platform. So, we still see people offering it, but definitely I think the way that sort of users are voting is towards passwordless.

[0:25:24] GV: Yes, I find that super interesting. I guess the part where platforms are still - I'm sure they've got their reasons, but say no, we need passwords because that's what our users need. Yes, that's very interesting to hear that from the source. So, looking at where Stytch sits, it's a pretty critical piece of a platform. I say pretty critical. It is kind of the most critical piece of a platform if you're going to integrate Stytch. Maybe, could you just walk us through a bit more on the architecture side. Have you approached this? Being where you sit, this has to be like massively scalable, reliable. We haven't even said the word security yet, because obviously, that just has to be security first. How have you approached this from an architecture perspective?

[0:26:08] JL: Yes. I think both security and reliability are just things that are table stakes to be building this product. So, we've been really intentional, I think about trying to build a culture on the engineering team of prioritizing that and emphasizing that. Because you can do everything possible to help protect against a security issue, a bad PR getting shipped to production, whatever it might be. But you're never going to get it 100% right if your engineers aren't thinking about it when they're shipping code. Because it's just too easy to do something that maybe leaves some issue out there or whatever it might be. So, I think building that culture and really reinforcing that on a consistent basis is super important. So, we take anything around security or reliability really seriously.

We'll call a SEV for things that probably aren't quite SEV worthy, but we're like, "Oh, this is potential to turn into something that will degrade performance for people. Like, let's jump on that." So, I think some of this just comes from kind of obsessing over it. We have from the beginning have been really sensitive with our monitoring and alerting, and have continued to refine that, so that we're not getting like paged just unnecessarily 24/7. But we tend to send like a lot of low urgency alerts for things that maybe aren't major issues, but are things that we should kind of have a pulse on, and then have good monitoring, and alerting for production issues as well.

A lot of this I think just comes from kind of like that operational culture and making sure that we're on top of that, but also building good systems is really important as well. So, some of this comes from just testing culture, making sure that that's a priority that we have the right sort of coverage there, making sure that people are also intentional about sort of testing out things that maybe are more risky, or complex, and testing them manually.

We have the ability to like spin up load testing clusters, for example, if someone is trying to make a change that will potentially have some impact on scale, or maybe it's, "Hey, we've seen some issues with this query or whatever it might be. Let's spin up that load testing cluster and actually validate this, see if that's true, see when we're going to break, see what's going to happen."

We've also done a lot on how we think about working with other vendors, so things like email, SMS, et cetera. Wherever we have redundancies or wherever we have dependencies, we try and have redundancies. So, making sure that we automatic failover with multiple providers for both SMS and email. So, if we start to see like latency issues, if we see an outage, whatever it might be, we'll automatically fail over to a different provider to make sure that SMS and email and WhatsApps are getting delivered to the user.

We have a similar approach to kind of how we think about just overall kind of like resiliency. We have the ability to fail over multi-region if we see an issue. This is something that we're continuing to invest in, building out more tooling, and fail over measures to make sure that we're able to deliver on that. But I think a lot of it just comes from obsessing over it. It's something that's really important to us, and I think it's something that we're really proud of. I think we're able to deliver a really great experience for our customers. That's something that we try and celebrate as well, so that it's not just like, "Oh, no. We did something wrong." But let's celebrate when we're doing well, or we're shipping things that can help us have confidence in kind of what we're doing there.

[0:29:51] GV: Nice. I mean, sticking with architecture, but flipping over to the developer side, how prescriptive is integrating Stytch from the platform architecture side? What are all the ways and means it can be done and how difficult is it to drop it into not a Greenfield project, but maybe take the harder one, like an existing project?

[0:30:14] JL: Yes. We try and kind of have different levels of flexibility, so that if you're building Greenfield and you don't want to spend any time thinking about your authentication, you want to drop it in, get it up and running as quickly as possible. We have out of the box front end components with our SDKs and good backend SDKs as well to support that. You can toggle on different auth methods. Whenever you want, it's very easy, very straightforward. There's a little bit less flexibility there, but still quite a bit of like customization that you can do in terms of the look and feel of it and all of that.

For people who maybe want a little bit more sort of ownership over the UX, but still don't want to have to deal with things like session management, and all of that, we have headless SDKs as well that are client side. So, JavaScript will sit in your browser, it'll do things like refresh the session, make sure that that's all managed for you. But then you get to fully own that UX, you call our headless SDK methods when it makes sense. It gives you a lot more customization, but still abstracts a lot away for you. Then, we also have backend SDKs that you can integrate directly with for everything. So, if you want to do a fully backend integration, you can. 

We tend to see folks that are doing more sort of like complex migrations from like in-house builds tend to go with that. If you're coming from an existing provider or something like that, then typically not too hard to migrate to any of these options, and just depending on kind of like where people's preferences for how much customization they have. Sometimes, people will spend the extra time doing a migration to the front-end components, for example, because the value they get from that is worth it. But if you have some very complex architecture today that you want to kind of like plug us into, using those and endpoints directly is a great way to do that.

We tend to be, I think, pretty flexible generally, but opinionated in some ways. So, there are some things that we think are just not worth giving people options around, because of the risk when it comes to security. So, there's some things like, for example, we deduplicate across OAuth providers and email Magic Links or email password in a way that either will do a verification if the OAuth provider hasn't verified the email or if they are verifying the email, we can do that deduplication. 

So, trusting that your email is verified is something that's really important. So, if people are trying to migrate to us with unverified emails, for example, we'll work with them to figure out how they can do that in a way that make sense, but doesn't leave their users open to account takeover vectors if the users haven't verified those emails. So, there's some things like that we kind of hold our ground on, but tend to be pretty flexible in terms of how you're actually integrating this into your systems. It kind of just depends on the world you're coming from and what you're trying to get out of stage, where people land on the spectrum there. 

[0:33:18] GV: Then, maybe taking it sort of one stage further. You mentioned it towards the beginning about the B2B product. Part of that, I understand is actually being able to integrate SCIM or SCIM. I think this might be very familiar for some people, but completely unfamiliar for others. So, could you even just give a quick explanation of SCIM, and then how is that B2B product, Stytch, making this easier, making this possible. Love to hear about that. Yes, definitely. So, SCIM is basically a way to provision access and permissions. So, big companies will use it. In particular, they'll have all of their users or all of their employees will be sort in some IDP. Often, that's like Okta or something like that.

Let's figure like workforce identity provider, people will belong to, maybe different groups, like your engineering, your product, sales, et cetera. People have different levels of permissions within that. All of that is like stored in their IDP, and SCIM is basically how you communicate that to a third-party application. So, you're using some SaaS tool at your company and you need to be able to figure out how all of the employees at your company get access to that SaaS tool. What do they have access to? Do they have admin permissions? Do they just have normal permissions? Whatever that might be.

What our SCIM product does is, it makes it really easy for a SaaS company to build that into their product, so that their customers can use SCIM then to get all of their users on boarded to that SaaS tool and do so with the right permissions. We have an RBAC product that integrates with that as well. So, if you're using sort of Stytch end-to-end, you're using us for SCIM, SSO and RBAC, this will all just sort of happen for you. The permissions that a user has will be then tied to your roles, and permissions, and your application. So, you just don't have to worry about any of this. You can serve those enterprise customers really easily, make them happy, because they don't have to deal with provisioning access to their users. Also, it can be really good for SaaS companies too, because that typically makes it easier to onboard more users from that company to your tool. So, it's kind of like a win-win across the board.

[0:35:39] GV: Yes, super nice. I mean, I guess sort of related to that, how developers are going to be coming at this. You've got so many kind of ways it could be integrated or facets, SCIM being one, which is quite different. One developer implementing SCIM with Stytch is going to be having quite a different experience, perhaps to one with say, the headless front-end side. How are you able to kind of keep up with developer feedback, and how do you prioritize across the product, I guess?

[0:36:12] JL: Yes, definitely. It's a really good question and I think it's like a constant challenge. I think if you're growing as a company, you're always going to have so many more feature requests than you can possibly manage. So, figuring out how to wade through those is always a challenge. I think there's a few things that we do here. One is that, I think we have really great developer success and solutions engineering teams that are working with our customers, and prospects, and helping them figure out what are they trying to build.

I think, sometimes there's pros and cons to just how many options we have, and how much flexibility there is, and how you integrate. If you're trying to do something more complex, we can probably help you and do that easily, but it's not always super obvious, what that's going to look like because we can't have documentation for every single complex use case that you could possibly dream of. So, having kind of good frontlines, engineers figuring out, how are we going to solve for these customer issues? Is there something that they're trying to do that they just don't quite know how do you Stytch to do it? Or, is this something that we actually just like don't support today? Funneling that back to our product team is really critical.

So, I think we have good just sort of channels of communication there and people are digging in with customers and trying to figure out, is there a way to do this or is this a feature request? Then, bubbling that up, we use Linear for all of our issue tracking and whatnot. We have a board there that's basically just feature requests. So, anyone can file those feature requests often is like developer success resolutions engineering that's doing it. But maybe it's an engineer that's running into some issue when they're trying to test something out, and they're like, "Oh, we should just build this feature." They can throw it in there. Everything then gets piped out to a Slack channel too, so people can kind of have a pulse on what customers are asking for, the feedback they have, what are they trying to do.

I think that can like help just create visibility into kind of where people are running into the most issues, and that helps to like build context on, "Okay, this feature that we don't have, this is a pain point that's coming up day after day. We should probably build something towards that." Then, we kind of take that into consideration when we're building our roadmap. We also try and just sort of be intentional about where we think Stytch is going, where we think authentication is going, and be building towards that feature. 

So, we kind of have to kind of match the two of those around, okay, what are the things that customers are asking for today that we think we might want to build? How does that help us advance towards our goals? Are there things that we think that we maybe want to be building a little bit ahead of where the customer demand is? Because we believe this is going to be something that is going to be really valuable in the future. Passkey is an example of that. I think we built that before. We had overwhelming customer demands, we're like, this is the future of authentication. We need to support this, and kind of balancing that future-looking vision with the pain points we're trying to solve today.

[0:39:14] GV: That's a great point to bring out this sort of the future versus the past. To my team, I often say, I didn't make up this quote, obviously, it's the, "Skate to where the puck is going, not where it was." For those that don't get that, it's partly ice hockey. I'm not into ice hockey, but I think it's a great quote, and I totally understand where that came from. I think, our kind of line of work, I'm also in the security authentication space. And this is it, you have to keep looking, not just at what's happened and say, "Oh, well. We'll keep building to those specs, because some of the specs are 20 years old. If not, more." So, we have to kind of, yes, do things that people say, "Well, who's going to adopt this?" It's like, "Well, if no one builds it, then there's no adoption whatsoever."

Just on that, you know, you're saying seeing sort of fielding feature requests, and you've got to decide what to build, what not to build. What are maybe just one or two cases, customer cases where you've - there's just been a really different, like a challenging use case that they've been trying to get Stytch to work for them, and it has worked, or just something outside of typical auth flows? Can you give any sort of examples of that?

[0:40:22] JL: Yes, definitely. I think, there's a few interesting auth examples. There's also some interesting applications of how people are using our fraud detection prevention products, as well for some of their use cases. I think one of the interesting authentication ones I can think of is someone who - I think they sell to like - it's like a veterinary clinic platform type company, and people are having to write vet prescriptions, and they have to authenticate whenever they're going to issue one of those or something like that.

Basically, they're having to do like authentication all the time, because whenever the technician or vet has to has to do that prescription, they have to do some authentication event. So, they used WebAuthn to do that. This was a little bit before passkeys when they integrated. So, that was a really great application of like touch ID, basically, being able to like simplify that auth experience. They didn't have to be constantly typing in a password. I think that was the previous sort of solution that they had and moving to something like a touch ID was a huge UX win for them. I think that was one of the ones that was like, wow, that's not quite how we think about authentication, because this is kind of more like, you're authenticating day after day for a specific use case, versus authenticating into an account.

So, I thought that was an interesting one. Some people use our fraud detection prevention products as well for kind of logged out sessions. What I mean by that is like, something online publication that has a bunch of articles. How do you make sure that you're able to enforce kind of your free tier of access, and then nudge people to create an account? They use that to basically make sure that people aren't able to abuse the free articles, and then tie that back to the logged in users, so that they can make sure that they're getting the content that they want. So, it was fun to see. That was not a thing in our product marketing when we built these products, and see the use cases that, that people come up with that I would have never imagined when we were building them.

[0:42:24] GV: Yes, that's super cool. Yes, the WebAuthn resonates a lot, because again, something I'm working on right now has that concept, where basically the WebAuthn enables so many things. But we kind of see, I guess, is almost like a zero-trust mechanism in that sense. We're able to say, well, you might be into the platform, sure. But if you want to do X, or Y, yes, you keep passkeying effectively, but as you say, it takes two seconds. Yes, that's super - I didn't sort of think about like the veterinary or I imagine like pharmacy to call and use cases like that, that's very interesting.

Kind of like coming up to the end a little bit. From what you can share, what's on the roadmap for Stytch, anything you can sort of share?

[0:43:04] JL: Yes. I think the sort of biggest new area of investment for us is definitely around this fraud detection prevention piece and tying that back to authentication. Building that so that you're getting really powerful tools out of the box, trying to build these really sort of, yes, precise mechanisms to make sure that you're reducing friction for the good users that are just trying to log into their account and making it either really, really challenging for a bad user to get in, or just blocking them entirely. I think with fraud and abuse, it's often a little bit of a game of whack-a-mole. So, trying to eliminate as much of that whack-a-mole as possible, so that your users aren't sort of negatively impacted by maybe fraud and abuse, and you're able to protect your user's accounts, your systems, all of that.

Continuing to lean into, we have a device fingerprinting product today and tying that back to the authentication platform, so that we can provide even more granular controls and mechanisms to do things like step up authentication, things like that. So, I think really excited about how we can more holistically protect our customers and their user accounts by getting these different signals and making sure that we're providing the right protections as the landscape is changing, as threats are evolving. So that you cannot have to worry about any of this, you can build your login, you can make it look and feel like your application, and you can get back to building all the interesting products you want to be building and not be worrying about any of these issues when it comes to identity, or fraud. and abuse.

So, yes. I'm really excited about that. I think it's a really interesting time. I think, generative AI is so cool in so many ways, but also, just makes it so much easier to run super-targeted phishing attacks, to run bot attacks, whatever it might be. It's really lowering the barrier to entry for fraudsters, which is not great. So, trying to protect against that, I think, is going to continue to be a moving target and excited to be building tools to help people get out in front of that.

[0:45:13] GV: Yes. I think that's a great point. With all the advances, gen AI can, in theory, give us at the same time, there's always going to be a sort of other side to that coin. In the fraud space effect, this is where there's has to be a lot of stepping up to think about how to deal with that. So, it always sounds slightly paradoxical in security to say, "That's exciting." It's like, I get to deal with these problems, but that is the line of work. So yes, that is exciting. 

Just a couple of final questions as a semi-new segment I've added to episode. First question is just, what's a day in the life for you as a CTO of Stytch? What does a typical day look like?

[0:45:52] JL: I grew up as an athlete and been an athlete my whole life. So, getting a workout in every morning is really important to me. So, I usually - I get up pretty early, I usually do a 6am workout, or I'll go for a run. I have a dog and live kind of by the Presidio in San Francisco. So, always fun to get to run around here, and just clear my head so that I can start the day right.

I think my day then can fluctuate, just depending on kind of where my focus is in a given week or month. I have been doing a lot of interviewing and hiring recently. So, I've been in pretty back-to-back meetings most of my days. So, it's kind of nine to five of just back-to-back meetings. Then, typically, we'll have dinner in the office most nights, which is fun to get to spend some time with people, clear my brain a little bit, and not be so focused on my day, and get my head clear so that I can then go and maybe do a little bit after that, try and have more deep work. I'm coming out of some of that hiring, so I'm excited to reorganize my calendar a little bit and have more downtime throughout the day. Because I think that's not an endlessly sustainable schedule. Then, yes, usually come home around 7pm, 8pm. Sometimes, I'll log on again. Sometimes I'll just kind of hang out with my dog, my fiancé, and try and relax, and recharge. 

I think something that's been interesting for me starting a company is that I feel like the more my role has been focused on people management and kind of higher-level strategy, like making sure I'm able to get a really good night sleep, and be really sharp and on is really important. So, try not to have too many late nights back-to-back, and be able to be really sharp each day.

[0:47:40] GV: Yes. In a past life, having to do a lot of hiring as a CTO, and I've asked this question to a couple of other guests now, and the hiring comes up a lot. So, I've said on another episode, it's underreported how much time a CTO spends hiring. So, I think that's useful just for listeners sometimes, just to sort of know what a role really entails. Obviously, the exercise piece, yeah,
for sure. I'm a very avid cyclist and I would not function without it. Of course, I use Strava. So, there we go. The final question is just, what advice would you give to yourself when you were starting out in tech? From what you know now, what advice could you give to yourself?

[0:48:15] JL: Yes. I think just being patient, and not being afraid to follow your interests, and just go deep on those. I think it can be so easy to see people, posting like their wins on Twitter or whatever. Like, I'm like not doing enough, I'm not moving fast enough. I got to be chasing the newest thing. I think, I sometimes felt like that, like a little restless, like I need to be doing more, I need to be further along in whatever it is I'm doing in my career, starting a company. I think, sometimes, you have to be patient and just kind of grind out whatever it is that you're doing, and spending that time, and really developing expertise in the areas that you're excited about I think has compounding benefits.

So, I think it's kind of trying to shut out some of the noise, and be intentional about where you're spending your time, and what you're trying to do, and not try and compare yourself too much. Because I think it's, yes, it's so easy to feel you're not doing enough, or you're behind, and that can just be distracting, and still focus from the things that you're trying to do.

[0:49:17] GV: Couldn't agree more, so I'm not going to even add anything there. I think that's a great place to leave things. Where can people, if they want to get started with Stytch, where's the best place developers or a business listener as well, like thinking this all sounds fantastic, where's the best place for them to get started?

[0:49:34] JL: Yes. So, we're stytch.com, s -t -y -t -c -h .com. That'll have a ton of information there. If you're a developer and want to try this out, also really suggest joining our Slack community. You can find links on our website and docs. Developer Success Team is super helpful there. You can find me on - I still call it Twitter, X, whatever. I'm Julianna E. Lamb there, and feel free to reach out. Always happy to chat with people and help them get integrated.

[0:50:01] GV: Awesome. Well, thank you so much for making the time, for coming on. I hope we get to catch up again some of our time in the future and hear how Stytch is getting on.

[0:50:11] JL: Awesome. Thanks so much for having me on. It was a great discussion.

[END]