1
00:00:00,191 --> 00:00:05,573
[SPEAKER_00] So before we jump into today's deep dive, I really want to mention the supporter of today's show safe server.

2
00:00:06,193 --> 00:00:15,217
[SPEAKER_00] Because, well, if you're building software right now, you know, the landscape is utterly dominated by these really expensive proprietary tools.

3
00:00:15,417 --> 00:00:20,062
[SPEAKER_01] Right, things like Auth or AWS Cognito, Google Firebase.

4
00:00:20,162 --> 00:00:20,582
[SPEAKER_00] Exactly.

5
00:00:20,883 --> 00:00:27,429
[SPEAKER_00] And Safe Server is entirely focused on replacing those costly black boxes with open source solutions.

6
00:00:28,010 --> 00:00:35,217
[SPEAKER_00] I mean, when you look at the long-term scaling costs, the financial difference of switching away from big vendors is absolutely staggering.

7
00:00:35,430 --> 00:00:35,690
[SPEAKER_01] Yeah.

8
00:00:35,830 --> 00:00:38,471
[SPEAKER_01] And there's also a massive compliance angle here too, right?

9
00:00:38,491 --> 00:00:41,332
[SPEAKER_01] Because authentication isn't just about logging in.

10
00:00:41,412 --> 00:00:45,474
[SPEAKER_01] You are handling passwords, personal emails, session tokens.

11
00:00:45,774 --> 00:00:53,797
[SPEAKER_01] And depending on your industry, you might be facing incredibly strict legal and regulatory requirements around like data protection or financial records, audit trails.

12
00:00:53,937 --> 00:00:55,758
[SPEAKER_00] Which is exactly where data sovereignty comes in.

13
00:00:56,298 --> 00:01:02,162
[SPEAKER_00] Because if your user's data lives on, say, an AWS server in a jurisdiction you don't control, you don't really control the data.

14
00:01:02,363 --> 00:01:03,143
[SPEAKER_00] No, not at all.

15
00:01:03,323 --> 00:01:11,770
[SPEAKER_00] So Safe Server helps organizations, whether you're a startup, a business, or an association, find and implement the right open source authentication solutions.

16
00:01:12,610 --> 00:01:18,635
[SPEAKER_00] They guide you from the initial consulting strategy all the way to operating the software on secure servers located right in the EU.

17
00:01:18,860 --> 00:01:20,843
[SPEAKER_01] That's a huge deal for Peace of Mind.

18
00:01:20,963 --> 00:01:21,464
[SPEAKER_00] It really is.

19
00:01:21,945 --> 00:01:26,913
[SPEAKER_00] You can explore how they can help your organization at www.safeserver.de.

20
00:01:29,231 --> 00:01:31,733
[SPEAKER_00] So, welcome to today's Deep Dive, everyone.

21
00:01:32,113 --> 00:01:38,878
[SPEAKER_00] Our mission today is to give you a really beginner-friendly, under-the-hood look at a tool to try to decentralize digital identity.

22
00:01:39,138 --> 00:01:40,179
[SPEAKER_00] It's called SuperTokens.

23
00:01:40,219 --> 00:01:52,228
[SPEAKER_01] Yeah, and we are pulling directly from the official SuperTokens documentation, their architecture blueprints, and we've even been analyzing the raw code in their GitHub repository, specifically the SuperTokens core repo.

24
00:01:52,508 --> 00:01:52,728
[SPEAKER_00] Right.

25
00:01:53,169 --> 00:01:54,009
[SPEAKER_00] OK, let's unpack this.

26
00:01:54,430 --> 00:01:57,272
[SPEAKER_00] Why is user authentication such a massive headache in the first place?

27
00:01:57,312 --> 00:01:59,874
[SPEAKER_00] I mean, it affects user experience, developer experience, security.

28
00:02:00,174 --> 00:02:03,537
[SPEAKER_00] It feels like something we should have standardized like 20 years ago.

29
00:02:03,777 --> 00:02:04,798
[SPEAKER_01] You would think so, wouldn't you?

30
00:02:05,659 --> 00:02:09,262
[SPEAKER_01] But it remains a massive headache because the target is constantly moving.

31
00:02:10,083 --> 00:02:14,646
[SPEAKER_01] And the philosophy we see throughout the SuperToken's documentation highlights this core tension.

32
00:02:14,906 --> 00:02:15,147
[SPEAKER_00] Right.

33
00:02:15,287 --> 00:02:21,372
[SPEAKER_01] Like, let's say you're a developer and you decide to hand roll your own authentication from scratch just to keep control.

34
00:02:21,760 --> 00:02:29,249
[SPEAKER_00] I feel like every time a developer says, I'll just write my own crypto, a security engineer somewhere just wakes up in a cold sweat.

35
00:02:29,309 --> 00:02:29,950
[SPEAKER_01] Oh, absolutely.

36
00:02:30,010 --> 00:02:36,999
[SPEAKER_01] Unless you are a dedicated cryptographer, hand rolling your auth almost inevitably leads to critical flaws.

