Security

There are some important principles to be aware of when handling auth.

The codebase contains guardrails and conventions in place to prevent you having to worry too much about most of this, but here's a quick rundown on some of the important concepts just in case you're unsure.

Session secrets

In your .env you'll notice a variable called SESSION_SECRET. This is used to sign and verify the session cookies to make sure they haven't been tampered with. You don't need to worry too much about how this works, but it's important to never expose this anywhere. It should always be stored as an environment variable and never hardcoded or committed in the code.

If you ever commit or reveal this value anywhere, you should generate a new one. This will invalidate all sessions, which will inconvenience your users, but you'll likely never have to do it.

A safe way to generate a valid string for the SESSION_SECRET is using the openssl library

openssl rand -base64 64 | tr -d '\n' ; echo

Multi-tenancy

All users and organizations exist in the same database side-by-side. When reading or modifying records in the database, it's crucial that there is always some sort of where clause, based on the current users ID or their defaultOrganizationId, to prevent users from accessing or modifying other user's data. There are plenty of examples of how this is done throughout the existing database calls so if you are unsure please check them.

You can read more about users and multi-tenancy here

Verification tokens

Users registering via email password, in comparison to OAuth, require email verification. OAuth users do not require this verification step as we can safely assume they are in control of the account being registered.