Rishabh Poddar is the CTO and co-founder of SuperTokens, an open source user authentication service. Rishabh has always been fascinated with computers and began coding when he was 12 years old. Programming came easily to him, and he loved doing it, so he went to school for computer science and made it his career.

In this episode, we have a conversation about creating SuperTokens and how they work compared to other authentication techniques. Rishabh shares how to prevent impersonation, the architecture of SuperTokens, tips for JavaScript developers, and more.

Show Highlights:

  • Rishabh’s earliest memory with a computer.
  • Why he created an operating system from scratch.
  • What got Rishabh interested in authentication.
  • What a rotating refresh token is.
  • What SuperTokens core strength is.
  • How passwordless authentication works.
  • What cross origin resource sharing (CORS) is.
  • What the SuperTokens business model us.

Links:

Episode Transcript

Rishabh Poddar:
Yeah, absolutely. I mean I started coding when I was about 12 or 13 and that was basically because of my school. They had a class for computer science where they taught us Visual Basic.

Josh Birk:
That is Rishabh Poddar, CTO and co-founder of SuperTokens. I’m Josh Birk, your host of the Salesforce Developer podcast. And here on the podcast you’ll hear stories and insights from developers for developers. Today we’re going to sit down and talk with Rishabh about creating SuperTokens, how they work compared to other OAuth techniques, the whole thing’s this really cool open source project that I’m really happy to give a little bit of a mic to. So we’re going to start right where we left off there with Rishabh’s early years.

Rishabh Poddar:
And I initially realized I had a knack for programming basically, I understood most concepts fairly easily and I loved it so much that I was pretty sure that that’s something I wanted to do.

Josh Birk:
Nice.

Rishabh Poddar:
As the years passed by, I just explored different programming languages and I was lucky enough to have friends who were also in computer science, so it gets easier to learn with your peers. And that just kept me on until I got to college, did my bachelor’s in computer science over there. And sort of unlearned all the mistakes that I had realized that a lot of the things I learned on my own were mistakes and had to unlearn a lot of things before I learned the proper way of doing programming, building large systems, distributor systems and thinking from a more resiliency and theoretical point of view. So that helped a lot. Yeah.

Josh Birk:
Nice. What’s your earliest memory of the computer?

Rishabh Poddar:
Probably creating my email ID or playing a video game, one of the… Video games for sure. I mean I had Nintendo, Game Boy playing a video game and I used to really enjoy that. And then on an actual PC it was probably writing stuff for my school and then just the usual stuff, what people do. Yeah.

Josh Birk:
Well speaking of usual stuff that people do, I know that on your LinkedIn that you created an operating system from scratch and I have a couple questions on that, and the first one is why?

Rishabh Poddar:
Well, that was actually a college project, so that’s why.

Josh Birk:
Gotcha.

Rishabh Poddar:
It was a lot of fun. It was basically, I can’t even remember much of it now, but we had to code in C and C++ and we had to think about thread scheduling and it was obviously part of the operating system course, but I probably think that was the most fun project, and the project in which I learned the most.

Josh Birk:
Gotcha.

Rishabh Poddar:
Yeah.

Josh Birk:
I mean it’s everything, right? You kind of have to put a blank piece of paper in front of you and just start figuring out all the moving parts. I would figure that gets pretty complicated at some point.

Rishabh Poddar:
Oh yeah, it does, but luckily we didn’t have to make a UI or a GUI or-

Josh Birk:
Gotcha.

Rishabh Poddar:
A lot of the parts we had to focus on some of the thread scheduling part and file system.

Josh Birk:
Got it.

Rishabh Poddar:
But not networking and stuff like that. Yeah. Because again, it was just part of a course, so there was limited time and…

Josh Birk:
Right. Right. You weren’t trying to ship a Linux competitor or anything like that?

Rishabh Poddar:
Not really, no.

Josh Birk:
Okay. Well speaking of shipping, what got you in so interested in something like authentication that led you to want to co-found something like SuperTokens?