37
00:02:37,099 --> 00:02:38,060
[SPEAKER_00] Like what, for example?

38
00:02:38,615 --> 00:02:42,456
[SPEAKER_01] Well, developers might forget to properly salt their passwords, for one.

39
00:02:43,157 --> 00:02:49,979
[SPEAKER_01] Salting is the mechanism where you add a unique string of random data to each user's password before you mathematically scramble or hash it.

40
00:02:50,039 --> 00:02:51,220
[SPEAKER_00] Right, to make it unique.

41
00:02:51,380 --> 00:02:51,960
[SPEAKER_01] Exactly.

42
00:02:52,320 --> 00:02:59,182
[SPEAKER_01] And if you don't do that, hackers can use pre-computed tables of common passwords to crack your database in literally seconds.

43
00:02:59,202 --> 00:03:06,105
[SPEAKER_01] Or maybe a developer misconfigures the secure flags on session cookies, leaving users vulnerable to session hijacking.

44
00:03:06,225 --> 00:03:09,006
[SPEAKER_00] So basically building it yourself is a total minefield.

45
00:03:09,467 --> 00:03:10,027
[SPEAKER_01] It really is.

46
00:03:10,127 --> 00:03:12,668
[SPEAKER_00] And that pushes developers to the other extreme, right?

47
00:03:12,708 --> 00:03:16,550
[SPEAKER_00] They go to a giant corporation and essentially say, Hey, can I rent a bank vault?

48
00:03:17,190 --> 00:03:20,171
[SPEAKER_00] You get the security, but the landlord keeps the master key.

49
00:03:20,331 --> 00:03:22,913
[SPEAKER_01] Which creates massive vendor lock-in.

50
00:03:23,053 --> 00:03:23,653
[SPEAKER_00] Exactly.

51
00:03:24,073 --> 00:03:30,976
[SPEAKER_00] So looking at the super tokens architecture, how do they actually provide the vault and let you keep the master key?

52
00:03:31,096 --> 00:03:32,237
[SPEAKER_00] Like how are they solving this?

53
00:03:32,635 --> 00:03:39,817
[SPEAKER_01] So they've engineered an open core Y Combinator-backed alternative, and their foundational promise is on-premises deployment.

54
00:03:40,017 --> 00:03:41,077
[SPEAKER_00] OK, so you run it yourself.

55
00:03:41,317 --> 00:03:41,517
[SPEAKER_01] Right.

56
00:03:41,597 --> 00:03:47,579
[SPEAKER_01] You deploy it on your infrastructure, connect it to your own database, meaning you own 100% of your user data.

57
00:03:48,159 --> 00:03:53,861
[SPEAKER_01] But to make this manageable, they completely decoupled the architecture into three distinct building blocks.

58
00:03:53,901 --> 00:03:59,162
[SPEAKER_00] OK, break those blocks down for me, because if I'm looking at a standard web app, I usually just think, well, front end and back end.

59
00:03:59,483 --> 00:03:59,723
[SPEAKER_01] Sure.

60
00:04:00,283 --> 00:04:02,484
[SPEAKER_01] Super Tokens uses a similar starting point.

61
00:04:02,684 --> 00:04:05,244
[SPEAKER_01] So block number one is the front-end SDK.

62
00:04:05,684 --> 00:04:09,385
[SPEAKER_01] This is the code living in the user's browser or on their mobile app.

63
00:04:09,645 --> 00:04:13,906
[SPEAKER_01] It renders the actual login UI and manages the session tokens on the client side.

64
00:04:14,346 --> 00:04:22,267
[SPEAKER_01] And they provide pre-built, highly customizable UI widgets so you can literally get a login screen running in like five minutes.

65
00:04:22,307 --> 00:04:22,527
[SPEAKER_00] Wow.

66
00:04:22,607 --> 00:04:22,827
[SPEAKER_00] Okay.

67
00:04:22,847 --> 00:04:23,687
[SPEAKER_00] Which is great for speed.

68
00:04:24,127 --> 00:04:26,808
[SPEAKER_00] So the user clicks login on the front-end SDK.

69
00:04:26,908 --> 00:04:27,548
[SPEAKER_00] What happens next?

70
00:04:27,931 --> 00:04:31,252
[SPEAKER_01] The request goes to block two, which is the backend SDK.

71
00:04:31,712 --> 00:04:38,294
[SPEAKER_01] This sits directly inside your existing server application, whether your team writes in Node.js, Python, Go, Ruby, whatever.

72
00:04:38,935 --> 00:04:45,517
[SPEAKER_01] This SDK intercepts the login request and provides the APIs for sign up, sign in, and refreshing sessions.

73
00:04:45,537 --> 00:04:46,057
[SPEAKER_00] Wait, hold on.

74
00:04:46,517 --> 00:04:52,628
[SPEAKER_00] If I'm a new developer, having a frontend taking the credentials and a backend receiving them, that sounds like a complete app.

