Should session tokens be encrypted by adapters?

[dstotijn]

I've noticed that when a session is created, the sessionToken (which itself is cryptographically securely created) is passed to createSession in plaintext. I've noticed that the adapter implementations shipped in this repo seem to store the session token as-is in the database, without encrypting them. Is this done deliberately? One could argue that session tokens shouldn't be stored in plaintext at rest in a repository; although the risk/impact of a leaked database/store can be reduced with a short TTL. On the other hand, this lib strongly encourages using JWT so I can imagine it might be deemed a non-issue.

As an alternative to letting adapters deal with encryption, a more (opinionated) alternative in the core of next-auth would be to handle encryption and decryption (for example with Argon2) in lib/callback-handler.ts. E.g. encrypt and decrypt before calling the session related adapter functions.

Curious to hear thoughts from other folks! 🙏

[gregonarash]

Hey @dstotijn,

Interesting question. I am looking at implementation of NextAuth in https://github.com/vercel/platforms with the Prisma adaptor.

From what I see is saved in the database under Account are plain text access and refresh token. I tried to dig through the Next-Auth repo and from what I understood is that in case of using JWT as session strategy the tokens are encrypted. However it looks like for the database adapter the data is sent as is.

I am bit green behind the ears, but it seems common sense like a good idea to encrypt the keys stored in database. It would be interesting to hear some thoughts of the team behind (big kudos for the library🙌)!

[WoetDev]

Was also thinking about if there are any possible dangers of storing the access & refresh tokens as plain-text in the db so eager to hear more about this from someone who has given it thought before.