
Launch HN: SuperTokens (YC S20) – Securely manage session tokens - advaitruia
Hi everyone! My name is Advait and I co-founded SuperTokens along with
@rishabhpoddar (<a href="https:&#x2F;&#x2F;supertokens.io&#x2F;" rel="nofollow">https:&#x2F;&#x2F;supertokens.io&#x2F;</a>). SuperTokens helps companies
securely manage their session tokens, saving developer time and
preventing identity theft.<p>We started SuperTokens 1.5 years ago when we were building a consumer
app and wanted our users to be logged in for a long time in a secure
way. When it came to managing user sessions, there was a lot of
ambiguity. We read many forums (Reddit, Stackoverflow) and blogs, and
found that developers were arguing about best practices, such as using
local storage vs cookies, implementing JWTs, etc. We had to do a lot
of the first principles thinking ourselves to understand the
tradeoffs. Around the same time, Facebook, Docker, Gitlab, Youtube,
Uber were in the news for session vulnerabilities.<p>Stealing a user’s session allows you to access their account as if you
had their username and password. Hence being able to mitigate against
this is important. We’ve audited companies and found large session
vulnerabilities that they were not aware of. For a YC company, we were
able to pull information on users that we shouldn’t have had access to.<p>Through our research, we built something internally and decided to
write a blog post [1] explaining how our system works. While
SuperTokens is not currently open source, you can see the original
codebase on Github [2].<p>Building a good solution for sessions requires a lot of specialised
knowledge and time that could otherwise be spent on building your core
business logic. Detecting session theft reliably is difficult. There
are multiple race conditions, edge cases and network issues that need
to be thought about. In fact, one of our libraries that solves a
difficult race condition has 100K downloads &#x2F; week and is even used by
Auth0 [3]<p>SuperToken mitigates against all session attacks (XSS, CSRF, etc) by
implementing best practices. For a full list of types of attacks with
real life examples please see [4]. However, it is not possible to
mitigate against all attacks (for eg: social engineering) and hence,
SuperTokens is also able to detect session theft. We use rotating
refresh tokens as per the official OAuth specifications in RFC 6819
[5]. Auth0 has also started offering this, but due to their setup,
they cannot use httpOnly cookies to store these tokens and this goes
against popular compliance recommendations.<p>Besides security, SuperTokens also offers improved API performance and
developer convenience. For clustered and distributed environments,
session verification for each API takes &lt; 1 millisecond. You can get a
user’s ID and access role without any database lookup. SuperTokens can
be implemented in 15 minutes, provides a simple API and has clear
documentation. We abstract away complexities of token management by
providing frontend and backend SDKs.<p>In the coming months we plan to offer Access Control, Internal Auth
between services and for internal tools (i.e. recent Twitter hack was
through unauthorized access to an internal tool), and more! We&#x27;re
still experimenting with pricing, so you won&#x27;t find this on our
website, but we&#x27;d love to hear your thoughts about it.<p>Thank you for reading! We’d love to hear what this community
specifically has to say and if you have any experience dealing with
this. We’d appreciate any feedback!<p>----------<p>Footnotes:<p>[1] - Blog post: <a href="https:&#x2F;&#x2F;medium.com&#x2F;hackernoon&#x2F;all-you-need-to-know-about-user-session-security-ee5245e6bdad" rel="nofollow">https:&#x2F;&#x2F;medium.com&#x2F;hackernoon&#x2F;all-you-need-to-know-about-use...</a><p>[2] - Github: <a href="https:&#x2F;&#x2F;github.com&#x2F;supertokens&#x2F;supertokens-core" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;supertokens&#x2F;supertokens-core</a><p>[3] - Library used by Auth0: <a href="https:&#x2F;&#x2F;www.npmjs.com&#x2F;package&#x2F;browser-tabs-lock" rel="nofollow">https:&#x2F;&#x2F;www.npmjs.com&#x2F;package&#x2F;browser-tabs-lock</a><p>[4] - List of attacks: <a href="https:&#x2F;&#x2F;supertokens.io&#x2F;pdf&#x2F;attackshomepagev1" rel="nofollow">https:&#x2F;&#x2F;supertokens.io&#x2F;pdf&#x2F;attackshomepagev1</a><p>[5] - OAuth RFC 6819: <a href="https:&#x2F;&#x2F;tools.ietf.org&#x2F;html&#x2F;rfc6819#section-5.2.2.3" rel="nofollow">https:&#x2F;&#x2F;tools.ietf.org&#x2F;html&#x2F;rfc6819#section-5.2.2.3</a>
======
hellcow
Is this really a problem that needs solving?

Generate a secret, hash it, and store it in your database. Set the secret as a
cookie in the client. On every request, hash the cookie value on your server
and compare it to your DB values.

It seems like very little effort to implement this yourself in a way that
doesn't involve completely trusting a different company.

~~~
jrexilius
I'm not going to speak for the company or their solution, but yes it is a
serious problem. The token itself isn't the hard part as you pointed out, it's
the full life cycle management of it and the security analysis is. Detecting
and acting on session hijacking is hard to do right. It can get very
complicated as well if your system needs to enforce things like non-concurrent
logins, etc.

But I'm glad the company offers a self-hosted version rather than being forced
to rely on their managed service (that was the first thing I looked at). I
haven't dug into it at all and am taking at face value that their self-hosted
daemon doesn't have any required real-time connections to their systems, but
that would be a deal killer as well.

~~~
rishabhpoddar
Thank you!! We use rotating refresh tokens to detect session theft reliably.

~~~
md_
I'm not entirely sure I'm understanding the terminology you're using.

Are you talking about OAuth2 tokens (i.e.
[https://tools.ietf.org/html/rfc6819#section-5.2.2.3](https://tools.ietf.org/html/rfc6819#section-5.2.2.3)),
or are you talking about browser cookies?

In both cases, rotation strikes me as being of limited (though nonzero) value.
While rotation (and invalidation of the previous token) can be used to prevent
long-lived concurrent use of cloned tokens, there's a good chance an attacker
can ensure that _they_ are the ones who get the "new" token.

As a result, the user--the legitimate OAuth client or browser--would be left
with the now-invalidated token, and will be logged out. The most likely result
of which--depending on application design choices--is that the user simply
logs in again! You now have two sessions, one of which is solely owned by an
attacker, and one of which is solely owned by a user!

(There are cases where this is still valuable: if you enforce "only one
session globally" per user, for example, or if you use the presentation of an
"invalidated" token as indicative of theft. But both are application design
choices that will commonly be inappropriate.)

At the extreme, of course, if your threat model is local malware, UXSS, etc,
an attacker can just do a "person in the browser" attack, in which no token
copying happens.

I'm not sure why I'm bothering to write all of this. Call it free consulting?
;)

My point is really that the threat model needs to be clearly stated and, for
some threat models (including some which are featured in case studies on your
website), this approach may be largely ineffective.

------
thrwaway2020aug
Congrats on launching!

If I understand correctly, you're having me integrate a library on my backend
that manages session cookies.

You've implemented refresh tokens and that seems to be one of your major
selling points, but I'm confused what benefit that provides?

I thought the use case for refresh tokens in OAuth was that the user can
revoke access from the OAuth provider side. But since the user can't go to
SuperTokens and revoke their session, isn't the refresh token functionality
superfluous?

~~~
rishabhpoddar
Thanks! The benefits we provide are session security and convenience (not
having to know or think about tokens and session management).

We don't use normal refresh tokens. We use one time use refresh tokens. This
allows to detect token theft in a reliable way for long lived sessions
([https://tools.ietf.org/html/draft-ietf-oauth-browser-
based-a...](https://tools.ietf.org/html/draft-ietf-oauth-browser-based-
apps-06#section-8)).

Also, OAuth is different to session management in that OAuth is for delegation
purposes, whilst "a session" can be used to maintain authentication between
your own frontend and backend.

In terms of revocation of sessions, our SDK provides functions that can be
used to revoke sessions. Soon, we will be making a dashboard that can be used
to do the same (and other things)

~~~
thrwaway2020aug
Thanks for your response!

I'm still a bit confused why you're referencing OAuth here and in the launch
announcement while also saying "OAuth is different to session management"

Why have you chosen to use OAuth solutions if you're not solving an OAuth
problem? How are you sure it's still the right solution? I see some overlap
but it's not obvious to me that OAuth methodologies should be applied here.

~~~
rishabhpoddar
Technically, you do not need to exactly follow OAuth methodology for sessions.
You are right. However, there is one common problem with sessions and OAuth,
which is token theft.

In order to detect token theft, we use the general principle of changing
tokens on each use. So theoretically, we can use one random string token, that
changes on each use and solve the problem in case of sessions.

The problem with that is that it's not scalable since for any request that
changes tokens, we need to synchronise calls to that request
([https://supertokens.io/blog/the-best-way-to-securely-
manage-...](https://supertokens.io/blog/the-best-way-to-securely-manage-user-
sessions#2)).

In order to make things scalable & have this security benefit, we use two
tokens. One that doesn't change, and one that is used rarely, but changes...
This starts to look like OAuth now.

Pushing it further, we can name those tokens access and refresh tokens. So
while OAuth and sessions are different, we can pick specific concepts from
OAuth and apply them to sessions.

------
agustif
I don't wanna hijack his thread, but I'm a small contributor to a great open
source project library called AccountsJS, which seems pretty similar to this,
AFAIK. and it's really modular/flexible on whatever you want to implement it
with!

You can use it both with REST/GraphQL, and any frontend you may like.

Also supports Oauth like Twitter, FB, Google, Insta, etc...

Has 2FA. MFA on the works...

Anyway if it piqued your interest here are some links:
[http://accountsjs.com/](http://accountsjs.com/) Repo in GH:
[https://github.com/accounts-js/accounts](https://github.com/accounts-
js/accounts)

~~~
ignoramous
> _I don 't wanna hijack his thread..._

But you did :) accountjs looks great! Another related hands-off do-it-all
solution that I like is [https://userbase.com](https://userbase.com).

------
soneca
I am using FaunaDB for a side project and your product would be a very good
fit to work with their tech.

They have a built-in authentication in their distributed database, but not
session management. A lot of people is starting to build things with FaunaDB
and struggling with auth. In their Slack they even had to open a channel only
for authentication doubts.

So if you are looking for a niche, the FaunaDB integration could be a good
shot.

~~~
rishabhpoddar
Actually yes! We are already working on providing session management for
FaunaDB users. Using us, you can easily get a FaunaDB token for a user on your
backend and frontend. We take care of all the heavy lifting of creating those
tokens and making sure they are alive (and of course, providing session
management).

We should have something out in a few weeks from now!

------
benmmurphy
How do refresh tokens work in the presence of concurrent requests from
multiple tabs? I don't see how two tabs could synchronize their access in a
way that won't lead to the possibility of one tab thinking it has been logged
out. I guess you can try and paper of these issues with JS but without client
side JS you are completely lost.

~~~
rishabhpoddar
Yea! That's why we have a frontend SDK that solves for issues like these. Our
SDK uses a library called browser-tabs-lock which provides locking across tabs
([https://www.npmjs.com/package/browser-tabs-
lock](https://www.npmjs.com/package/browser-tabs-lock)). So essentially,
whenever a refresh call is made, we synchronise those requests.

This library is written by us to solve for the exact problem you mentioned!
It's also being used by Auth0

------
candiddevmike
I don't see any kind of compliance, code audit, or SLA to back up the kind of
claims your landing page makes.

Also, maybe it's just me, but your landing page is very slow and laggy, and my
browser hung a bit while navigating around.

~~~
rishabhpoddar
Thanks for letting us know! We use Cloudflare and had to purge the cache today
cause of some changes.. Is it laggy while scrolling any specific page? Or only
when switching pages?

About compliance & code audits, those are being planned. We will have code
auditing done in a few weeks from now. But yea, I understand your point.
Thanks!

~~~
candiddevmike
Both, the initial page load and getting to the carousel is pretty sluggish.

~~~
rishabhpoddar
Thanks! Will investigate & fix.

------
endiangroup
AD: I authored a solution to the revocation of tokens[1] for JWT and even
verified the solution through TLA+. It uses a monotonic counter as a claim per
JWT, you can revoke X active sessions behind the last issued, you can also use
time to do temporal permission inflating (sudo... etc).

What sort of verification have you done on your solutions? What are the down
falls of your solution?

[1] -
[https://github.com/endiangroup/compandauth](https://github.com/endiangroup/compandauth)

~~~
rishabhpoddar
Sounds interesting! I'll have a look at your library. Our solution takes
relevant aspects of the OAuth specs. Specifically the idea of using rotating
refresh tokens to detect session theft.

That being said, we have not had any formal verification. We plan on doing an
outside code review / audit from a reputable 3rd party in the coming weeks.

Two question for you: \- In your solution, I assume there is one JWT per
logged in user. If I want to revoke one user's session specifically (without
affecting other users who have a similar count), how would I do that? \- When
would I want to revoke all sessions before some count X?

Apologies if I have misunderstood how your lib works.

~~~
endiangroup
Good luck with the audit, the solution sounds interesting on the surface!

Ah I think you've slightly misunderstood, there is a 'counter' per entity,
each user has their own separate counter so when you are revoking it is only
relevant to sessions related to that users account. This would fall under your
database lookup version of JWT management, it's centralised but in the
smallest way possible.

That might clear up your second question, you'd want to revoke all sessions
like I'd want to 'Log out all other active sessions', logging in to my Spotify
on my friends computer last week, and my sisters the week before, I want to
log them ALL out.

~~~
rishabhpoddar
I see. Thanks for the clarification.

So when you are verifying an incoming JWT, don't you need to check what the
allowed counter is for that session? If yes, then doesn't that require a
database / cache lookup for each verification? And if it does, then how are
you able to get super fast session verification?

~~~
endiangroup
Yes absolutely, as I stated in the comment before. The super fast verification
is once you've done the DB lookup and do the actual comparing (as it's just
int64 comparisons). CAA is intended as a set of primitives to be built on top
of.

As I understand ST is in effect making the client act as the cache by giving
them a refresh token (RT), you delay having to do a central DB lookup until
the AT expires and RT is used... You could do the same with CAA, check the DB
every X interval (30s) instead of every request, the security implications
would be the same (some period of time that no matter who is using the token
it will work) as I understand?

From what I've read Theft Protection is a matter of detecting reuse of RT (as
I've understood), again with CAA and using the above, you could track each
periodic "check" against the master with another counter and embed into the
token, if you see a tracking number < or > what you've seen then a Theft has
occurred. Would that be the same as ST?

~~~
rishabhpoddar
Yea! Absolutely. Both our solutions follow the same fundamental idea of
changing tokens to detect theft. That being said, there are edge cases that
need to be considered when detecting token theft such that there are no false
positives:
[https://youtu.be/6Vzit514kZY?t=747](https://youtu.be/6Vzit514kZY?t=747).

The video about describes 2 edge cases specific to our flow, but I maybe they
also apply to your solution?

------
jrexilius
Good luck guys! Do it right and keep moving forward, it's a problem that does
need to be solved. Just make sure it can work behind a corp firewall without
hooks back to your servers ;-)

~~~
rishabhpoddar
Noted. Thank you!

------
pletsch
Your pricing is pretty hard to find, had to go to documentation -> scroll to
the bottom and it's in the right hand corner. Then when I click on it, there
is no pricing on that page.

~~~
rishabhpoddar
I understand that this is annoying. The reason we have it that way is cause we
are experimenting with pricing on a per user basis - it's like the "contact
us" pricing plan for other SaaS products.

Soon, we plan on standardising pricing based on our pricing experiments.
Thanks for the feedback!

~~~
ck_one
Cool product and I can see myself using it. What's the difference between the
non-pro and the pro licence?

~~~
rishabhpoddar
Thanks! As of now, there is only one version - the pro version. We may add an
open source version soon. If we do, it will be clearly mentioned on our site
along with what the feature differences between the non-pro and pro versions
are.

------
ignoramous
> _While SuperTokens is not currently open source..._

Might want to update your Twitter, then?

 _@supertokensio The most secure solution for user session management... We
're open source and easy to implement._

~~~
benatkin
There's this: [https://github.com/blitz-
js/blitz/blob/724c6921da1646a35625b...](https://github.com/blitz-
js/blitz/blob/724c6921da1646a35625b96320a3cf97478c357a/packages/server/src/supertokens.ts)

It's neither the old open source version of supertokens, which is deprecated,
or the new version of supertokens, but is in between.

~~~
rishabhpoddar
Yup. For blitz, there is a default session management solution that's
essentially based on a long lived, opaque access token. There is also going to
be one which is what SuperTokens is. Either using SuperTokens directly, or an
implementation of that in Blitz itself.

------
hashamali
Can you talk a bit about the tech stack behind this? I see <1ms API responses
which is very impressive, curious to hear more about the implementation.

~~~
rishabhpoddar
Sure! Briefly, we use JWT access tokens which are used for session
verification. JWTs can be verified using just a secret key which can be stored
in memory. Hence, no network calls = < 1MS latency.

However, there are issues with using just a JWT, like inability to revoke them
or bottlenecking all user security on one secret key. To solve those and other
issues, we use rotating refresh tokens. More about this here:
[https://supertokens.io/blog/are-you-using-jwts-for-user-
sess...](https://supertokens.io/blog/are-you-using-jwts-for-user-sessions-in-
the-correct-way)

------
samjs
Congrats on the launch!

We're building stuff in a similar space! Would be cool to chat and swap ideas:
we're [https://www.osohq.com](https://www.osohq.com), I'm sam@ the same
domain.

~~~
rishabhpoddar
Awesome!! Your site looks really clean! Will reach out!

------
new_guy
This really isn't a problem that needs solving? Much less paying some random
company to have access to all your user data.

~~~
rishabhpoddar
Not all apps will want to have a good level of session security (as of today).
But there are enough that do.

We have a self hosted version that uses your own db to store tokens. So you
don't need to give us any "user data".

------
aloukissas
This is great! Any plans to support Elixir/Phoenix anytime soon? Don't see it
in the dropdown in your website :(

~~~
rishabhpoddar
Thank you :)

We can add that to our roadmap. We are also happy to prioritise depending on
your use case and commitment! Do reach out to us via email
(team@supertokens.io)

------
biolurker1
Can I ask how this fits with the YC thinking that startups should have unicorn
potential?

~~~
rishabhpoddar
We are in the authentication space. Sessions is a way to get into the space.