75
00:04:52,989 --> 00:04:54,451
[SPEAKER_00] But you said there are three blocks.

76
00:04:54,631 --> 00:04:56,915
[SPEAKER_00] Why split the core from the backend SDK?

77
00:04:56,935 --> 00:04:58,298
[SPEAKER_00] That just sounds overly complicated.

78
00:04:58,857 --> 00:05:06,422
[SPEAKER_01] Well, what's fascinating here is that the specific decoupling is the secret to their flexibility because block three is the super tokens core.

79
00:05:06,842 --> 00:05:17,169
[SPEAKER_01] This is a completely separate standalone HTTP service and the super tokens core handles all the heavy lifting, the complex cryptographic logic, reading and writing to your database.

80
00:05:17,610 --> 00:05:20,431
[SPEAKER_01] Your backend SDK simply talks to this core service.

81
00:05:21,032 --> 00:05:25,615
[SPEAKER_01] You can actually use super tokens for just log in, just session management or both.

82
00:05:25,992 --> 00:05:28,533
[SPEAKER_00] I mean, if I can play devil's advocate here for a second.

83
00:05:29,013 --> 00:05:39,856
[SPEAKER_00] If I'm running a lean, agile startup, the moment you tell me I have to deploy and maintain a completely separate standalone core service just to let my users log in, my alarm bells are ringing.

84
00:05:40,416 --> 00:05:41,636
[SPEAKER_01] That's a common reaction.

85
00:05:41,736 --> 00:05:41,976
[SPEAKER_00] Right.

86
00:05:42,316 --> 00:05:44,137
[SPEAKER_00] Because that sounds like a DevOps nightmare.

87
00:05:44,697 --> 00:05:47,958
[SPEAKER_00] Why not just bake the database logic right into the backend SDK?

88
00:05:48,188 --> 00:05:49,489
[SPEAKER_01] It's a very valid concern.

89
00:05:50,089 --> 00:05:52,310
[SPEAKER_01] But think about modern company infrastructure.

90
00:05:52,670 --> 00:05:55,211
[SPEAKER_01] You rarely just have one backend anymore, do you?

91
00:05:55,251 --> 00:05:55,731
[SPEAKER_00] Well, yeah.

92
00:05:55,891 --> 00:05:56,571
[SPEAKER_00] I guess that's true.

93
00:05:56,792 --> 00:06:05,335
[SPEAKER_01] You might have a Node server handling your web app, a Python server running your AI features, and maybe a Go server handling real-time chat.

94
00:06:05,755 --> 00:06:06,315
[SPEAKER_00] Ah, right.

95
00:06:06,475 --> 00:06:07,376
[SPEAKER_00] Microservices.

96
00:06:07,496 --> 00:06:08,096
[SPEAKER_01] Exactly.

97
00:06:08,476 --> 00:06:15,859
[SPEAKER_01] If the auth logic was baked directly into the backend, you'd have to implement and synchronize complex database operations across Node, Python, and Go.

98
00:06:16,179 --> 00:06:17,020
[SPEAKER_01] It'd be a mess.

99
00:06:17,220 --> 00:06:17,500
[SPEAKER_00] Awful.

100
00:06:17,820 --> 00:06:27,385
[SPEAKER_01] By pulling the heavy security logic out into one central supertokens core, your microservices don't need to know how to hash passwords or query user tables.

101
00:06:27,425 --> 00:06:28,526
[SPEAKER_01] They just ping the core.

102
00:06:28,626 --> 00:06:30,087
[SPEAKER_01] It gives you a single source of truth.

103
00:06:30,818 --> 00:06:32,359
[SPEAKER_00] OK, that actually makes a lot of sense.

104
00:06:32,419 --> 00:06:35,602
[SPEAKER_00] You centralized the dangerous critical code in one place.

105
00:06:36,743 --> 00:06:44,869
[SPEAKER_00] But speaking of that centralized code, I was digging through the super tokens core repository on GitHub and I noticed something that honestly made me do a double take.

106
00:06:45,209 --> 00:06:45,610
[SPEAKER_01] Oh, yeah.

107
00:06:45,790 --> 00:06:46,290
[SPEAKER_01] What was that?

108
00:06:46,530 --> 00:06:51,674
[SPEAKER_00] The core service is written in Java, like the repost ads show it's ninety eight point four percent Java.

109
00:06:51,814 --> 00:06:52,035
[SPEAKER_01] Right.

110
00:06:52,255 --> 00:06:52,455
[SPEAKER_01] Yes.

111
00:06:52,795 --> 00:06:57,681
[SPEAKER_00] And in the world of fast moving, trendy startups, Java often gets a bad rap, right?

112
00:06:58,142 --> 00:07:00,545
[SPEAKER_00] People view it as legacy, heavy, bloated.

113
00:07:01,166 --> 00:07:06,172
[SPEAKER_00] Why on earth would a modern YC backed startup choose Java for their core product?

