Paul: Hi there and welcome to PodRocket. I'm your host Paul, and today we're joined with Rishabh and Advait. These guys are the founders of SuperTokens. Advait is the CEO and Rishabh is the CTO. And we're going to be talking about authentication, kind of bringing this out of the bubble that we feel like we've been stuck in with Supabase Auth or maybe Auth0, and how can we bring these other solutions to the landscape of our microservice architectures? Welcome to the podcast, guys. Advait: Thank you so much for having us. Rishabh: Great to be here. Thanks. Paul: Awesome. Yeah, thanks for coming on and taking the time. So quick elevator speech of what your product is. We're talking about self-hosted authentication, right? Would you extend that little definition to be anything more for that one little sentence when you intro to people? Advait: Yeah, sure. So SuperTokens is open source, user authentication. Essentially what we try to do is we try to solve the build versus by trade offs with typical software decisions. So you get the power of build with the speed of buy. So it's not only self hosted, it we also have a managed service. Paul: So when you say the speed of buy, but what was the other? Advait: Power of build. Paul: The power of build. Advait: When you build software, you get a lot of control over the way it works, right? It's completely your use case. So you can control and manage the user data. You don't have to wait for the vendor to build a particular feature, you can build it and launch it yourself. You can customize any part of the product. So that's the the power that build gives you. Whereas if you buy software, it's off the shelf and it's very quick. We want to basically, instead of you having to make those trade offs, we want to give you the best of both worlds. Paul: So what's maybe an example of something that I would want as a build flexibility or feature that maybe isn't present in Firebase or Auth0 that you guys immediately identified and wanted to bring to the table? Advait: For example, the front end user experience. So on Auth0, the UI is hosted on their domain. So your user gets redirected to their domain and then signs up there and then gets redirected back to your app. With SuperTokens, the UI is hosted completely natively on your domain.com. So you have complete control of the way it works, the way it looks, the end user experience. Similarly, there's multiple customizations. If you want to add any business logic to your users, it's a lot easier to do with our architecture. So for example, let's say you want to limit the number of sessions that a user has. Let's say you're building a streaming app and you want the user to only have one active session at any point of time, that's pretty easy to do with something like SuperTokens. Paul: Is that something that's traditionally more difficult to do with a Firebase or Auth0 implementation? I just have never tackled something like that in my experience. Advait: So generally, stay shy of generalizing too much. But yes, so our architecture is fundamentally different from all the other authentication providers. A lot of the logic resides within your front end and within your backend API layer. So because it's within your front end backend, it's a lot easier. You can customize, let's say your backend, your APIs are written in node, Golang, Python. SuperTokens will give you an SDK for that language, which consists of all the auth logic. So you can make those changes within your API layer as opposed to, for example, with Auth0, you'd have to go to their dashboard and upload JavaScript snippets onto their web editor into what they call Auth0 actions. Paul: Is the way that you would interact with this via the SDK, something like a plug-in base or component based sort of architecture when you want to add these bubbles of custom logic into the backend code? Rishabh: Well, it's more like inheritance. So the backend SDK exposes... It has a middleware function which exposes all the APIs which the front end can call. So for example, sign out, sign in, session refresh, all of these APIs exposed by the backend SDK. And they have a default implementation to them, so you don't really have to implement anything specifically other than just add the middleware to your app. And when you want to customize any of these APIs, you can create a child function similar to how in inheritance you have a parent class and you create a child class that inherits from the parent. Similarly, you create a child implementation of these APIs which can either do something completely custom or do something before and then call the super class version of those APIs and then do something after based on the output of the super class. So that's kind of how it's architected. It's based on this feature called overrides, which is inspired by inheritance. Paul: Right on. That really answered my question completely and thoroughly. I mean if you have users able to get a magnifying glass, a sight into what's happening with these backend processes and edit them themselves. This is a new tool that we're giving developers out there that might not have reached into the mud themselves. Do you think that your product is going to give way to interesting new authentication power structures in the way... Because you mentioned for example, "Oh, I only want this user to log in with this restriction." I'm thinking about we're in the day and age of blockchain when we're talking about how do we organize as people? How do we authenticate people? Which it's not totally related, but I'm thinking somebody might come up with some interesting gamified ways to log in, ways that I've never thought about interacting with an application. Are you guys hoping to see that? Have you already seen that? Rishabh: Yeah. Due to the way we architected, the way people can customize SuperTokens, you can essentially create plugins on top of our default implementation, which allow you to do more than what would otherwise be possible. So one example of what we've done is there's a database called Fauna DB, which issues tokens specific to the login user. And when you query Fauna DB with that token, it returns only the roles that user has access to. So the way the token is managed and its lifecycle is something that can be added on top of SuperTokens. So that developer using SuperTokens and Fauna DB don't have to do the hard work of actually getting the Fauna DB token and refreshing it and all of that. It's sort of coupled with the session creation and refreshing of SuperTokens and it's implemented as a plugin on top of SuperTokens, which overrides the create new session function or the refresh session function and the sign on function. All the end user has to do is just add that plugin into the SuperTokens function call on the backend and provide the Fauna DB credentials and you're done. Paul: If I may, it sounds like you really made an API to this substantial application that allows you to just interact with this abstract idea of a token in any way that I could see possible. That's banger. Okay. So if I had a database, if I had a Raspberry Pi... And the general idea of a token, are you trying to abstract the idea and the utility of a token to any domain? Is that the goal of SuperTokens? Rishabh: Well, that's one of the parts of SuperTokens, specifically the session management part. Using that, you can transfer any authenticated information across the back end and front end for an authenticated user. So for example, you could store a Fauna DB token, you could store Supabase token, you could store Google access token, really any sort of token that you want or any other information as well, like the user roles and all of those things in the session very easily and read them on the front end and backend without worrying about keeping them up to date and refreshing them, things like that. That's specific to the session features of SuperTokens. Then we also have other recipes is what we call them for different types of login methods. So for example, we have an email password login method like a social or enterprise SSO login method, passwordless login method. We have user roles and we have machine to machine authentication. And all of these are architectured in a similar way where you can inject your own logic through overrides on any of these recipes and customize the default behavior. The other very important part about these recipes is that they're fairly independent. So unlike other auth providers, you can use the session recipe without actually using SuperTokens for logging in. You could have your own login system and the user ID that you have from your system, you could pass that to the session, create new session function and that would work with that user ID. Even though SuperTokens doesn't know about that particular user ID from before, it would still work. These recipes are modularized and independent as well. Paul: So in the example of the passwordless login, maybe could we go over an example deployment of how somebody might have SuperTokens for their own group and which systems might talk to one another? Because when I hear Passwordless deployment I'm hearing, "Well there's going to be some API endpoint that's going to have a link and a callback for somebody to click on." If I'm hosting that versus some other provider, I'm exposing myself to things such as DDoS or other weaknesses in the protocols. Do you guys have extra security measures for these recipes that come up or are they more just connectors and just getting the thing to work? Rishabh: We have sort of a balance between the two. So let me just take you through the flow of passwordless login, right? So we have a front-end SDK which provides the UI and those are just React components that you can put into your app. For example, the magic links for example, when the user enters their email and hits the sign in button on the React component, that calls an API exposed by the backend SDK, which is to create passwordless code. That API then sort of talks to SuperToken's core microservice, which is connected to your database, to generate a passwordless code for that email and send the email out to the user. Now the sending of the email is something that happens within the backend SDK which allows developers to customize how the email is sent and what is sent. So we have default implementations that sends email using our servers, but you can sort of provide your own SMTP config or you can just provide a call back for completely sending emails however you like. Once the email gets sent with the link, when the user clicks on it, it opens the browser. For magic links, that's sort of a tricky area because the browser could be either the original browser in which the login attempt was first done or it could be a completely different browser. So if it's the original browser, for example, then all is good and we just log the user and we sort of consume the code, and if the code is valid, then we log the user. And if it's a different browser, then we have a prompt on the browser saying you want to log as this user, click and continue. And then when the user clicks on that, then they get logged in. And the reason for this extra step, extra user interaction is because if you didn't have this, then email clients could, for example, open the magic links and consume the token thereby rendering them useless. So this extra step is to prevent that. This is one of the edge cases or security features that we have. Of course there are many more, but this is a simple example. You mentioned DDoS. That's something that is done on the managed service side for the SuperToken's core. But on the backend API layer, which where the backend SDKs sit, that's your own API layer, so you need to protect your API layer for DDoS anyway if you are at that scale and whatever you do there would work for the SuperTokens APIs as well. Paul: Right, of course. Okay, so thanks for bringing us through that example flow. For any of these recipes that you deploy, the way that these systems might interact, of course it's going to change with the way the recipe orchestrates the system, right? Rishabh: Yes. Paul: Which system talks to which system and such. So if you don't want to think too much about managing one of your own deployments of the core API, you said you have a managed service, right? Rishabh: Yeah. The managed service essentially is where we deploy a SuperToken core for you connected to a database. So all you have to do is integrate a backend SDK on your API layer, integrate a frontend SDK on your website or mobile app and then the core is handled by us. Paul: That sounds like the closest sort of analog to what a lot of developers might be used to if they're looking for a backend as a service plugin that has to do with authentication if we're thinking about Firebase or something like that. You take care of the database, you take care of the core API, you sign up and then you can tool the backend APIs and SDKs as needed, right? Rishabh: Yes. Paul: Okay, great. I mean if anybody watching wants to compare the SuperTokens solution to another solution, at PodRocket, we also have a episode with Supabase. They also kind of try to gear themselves towards an open source solution. They have an authentication piece which is part of their backend as a service stuff. Yeah, definitely go check out that rest that excuse episode if you want to learn more about the Supabase products. But one thing that I think they might be missing that you guys are bringing to the table here the whole recipe situation. Personally whenever I'm trying to do authentication, I always find myself trying to battle and pigeonhole myself into an existing solution and tooling around that versus it'd be nice to go into a library and pick a book off the shelf and have it do exactly what I need, which is passwordless authentication and just forget about it. What do you think is the most, I want to say approachable or most familiar recipe, or is it even a recipe for people first wanting to try out SuperTokens? Advait: The easiest way to get started at SuperTokens is to run the CLI that we have. So it does ask you which recipe you're looking for, but you could just get started with let's say email password or pretty much any recipe. And then it would give you the demo app of that particular recipe and it'll show you how everything works. In general mostly, we see a pretty even distribution across all the different login methods. So between email, password, passwordless, social login. It's generally an even distribution, so there's not one that's clearly the winner, but probably email password if I had to say one. Paul: Right. Okay. Do you think that the distribution... You say it's pretty common or pretty equal across the different methods, is it that each group or company is equally employing a common base set of methods or is it one company and group will typically stick to one and then another will do another one and it just happens to even out over the people who are using it? Advait: Yeah, it's more the latter. So just one quick clarification here is we also allow you to combine things. You can also have social login plus passwordless, right? And you can also have social login plus email password. So that also happens quite often, but mostly you'll see one company picking passwordless and then another company saying, "No, we don't want passwordless, we want specifically email password." Paul: Gotcha. Yeah, if you can have multiple methods, that's crucial if you want to have... Because I assume if you have SuperTokens and you know how to use it and your developers are used to it, you might as well use it for other internal systems and other internal logins. Internal logins are always different than what your application is sporting. So that's great to hear that you can really extend yourself and the core can be flexible to support as many use cases as is needed. I feel like we've talked a lot about what you guys have to offer as a product. I'm sure there's a lot more we could go over and definitely interrupt me if there's something you want to bring up. But I'd love to talk really briefly about how you guys started this thing because I feel like there's a lot of different open source sort of, "Oh, we're a back end as a service," things coming up. But this one is really disruptive to the existing solutions out there. So how did you start it? How long ago did you start it? Did you guys start it together? Advait: Yeah, we started it together. We've actually been working on a previous startup before this together as well. So that's mine and Rishabh's personal journey is that we were working together for a previous startup and then for that startup we had to build the session management layer. The session management layer in our opinion wasn't well solved at the time. There were a lot of security vulnerabilities. There were a lot of things that people didn't understand completely or misunderstood. For example, there was a lot of debate around local storage versus [inaudible 00:18:55] cookies. So we built a pretty secure way of handling sessions. We wrote a blog post about this proposed solution and that blog post went viral and did really well and people from all over the world are reaching out about implementing that kind of a flow. That's the initial way we got into the space. I mean Docker, Facebook, a bunch of the biggest companies had all had session vulnerabilities in the preceding six months. So that's how we started. And then one thing led to another. We got into Y Combinator, which is this leading accelerator. That's how we got into the space. Paul: Do you think that the issues with the session layer of help propel you into the position that you're in now to really cause people to raise an eye eyebrow and go like, "Oh wow, these guys, they really solved the problem that we've been kind of tech debting away for a while"? Advait: Yeah, it definitely helped. It definitely helped. So initially we only did sessions. The move into authentication was driven by insights on the problem statement being much bigger than just that. So we understood, again, the typical user research, we did a lot of it and we understood there were multiple problem statements. But yeah, sessions was again another important product differentiator for us. For some people it obviously matters a lot, but it doesn't matter as much for everyone. It sort of depends on the size of the customer you're referring to. For those, yeah, session is pretty important. Paul: When you were going out to doing this initial customer research, who were you talking to as well? Because I feel like everybody needs authentication. It doesn't even need to be an app team. Like I alluded to earlier, somebody could be working on a Raspberry Pi and need to authenticate another node into a cluster or something, god knows what. So yeah, who did you talk to and did you really try to be diverse? Did you try to reach out to different layers of stack? Advait: The majority of people we spoke to were essentially people like us. So early stage startups, people building companies that wanted to build that company for scale, everyone that had ambitions of becoming unicorns. So early stage companies that wanted to become unicorns was our core area of focus. So early stage startups. Then just to validate the long term thesis here, we also did talk to mid-market and enterprise customers just to understand what authentication are they using? What are the pain points? Does what we are thinking about the early stage scale well? As the company matures, obviously we will be going up market. Does this hypothesis work well from a 5 to 10 year point of view? So we validated with the larger companies but the focus area was building something that companies like us would use. Paul: Right on. So speaking of this long term plan, do you guys see yourselves eventually being competitors to the more easy going... I don't want to say easy going, the easy to reach to authentication methods that people just see in every YouTube tutorial out there? Do you want to be on that list of GCP products that you can plug into your stack eventually? Or trying to keep it small, trying to keep it a little more towards this type of customer that we're talking about right now? Advait: The goal is unambiguously to be the number one authentication provider. We should be the default for anyone that wants to add authentication to their app, which is why the vision of solving this build versus buy trade off. Because so many people still build authentication for various reasons because they don't want to be locked into a vendor and they don't want to use a SaaS, they want to control their own user data, all of that. So there's multiple reasons why. There's still a very large percentage of people that build. So we wanted to bring those people into the fold as well and give everybody an option where you can still maintain all of those benefits without giving up those trade offs. So yeah, the goal is definitely to be the number one. We haven't spoken about this too much, but the ease of using SuperTokens, the experience of using SuperTokens is also really important. We want it to be super easy to set up and use. As easy as using a library, effectively, like an open source library. Paul: Yeah. We're running a little bit up on time here, so let's start to move into this last part which is like we want to tell people how they can get started. We did allude to it, like you said, Advait, here or there. But it's very easy to get started. This is open source. You can go on GitHub. If people just Google GitHub SuperTokens, it'll probably pop up, right? Advait: Correct. So that's the setup for the call. But yeah, it's super easy to get started. So with the CLI, you can get started in under five minutes. But even if you don't do that, even if you follow the quick setup that we have in the docs, our goal is for you to be able to finish that in under an hour. And a lot of people do that in 20 to 30 minutes. Paul: And that initial setup, is it sort of having that the most common password email authentication up and running with a core deployment? Advait: Correct. Paul: Awesome. You could get password email authentication on an open source code base plugins... Well, I guess you folks call them recipes, right? Recipe based already in 20 or 30 minutes. In general, the goal is to get everybody in under an hour. Advait: Yeah. The whole goal of this CLI tool that we have is to make that five minutes. Again, the goal is always to make it easier and easier, less terms that you need to understand, less steps that you need to do. So even last week, we removed one more step from the implementation process. So we're constantly working on even reducing that time for you. Paul: Are there any languages that you haven't tackled yet with the SDK or tooling that people are looking at? Advait: Yeah, both on the front end and backend side, yes. On the backend side, for example, we support Node, Golan and Python, all the Python frameworks. But we don't support, for example Java. We don't support PHP and Laravel, which are of common requests. And then on the front end side, we have pre-built UI. We give you UI components for React only. So if you are using Angular view, you can still use us. We still handle all the managing of the tokens and all of those things. We expose helper functions, but we don't actually give you the UI fine grain view. So that's again something that we'd be working on. Paul: So you got the logic but not the actual styling and phenotype to make it pop up. But at least the logic's there. So if you had it and you really want to use it, you can. It'll probably still be less building than doing it by yourself. Rishabh: You can even just inject our React library into an app and we have guides for that. So you can actually use the React components as well. Paul: Oh right. You can essentially transpose them on the fly, right? Little connector here. Rishabh: Yeah. And that [inaudible] as well. So just inject React and a React SDK on that one route, like the [inaudible] route for example. And that will give you the entire UI. React would only run on that particular route, no other route. So you get the pre-built UI as well as the optimized bundle size. So that works out. Paul: And just to direct people, so the docs, we keep bringing up the docs, this is on the SuperTokens website, which is a SuperTokens.com. Correct? Advait: Correct. Paul: Awesome. So if you want to go read the docs, find out more, head over to SuperTokens.com. Thank you for your time, guys, for coming on talking about this, talking about authentication. I definitely feel like it's one of those things that as most developers go through to your career you don't touch much because it kind of is a one and done type of thing. So having these low hanging fruits for people to look at recipes, hopefully it can be an educational path forward for people as well to learn about, well how does OAuth actually work? How do magic links actually work? Because I assume a lot of the recipes are open source as well. We can go look at them, right? Advait: A hundred percent of what we've built so far is all open source. Paul: That's beautiful. That's the way that we should all be moving with development. Thank you for doing that and thank you for your time, guys. Advait: Thank you so much. Thanks so much, Paul. Rishabh: Thank you.