Rishabh Poddar:
So that’s a good question. So before SuperTokens, I was working on a consumer app and one of the requirements for that app was that the users should remain logged in essentially forever, just as consumer apps do. And I had this knack for security, where I would just keep thinking about edge cases about, oh, what happens if your session tokens are stolen? If you keep users logged in forever and the session tokens are stolen, then the attacker can basically become the user forever. And how do you prevent those kind of attacks? And then it turns out you can’t really… it’s impossible to prevent them because token theft can happen in many ways, but you can detect them. And then I started exploring about how we can detect them, and propose a solution that sort of used this thing called rotating refresh tokens to detect token theft.
And that actually worked well, and so I decided to write a blog post about it. And that blog post sort of went viral, because a lot of people… We got a couple of 100,000 views on it. And a couple of people started emailing us about how do you actually implement it, or do you have something out there which already implements this that we can use in their project. And that’s kind of where we pivoted from a consumer app to building session management for the apps. And that’s kind of where the authentication journey began.
At first, we weren’t really focus on the authentication part, we just focused on the session management part because we thought authentication was solved because there’s so many providers out there that people were using. So we just focused on session management, and that sort of got us into YCombinator, which is an accelerator and as founders do, just talking to a lot of people, talking to a lot of users or potential users. And what we learned is even though there are so many authentication providers, people still do not really like many of them because of various reasons, either the cost or the developer experience or the amount of customizability they offer, or just the control. And that sort of brought us to building an authentication solution that solves a lot of these pain points, and expanding from session management to authentication plus session management, which is what SuperTokens is.

Josh Birk:
Gotcha. Let’s dig into that a little bit. What do you mean by, and I can get an impression on it, but what do you mean by a rotating refresh token?

Rishabh Poddar:
Right. So when you log in, you essentially get back session tokens, and you get back an access token and a refresh token. The access token is typically short lived, like say one or two hours and the refresh token is longer lived, maybe a few days or a week or a month. Depends.

Josh Birk:
Right. And actually, let’s take a step back here because I think we are both assuming people understand a basic [inaudible 00:06:26]. So when I’ve logged in, I’ve given my credentials, the access token is the thing that tells the server, “This is me, I’m a legitimate user,” and it’s the thing that’s actually doing the interactions with what I should be allowed to do on the server, right?

Rishabh Poddar:
That’s correct. Yeah.

Josh Birk:
And then the refresh token is my way of getting new access token without having to go through all that loop.

Rishabh Poddar:
Yeah, without having to authenticate again basically.

Josh Birk:
Right. Okay. Back to you. Now, a rotating refresh token, go for that.

Rishabh Poddar:
Right. So just a normal refresh token would be that when your access token expires, you use the refresh token to get a new access token. But the rotating refresh token is when you use the refresh token to get back a new refresh token and a new access token and that ’cause the refresh token changes on each use, that’s why it’s called rotating refresh tokens. So that’s sort of what the concept is. And this allows you to detect refresh token theft, which in turn allows you to detect session hijacking.

Josh Birk:
And precisely how is it doing that? So I’m asking for a new refresh token and if I’ve stolen, and correct me if I’m wrong here, so if I steal your access token, I can impersonate you. If I steal your refresh token I can get a new access token. How does the rotating portion of a rotating refresh token keep me from doing that?

Rishabh Poddar:
Right. So let’s take an example. Let’s say you have the attacker and the victim. The victim has the session, the access and refresh token. Let’s call them A1 and R1.

Josh Birk:
Okay.

Rishabh Poddar:
I’m an attacker and I steal A1 and R1. So at some point A1 will expire, hopefully very soon. At that point in time, either the victim or the attacker would have to use R1 to get back new tokens. So let’s say the victim uses R1 first. At that point in time, the victim gets back a new access token and new refresh token, and let’s call it A2 and R2.

Josh Birk:
Okay.

Rishabh Poddar:
And at that point, R1 is sort of invalidated and then the attacker, when the attacker just has R1, he or she does not have R2 or A2. And if they use R1 when they want to use it, that’s sort of a signal to the server saying that R1 was already consumed before, the fact that it’s used again means that something is wrong and it just revokes the entire session. And yeah, that’s how it works.

Josh Birk:
Gotcha, gotcha. So in it sort of insists that it’s going to be a singular thread of a conversation between the original user and the server itself.

Rishabh Poddar:
Yes, exactly.

Josh Birk:
Got it. And tell me a little bit more about SuperTokens in general. Is that kind of its core strength or is there more to it?

