thanks for pointing this out!

So we are not an OAuth 2.0 provider and should not be treated or used as an OAuth 2.0 provider, instead, we have our own protocol for session management. In this protocol, we use the term access token and refresh token since that's what most accurately describes them. We are also not an Open ID client (since that's a protocol that's usually used on top of OAuth 2.0). However, we have a few parts of it like exposing a JWKS URL. So in the realm of our session solution, it is a custom one, but that's cause it's use case is totally different than OAuth 2.0's use case (see https://supertokens.com/blog/oauth-2-vs-session-management) Finally, we do plan on become an OAuth 2.0 + Open ID provider. Once we have those, then we will be sticking to those standards. But since their use case is different that session management, we will continue to offer our custom session solution as well.