[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...).

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-...).

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.