Rishabh Poddar:
So that used to be the core strength when we just focus on sessions, but after that it’s not on one to develop experience being the core strength and the customizability that we offer, that being more important. So right now the core strength is essentially architecture, which is very different compared to other providers. So if you look at other OAuth providers, the way they work is you have an old server which also has the hosted UI on it. So I go to the old server domain, I see a login screen, the login screen interacts with APIs exposed by the old server, and at the end I get back an access token and a refresh token for my app to consume. Now if you’re using, for example, an old server in Java, for example, which other open source authentication providers exist with a Java backend, or if you’re using a SaaS based authentication solution, the problem with this architecture is that you lose control of customizability.
So if you want to modify, for example, the UI on the front end, you have to… The UI is controlled by the old server, so you have to go to the old server and change, upload an HTML template or building your own UI is very difficult in these situations. Or if you want to customize the backend APIs, then you have to modify or you have to either create webhooks for the old server to call you, or you have to upload code to the old server, which may be annoying because maybe you don’t use the language that the old server was built in.
Or it’s a different piece of software that you have to maintain outside of your main repo. So there are a few developer experience issues there. So what we do is we have more tightly integrated with your application. So we offer front end SDK, which gives you UI as react components, which you can embed on your website. We have a backend SDK which exposes all the APIs that the front end can call. And we have the SuperTokens score, which is a microservice that connects your database. Now the way it works is the front end SDK, when you click on the login button on the React component that we offer you, that calls an API on your API layer, and that API is exposed through the backend SDK middleware. And that API in turn calls the super token score, which talks to the database. So now if you want to make any customizations to the backend logic, it happens within your own API layer.
So whatever language you use, like NodeJS or Python or Golang, you can make customizations within those language… using those languages within your own API layer. There’s no separate code base that needs to be maintained, no effort needs to be created. Everything is fully typed and it’s very, very flexible in terms of the customization that you can make.
On the front end side, because it’s React components it’s sort of embedded in your website. So there’s no need for the user to leave your domain to go to the other domain and then redirect back. It’s native to your website so it’s better user experience. You can customize the React components in several ways, including colors and themes, but also just using JavaScript you can customize anything you like, because at the end of the day it’s just all JavaScript. So there’s a lot of flexibility that you get on the front end, and this architecture allows us to take care of session management as well, using [inaudible 00:12:29] cookies out of the box. So a lot of advantages to the architecture and this is what makes that different.

Josh Birk:
Got it. A few things on your blog that I thought were pretty interesting. I think that dovetails nicely into it. For instance, you describe how to do passwordless authentication, and I’m just going to take a guess that it makes it easier for a developer to go down these routes, because they’re kind of in complete control. So if they wanted to try something like a passwordless authentication, they’re doing it all within their domain and not two or three different ones, right?

Rishabh Poddar:
Absolutely, yeah. The front ends will be on their domain.com, call the API layer to generate the passwordless like Magic Link or OTP. They can also take control of how the email or SMS is sent. So we have a default implementation, but because within your own backend layer, the initialization function just takes a call back, send email with the Magic Link as an argument, and you can send the email how you like, with whatever template, right? There’s no restrictions there in terms of how the email is sent or what is sent. You can overlay almost anything.

Josh Birk:
And let’s cover that gap too. So how exactly does a passwordless flow work?

Rishabh Poddar:
The way we’ve implemented is that the user types in, let’s take Magic Links as an example.

Josh Birk:
Okay.

Rishabh Poddar:
So the user types in the email on the front end UI, clicks on send me an email, the backend receives an API call to create a passwordless code with the email as an input. And we generate a one time use short lived code, which gets embedded into a link. The link points to your front end domain, and that gets sent via email to the user. Now all of these parts are configurable. So what the link looks like, or what domain you want to send it to, how you want to send the SMS, lifetime of the link, all of that is super customizable. And when the user clicks the link on the email, it opens the browser and the front end SDK, again captures that route and extracts the code from link and sends that code to another API, which sort of consumes the code to create the user and SuperTokens, all of them.

Josh Birk:
Gotcha. And what are some of the advantages of doing that over the traditional username and password flow?

Rishabh Poddar:
So you have advantages more to do with the user experience and security, right? Well it is debatable, this is a debatable topic.

Josh Birk:
Yeah.

Rishabh Poddar:
It’s not absolutely clear. So the one is that there no passwords anymore. So users can’t use weak passwords or they never get their password, and then you have to go to the reset password flow. Now the reset password flow in a way is a very similar flow to the Magic Link login, right? So it sort of skips all that from user experience point of view. If you forget your password, it’s a good experience.
Sort of the disadvantage here is that you’re asking the users to leave your app and open another mail client. And if you’re trying to log through your browser on your desktop like PC and you get the mail on your mobile phone and then you click the link there, it opens the browser on your mobile phone and then you probably log in there, which is not what you wanted to do, right? That is the downside from the user experience point of view. And the argument against passwords is that if somebody using password managers, then arguably the experience for them is better with email and password compared to with Magic Links, because just quicker to log in, and password managers do a great job of generating secure passwords, and keeping track of them and stuff like that. So it’s debatable, but yeah.

