Refresh Token Storage Strategy

[ShantKhatri]

Summary

We need to decide and document how DevCard stores OAuth refresh tokens securely on the backend. This is foundational for the in-app connect feature (GitHub follow, future LinkedIn/Twitter actions) described in the architecture doc, and we want community input before locking in the approach.

Contexts

Per the product architecture, DevCard never stores passwords, only OAuth tokens issued by platforms (GitHub, LinkedIn, etc). These tokens need to be encrypted at rest, scoped per platform, revocable by the user at any time, and never exposed to client apps.

This issue is open for discussion. We want proposals on:

• Encryption strategy (e.g. AES-256 at the application layer vs database-level encryption vs a dedicated secrets manager)
• Where encryption keys themselves are managed (env-based KMS, cloud provider KMS, self-hosted vault)
• Token refresh flow: how we detect expiry and silently refresh without forcing re-auth
• Schema design: how tokens map to users and platforms in PostgreSQL
• Revocation flow: what happens end to end when a user disables in-app connect for a platform

Open a comment with your proposal, or open a draft PR if you want to demonstrate an approach. We'll discuss in the weekly call and the best proposal gets priority assignment to implement it, including any related sub-tasks the proposer identifies.

Tasks

• Research encryption-at-rest options compatible with our PostgreSQL + Fastify stack
• Propose a token schema (tables, fields, relationships)
• Propose a key management approach
• Design the refresh flow (detection + silent refresh)
• Design the revocation flow
• Document the chosen approach in /docs/architecture/token-storage.md

Acceptance Criteria

• A documented, agreed-upon token storage design exists before implementation begins
• Design covers encryption, key management, refresh, and revocation
• Design reviewed and approved by a maintainer
• Tests added once implementation starts (tracked in a follow-up issue)
• docs updated

Area

backend

Difficulty

Hard (discussion + design phase, implementation will be split into follow-up issues)

[github-actions]

Hi @ShantKhatri,

Thanks for opening this issue.

Please reply with one of the following areas so the issue can be routed to the appropriate team member:

- /backend
- /web
- /mobile
- /devops

Once an area is selected, the corresponding label will be added automatically.