关于创建OAuth 2.0服务器：Token与用户绑定的数据库设计咨询

嘿，这个问题问到点子上了——很多刚搭OAuth2服务的开发者都会纠结Token存储的问题，尤其是想兼顾第一阶段的快速落地和未来的扩展性。先直接给你明确答案：完全可以在单表中实现Token、过期日期与用户的绑定，但要不要这么做得看你后续的业务规划，下面给你拆解两种可行方案：

一、单表绑定方案（适合第一阶段快速落地） #

如果你的第一阶段只需要支持单设备登录、功能简单，完全可以把Token相关字段直接加到用户表中，表结构大概是这样：

CREATE TABLE users (
    id INT PRIMARY KEY AUTO_INCREMENT,
    username VARCHAR(50) UNIQUE NOT NULL,
    password_hash VARCHAR(255) NOT NULL, -- 绝对不要存明文密码！
    access_token VARCHAR(255) UNIQUE,
    refresh_token VARCHAR(255) UNIQUE,
    access_token_expires_at DATETIME,
    refresh_token_expires_at DATETIME
);

优点： #

• 实现简单，不用额外维护关联表，查询用户和Token信息时一次SQL就能搞定
• 适合初期快速验证业务逻辑，减少复杂度

缺点： #

• 同一用户只能同时存在一对有效Token，多设备登录会直接覆盖之前的Token，用户体验差
• 扩展性极差，后续要支持多客户端、多Grant Type（比如Authorization Code）时，几乎要重构表结构

二、关联表方案（推荐长期扩展） #

如果你的API未来要支持多设备、多客户端或者其他OAuth2 Grant Type，强烈建议用单独的Token表和用户表关联，这也是行业通用的规范做法。Token表结构参考：

CREATE TABLE oauth_tokens (
    id INT PRIMARY KEY AUTO_INCREMENT,
    user_id INT NOT NULL,
    access_token VARCHAR(255) UNIQUE NOT NULL,
    refresh_token VARCHAR(255) UNIQUE NOT NULL,
    grant_type VARCHAR(20) NOT NULL DEFAULT 'password', -- 方便后续扩展其他类型
    access_token_expires_at DATETIME NOT NULL,
    refresh_token_expires_at DATETIME NOT NULL,
    client_id VARCHAR(50) DEFAULT 'web_app', -- 预留多客户端支持
    scope VARCHAR(100) DEFAULT '*', -- 权限范围，后续可细化
    FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE
);

优点： #

• 支持同一用户多设备登录，每个设备拥有独立的Token，互不干扰
• 便于管理和 revoke 特定Token（比如用户注销某设备登录）
• 完全符合OAuth2规范，后续扩展其他Grant Type、多客户端时几乎不用改核心结构

缺点： #

• 初期需要多维护一张表，查询时需要关联用户表（但这点性能损耗在大多数场景下可以忽略）

几个关键注意事项 #

• 安全永远是第一位：
  • 密码必须用强哈希算法存储（比如bcrypt、Argon2），绝对不能存明文或者弱哈希（MD5、SHA1）
  • Token必须用密码学安全的随机生成器生成，确保足够不可预测
• 过期Token清理：定期用定时任务清理过期的Token，避免表数据膨胀
• Refresh Token的安全处理：每次用Refresh Token获取新Access Token时，建议生成新的Refresh Token并作废旧的，减少Token泄露带来的风险
• 单表还是关联表？：如果第一阶段只是验证原型，单表没问题；但如果有明确的扩展计划，直接上关联表，后期迁移的成本会低很多

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