Workspace specific secret key

[FelixMalfait]

After we work on https://github.com/twentyhq/twenty/issues/4587 I wonder if we could find ways to mitigate the risk if someone gets access to a token through a given workspace.

One solution to explore would be to introduce workspace-specific tokens: merging our server key with a workspace-specific key the user doesn't have access to. We can use the appToken table we will create for OAuth. We could even rotate keys at a workspace level in the future!

That way if the attacker manages to brut-force getting access to the key (e.g. through the files endpoint), then they can't exchange their workspace-level key against a server-level key. The workspace-level token would still be used on the login endpoint but it's the only place where it would be used and it will benefit from additional protection (e.g. captcha)

[charlesBochet]

We can leverage the keyValuePairs table to store it

[FelixMalfait]

Potential path:

• Create a new type in keyValuePairs (ENCRYPTION_KEY).
• Look for places where ACCESS_TOKEN_SECRET, LOGIN_TOKEN_SECRET, REFRESH_TOKEN_SECRET, FILE_TOKEN_SECRET are used in the code.
• Retrieve the most recent encryption key for that workspace and concatenate the server secret key + the workspace-level secret key

Think about:

• The transition for existing logged in users (how do me ship this in 2 times to avoid logging out users, create followup issue for deprecation)
• The impact on performance (DB calls to retrieve the token? should it be loaded once along with the workspace for example)