Josh Birk:
Nice. Kind of taking it off to the side, how does something like SuperTokens work if I wanted to use social logins, if I did want to log in through a Google or something like that?

Rishabh Poddar:
So just like the passwordless flow, you have the UI on the front end which displays the buttons for the different login providers you want. And you have initialization on the backend as well, which is the backend SDK on your API layer where you given the credentials for your Google work, which you get from the Google dashboard. When the user picks the button on the front end, it generates the link with the [inaudible 00:16:51] google.com essentially where the user should be redirected to for sign in with Google, and the link has the configure scopes and the client ID and all of those things.
And then the user’s redirected to Google, and once the user signs in there Google sends them back to your app, and that route is again captured by a front end SDK. That URL on the route contains a query program called Code, which is an authorization code, it’s a one time use code sent by Google. The front end SDK takes the code and sends it to a backend API, and the backend API takes the code and along with the client secret that’s configured on the backend, it querys Google to get the access token and user profile information. And after the backend SDK has the use user profile information, it creates the user SuperTokens or logs them in. That’s the authorization code grant flow.

Josh Birk:
Got it.

Rishabh Poddar:
Yep.

Josh Birk:
Nice, nice. So let’s talk about something else you’ve written about on your blog. And it’s something that I think JavaScript developers in particular, they don’t have to worry about it until they do, and then once they do it’s this most infuriating thing that they run into. So for the uninitiated, describe to me what cross-origin resource sharing or CORS is.

Rishabh Poddar:
Yeah, that’s a classically annoying…

Josh Birk:
Why won’t my library load?

Rishabh Poddar:
Yeah. So earlier before CORS, browsers had a restriction where you could load resources only from the same domain as the one you’re visiting. So if you had a domain like example.com, you could essentially only query example.com on using JavaScript on that site. Now that obviously causes problems because if API is on api.example.com, then that’s not allowed based on… If CORS didn’t exists you couldn’t do that. And if CORS didn’t exist you couldn’t load fonts from Google or some other place. So that’s obviously a problem. So on the other hand, if they made it such that any domain could query any other domain, then you have security risks. Such that, if I’m logging to my bank and I have cookies on my bank’s API layer, then if I visit a malicious site, that malicious site could query the bank’s API and do actions on my behalf, and the cookies would get sent along as well, because browsers would allow that.
So browsers couldn’t keep it free for all, but they didn’t want to be super restrictive either. And that’s why CORS was sort of introduced. And what this allows you to do is define which domains are allowed to be queried from the front end, and the browser checks, decides whether or not to allow requests based on the CORS configuration that you have done. So the way this works is if my domain is example.com and I want to query a different domain like api.example.com, the browser will first send what we call a pre-flight request. This is an options API call to api.example.com in that the server, that’s api.example.com returns that, “Okay, example.com is allowed, I accept request from example.com.” And only then will the browser send the [inaudible 00:20:10] to the post or delete or whatever it is to api.example.com. Otherwise, it won’t send that request. So in this way your backend server essentially tells the browser that “This site, this front end is allowed to query me, allow that.”

Josh Birk:
Because if we go back to the start of the conversation, if everybody had access to everything, then I could easily be that guy stealing your access token and impersonating you, and then getting access to all your bank credentials. And there’s also a danger of trusting code from another server, right?

Rishabh Poddar:
Well yeah, it is. I mean there are different interpretations of this. If you go to the bank and malicious site example, the bank is api.somebank.com and if you go to malicious.com in this case, and if malicious.com queries api.bank.com, the bank is not going to have malicious site as it’s allowed origins. So the browser’s going to reject that particular request from going in the first place. This is where the CORS sort of kicks in. About trusting code, I’m not sure What do you mean by…

Josh Birk:
Well, so for instance, if I am pulling in code from like, oh God, I’m going to date myself so wonderfully here, let’s say I’m just going to pull in jQuery from a third party site, right? And so now my code is dependent on that library working as intended, but if somebody on jquery.com decided to basically keep the interface the same but change a whole bunch of stuff, it’s like now I’m at the mercy of whoever it was, I don’t know if they’re still using jquery.com, but whatever that person’s doing on that site, basically.