114
00:07:06,444 --> 00:07:12,909
[SPEAKER_01] Yeah, the developers actually address this exact question in their documentation, and their rationale is incredibly pragmatic.

115
00:07:13,069 --> 00:07:13,369
[SPEAKER_01] Oh, so.

116
00:07:13,749 --> 00:07:19,434
[SPEAKER_01] When you're building a foundational security product, you really don't want to be experimenting with the newest, trendiest programming language.

117
00:07:19,554 --> 00:07:22,476
[SPEAKER_01] You want a massive, mature, battle-tested ecosystem.

118
00:07:22,776 --> 00:07:26,658
[SPEAKER_00] OK, so security needs to be boring, like in the best possible way.

119
00:07:26,858 --> 00:07:27,539
[SPEAKER_01] Precisely.

120
00:07:27,879 --> 00:07:31,361
[SPEAKER_01] Java has been hammered by global enterprise usage for over two decades.

121
00:07:31,761 --> 00:07:39,665
[SPEAKER_01] Additionally, Java's strong static typing system catches a massive class of bugs at compile time before the code ever even runs.

122
00:07:39,785 --> 00:07:41,246
[SPEAKER_00] Right, which is huge for security.

123
00:07:41,446 --> 00:07:41,886
[SPEAKER_01] Exactly.

124
00:07:42,327 --> 00:07:46,550
[SPEAKER_01] When you're managing cryptographic keys and user identities, fewer bugs are non-negotiable.

125
00:07:46,710 --> 00:07:57,217
[SPEAKER_01] Plus, from a company-building perspective, finding highly experienced Java developers to scale their team is just much easier than hunting for engineers fluent in, like, super-niche systems languages.

126
00:07:57,898 --> 00:08:00,299
[SPEAKER_00] I completely buy the security and hiring arguments.

127
00:08:00,459 --> 00:08:00,920
[SPEAKER_00] I really do.

128
00:08:01,805 --> 00:08:03,207
[SPEAKER_00] But what about performance critique?

129
00:08:03,527 --> 00:08:07,592
[SPEAKER_00] I mean, the classic complaint about Java is that it's an absolute memory hog.

130
00:08:08,093 --> 00:08:14,200
[SPEAKER_00] If I'm self-hosting this, I don't want to spin up a massive, expensive AWS instance just to run my login core.

131
00:08:14,501 --> 00:08:16,964
[SPEAKER_00] Doesn't that defeat the whole purpose of escaping big vendors?

132
00:08:17,296 --> 00:08:19,537
[SPEAKER_01] This is where their architectural choices really shine.

133
00:08:19,897 --> 00:08:22,077
[SPEAKER_01] And it goes back to that three block system.

134
00:08:22,297 --> 00:08:24,838
[SPEAKER_01] Think about how authentication actually works in practice.

135
00:08:25,218 --> 00:08:29,579
[SPEAKER_01] Logging in like, typing a password and hashing it is actually a very rare event.

136
00:08:29,699 --> 00:08:31,320
[SPEAKER_01] A user does it maybe once a month.

137
00:08:31,520 --> 00:08:33,561
[SPEAKER_00] Right, they log in and then they just stay logged in.

138
00:08:33,701 --> 00:08:34,201
[SPEAKER_01] Exactly.

139
00:08:34,501 --> 00:08:38,502
[SPEAKER_01] The most frequent operation by far is session verification.

140
00:08:38,962 --> 00:08:47,091
[SPEAKER_01] Every single time a user clicks a link, updates their profile, or loads a private image, the system has to verify that their session is still valid.

141
00:08:48,093 --> 00:08:56,122
[SPEAKER_01] If the Super Tokens Jamacore had to process every single one of those verification checks over the network, it would absolutely become a bottleneck.

142
00:08:56,162 --> 00:08:58,064
[SPEAKER_01] And yeah, it would require a massive server.

143
00:08:58,555 --> 00:08:59,755
[SPEAKER_00] So how do they avoid that?

144
00:08:59,775 --> 00:09:01,036
[SPEAKER_00] Do they cache it or something?

145
00:09:01,176 --> 00:09:09,818
[SPEAKER_01] No, they use a mechanism where verification happens entirely within the backend SDK like in Node, Go, or Python without ever contacting the Java core.

146
00:09:09,898 --> 00:09:14,739
[SPEAKER_00] Wait, if the backend SDK doesn't talk to the core, how does it know the user isn't an imposter?

147
00:09:15,159 --> 00:09:20,800
[SPEAKER_01] It all comes down to JSON web tokens or GWTs and cryptographic signatures.

148
00:09:21,240 --> 00:09:24,461
[SPEAKER_01] Think of the Java core like an embassy issuing a passport.

149
00:09:24,779 --> 00:09:25,760
[SPEAKER_00] OK, I like that analogy.

150
00:09:25,980 --> 00:09:31,924
[SPEAKER_01] When you log in, the core verifies your identity and issues a passport, the JWT.

151
00:09:32,664 --> 00:09:35,086
[SPEAKER_01] This token has a mathematical signature stamped on it.

