Ben:
Hello, and welcome to PodRocket. Today I'm here with Julianna Lamb who's the co-founder and CTO at Stytch. How are you Julianna?

Julianna Lamb:
I'm good. Thanks for having me on.

Ben:
Yeah. Well, super excited to have you joining us, been hearing a lot about Stytch in the general ecosystem. So, excited to hear from you what you are all about. So, maybe you could start by giving us a quick introduction on the company.

Julianna Lamb:
Definitely. So my co-founder Reed and I met working at Plaid a few years ago, and we both basically worked on projects related to authentication, and saw firsthand the downsides of passwords. Both from a security perspective with things like credential stuffing, account takeover attacks, but then also from a user conversion standpoint, and just how many people drop off at password entry, password reset, et cetera. And so a lot of that work sparked some of the ideas for what we're working on here at Stytch, which is basically building a developer platform for passwordless authentication. Making it really easy for people to integrate the myriad of different ways that you can do passwordless authentication, and navigate that transition as more and more companies start to go passwordless.

Ben:
So, I guess the question in my mind is nowadays it seems like most sites have a social login, or if it's B2B they probably have some sort of SSO auth option. If it's B2C, social logins. So what are the advantages of the passwordless platform like Stytch versus the norm of the social, or SSO logins?

Julianna Lamb:
Yeah, it's a great question. And we support logins like Google, Microsoft, Facebook, Apple, all of those. And basically a lot of the value comes from getting those out of the box, as well as the other options you might want to offer. We see a lot of people doing something like email magic links side by side with a Google and Microsoft if you're more B2B, or maybe it's Google, Apple, Facebook if you're more consumer with that magic link experience. Another piece is if you want to do multifactor authentication, and have some concept of step-up auth. Like an SMS one time passcode, WebAuthn, et cetera. And so I think we see those as really compelling options, but one out of a set of different authentication factors that a company might want to offer. And with us, you get all of those out of the box.

Ben:
And for those that aren't familiar, what's a magic link?

Julianna Lamb:
Yeah. So a magic link is basically a one time use token that is appended to a link that you get via email, or text message. And you click that link, and the one time use token is what enables you to authenticate and be magically logged into your account.

Ben:
Got it. So I'm on a website and I need to log in. I type in my email address, it sends me a link. That link has a long obscure URL, but there's a button there. I click it. It navigates me to that obscure URL, which instantly logs me into the site, and it's a one time use thing. So that way I never need to type in my password. And I guess, correct me if I'm wrong, but that model assumes that the user trusts their email. And you can trust the user's email as basically a way to prove that they are logged in, and prove who that they are who they say they are.

Julianna Lamb:
Yeah, that's exactly right. And if you think of probably nine out of 10 password reset experiences you have, they are essentially an email magic link experience, but with a bunch of extra steps tacked on top. That involve creating that new password, logging in again, et cetera. And so, if you're already relying on the security of the inbox to reset a password, it provides just a much better user experience to do that magic link out of the gate. And then it also closes the vulnerability of account takeover because there is no password concept. And so, you then aren't reliant on the weakest link with where a user has reused that password that they're using with your site.

Ben:
Got it. Yeah. That makes sense. And I'm curious, you mentioned earlier that aside from account takeovers, credential stuffing is another concerns with passwords. What is credential stuffing? I'm curious.

Julianna Lamb:
Yeah. So whenever there's a hack out there, passwords are compromised. Basically, attackers will take those stolen passwords and stuff them through a login form somewhere to see if they can match an account that is using that same password. And so, they'll basically do credential stuffing to then figure out where they can do the account takeover attack.

Ben:
Got it. So basically they have some compromised list of usernames and passwords, and they try a bunch of them in a site to figure out which ones are legit, and then use that to take over your account.

Julianna Lamb:
Exactly.

Ben:
I'm curious, you mentioned SMS passcodes as one of the options that Stytch supports. I've been hearing more and more about how SMS two-factor auth is not really secure. Some of the reasons I've heard, of SIM swapping, or the fact that it can still be fished. So I'm curious, what do you see as the future of SMS for use and passcodes? Is it more of a temporary thing, or is there a long term, and maybe a way to make it more secure?

