Properties we need:

• No database storage consumptions - since high traffic websites would needlessly occupy space.
• Created as soon as the first API call is made
• Anonymous session data is transferred to an authenticated session easily
• Enable / disable anonymous sessions - enabled by default.
• On unauthorised / logout, create a new anonymous session automatically.
• Have one persistent string that's the same across anonymous / authorised sessions, no matter how many times the switch occurs.

The output on start is as follows:

We can start by:

• Deciding what to remove and add to the initial output. Some ideas:
  • A good welcome message
  • Clearly highlighting which database is being used (in memory vs mysql vs mongo etc..)
• Deciding the colour scheme for the different parts of the output
• How the exit message should look (when a kill command is passed to the process)

If a user has set * in allow-origin and is using sameSite: none, then CSRF attacks are possible. Solve this by using an anti-csrf token for refresh APIs in above case

Nice job with this!

Do you guys plan to throw up a Docker image?

Right now, the developer has to set the tokens manually in Postman, and it can be difficult to know which those cookies are, and how to use them. Plus they keep changing over time.

Perhaps have a flag in the SDK that will enable them switch to a different mode of sessions where it's just one long lived token in the header which is mapped to the actual access / refresh tokens that the API expects.

These functions can be used to build out a simple login / sign up API. These will probably form the basis of higher level login flows that will come next

• userId = createUserWithEmailAndPassword(email, password) else throw error if email is already exists

• userId = getUserWithEmailAndPassword(email, password) throw an error if email doesn't exist

• success = resetPassword(userId, password) throw an error if userId doesn't exist

• email = getEmailForUserId(userId) throw an error if a user doesn't exist

• userId = getUserIdForEmail(email) or undefined if email doesn't exist

• exists = checkIfEmailExists(email)

The initial implementation will be done for NodeJS only. A few flow optimisations:

• Use handshakeInfo to get the access token lifetime in createNewSession so that the FDAT can be created before creating a ST session. This will reduce the number of round trips.

• If the FDAT is only going to be accessed only on the backend, then can increase the lifetime by a lot. Or even keep it infinitely lived. This means, no need to get a new FDAT on each refresh.

• When fetching the FDAT from the backend, ensure that the token is alive. If not, then get a new token, update in session and return that.

• Allow the user to set the lifetime of the FaunaDB access token. They will have to ensure that that's > than the lifetime of the ST session, else throw an error.

• Allow to get FaunaDB tokens of any sessionHandle in the system on the backend. This would query the JWT payload / session data of that session and retrieve that token for that userID.

The refresh API will always be {some-prefix}/session/refresh. The prefix can be defined by the user. This will make it easier for users to use login + sessions using us.

• We will need to remove the relevant config params, and take a new param called the apiBasePath. The default value of this will be /auth. However the user can override it by providing:
  • a full URL: https://example.com/custom-base/ => /custom-base
  • a path: /custom-base/ => /custom-base
  • empty path: / => "" OR "" => ""
  • The above can be provided with or without a leading and or trailing slash:
    • custom/base => /custom/base
    • custom/base/. => /custom/base
    • /custom/base => /custom/base
    • custom/base/ => /custom/base
    • custom/base/ => /custom/base
    • custom-base => /custom-base
    • If there are a domain, or protocol, or query or # or anything else, remove them.
• On the frontend SDKs, users will also need to provide their API domain, which they can provide via a variable apiDomain. This is a compulsory value. It can be of the form:
  • example.com => https://example.com
  • example.com/ => https://example.com
  • http://example.com => http://example.com
  • https://example.com/ => https://example.com`
  • localhost ⇒ http://localhost
  • IP Address ⇒ http://IP Address
  • If there is a path or query or #, remove them

Therefore, on the frontend, the refresh endpoint will be: ${apiDomain}${apiBasePath}/session/refresh
On the backend, the API will listen for the path ${apiBasePath}/session/refresh

Tasks

• nodejs
  • change
  • testing
• supertokens-website
  • change
  • testing
• Migration guide
  • supertokens-website
  • nodejs
• Documentation change
  • supertokens-website
  • nodejs
• Create an issue on other SDKs about this
  • flask
  • javalin
  • golang
  • laravel
  • fastapi
