The scope problem
Most Gmail integrations request the full https://mail.google.com/ scope because it's the path of least resistance. That scope grants read, write, delete, and send access to the entire mailbox — far more than any product actually needs.
NexusSend requests only two scopes: gmail.send for outbound delivery and gmail.readonly for inbox summaries. This is a deliberate product constraint, not an afterthought. Narrower scopes mean a smaller attack surface, a simpler Google verification submission, and a more honest relationship with users.
Token encryption
OAuth tokens are sensitive credentials. Storing them in plaintext in a database is a common mistake that turns a database breach into a full account takeover.
NexusSend encrypts every token field — access_token, refresh_token, and id_token — using AES-256-GCM before writing to the Account table. The envelope format is enc:v1:<iv>:<tag>:<ciphertext>. Decryption only happens server-side, in memory, immediately before constructing a Google API client. Tokens are never returned to the frontend.
The encryption key is a 32-byte secret stored in TOKEN_ENCRYPTION_KEY. Rotating it means re-encrypting existing rows; the repository README documents a one-off approach you can adapt for your environment.
Session & API guards
Every tRPC procedure that touches Gmail is a protectedProcedure. This means the session is validated before any business logic runs. There is no way to reach the Gmail layer without an authenticated session.
On top of that, every database query that fetches templates, logs, or drafts includes a userId filter. Even if a procedure is called with a valid session, it cannot read another user's data.
What's next
We are working on automated token rotation health checks, alerting for repeated auth failures, and a user-facing reconnect flow that surfaces scope health diagnostics directly in the dashboard.