152
00:09:35,486 --> 00:09:39,169
[SPEAKER_01] Now, your backend SDK acts like the border guard.

153
00:09:39,489 --> 00:09:39,689
[SPEAKER_00] Right.

154
00:09:40,089 --> 00:09:43,372
[SPEAKER_01] When a user tries to access a page, they present that passport.

155
00:09:43,932 --> 00:09:48,095
[SPEAKER_01] The border guard doesn't need to call the embassy every single time to ask if the passport is real.

156
00:09:48,567 --> 00:09:49,788
[SPEAKER_00] because they can just check the stamp.

157
00:09:50,008 --> 00:09:50,488
[SPEAKER_01] Exactly.

158
00:09:51,089 --> 00:09:56,553
[SPEAKER_01] They have the public key, the mathematical formula, to verify the embassy signature right there on the spot.

159
00:09:57,153 --> 00:10:01,996
[SPEAKER_01] Because the back-end SDK can verify the math locally, it takes less than a millisecond.

160
00:10:02,497 --> 00:10:04,238
[SPEAKER_01] And the Java core never even hears about it.

161
00:10:04,498 --> 00:10:04,838
[SPEAKER_00] Oh, wow.

162
00:10:05,079 --> 00:10:10,063
[SPEAKER_00] So they've effectively outsourced the heaviest processing burden directly to the client's own servers.

163
00:10:10,603 --> 00:10:13,526
[SPEAKER_00] That completely flips traditional backend scaling on its head.

164
00:10:13,826 --> 00:10:14,507
[SPEAKER_01] It really does.

165
00:10:14,927 --> 00:10:22,594
[SPEAKER_01] Because the core isn't bogged down verifying every click, a single lightweight instance of the Java core can handle tens of thousands of users easily.

166
00:10:22,694 --> 00:10:23,294
[SPEAKER_00] That's incredible.

167
00:10:23,354 --> 00:10:23,594
[SPEAKER_01] Yeah.

168
00:10:23,874 --> 00:10:28,976
[SPEAKER_01] And to optimize the Java footprint itself, they don't use massive enterprise application servers.

169
00:10:28,996 --> 00:10:32,238
[SPEAKER_01] They use an embedded Tomcat server, which is really stripped down.

170
00:10:32,598 --> 00:10:35,219
[SPEAKER_01] And they also plan to use Graal VM in the future.

171
00:10:35,639 --> 00:10:36,379
[SPEAKER_00] Graal VM.

172
00:10:36,639 --> 00:10:41,461
[SPEAKER_00] For the listener who isn't deep into the Java ecosystem, what does Graal VM actually do?

173
00:10:41,701 --> 00:10:45,923
[SPEAKER_01] So usually Java runs on a virtual machine that translates code on the fly.

174
00:10:46,515 --> 00:10:49,437
[SPEAKER_01] That requires a decent amount of RAM just to keep the engine running.

175
00:10:49,717 --> 00:10:56,961
[SPEAKER_01] GrelVM is a modern technology that takes that Java code and pre-compiles it directly down into a native machine executable.

176
00:10:57,362 --> 00:10:59,143
[SPEAKER_00] Oh, so it just runs directly on the hardware.

177
00:10:59,363 --> 00:10:59,903
[SPEAKER_01] Exactly.

178
00:11:00,023 --> 00:11:04,346
[SPEAKER_01] It allows the program to start instantly and sift memory like a lightweight language.

179
00:11:04,766 --> 00:11:08,409
[SPEAKER_01] SuperTokens projects this could reduce the core's memory footprint by up to 95%.

180
00:11:09,353 --> 00:11:11,817
[SPEAKER_00] A 95% memory reduction is wild.

181
00:11:11,917 --> 00:11:19,349
[SPEAKER_00] Okay, so the engine under the hood is mathematically clever, it scales, it's lightweight, but knowing the engine is solid is only half the battle, right?

182
00:11:19,730 --> 00:11:20,892
[SPEAKER_00] Here's where it gets really interesting.

183
00:11:21,212 --> 00:11:22,414
[SPEAKER_00] What can you actually build with it?

184
00:11:22,434 --> 00:11:23,977
[SPEAKER_00] Like, what's the out of the box feature set?

185
00:11:24,369 --> 00:11:28,111
[SPEAKER_01] Well, the feature set is remarkably comprehensive for an open source tool.

186
00:11:28,491 --> 00:11:31,193
[SPEAKER_01] They aren't just giving you a basic email and password form.

187
00:11:31,633 --> 00:11:34,335
[SPEAKER_01] They provide passwordless login via magic links.

188
00:11:34,575 --> 00:11:36,736
[SPEAKER_01] They have full social login support.

189
00:11:36,776 --> 00:11:39,398
[SPEAKER_01] So, you know, continue with Google, Apple, GitHub.

190
00:11:39,538 --> 00:11:39,838
[SPEAKER_00] Nice.

