Long-lived Resume Tokens vs. Short-lived Session Expiry for Least-Privilege Access

Meteor's accounts-base package implements a session management system based on hashed login tokens stored in users.services.resume.loginTokens. By default, these tokens allow clients to silently re-authenticate via DDP for approximately 90 days, which may conflict with security requirements for applications requiring strict least-privilege access and frequent credential validation.

There are two primary documented approaches to managing this lifecycle:

• Global Expiry Configuration: Using Accounts.config({ loginExpirationInDays }) to shorten the validity of all issued tokens globally.
• Manual Server-Side Revocation: Utilizing Accounts._expireTokens or user-initiated logouts to invalidate specific sessions on demand.

While global expiry reduces the window of vulnerability for stolen tokens, it introduces friction for all users. Conversely, relying on long-lived tokens with manual revocation requires a robust event-driven system to trigger invalidation when user privileges change or security events occur.

Technical Uncertainties

When implementing a least-privilege model in Meteor (likely version 2.x or 3.x), the trade-off between these methods impacts how reactive subscriptions and Method calls are authorized.

• Does shortening loginExpirationInDays provide sufficient granularity for high-security roles, or is a custom token rotation strategy necessary?
• How does the latency between server-side token revocation and the termination of existing DDP subscriptions affect the enforcement of immediate privilege removal?