Julianna Lamb:
Yeah, definitely. So I think it comes down to the value of the account that you're protecting. SIM swap attacks are pretty expensive to execute, and so you see a lot of them happening in the crypto world where the account that you're taking over is super valuable, and you can do a lot of damage really quickly there. And so, for a lot of use cases SMS passcodes are still reasonable just because it won't make sense from a financial perspective for someone to go through the effort of doing a SIM swap attack. There's a lot of social engineering that you need to go through, you need to convince a customer support agent basically to let you take someone else's phone number. You can also call your phone provider, and require that somebody go in person, and show ID to be able to move the phone number from one phone to another. So that somebody can't do that on the phone with support, which is typically how these attacks are happening.

Julianna Lamb:
So for accounts that there is a lot of value there, and SMS isn't going to be the right way to protect it, what you can do is something like an authenticator app. So Google authenticator, et cetera, or something like WebAuthn. Which basically enables YubiKeys, as well as touch ID on desktop, face ID on mobile, et cetera. And so we see those as being really powerful options, and sometimes depending on the sophistication of your users and the type of account you have, sometimes people will offer all three of those and leave it up to the user to figure out, "Okay, what makes sense for me? How I'm using this account," et cetera. But there definitely are some considerations to keep in mind there when you're thinking about what two-factor to implement.

Ben:
So let's explore a bit more what it looks like to actually use Stytch. So imagine I'm building a new web or mobile... Some sort of new application, what's the process for integrating Stytch? How does it work?

Julianna Lamb:
Yeah, definitely. So we have two main integration options. One is a client side SDK. So, install a couple lines of JavaScript, and get that out of the box. We also have a direct API integration with client library support, et cetera. And we see both of those as really valuable, and sometimes having slightly different profiles of people that want to use them. People really like the backend API integration as an option if they're trying to own more of their UX, and brand experience, or maybe they're trying to do something like step-up authentication from within a logged in session.

Julianna Lamb:
So somewhere within your application, user goes to take a more sensitive action, you want to do a step-up at that point in time. That backend API integration just gives you maximum flexibility in terms of how you integrate this into your workflows. And then, the SDK option can be really powerful if you don't want to be spending any time thinking about auth, you want to be focusing on building your core product. Just drop something in and get a really great experience out of the box, and you can still customize that in a lot of ways so that it does look and feel like your application, embedded within your homepage. All of that is possible with the client side SDK as well.

Ben:
Got it. So do those client side SDKs take care of the... Can you do a UI out of the box around these auth experiences, or is that more up to the UI developer who leverages your SDK to build react components, or other UI on top of your APIs?

Julianna Lamb:
Yeah. So you can get that out of the box, and then customize things like the font, et cetera. So that it still is your brand elements, but you don't have to build the whole form experience and all of that. You'll get that out of the box. We do some cool things there as well. So for email magic links for example, once the user enters their email, we will show a couple options to click a link to go to Gmail, or your other email providers, and it'll run a search for the email information that will show the email magic link. So you don't have to, yeah, look through your inbox. It's just one click, and you are shown that email magic link at the top.

Ben:
That's super clever. So it links you into Gmail with a search parameter for Stytch, or-

Julianna Lamb:
Exactly.

Ben:
Yeah. That's cool. And I'm curious, you mentioned step-up auth. I'm not familiar with that concept. So can you explain that a bit more?

Julianna Lamb:
Definitely. So this basically bifurcates different types of access from within your application. So a really common use case would be enabling read only access to an account with one authentication factor. So maybe you do an email magic link to get read access to your account, you can see all the information there. But then when you go to take a more sensitive action like maybe updating a shipping address, or viewing billing information, things that could be potential fraud factors. That's when you would get a step-up authentication and do something like an SMS one time passcode, or other two-factor. And basically, what that enables is a really low friction experience for the nine times out of 10 you're browsing your account and you're probably not doing too many actions. And so it's a bit superfluous to always have two-factor, when you might not be taking an action that can really do too much damage.