191
00:11:40,158 --> 00:11:46,182
[SPEAKER_01] And they include natively built multi-factor authentication, which is basically a mandatory compliance requirement now.

192
00:11:46,765 --> 00:11:51,291
[SPEAKER_00] And looking through their documentation, they also heavily highlight multi-tenancy.

193
00:11:51,551 --> 00:11:55,456
[SPEAKER_01] Yes, which is a massive differentiator for B2B software.

194
00:11:55,857 --> 00:11:59,842
[SPEAKER_01] Multi-tenancy is what allows you to offer enterprise single sign-on or SSO.

195
00:12:00,732 --> 00:12:05,273
[SPEAKER_00] Let's pause on SSL because I feel like users see it all the time but might not realize how complex it is.

196
00:12:05,893 --> 00:12:13,195
[SPEAKER_00] This is when you try to log into a software tool and it redirects you to your company's internal Microsoft or Okta login page, right?

197
00:12:13,375 --> 00:12:13,875
[SPEAKER_01] Exactly.

198
00:12:14,395 --> 00:12:24,037
[SPEAKER_01] If you build an app and try to sell it to a Fortune 500 company, their IT department will absolutely demand that their employees log in using the company's existing corporate credentials.

199
00:12:24,477 --> 00:12:28,918
[SPEAKER_01] Building the SAMALO or OIDC protocols to connect your database securely

200
00:12:29,338 --> 00:12:33,682
[SPEAKER_01] to a massive corporation's active directory is notoriously painful.

201
00:12:34,182 --> 00:12:42,609
[SPEAKER_01] But supertokens having multi-tenancy built in means you can compartmentalize different enterprise clients within the same instance securely.

202
00:12:43,029 --> 00:12:48,694
[SPEAKER_00] It's like having one apartment building, but every tenant gets their own highly customized security system.

203
00:12:48,814 --> 00:12:49,935
[SPEAKER_01] That's a great way to put it.

204
00:12:50,035 --> 00:12:53,958
[SPEAKER_00] And speaking of customization, they have a really interesting approach to adding features.

205
00:12:54,399 --> 00:12:56,040
[SPEAKER_00] You don't have to rewrite the core code.

206
00:12:56,496 --> 00:12:56,716
[SPEAKER_01] Right.

207
00:12:56,756 --> 00:12:59,798
[SPEAKER_01] They use a highly modular plugins architecture.

208
00:13:00,058 --> 00:13:00,238
[SPEAKER_00] Yeah.

209
00:13:00,258 --> 00:13:02,440
[SPEAKER_00] The way I visualize this is like having a smartphone.

210
00:13:02,920 --> 00:13:05,021
[SPEAKER_00] The super tokens core is the operating system.

211
00:13:05,622 --> 00:13:10,925
[SPEAKER_00] But if you suddenly need your phone to, I don't know, scan QR codes, you don't rewrite the OS.

212
00:13:10,945 --> 00:13:11,946
[SPEAKER_00] You just download an app.

213
00:13:12,066 --> 00:13:15,088
[SPEAKER_00] Their plugins act exactly like apps for your authentication core.

214
00:13:15,704 --> 00:13:16,585
[SPEAKER_01] Perfect analogy.

215
00:13:16,905 --> 00:13:18,486
[SPEAKER_01] The plugins are entirely modular.

216
00:13:18,506 --> 00:13:25,871
[SPEAKER_01] So if your platform suddenly gets targeted by automated bots trying to brute force your login page, you don't panic and rewrite your front end.

217
00:13:26,111 --> 00:13:27,132
[SPEAKER_00] You just snap in a plugin.

218
00:13:27,512 --> 00:13:27,992
[SPEAKER_01] Exactly.

219
00:13:28,012 --> 00:13:34,717
[SPEAKER_01] You just snap in their Capshot plugin, which natively integrates things like recap TCHA or Cloudflare turnstile.

220
00:13:35,137 --> 00:13:36,898
[SPEAKER_01] They have plugins for user banning.

221
00:13:37,218 --> 00:13:43,743
[SPEAKER_01] So an admin can instantly revoke a bad actor's access everywhere and plugins for tenant discovery interfaces.

222
00:13:44,117 --> 00:13:49,440
[SPEAKER_00] It's one thing to read a list of features, but the real-world examples they share really prove its value.

223
00:13:49,800 --> 00:13:54,563
[SPEAKER_00] There's a fascinating story in the sources about Poppy, which is a Belgian ride-sharing company.

224
00:13:54,703 --> 00:13:55,103
[SPEAKER_01] Oh, yeah.

225
00:13:55,163 --> 00:13:58,145
[SPEAKER_01] Ride-sharing apps are incredibly lucrative targets for fraud.

226
00:13:58,445 --> 00:13:59,326
[SPEAKER_00] Huge targets.

227
00:13:59,646 --> 00:14:04,869
[SPEAKER_00] You have bad actors creating fake accounts to take free rides, testing stolen credit cards, you name it.

