同一账号多设备登录时Access Token的处理方案咨询

针对你提到的场景——同一账号在多台设备登录时的access token管理，结合你现有的Mongoose Schema，我来分享几个业界常用且贴合实际需求的处理方案：

方案1：为每台设备生成独立令牌（推荐） #

这是最通用且用户友好的做法，核心思路是每个设备对应一条独立的OAuthTokens记录，让令牌与设备强绑定。

为什么这么做？ #

• 支持设备追踪：用户可以在账号中心查看所有登录过的设备（比如"iPhone 14"、"Windows Chrome"），提升账号安全性。
• 精准权限控制：用户可以单独注销某台设备的登录状态，不会影响其他设备的使用（比如丢失手机后，仅注销该设备的令牌）。
• 审计与排查：出现异常登录时，能快速定位到具体设备，方便后续排查。

如何修改你的Schema？ #

你需要在现有Schema中添加设备相关字段，用来标识不同设备：

mongoose.model('OAuthTokens', new Schema({
    accessToken: { type: String, required: true },
    accessTokenExpiresOn: { type: Date, required: true },
    client : { type: Object },
    clientId: { type: String, required: true },
    refreshToken: { type: String, required: true },
    refreshTokenExpiresOn: { type: Date, required: true },
    user : { type: Object },
    userId: { type: String, required: true },
    // 新增设备标识字段
    deviceId: { type: String, required: true }, // 设备唯一ID（可由前端生成UUID或设备指纹）
    deviceInfo: { 
        type: Object,
        default: {
            deviceType: '', // 手机/平板/PC
            os: '', // iOS/Android/Windows
            browser: '', // 网页端浏览器信息
            lastActiveAt: { type: Date, default: Date.now } // 设备最后活跃时间
        }
    },
    // 可选：软删除标记，方便审计
    revoked: { type: Boolean, default: false }
}));

业务逻辑配合 #

• 用户登录时，前端需要传递设备标识（比如生成一个UUID作为deviceId，同时收集设备类型、系统等信息）。
• 后端收到登录请求后，为该设备生成独立的access token和refresh token，并存入OAuthTokens表。
• 当用户需要管理登录设备时，通过userId查询所有未被revoked的令牌记录，展示设备列表。
• 用户注销某台设备时，通过userId + deviceId找到对应记录，标记revoked: true或直接删除。

方案2：单令牌多设备共享（仅适用于强制单设备场景） #

这种方案是同一账号只保留最新的access token，新登录会覆盖旧令牌，导致其他设备立即失效。

适用场景 #

仅适合强制单设备登录的业务（比如银行、企业内部系统），但不推荐普通C端应用——用户体验极差，比如用户在手机登录后，PC端的登录状态会被强制下线。

实现方式 #

登录时，先根据userId删除所有旧的OAuthTokens记录，再创建新的令牌记录即可。但这种做法完全放弃了多设备支持，灵活性很低。

方案3：基于Refresh Token关联设备 #

因为access token有效期通常较短（比如15分钟），而refresh token有效期较长（比如7天），可以让每个设备对应独立的refresh token，access token则可以在刷新时重新生成，但始终绑定该设备。

核心逻辑 #

• 设备首次登录时，生成一对绑定该设备的access token和refresh token。
• 当access token过期时，设备用自己的refresh token请求新的access token，后端验证refresh token有效性后，生成新的access token（可选：同时生成新的refresh token，旧的失效）。
• 要注销某台设备时，只需失效对应的refresh token，该设备就无法再获取新的access token，旧的access token过期后自动失效。

这种方案和方案1本质类似，但更聚焦于refresh token的设备绑定，适合对access token生命周期管理更严格的场景。

额外最佳实践 #

• 缩短access token有效期：建议设为15-30分钟，减少令牌被盗用的风险。
• 安全存储refresh token：后端返回refresh token后，前端应存在HttpOnly、Secure的Cookie中，避免XSS攻击。
• 密码变更触发全设备注销：当用户修改密码时，应将该账号下所有未revoked的令牌标记为失效，防止旧设备继续使用。

内容的提问来源于stack exchange，提问作者ANSHU GOYAL