Ben:
Right. I think, correct me if I'm wrong, but I believe Stripe uses this paradigm a lot. Because I'm in Stripe a lot, and I'm browsing around, I'm doing read only actions. And suddenly I want to modify something, and it's like, "Oh, wait. Just confirm, put in your username and password. Confirm it's actually who you say you are." So I guess I'm not sure if they a pioneered it, or who pioneered it, but I guess sounds like more and more companies are adopting that paradigm.

Julianna Lamb:
Yeah, definitely. GitHub is another example that we'll point to. Yeah, if you go to update a repo setting or something, they'll make you go through another authentication event.

Ben:
I'm curious. I'm looking through some of the products you offer on your site, and session management is one, and this is a concept we talked about. We had one of the founders of Clerk, which is another company in your space, on a few weeks ago and we talked a bit about the importance of session management. But for folks who did not listen to that episode, could you give us a quick overview of what is session management, why is it complex, and why is it nice that Stytch helps you handle that?

Julianna Lamb:
Yeah, definitely. So after a user goes through an authentication event, you basically verified that that is the person that they say they are. And then you need to be able to know who that user is for the duration of their logged in session, understand what permissions they have. Is that session still active, or do they need to go through another authentication event? Something really cool that we've built into our session management product as well is this concept of step-up authentication. So you can create a more privileged session if you have a user go through a step-up authentication event, and set a different time expiration for that.

Julianna Lamb:
So maybe you say, "Okay. Generally, we want our sessions to last for 30 days for read access, you don't need to log too often." Session management will say, "Okay. This is Julianna's laptop, and she's logged into this Chrome session for her Stytch account, or whatever website you're logging into. Give her read access." And then if I go and try and do that more sensitive action, I do the two-factor. Maybe you only want that privileged session to last for five minutes, or 10 minutes, or something much tighter. You can set that with our sessions. So, essentially sessions will give you information about is the user still active? Can they still view these resources? What are their permissions? What do they have access to? All of those types of questions.

Ben:
Got it. Another concept, I think you mentioned this earlier, another one of your products is WebAuthn. What is that?

Julianna Lamb:
Yeah. So WebAuthn is basically this protocol that enables you to use things like a touch ID on a Mac, it does YubiKeys, other hardware keys, et cetera. And so, it's a really great option for two-factor authentication because it is the security of having some hardware device on you. It's really low friction to tap a touch ID, tap your YubiKey, whatever it might be. And it's still, I think, in the early days of adoption. There aren't too many websites out there that enable this. I think Stripe and GitHub that we already talked about, definitely first movers when it comes to authentication offer both of those as options. But yeah, it's really fantastic as well because you can also use it on mobile web. So if you want to do face ID on mobile, and you want to do that from a website, you can do that really easily with WebAuthn as well.

Ben:
Got it. And if I'm a developer who uses Stytch, are all of these things transparent to me? I can just press a button and turn them on. And if I can just enable all these different ways for my users to log in, or what does it look like as a developer to choose which login, or authentication methods a user can use?

Julianna Lamb:
Yeah. So for the SDK integration, it's basically some configuration that you need to do in the code. Basically select which products you want to show. For the API integration, you will need to do a little bit more of that heavy lifting of integrating the different products, and handling them, and deciding what you're going to surface, et cetera. But basically all of it is tied back to our core sense of what a user is, and so it's really easy to add additional products over time too if you want to expand the authentication options that a user has.

Ben:
I'm curious, this is a bit unrelated to your product, but I'm curious for your thoughts as a general point on the space. What is the future of password managers? In a world where every company uses a product like Stytch, is a password manager necessary, or what are your thoughts there?