228
00:14:05,529 --> 00:14:09,612
[SPEAKER_00] Poppy decided to switch their entire authentication system over to supertokens.

229
00:14:10,152 --> 00:14:11,835
[SPEAKER_00] and they managed to do it in just one day.

230
00:14:11,855 --> 00:14:13,238
[SPEAKER_01] Wow, one day?

231
00:14:13,258 --> 00:14:19,990
[SPEAKER_00] Yeah, and by locking down their off-flow, they eliminated thousands of euros in daily fraud in a single afternoon.

232
00:14:20,240 --> 00:14:23,021
[SPEAKER_01] That really validates their claim of the five-minute setup.

233
00:14:23,361 --> 00:14:30,003
[SPEAKER_01] When an API is logically designed, swapping out an old, leaky system doesn't have to be a six-month engineering saga.

234
00:14:30,323 --> 00:14:30,763
[SPEAKER_00] Exactly.

235
00:14:30,843 --> 00:14:32,503
[SPEAKER_00] And there's another example that stood out to me.

236
00:14:32,963 --> 00:14:34,204
[SPEAKER_00] Traceable.ai.

237
00:14:34,464 --> 00:14:39,165
[SPEAKER_00] They've raised like over $80 million, so they clearly have a budget to buy whatever they want.

238
00:14:39,785 --> 00:14:45,827
[SPEAKER_00] But they explicitly chose super tokens because other open source options were simply too complex.

239
00:14:46,157 --> 00:14:46,397
[SPEAKER_01] Right.

240
00:14:46,437 --> 00:14:50,339
[SPEAKER_01] A lot of the alternatives require deploying multiple different services.

241
00:14:50,419 --> 00:14:50,799
[SPEAKER_00] Exactly.

242
00:14:50,819 --> 00:14:57,402
[SPEAKER_00] The competitors required them to orchestrate a dozen different microservices just to get a basic login system working.

243
00:14:57,743 --> 00:15:00,184
[SPEAKER_00] They needed something robust but simple to deploy.

244
00:15:00,644 --> 00:15:02,545
[SPEAKER_00] Super tokens fit the bill perfectly.

245
00:15:02,880 --> 00:15:07,062
[SPEAKER_01] But, you know, this raises an important question about the reality of migrating user bases.

246
00:15:07,602 --> 00:15:13,404
[SPEAKER_01] It is incredibly easy to look at a sleek new tool and say, wow, I wish we had built our application with this from day one.

247
00:15:13,464 --> 00:15:13,945
[SPEAKER_00] Oh, for sure.

248
00:15:14,305 --> 00:15:17,666
[SPEAKER_01] But the reality is most established companies are deeply entrenched.

249
00:15:18,006 --> 00:15:23,028
[SPEAKER_01] They are currently stuck paying massive monthly invoices to Auth or AWS Cognito.

250
00:15:23,509 --> 00:15:26,790
[SPEAKER_01] How do they actually escape without ruining their users' experience?

251
00:15:27,234 --> 00:15:33,460
[SPEAKER_00] Yeah, you can't just flip a switch and send an email to 100,000 users saying, hey, please click this link to reset your password.

252
00:15:33,780 --> 00:15:35,702
[SPEAKER_00] You would lose half your active users overnight.

253
00:15:36,203 --> 00:15:37,704
[SPEAKER_00] The friction is just way too high.

254
00:15:37,864 --> 00:15:38,345
[SPEAKER_01] Exactly.

255
00:15:38,825 --> 00:15:45,191
[SPEAKER_01] The fear of user friction is the single biggest reason companies remain chained to vendors they actively dislike.

256
00:15:46,152 --> 00:15:50,697
[SPEAKER_01] But SuperToken supports both bulk and what they call lazy migrations.

257
00:15:51,132 --> 00:15:53,634
[SPEAKER_00] OK, walk me through how lazy migration works.

258
00:15:54,174 --> 00:16:00,879
[SPEAKER_00] Because moving users without asking them to change their password and without even forcing them to log out, that sounds like magic.

259
00:16:01,159 --> 00:16:03,941
[SPEAKER_01] It's not magic, but it is brilliant API routing.

260
00:16:04,181 --> 00:16:09,565
[SPEAKER_01] The migration happens invisibly to the end user one user at a time at the exact moment they try to log in.

261
00:16:09,785 --> 00:16:12,046
[SPEAKER_01] OK. Let's imagine you are migrating away from us.

262
00:16:12,166 --> 00:16:15,669
[SPEAKER_01] First, you set up super tokens to act as a proxy, a middleman.

263
00:16:15,909 --> 00:16:18,911
[SPEAKER_00] OK, so the user goes to my app and types in their email and password.

264
00:16:19,313 --> 00:16:19,553
[SPEAKER_01] Right.

265
00:16:20,293 --> 00:16:23,775
[SPEAKER_01] Your SuperToken's backend SDK catches those credentials.

266
00:16:24,475 --> 00:16:28,777
[SPEAKER_01] It looks at its own local database and realizes, uh-oh, I don't have this user yet.