• Create an issue on other frontend SDKs
  • react-native
  • android
  • ios

This would involve open source developers to optionally share their details and the version they use so that incase of critical issues, we can inform them that they should update the version of the SuperTokens Core

The repo containing the Dockerfile and the entrypoint is here.

• Change blacklisting to also check for the actual access token from the database, cause when we regenerate a session, the session is not removed fully, but only the token is changed (make sure to send try refresh token in the case that session exists, but tokens don't match as opposed to unauthorised). We do not need to change the refresh token because that has token theft detection anyway.

• We must update lmrt only when the session is being regenerated for the purpose of auth? Otherwise, if we simply update the lmrt each time the JWT payload changes (like in the case of fauna), that may pose inaccurate results.

This conversation has been moved to this document.

Please feel free to ignore the remainder of this issue thread.

It prints out the final "Goodbye", however, it doesn't quite the actual process.

🚀 Feature

Allow the user to change the cookie name for session tokens. This can allow multiple, independent websites to have their own sessions even if they all take to the same API. This is useful in the context of apps where there are different types of users, using different websites, but all talking to the same endpoint.

Implementation details

• We must allow the user to give cookie names for all the session tokens, during createNewSession.
• The names of the cookies go on the frontend as a header and saved there (domain's cookie storage).
• During requests, those names are added to the request header which is then used to read the actual cookies on the backend.
• If the names are the default ones, this extra header is not needed and things would work exactly like they work now.

This does not have any security implications since right now, it's as if this feature is there already and everyone just uses the default cookie names.

This was there for backwards compatibility reasons, however, since table creation happens only for new users, you don't need this anymore.

We will also need to ensure that any associated cron job runs only if this table exists.

@jscyo If it works properly after that release, please close this issue, else raise another issue and then close this.

This will allow integrations that depend on the lifetime of these tokens to work in a more efficient way. An example of such an integration is FaunaDB.

This is in com-core as well. It needs to work in exactly the same way.

This issue is thanks to the team at manycore.io

We currently use a JRE extracted from OpenJDK 12.0.2. This comes along with the SuperTokens zip file that's downloaded via our website. It's also present in the various docker containers that we ship. The docker containers can be found in the org repos list and have a name like "supertokens-docker-"

Docker Image size: 161MB (for the one compatible with MySQL)
Minimum resources consumed (see the supertokens row. Others are there for a comparison):

While this would speed things up, we must analyse what effect each stolen item can have. CSRF protection does not count since that validation is stateless. We must assume that the attacker can create their own refresh token given the session handle. In case they do that, it should yield an unauthorised error.

A few questions to think about:

• what if the attacker keeps everything the same, except changes the userId in the token?
• Would it be easy for the attacker to trigger a token theft detection error?

If that is guaranteed, then we can remove the need for encryption, else we can at least use a method that's less time consuming.

@bhumilsarvaiya one more point:

• SaaS API keys should be 30 chars long, not 20

• Add an empty commit with the latest build so that we are sure that the latest build is being released
  • For all java based projects, we want to rebuild the JARs
  • For all typescript based projects, we want to rebuild so that all ts is converted to js
• Enforce that there are no updates to master that are not applied to this branch
• In ./addReleaseTag, remove the --ours in the merge command when merging into master

• core
• plugin interface
• mysql
• postgresql
• mongodb
• nodejs
• website
• auth-react

The instructions here will be very similar to that in contributing. The aim should be to allow anyone who wants to use a modified version of SuperTokens to be able to use it:

• Via manual installation
• Via their own docker image

Core

• Load the configs
• Load the storage layer
• Parse CLI args
• Start cronjob scheduler
• Start webserver
• Load module manager (see below)
• Load version file
• Initialise logging
• Listen for kill signal (and propagates them to the modules)

Module manager

Should be responsible for:

• Loads all the module JARs and their dependencies from the /modules/ directory in the installation location

• Routing of an API to a module:

  • Check if the API path starts with /recipe. If not, then perhaps it's for a different functionality in the core.
  • Ask all modules if they can handle the current API request.
  • If 0 modules say yes, then return 404
  • If 1 module says yes, then pass the task to that module
  • If > 1 say yes, then get the rId of that module and check it against the header's rId:
    • If the header has no rId, then throw an error saying "Please pass the rId in the header request. One of "rId1", or "rId2",...
    • If no rId match, then throw an error saying "Have you passed the correct rId in the request? Please use one of ...
    • If more than one match, then throw an error asking if one module has been specified two times in the /modules/ directory?
    • Pass the task to the one that matches.

• Provides a module interface (module-interface) that:

  • Asks a module if they can handle the current path (excluding /recipe) and method.
  • Gets the module's rId
  • Lets a module handle an API request
  • Allow a module to schedule a cronjob
  • All a module to interact with the underlying storage layer
  • Allow the module to use the apiKey if needed
  • Provide error and console logging functionality to a module
  • Give the installation path to a module so that they can load files like config.yaml from them
  • Let modules query for the version info
  • Propagates a stop signal to the module

Plugin interface change:

• #72
• Abstract operations of the underlying storage layer to allow users to do:
  • Transactions
  • Locking
  • Queries
  • Creation of tables if not created

Changes to config:

Please see #76

This issue is thanks to @mmaha

Even with the correct version, we get the following error:

io.supertokens.test.ShutdownTest > shutdownSignalTest STANDARD_OUT
    ----------DELETE ALL INFORMATION----------
    Process ID: 9f5c5125-18e1-4e1e-94c4-1ebde3c1af62

io.supertokens.test.ShutdownTest > shutdownSignalTest STANDARD_ERROR
    Failed to load native library:sqlite-3.30.1-bed70ca4-76c6-4354-a16f-f4c8b4da2104-libsqlitejdbc.jnilib. osinfo: Mac/x86_64
    java.lang.UnsatisfiedLinkError: /private/var/folders/z_/__5pkjcd3018c15c6w15fq4h0000gn/T/sqlite-3.30.1-bed70ca4-76c6-4354-a16f-f4c8b4da2104-libsqlitejdbc.jnilib: dlopen(/private/var/folders/z_/__5pkjcd3018c15c6w15fq4h0000gn/T/sqlite-3.30.1-bed70ca4-76c6-4354-a16f-f4c8b4da2104-libsqlitejdbc.jnilib, 1): no suitable image found.  Did find:
        /private/var/folders/z_/__5pkjcd3018c15c6w15fq4h0000gn/T/sqlite-3.30.1-bed70ca4-76c6-4354-a16f-f4c8b4da2104-libsqlitejdbc.jnilib: code signature in (/private/var/folders/z_/__5pkjcd3018c15c6w15fq4h0000gn/T/sqlite-3.30.1-bed70ca4-76c6-4354-a16f-f4c8b4da2104-libsqlitejdbc.jnilib) not valid for use in process using Library Validation: mapped file has no cdhash, completely unsigned? Code has to be at least ad-hoc signed.
    Exception in thread "Thread-3" java.lang.UnsatisfiedLinkError: org.sqlite.core.NativeDB._open_utf8([BI)V

However, things work just fine with OpenJDK

To recreate the problem that exists today:

• run docker pull supertokens/supertokens-mysql:2.4
• Start the docker image in foreground: docker run -p 3567:3567 supertokens/supertokens-mysql:2.4
• Wait for it to start.. It should display Started SuperTokens on 0.0.0.0:3567 with PID: <some PID>
• Now send the kill signal (Ctrl + C / Z on a Mac)

At this point, the Java process in the docker process should stop and the docker process itself should quit. However, that does not happen.

The docker file for the above image can be found in this repo. Please feel free to fork that as well.

As some extra info:

• if not using docker (manually installing it on your system), sending the kill signal does stop the running process.
• In the Java code (this repo), in Main.java, there is a function that registers a shutdown hook.

An example is that in all drivers, instead of "session does not exist", it says "missing idRefresh token"

• This should be switched off by default.
• Implement it by checking if the associated session handle exists in the database

I'm trying to install the community edition like this cd supertokens && mkdir lib && ./install --path=./lib but I'm getting this error.

java.io.IOException: Permission denied
        at java.base/java.io.UnixFileSystem.createFileExclusively(Native Method)
        at java.base/java.io.File.createNewFile(File.java:1024)
        at io.supertokens.cli.commandHandler.install.InstallHandler.createSupertokensScript(InstallHandler.java:205)
        at io.supertokens.cli.commandHandler.install.InstallHandler.doCommand(InstallHandler.java:86)
        at io.supertokens.cli.commandHandler.CommandHandler.handleCommand(CommandHandler.java:49)
        at io.supertokens.cli.Main.start(Main.java:122)
        at io.supertokens.cli.Main.main(Main.java:70)

error while installing SuperTokens. Please try again

Change the signing key, invalidating all issued JWTs. However, the users can fall back on using their refresh tokens to get a new JWT signed with the new key.

🚀 Feature

The method would be called from the SDKs on signup, and maybe other functions too.

Remove it:

• from the core
  • from config
  • from APIs
  • from tests
• nodejs driver
  • API response handling
  • CDI compatibility change
  • take session expiry status code in init
  • If cookieSameSite is none and anti_csrf is not enabled, throw error
  • Normalise sameSite values for capital letters etc..
  • Remove support for older CDI
  • Open issue for this in other drivers
• docs
• migration
  • migration steps for driver

These changes are also in accordance to CDI 2.4: https://github.com/supertokens/core-driver-interface/blob/master/v2.4.0.md

Using SuperTokens, Inc

• for linux
• for windows

For Windows, we need to make a change for this file, to delete line 12-15.

• Nodejs
• Flask
• FastAPI
• Javalin
• Laravel
• Golang
• Auth0-spa-js
• Website
• Android
• iOS
• react-native

This information will also be used to determine how we can add a proxy function to the driver to help the sign in / up form communicate with the core

• NodeJS
• Flask
• Javalin
• Golang
• FastAPI
• Laravel

Summary

The idea is to detect IP address changes, combined with device fingerprint to detect session theft.

(Edited version based on feedbacks)

• IP change detection: Revoke access token, this will force reuse the refresh token which can then be used to detect token theft. This will also prevent logouts due to false positives.

• Device fingerprint change=> Revoke access token

Questions to solve:

• What is considered as a reliable device fingerprint?
  • On web
  • On mobile
• How do we compute/encode it?
  • This would be done from the Front end, so possible for an attacker to reverse engineer, but adds an additional layer of complexity to a session theft attack.
• The above would only work if the access token has blacklisting turned on. How should we deal with the case when blacklisting is off?

Our backend is written in Elixir/Phoenix and would love to be able to easily integrate it into our backend.

Branch rules can be found here: https://github.com/supertokens/supertokens-core/settings/branches

It has already been done for this repo, and for supertokens-node

I get below error with the latest version of servertokens downloaded from the website.

What caused the crash: Failed to initialize pool: Could not connect to address=(host=localhost)(port=3306)(type=master) : Client does not support authentication protocol requested by server. plugin type was = mysql_native_password

I have tried both caching_sha2_password and mysql_native_password protocols. Both failed.
Other mysql clients can connect just fine.

My setup:
mysql 8.0.19
Macos catalina
servertokens latest from website

During setup for supertokens-root, it directly calls the supertokens-core,supertokens-plugin-interface and plugin repositories resulting in changes being made directly to the supertokens repositories which is not ideal for contributing

🚀 Feature

Merge back supertokens-interface-plugin into supertokens-core

java.io.IOException: Cannot run program "kill": error=2, No such file or directory
	at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1128)
	at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1071)
	at io.supertokens.cli.commandHandler.stop.StopHandler.stopProcess(StopHandler.java:90)
	at io.supertokens.cli.commandHandler.stop.StopHandler.doCommand(StopHandler.java:52)
	at io.supertokens.cli.commandHandler.CommandHandler.handleCommand(CommandHandler.java:31)
	at io.supertokens.cli.Main.start(Main.java:101)
	at io.supertokens.cli.Main.main(Main.java:49)
Caused by: java.io.IOException: error=2, No such file or directory
	at java.base/java.lang.ProcessImpl.forkAndExec(Native Method)
	at java.base/java.lang.ProcessImpl.<init>(ProcessImpl.java:340)
	at java.base/java.lang.ProcessImpl.start(ProcessImpl.java:271)
	at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1107)
	... 6 more

Could not stop SuperTokens instances. Please try again

This happens inside the docker container, however, it may also be happening without docker on linux (This error doesn't happen without docker on mac)