Julianna Lamb:
Yeah, definitely. So I am a big user of a password manager. There's obviously so many accounts out there today that are still password based, and I think we're really bullish on passwordless as the future. But I think it'll be some time before that fully proliferates, and I think even in a passwordless world, you still might end up with a couple core accounts that you do need to protect with a password. So an email might be one example of that. So it's a password to rule them all, or an account to rule them all. So I think it's still to be proven how fast passwordless picks up. But given, I think, just the number of online accounts that everyone has, I still see password managers being valuable for some time to come.

Julianna Lamb:
But I think, really, our vision here at Stytch is that you get down to the point where you have maybe just a couple key passwords. Maybe one of those is to a Stytch account that's your passport for the internet, that lets you log into a bunch of different websites, et cetera. And I think, yeah, your email account will probably continue to be something similar there. Maybe there'll be new technology in five or 10 years that enables us to fully get rid of that sort of concept, but I think we still have a ways to go in fully proliferating passwordless.

Ben:
Is that one Stytch account to rule them all? Is that a hint at potential future roadmap, or is that really more of a long, long term goal?

Julianna Lamb:
Yeah. I think that's definitely a north star that we're working towards. We're super focused right now on just building the developer tools to make it really easy to integrate authentication. But I think if you're thinking about what the ideal end user experience is, having the ability to have an identity store that you can carry with you across all your different online accounts, passively log into them, et cetera, would be super compelling. And so, it's something that we sort of, yeah, have in the back of our minds as a potential future avenue that we could go down.

Ben:
Beyond that north star goal, what does the next one to two years look like on the Stytch roadmap to the extent you can share?

Julianna Lamb:
Yeah, definitely. So I think we have a lot of building blocks right now, and we still ask that developers put those building blocks together in a lot of ways. And so, just continuing to invest in making it really easy and fast to get up and running with authentication, not have to spend any time thinking about what you need to be integrating, how it all fits together, all of that, and just doing more and more of that heavy lifting, abstracting away more when it comes to authentication. So, yeah, excited to continue to deepen as well as still add net new products as well over the next few years.

Ben:
Got it. I'm curious, in the competitive landscape, so I imagine most folks nowadays are familiar with Auth0. They were one of the earlier developer-focused auth platforms. They were acquired by Okta recently for a large, big deal. And then, we spoke to the folks from Clerk, who are kind of a more modern developer-focused auth platform. I believe AWS and Google have some kind of auth options, and tools for developers, Firebase. So there's a lot of other companies out there. I'm curious how you view those different classes of competitors, and maybe compare and contrast how Stytch approaches the market?

Julianna Lamb:
Yeah, definitely. So I think the analogy that is the most apt, if it is sometimes overused, is the Stripe for authentication. And so I think we see a lot of those other competitors out there as they offer a great product. If you need to get authentication built, you can make it happen with them, but they don't offer really clean developer interfaces and an API first solution. And so that's what we see as the big differentiator here is focusing both on the developer experience, as well as the end user experience, and giving people a lot of flexibility when it comes to how you integrate the product. So that you can own a lot of that branding, own the experiences, et cetera. So, yeah, I think Auth0 has done some awesome stuff in this space. We see them a lot.

Julianna Lamb:
I have some experience working with them in the past as well. And yeah, they were definitely a pioneer in authentication as a service. I think, because they were built around passwords, a lot of their product architecture is very password centric. And so with passwordless, you can lean into things like the API first solution because you don't have to worry about developers collecting and storing password information. So a lot of Auth0's architecture is around their login form, and so we just have more flexibility because we're passwordless first by nature. And so, I think that flexibility is the number one thing that we go back to in terms of how we differentiate against those other competitors in this space.

Ben:
So, I'm curious to learn a bit about how you actually started Stytch. So you mentioned that, I think you said you and your co-founder were working at Plaid, is that right?

Julianna Lamb:
Yeah. So we'd met working together at Plaid. I had left Plaid in 2019 to join a company called Very Good Security. I worked on product there, and so my co-founder Reed and I had basically stayed friends after Plaid, and would do a monthly coffee catch up. And so it was over one of those catch ups that we were complaining about how hard it was to be building some of these authentication experiences, and I was working with Auth0 at the time, he was working with AWS Cognito. We were like, "This is really frustrating. Why isn't there that Stripe for authentication?"