267
00:16:29,297 --> 00:16:37,401
[SPEAKER_01] Now, instead of throwing an error, SuperToken silently takes those credentials and behind the scenes fires an API request over to your old auth account.

268
00:16:37,901 --> 00:16:40,402
[SPEAKER_00] Ah, so it's asking the old landlord to verify the key.

269
00:16:40,562 --> 00:16:41,082
[SPEAKER_01] Precisely.

270
00:16:41,462 --> 00:16:45,024
[SPEAKER_01] Auth checks its database and responds, yes, these credentials are valid.

271
00:16:45,564 --> 00:16:47,925
[SPEAKER_01] SuperToken's intercepts that success message.

272
00:16:48,389 --> 00:16:57,754
[SPEAKER_01] It then takes the password the user just typed, hashes it securely using its own algorithms, and creates a brand new account for that user in your self-hosted database.

273
00:16:58,355 --> 00:17:01,136
[SPEAKER_01] And finally, it issues the local session token to the user.

274
00:17:01,276 --> 00:17:03,638
[SPEAKER_00] And how long does all of that proxying and hashing take?

275
00:17:03,778 --> 00:17:04,638
[SPEAKER_01] Fractions of a second.

276
00:17:04,798 --> 00:17:07,100
[SPEAKER_01] The user experiences absolutely zero delay.

277
00:17:07,320 --> 00:17:08,741
[SPEAKER_01] They don't have to reset their password.

278
00:17:08,781 --> 00:17:10,942
[SPEAKER_01] From their perspective, they just logged in normally.

279
00:17:10,962 --> 00:17:11,863
[SPEAKER_00] So what does this all mean?

280
00:17:12,303 --> 00:17:17,848
[SPEAKER_00] It means the biggest hurdle, the terror of ruining the user experience, is completely eliminated.

281
00:17:18,128 --> 00:17:22,992
[SPEAKER_00] You just completely eliminate the friction of switching to an open source, cost-saving alternative.

282
00:17:23,392 --> 00:17:23,653
[SPEAKER_01] Yes.

283
00:17:24,413 --> 00:17:29,217
[SPEAKER_01] You get the robust security of an enterprise giant, but you reclaim your data sovereignty.

284
00:17:30,098 --> 00:17:33,201
[SPEAKER_01] Which leaves us with a really provocative final thought to ponder.

285
00:17:33,401 --> 00:17:33,661
[SPEAKER_00] Hmm.

286
00:17:34,061 --> 00:17:34,582
[SPEAKER_00] Late on me.

287
00:17:35,227 --> 00:17:50,231
[SPEAKER_01] If authentication, the literal gateway to our digital identities, becomes completely modular, decentralized, and developer controlled, what does the future hold for those massive tech companies whose main leverage has always been holding our user data hostage?

288
00:17:51,011 --> 00:17:51,991
[SPEAKER_00] That is a great question.

289
00:17:52,611 --> 00:17:59,253
[SPEAKER_00] If the vault door is suddenly affordable and incredibly easy to install yourself, the landlords are going to face an existential threat.

290
00:17:59,353 --> 00:17:59,853
[SPEAKER_01] Exactly.

291
00:18:00,243 --> 00:18:05,786
[SPEAKER_00] And empowering organizations to break free from that lock-in is exactly the mission of our supporter, SafeServer.

292
00:18:06,486 --> 00:18:17,052
[SPEAKER_00] As we've explored today, what organizations, whether you're a business, an association, or any other group stand to gain by switching to an open source solution like SuperTokens is immense control and major cost savings.

293
00:18:17,132 --> 00:18:17,632
[SPEAKER_01] Absolutely.

294
00:18:17,672 --> 00:18:20,233
[SPEAKER_01] Reclaiming that data sovereignty is just so critical today.

295
00:18:20,573 --> 00:18:21,034
[SPEAKER_00] It really is.

296
00:18:21,534 --> 00:18:24,796
[SPEAKER_00] And just as a reminder, SafeServer can be commissioned for consulting.

297
00:18:25,436 --> 00:18:29,158
[SPEAKER_00] So whether the right fit for your specific organization is SuperTokens,

298
00:18:29,934 --> 00:18:34,322
[SPEAKER_00] or a comparable open source alternative, they have the expertise to help you figure it out.

299
00:18:35,083 --> 00:18:39,791
[SPEAKER_00] You can find more information and get in touch with them at www.safeserver.de.

300
00:18:40,152 --> 00:18:41,293
[SPEAKER_01] It's definitely worth checking out.

301
00:18:41,834 --> 00:18:44,098
[SPEAKER_00] Well, thank you so much for joining us on this deep dive.

302
00:18:44,459 --> 00:18:50,168
[SPEAKER_00] Keep questioning the software you rely on every day, because at the end of the day, it's your digital house.

303
00:18:50,609 --> 00:18:53,113
[SPEAKER_00] You should be the one holding the master key to the front door.