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