Julianna Lamb:
And so that was sort of the initial spark that led us down a path of doing a bunch of discovery, talking to potential customers, et cetera. To try and figure out, were we missing some vendor on the market that really was serving those needs, or was this a more universally felt pain point? And I think just kept hearing over and over again from people that they were really frustrated with whatever it was they'd chosen for auth, whether that be using a vendor, or building in house. And people seemed to be excited about the approach that we were considering, and so that gave us the conviction to go and quit our day jobs, and start the company.

Ben:
And then, after that did you build out a prototype and then raise money, or what was your order of operations?

Julianna Lamb:
Yeah, so we raised our seed round pretty quickly after leaving our jobs. I think we had a really clear idea of the product that we were looking to build from all of those discovery conversations that we'd had. We had a very rough prototype built, but I think the interesting piece was more the vision and product roadmap. And so, raised the seed round in basically June of 2020, and then went out and hired a few engineers that joined our team in September of 2020. And then, from there sort of built out our alpha product, and launched to beta in January of 2021.

Ben:
Awesome. And you raised a very big series B, series A recently. That was, I think, $90,000,000 announced. So what are the plans for all of that capital, in terms of growing over the next few years?

Julianna Lamb:
Yeah. Definitely a lot of hiring, a lot of hiring engineers. But really across the board, I think we are super excited about the traction that we have today, and have a lot more products, and just product functionality to build out as well. And so, the money is really going towards building out the team, and continuing to invest in our product.

Ben:
I'm curious on the subject of traction and monetization. How does the pricing model work? I know one of the complaints about Auth0 is that you get hooked, and then it gets expensive. And then it's hard to switch off once you're built your whole infrastructure around a given authentication provider. So I'm curious how you, yeah, how you think about your pricing, and how your pricing scales as a customer scales?

Julianna Lamb:
Yeah. So we price around monthly active users, and so it's important to us to tie our pricing structure to the users that our customers are getting value from. And so that's why it's a monthly active user, and our rack rates are basically 10 cents per monthly active user. And then as people go and scale with us, we always want to have a conversation with them about how we can figure out something that will work as they go and scale. And so, we see that happening, and being a pretty compelling metric to tie to because people tend to know what their monthly active users are. They tend to have projections as well, and so we find it to be really simple and straightforward, which has sort of been our number one thing when it comes to pricing.

Ben:
I'm curious, one of the struggles I often hear companies debating when they do a monthly active user based pricing is that in a B2B company... If you sell to both B2B and B2C, in B2C you usually have a much larger number of monthly active users, but your value per user is low. And then B2B, smaller number of MAUs, but higher value per user. So I'm curious how you think about pricing, I imagine the products applicable to both B2B and B2C. How do you think about that challenge, in terms of pricing?

Julianna Lamb:
Yeah, definitely. I think it comes up a lot, and I think over time as we build out more use case specific products we probably will start to differentiate a little bit on pricing there as we build more B2B specific ones in particular. I think that will be a natural inflection point to revisit that, but for now I think we found that we may be leaving some on the table with those B2B use cases. But given that the product is very similar across both, we haven't tried to differentiate there on the pricing.

Ben:
Well, Julianna, thank you so much for joining us today. It's been awesome learning about Stytch, and it's really exciting to hear about all your progress. For folks who want to check it out, the website is Stytch.com. That's S-T-Y-T-C-H. So, make sure you type that in correctly. Any other resources you would recommend if people want to learn about the platform, aside from your website?

Julianna Lamb:
I think finding us on Twitter is always good. We're Stytchauth on Twitter. You can also find me on Twitter, Julianna E Lamb, always happy to chat with people.

Ben:
Great. Well, thanks again for joining us.

Julianna Lamb:
Thanks so much for having me on.

Brian:
Thanks for listening to PodRocket. Find us at PodRocketpod on Twitter, or you could always email me even though that's not a popular option. It's Brian, at LogRocket.