When using SuperTokens our default session management solution will suffice for most use cases. You do not need to use JWTs unless you want to:
- Integrate with services that rely on JWT based authentication (For example Hasura)
- Integrate SuperTokens with a backend framework that we do not support yet
Using this feature exposes the generated JWT to the frontend. This makes the token susceptible to XSS attacks, this in turn implies that the token can be stolen and an attacker can use this to query any service that relies on this token. If security is very important, then do not enable JWT and rely on our default session management which uses httponly cookies.
In our session flow, we issue an access and a refresh token. Our access token is NOT a typical JWT and should not be used in replacement of one. Here are the differences:
- Our access token doesn't have the
- The access token doesn't follow the JWT standards strictly. So verification of it using a generic JWT library might not work - therefore, we provide functions in our backend SDK to easily very our access tokens.
However, there are few similarities:
- Both, our access token, and a JWT can be verified in a stateless manner. Therefore, session verifications are very quick (< 1 MS)
- Our access tokens are signed via RSA256 using the private key stored in the SuperTokens' database. Verification happens using the associated public key.
That being said, we do issue JWTs per session (you need to enable this feature) and can be accessed from the session. This JWT is a different token than the access token and can be used to authenticate with external services like Hasura or AWS lambda.
However, whenever possible, stick to using our access tokens for session verifications - it's way more secure.