Rishabh Poddar:
Yeah. Yeah, that’s true. So that’s a classic way of introducing XXS attacks on your website. So if someone on jQuery’s, wherever you’re importing your script, if the script has some malicious code in it, it will run on your app if you get the JavaScript from there. And that’s where things like issuing a cookie for session tokens come into the picture, right? Because issuing cookies are basically a browser storage mechanism, where the browser stores those tokens or such that the JavaScript cannot access them, but the browser injects those tokens in the relevant API calls, which is why they’re recommended as a way of storing and managing session tokens.

Josh Birk:
Gotcha. Nice. Let’s take a couple steps back because I’m kind of curious. I think this is something that’s come up. It comes up a lot in the tech industry. SuperTokens, it’s open source and free for developers to use, correct?

Rishabh Poddar:
Mm-hmm. Yep.

Josh Birk:
What’s-

Rishabh Poddar:
With the current feature set, yeah.

Josh Birk:
Okay. So I think that’s the follow-up question then. What does the business model look like for you?

Rishabh Poddar:
So a couple of things. One, we have a manage service offering, where we host the Super Token score for you. And that’s priced based on the number of end users that you have in your app.

Josh Birk:
Gotcha.

Rishabh Poddar:
We also plan on having a few features for advanced use of different authentication requirements, which will be part of, not the open source project, but sort of the feature gated with a subscription behind it. So even if you sell for SuperTokens, you would have to pay for those features. And that’s where we hope the business evolves.

Josh Birk:
What kind of features are those?

Rishabh Poddar:
So obviously this keeps changing over time, but right now stuff like multitenancy and someone’s security stuff related to… So some of it like logging, for example, log retention and IP white listing for the call, and some features like automatic account linking, which can be fairly complex to implement. So stuff like that. Yeah.

Josh Birk:
So that makes a lot of sense, because it’s like if you’re a developer and you want to use your own resources to do things like tracking your logs and stuff like that, and multitenancy obviously requires some iron thrown behind it, great, but if you would like for us to take care of that for you then you’re at the table.

Rishabh Poddar:
And the really nice thing about SuperTokens and the architecture is that if you want these features and don’t want to pay us for it, that’s also possible. Because you can customize the pack and SDK functions to implement these features yourself on top of the open source stuff. And so there’s nothing stopping you from doing that.

Josh Birk:
Got it. Nice. Now you do have a wildly informative blog and we could probably spend another two or three hours getting into some of the information you have on there. We will definitely link that to the show notes. But if people want to kind of get up and running with SuperTokens, how would they do that?

Rishabh Poddar:
The easiest ways through the CLI that we have. So basically NPX creates SuperTokens app, and when you run that in a terminal, it asks you for your tech stack. So what is your front end, what is your backend, and what kind of login methods do you want? So do you want email password or do you want social, or do you want a combination of these or do you want passwordless? And when you select the different options, it generates a fully working application based on the front end backend that you selected. And you can sort of inspect that, the code generated there to see how it works, or copy that over into your project. So that’s the easiest way of getting started. But if that doesn’t work or if you want to go step by step, then we have guides for each of these login methods as well for your tech stack, which you can follow along and add it to your app.

Josh Birk:
And that’s our show. Now before we go, I did ask Rishabh’s favorite non-technical hobby and it is, well one that we share.

Rishabh Poddar:
I think I mentioned that [inaudible 00:25:56], but I like my video games a lot. So I do spend some time on the weekends doing that and recently, well not recently, but in the last one or two years I started working out quite a bit. So that helps maintain health.

Josh Birk:
Yep, yep.

Rishabh Poddar:
And yeah, these two things.

Josh Birk:
[inaudible 00:26:16] What are you playing lately?

Rishabh Poddar:
Right now I’m playing this… Well recently the new version of Pokemon came out, so that’s something I like. And there’s a game called Stray on the PS4 and five.

Josh Birk:
Yes. Yes. It is sitting on my hard drive waiting for me to start it because I can’t start it until I finish Breath of the Wild, which I’m about 230 hours into at this point.

Rishabh Poddar:
Oh wow.

Josh Birk:
I’m milking that thing for everything I can. Yeah.

Rishabh Poddar:
That game is really cool. I mean it’s also because I like cats, so that was the primary motivation to get that game. But yeah, it’s pretty cool.

Josh Birk:
I want to thank Rishabh for the great conversation, information, and as always I want to thank you for listening. Now, if you want to learn more about this show, head on over to developer.salesforce.com/podcast where you can hear old episodes, see the show notes, and have links to your favorite podcast service. Thanks again everybody, and I’ll talk to you next week.

 Get notified of new episodes with the new Salesforce Developers Slack app.