Add ability to encrypt session data

[paulomarg]

WHY are these changes introduced?

Currently, when storing sessions in a database, we don't provide any utility from @shopify/shopify-api to encrypt the access token, which is easy to rotate for apps but might be annoying for developers if their databases are ever leaked.

WHAT is this pull request doing?

To add an extra layer of security to the way apps store tokens, this PR introduces the ability to serialize and deserialize sessions in a way that handles the encryption for apps, given a CryptoKey.

If a row was previously unencrypted, these functions will still be able to load it and update the row when saving it, which means that the migration path for session storages is simply:

• loadSession
• storeSession

for every row in their database, if they don't want to wipe it clean.

I'll add documentation and a changelog entry to this PR once we're aligned on what it will do.

Type of change

• Minor: New feature (non-breaking change which adds functionality)

Checklist

• I have used yarn changeset to create a draft changelog entry (do NOT update the CHANGELOG.md files manually)
• I have added/updated tests for this change
• I have documented new APIs/updated the documentation for modified APIs (for public APIs)

[lizkenyon]

We could explicitly say it is the access token that is getting encrypted.

[lizkenyon]

Question: Should we be making it flexible to allow folks to encrypt more than just the accessToken?

[paulomarg]

I thought of that too, but haven't thought of how the app would convey that information. I think it would need to be a direct argument to to/fromEncryptedArray that the app would have to pass in to the session storage.

That would mean the app could do something like:

// Evergreen way of encrypting every column we allow
new PrismaSessionStorage(prisma, {encryptionKey: true, encryptColumns: 'all'});

// Explicitly select which columns
new PrismaSessionStorage(prisma, {encryptionKey: true, encryptColumns: ['accessToken', 'userId']});

[lizkenyon]

Yeah, I think it would have to be something like that. I think it would be a nice to have, but does go beyond the scope of this required work.

[paulomarg]

It is fairly easy to implement though, I'm going to timebox it and see if I can get it off the ground.

[paulomarg]

In the end, we decided not to go forward with this as developers are probably better served by using encryption at the infrastructure level for their production databases, rather than making the API more complex at the software level.