Ben: Hello, and welcome to PodRocket. Today, I'm here with Colin Sidoti, who's the founder and CEO of Clerk. How are you, Colin? Colin Sidoti: Doing great. How are you? Ben: Doing pretty well. So, for folks out there, Colin and I know each other from the Boston tech ecosystem, had some mutual friends, and I'm really excited to have Colin here joining the podcast, and give him an opportunity to share what he's building. So, Colin, take it away on what Clerk is and how it helps developers build great applications. Colin Sidoti: Yeah, definitely. And thanks so much for having me. Clerk is, we're building authentication for the modern web. I think at a high level, what we're seeing is that the architecture that developers use to build applications today has changed significantly from the era of MVC and Ruby on Rails. Now it's more React and Next.js, and instead of Active Record, we're using tools like Hasura and Supabase. Really, the authentication strategy of the past, we think, isn't optimized for this new world. So, we've been working to build a better set of authentication tools for the modern web or JAMstack. It has a lot of different names, but that ecosystem. Ben: Got it. So, help me understand, I'm building a Next.js app ... React, Next, are all one and the same, in a sense. Then I guess I could be using any of a whole range of back ends, and how do I use Clerk? What does it do for me? Take me through what is the developer experience? Colin Sidoti: Yeah, so I guess very simply in your initial integration, the first thing you'll set up is a sign up, a sign in, and a user profile screen. With Clerk, there's a few ways to do that, but the easiest way is we give you a React component to just drop onto the page. It's literally called, sign up, sign in, and user profile. That provides a whole UI for you. It's a lot like Stripe checkout in that sense, you can just outsource the UI to us and we'll provide it. If you don't want to do that, you can also use our hooks. We have a use sign in hook, and a use sign up hook, and that'll talk to our API directly and you can design your own UI. Ben: Got it. So I drop in the component, it handles all of the complexity around building, even just a login interface in terms of error handling in different states; so it sounds like you kind of abstract that all away. Colin Sidoti: Yep. Ben: Then once the user logs in you provide hooks, or state, or something that tells the app that the user is logged in, is that roughly accurate? Colin Sidoti: Yeah, exactly. I'd say honestly, that's almost where the hard part comes in. There is a lot of hard parts to the login itself, right? Setting up password list, so it's streamlined or setting up Eof, so it's streamlined, and so accounts link. There's a lot of headaches that we do solve than just the UI component. I think from a technical perspective, or just engineering perspective, where things are different in the modern web world versus end of the rails world, is more this back off the problem, okay, my user is signed in, how do I know who my user is? Colin Sidoti: And a big part of the reason why is ... With Next.js and React, it's not static on the front end anymore, so Clerk provides a user hook to figure out who the user is from the front end; but then we also have to make that work during SSR, if someone's doing SSR, which is half back end half front end. Then, if you're calling one of your API routes in Next.js, that's another context that we need to know who the user is. And then Next.js also has Middleware now. That's a fourth context. Colin Sidoti: I think maybe even more interesting than that is Next.js doesn't come with a database the same way that Rails did. And so you pull in a Hasura or a Supabase and you need a way to tell those databases who the user is. So, Clerk really tries to cover that whole surface area with the exception of SSR, which is launching this month. Ben: Got it. So each of the places in my stack where it needs to know who the user is, is able to communicate with Clerk and Clerk abstracts away all of the complexity of managing who is the active user, and are they logged in or not? And what means do they use to log in? That's just all taken care of. I can just build my app and rely on Clerk for all the off type stuff. Colin Sidoti: Exactly. We do all of the session management piece, we drop the cookie. We even do, if someone goes into the user profile, they could see all the devices that they're signed in on and revoke them, all of that is just provided out of the box. Ben: I've used Auth0 in the past, which I guess is pretty well known as a developer friendly, abstract away some of the complexity of Off. How does Clerk compare to Auth0 or maybe some of the other tools out there, the more legacy tools? We'll talk about Stitch after because, it sounds like they are one of your current competitors; but curious just to understand the difference between Auth0 and other previous generation of tools. Colin Sidoti: I mean, I think a lot of the differentiation you'll notice right away is Clerk is very much trying to operate in all those different contexts. The SSR, the client side rendering, [inaudible 00:06:19] ware, as well as the third party services. I'd also say that we take a stronger approach in the UIs we provide, right? Auth0, they do have some concept of giving you a sign up form and a sign in form. You have to redirect a way to it. We let you embed it in the app. But then also our user profile component where someone can go and they can change their profile information, change their password set up to 2FA, all that's just included. Auth0 doesn't really have a concept of a user profile screen at all. They have a way to build it, but you're still building that in house. Ben: Got it. So just more comes out of the box and would it be accurate to say it's bit more opinionated around how to use an authentication provider in the context of a modern JAMstack or modern app? Colin Sidoti: Yeah, I think that's fair. We've worked really hard to provide the same amount of flexibility on the different ways that someone can log in, but certainly in terms of the implementation into an Xjs app. Yeah. I'd say we're more opinionated in an effort to try to make it faster. Ben: How tightly coupled are you to React and Next? Is it just that you ... It sounds like, but correct me if I'm wrong, you kind of have built a fairly extensible platform and just built a lot for the Next and React users, but technically anyone could use Clerk with any application stack? Colin Sidoti: Yeah. So that sign in component under the hood, it actually is, window.clerk.mountsignin. So, our React library is actually just a wrapper over vanilla JS. So, anyone can use that and integrate it into any other framework, but so far in house, we've only built out the SDK for React. Ben: So, we covered Auth0 ... I've seen Stitch as kind of another modern take on authentication. It seems like they lean in a lot to magic links and password lists. How do you kind of see them in the market and compare and contrast there? Colin Sidoti: Yeah, I think there's a lot of extra opinions that we have around what integrating into Next.js and React looks like. I think we're far more focused on that ecosystem than a Stitch. I also think that we don't really hold opinions about how your users should sign in. We have a guide on our website about password less and kind of the trade offs of doing that. We've also worked really hard to make our passwords secure. So we work with, have I been honed to check that, or whether or not passwords have leaked. We don't let you, your users use leaked passwords. I think everything in authentication, like how actually a user signs in to your app, there's trade offs, depending on the strategies you want. So, we don't intend to be rigid on password less, ever. Ben: Got it. I'm curious to hear a bit more about what you think is the future of the password. This is like a very broad question, but passwords are just terrible. I personally ... He's a password manager and so, it doesn't bother me that much; but just seeing other humans try to remember passwords, and wrangle password managers, and the whole concept of the password feels like something in 10 years from now is not going to exist. That's just my own personal opinion. I'm curious, as someone who spends a lot of time in this space, do you agree, or what are your general thoughts? Colin Sidoti: I think we're more than halfway there. In a B2C context. If, an app on Clerk has sign in with Google on, more than half the users are going to pick sign in with Google. If, you do that, there's no password. It's also faster than passwords. It's more performance. So, all around, sign in with Google is better. If, you have an application where users are likely to have ... Or any Eof off vendor or social vendor, we definitely recommend putting that there, and Google is just the top one. Colin Sidoti: In a B2B context, passwords are, at the enterprise level, gone as well. Right? So we have SAML authentication. I guess if you work at a company and you sign in with Okta ever, that's SAML authentication. So, it's like we are already, chipping away at the password. I think, where I have a little more hesitancy is saying that, "Is sign in by OTP code sent to a phone number sent to an email address is going to be the password." And a lot of that is actually just deliverability challenges, is the process of bringing someone out to their email takes too long right now. Colin Sidoti: Perhaps the infrastructure there will improve such that, that mechanism of going out of band will work better. I personally think we'll end up more with face ID and touch ID style systems leading the way. Yeah, I certainly think it's dying, but I think today it still has a lot of merit for a lot of use passwords. Ben: So, curious to learn more about the business side of Clerk. First off, what led you to start this company and why take on the challenge of authentication? Colin Sidoti: Yeah. I guess the history of it is my brother and I are both engineers. We both always have a side project going and we just always hated the authentication part of it. It wasn't so much because it was hard. I think there's a good set of open source tools to get something working, but it never looked good. Right? You'd sign in to your own app versus sign in to Google and you'd just be like, "Wow! Google's UX is just so much more delightful," and I want that, I want the better experience. Colin Sidoti: Even things like adding Eof. Adding Eof is really hard in a lot of open source libraries because, you have to do the whole account making thing. This actually is one of the most surprising stats I'd say we've seen at Clerk is, 15% of users, if they originally sign up with email, or if they originally sign up with Google, at some point they're going to try the opposite one. Colin Sidoti: From a programming perspective, this is an edge case, right? Like it doesn't matter that much, it's an edge case, not that many people should hit it; but then it's 15%, that's crazy. It's a real pain to do and yeah, I don't know. I think it was just always a thornier problem than we really wanted to spend time on. We wanted to work on our differentiation and it never made sense to us that this was still so hard. Colin Sidoti: It made more sense after starting. It's really hard to do as it turns out, as a third party service, it's hard to keep the security models all there. It's even hard to just stay up to date on all the authentication schemes. But as a developer, I think you just want it to work and you want to get the focus on your app. Ben: I'm curious, does Clerk solve the problem of merging to authentications? That's always something, I've built a few SaaS products before, that's always just a pain to deal with building. The logic that, a user's been signing in with Gmail and then they sign in with email, they have to verify because, it could technically be two different people if the owner ... So it's always just ... Colin Sidoti: It's all out of the box. Yeah. I'd actually say that's, another small differentiation from Stitch I believe. I think Stitch is very isolated around here. It's a service around the single authentication factor and then you have to do that grouping on your back end. The linking on your back end. Hopefully I didn't misspeak there, I should double check. Ben: Yeah. Well, I know some competitors are always building things and you're not exactly sure if they have a certain feature or not, but we don't hold that against you. I imagine that, in building a startup in the authentication space, the burden to have a very strong security posture feels like it's probably a bigger hurdle for an early stage startup than most. Usually most early stage startups they don't put as much focus on security as they should; but when you're building an off company, I'm guessing your customers require a certain level of security and compliance. How have you thought about building your security program, and team, and practices? Colin Sidoti: Yeah, I really have to shout out to both South Park Commons and S28 our two investors, in their extraordinary patience as we got this up to par, to a place we were comfortable with before we launched. Because, it really was a big focus internally that delayed the launch a lot. I think we had our proof of concept and the developer experience down, then we were like, "Okay, we show this to a lot of developers. It works now we got to get security and reliability;" really, both parts of that just totally locked down. Colin Sidoti: You know, it's a conversation in absolutely every feature we build. Does this break the security model or not? It's often where we need to innovate a lot. As a third party service, we can't skirt the requirement that says it needs to be an HTB only cookie that can't be JavaScript accessible. So, we need to design around, how can we put that cookie on a different domain than it's been on in the past. Colin Sidoti: I think the first thing we did is, we all have in our founding team, at least, a pretty significant background in web security and whether that's taking ... Mostly coursework. It took a lot of classes in web security and that's where that knowledge is coming from. Colin Sidoti: Separate from that, we also work with third party security auditors to download our whole code base, they look at it line by line, and they call out any issues they find. At the end of it they give us a letter of attestation and we do those regularly. It's a lot of work. There's a lot of reading and knowing all the different threat vectors and just staying on top of it. Ben: I'm curious now to understand growth and how you're thinking about customer acquisition. I mean, as a company that's one of our core personas as developers, it's always interesting to hear how other companies are reaching developers, building a developer audience, and ultimately selling to developers. What's your approach there? What are you thinking about in terms of the next year or so of your go-to market efforts? Colin Sidoti: Yeah, I think you've heard it a little bit during this podcast. A lot of it we've just ... When we first launched Clerk, it was just outsourced off. Outsourced off, outsourced user management, and I think what we found is that it's all JAMstack developers naturally attracted to us. I think it's a lot of that persona shift that I was just talking about, where, that crowd is more eager to outsource than the previous generation. Colin Sidoti: So, we're really just working to embrace that community as much as possible. We're working to build integrations with Hasura, with SupaBase, and drive that ecosystem forward to whatever extent we can and talk about it to whatever extent we can. Even just staying on top of the Next.js launches and making sure that we can opt in all of their different contexts. There's a lot of work to do there, and a lot we can talk about there. Ben: Is Clerk open source? Colin Sidoti: It is not completely open source and actually we're less open source now than we want to be. We're in the process of open sourcing all of our front end libraries. The back end will remain close source. Ben: Got it. So, the front end libraries that's like, the React components or the ... It sounds like there's a vanilla ... We talked about this earlier vanilla JS library as well; that will be open source. Do you have a back end, like a MPM client, or things like that as well? Colin Sidoti: I'm not sure what you mean by MPM client. Ben: I guess, node client rather like, some kind of server site [crosstalk 00:20:57]. Colin Sidoti: All of the back end SDK's and front end SDK's, will be open source. Some are interspersed already, but we're building out a monorepo and it's all going to go open source at once. It's just really the code powering or APIs that's going to remain close source. Ben: Have you considered at all open sourcing part or some core of the back end, the infrastructure that serves the API? Colin Sidoti: Yes. The session management piece ... I honestly think that we will likely do it eventually, it's just getting around to the work to fully ... I can't come up with the word to fully separate out session management from user management. Decouple is what I was looking for. The way we do session management is I think interesting and warrants merit beyond our system and that's that, we have a long live cookie, but the long live cookie is used to generate short lived cookies that are ultimately used for authentication. Colin Sidoti: We have this polar running on the front end that updates JWT every minute, and that JWT expires every minute. The benefits of that is that when a request finally gets to your back end, all you have to do is verify the JWT. It needs to be short lived so that it can be revocable so that if someone does want to revoke a device, that token expires in a minute. Colin Sidoti: Any authentication within the system itself is under a millisecond. We really like that design and it's very close to being completely decoupled in our back end; I think we're also just really excited for the implications as we get into authorization more, and what can we decorate? How can we decorate that JWT to put authorization information in it as well, to really just cut out the first ... Normally the first 20, 30 milliseconds of a request are going to database GRACE to figure out who the user is and whether they can do something. Colin Sidoti: So, I don't know, we like that design a lot and I think we're engineers ourselves, we like the idea of open sourcing it. Ben: Got it. So, just so I understand, that's like storing more information about who is the user, and what can they do, and their permissions, and authorizations, all within the encrypted JWT. So that when you unpack that somewhere, you instantly know everything you need to know. And if you have a system in place, which you already do, to invalidate JWT's, when the user signs out, or changes their password, or de-authorize the device, and you're checking that often enough, it can work and you don't necessarily need to store the information in the database. Colin Sidoti: Yep. Ben: I'm curious, if I was thinking about adopting a product like this, especially early on in the life cycle of a product where I'm kind of just choosing the foundational technologies, I would think about lock in as a potential long term concern if I'm building all of my Eof, on a provider. How do you explain to potential customers or developers, how they should be thinking about potential lock in on your platform, and if they wanted to move off in five years when their company reaches certain scale? How would they do that? Colin Sidoti: Yeah. Just send us an email and we'll work with you to export all the data. Passwords are kind of the only somewhat tricky part of this in that, all the passwords are decrypted in our database. And our API endpoints don't, by default, return the decrypted password. So for that reason, it's an email to us, we'll export everything, including the decrypted passwords, and you can move off of it. Yeah. You have all the data you need to do whatever you want. Ben: Curious to hear a bit about the future, what does the roadmap look like for, I guess we're in the beginning of 2022, so it's a good time to talk about that. What does your roadmap look like and what are you most excited about? Colin Sidoti: Yeah, the biggest feature is B2B. I like to say right now we do user management, and we're getting into customer management, and for some companies the customers are organizations rather than just users. Similar to how we provide the UI's for sign up sign in user profile, we're going to provide UI's for create an organization, on board a team to that organization, set everyone's roles and permissions; and we're going to start entering the authorization side of the space. So, there's this distinction of authentication being signing in and then authorization being, what actions is that user allowed to take after they signed in. A lot of that is associated with their role within the organization, and we're starting to enter that space. Ben: Interesting. So, role based access control is kind of one of those checklist items that almost every SaaS product that sales B2B has to build before being ready to sell into enterprise. I guess, thinking about it is one of those things that it's somewhat different for every company, but a lot of it sounds like, and I guess this is why you're building it, a lot of the core logic of building our back system is kind of generic. Like you have to integrate with the enterprise, off providers, you have build the framework for roles, and adding permissions to roles, and giving people roles. Sounds like you're taking all the complexity out of that. Colin Sidoti: Yeah. I think there's actually something interesting from a shifting developer persona perspective, where ... I think years ago, these authorization checks is something that you would always do in house, you'd always want to do in house. You'd never think about outsourcing it. Something has changed, and to me it's really coming with this JAMstack and modern web era of ... Developers are more comfortable than ever outsourcing microservices, as long as you can draw a clean product line around it, and then they're comfortable doing it. Colin Sidoti: It was really peculiar to me for about a year at Clerk, where, people were asking for B2B feature set, but my response was always, "With Devise, it didn't come with." Devise is the popular Rails authentication, open source library; it never came with authorization, this other element. So, people could build it on top of Clerk the same way they would build authorization on top of Devise. But for some reason we've been getting all these requests. Colin Sidoti: I think it's just interesting to call out it, to me, it's just a shift in the developer persona. They'd rather outsource it. And so we're jumping into it head first in 2022, and we'll probably get the first version out early Q2. Ben: Do you have any plans, long term, to consider billing or that next level of account management within Clerk? Colin Sidoti: Yeah, totally. It's part of that authorization game too. Right? So, the two big things that inform, can a user take an action, it's first, what role do they have within the organization? And then second, what plan are they on within the product? Do they even have access to this feature altogether? And so we want to loop both in. Ben: Yeah. I mean, it makes so much sense. If you can abstract away all of the boiler plate of building a SaaS dashboard with billing and users and off and roles, and just let ... If I'm starting a new SaaS company, I can just focus on building what is actually unique to my business that I'm serving to my users. In the same way, Stripe did this for payments, it's kind of like you're building that whole next layer of abstraction. Colin Sidoti: Exactly. Yeah. I talk about Stripe and SendGrid as kind of this last generation of API companies where they were so vertical specific, it's an email API, and it's a payments API, but when you really get down to it, you're emailing a user and you're charging a user. And Clerk gets to think about the API that way. Ben: Colin, thanks so much for joining us. It's been really interesting learning about Clerk. We will put a link in the episode description for Clerk.dev, which is the website. If folks out there are interested in what you're building, learning more, potentially joining the team, it sounds like you're hiring, how would you recommend folks get in touch with your team? Colin Sidoti: Yeah, absolutely. Thanks. Thanks again so much for having me. And we are hiring. If you go to Clerk.dev, kind of in the footer of the website, a careers link, JavaScript engineers, writers, technical writers, and then really just full stack engineers all over the place. We would love to talk to you. And yeah, thanks again. Ben: Thanks Colin. Speaker 3: 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@logrocket.