用户登录服务以数据库User表为核心围绕账号密码的存储与校验实现注册与登录两大基础功能。意义身份认证账号是识别用户身份的关键凭证保障账户安全与数据隔离。个性化服务基于用户信息与行为数据提供定制化推荐与专属功能。数据积累通过收集使用数据洞察用户需求驱动产品持续优化迭代。常规的实现方式数据存储层User表字段名数据类型约束条件含义说明idBIGINT主键自增用户唯一标识IDusernameCHAR(100)唯一用户账号用于注册和登录的唯一字符串如微信号passwordCHAR(100)非空用户密码statusINT非空用户状态枚举0:未登录1:已登录2:已注销3:已冻结4:已封禁等用户注册流程用户在注册页填写账号、密码和验证码并提交后后台先校验账号是否已存在若存在则返回报错不存在则写入账号、密码及未登录状态完成后返回注册成功。用户登录流程用户在登录页输入账号、密码和验证码并提交后后台会校验账号密码是否匹配并将未登录状态更新为已登录若更新成功则返回登录成功失败则提示账号或密码错误、账号异常。优点该流程仅依赖数据库操作通过一条INSERT语句完成注册、一条UPDATE语句完成登录校验与状态更新。真实痛点用户ID依赖自增主键会泄露用户数量。使用雪花算法HTTP是明文传输可能会导致用户账号和密码泄露。明文在数据库存储用户密码安全性低。传统的“账号密码”登录方式因记忆负担重、操作繁琐。需要多种便捷登录方式在微服务架构下若各服务直接查询User表校验登录态高频请求会迅速击垮数据库。期望功能密码安全任何时候都不可以将用户密码暴露给任何人包括服务设计方。以多种方式登录需要具有支持手机号登录、邮箱登录、第三方登录和扫码登录的能力。支持登录态查询用户登录态是一个热门话题需要使用高性能、高可用的方式支持这个需求。密码保护无论是客户端与服务端之间通过网络传输密码还是将密码保存到数据库中都需要保证密码安全使用HTTPS通信目的客户端发送注册、登录请求到服务端时防止第三方抓包工具获取到密码。特点HTTPS是身披SSL外壳的HTTP, 在HTTP通信链路中利用SSL/TLS建立全信道加密数据包在请求传输过程中第三方抓包工具看到的是密文。缺点HTTPS只能保证在数据传输期间的安全性但是数据包在客户端进行加密之前是明文容易被拦截。非对称加密目的HTTPS只能保障传输链路的安全无法防止端点客户端/服务端被劫持。因此我们需要引入非对称加密让密码在离开客户端之前就变成密文确保只有持有私钥的服务端才能解密从而杜绝中间人攻击和端点窃密。定义对数据的加密和解密使用了两种钥匙分别是公钥和私钥。公钥服务器下发给客户端。私钥服务端自己持有只有私钥才可以解密公钥加密的数据。非对称加密实现用户注册与登录请求安全传输的流程客户端从服务端获取公钥。客户端利用公钥对用户提交的密码进行加密。客户端使用HTTPS向服务端请求注册与登录。服务端解密HTTPS,得到HTTP明文数据包。用户登录服务处理数据包使用私钥解密得到原始密码HTTPS 负责把数据“安全地运过去”应用层非对称加密负责把数据“锁好了再运”。密码加密存储目的明文在数据库存储用户密码安全性低。解决使用单向加密算法对数据加密存储加密之后的数据。单向加密算法加密之后无法解密例如MD5SHA1等。登录将输入的密码加密后与数据密码比较相同则一致。多种方式登录手机号登录和邮箱登录数据库表设计为了支持以手机号、邮箱等类似方式登录的功能在数据库中需要额外创建一个用户 授权表User_auth字段名类型说明索引建议idBIGINT自增主键PKauth_idCHAR(100)唯一凭证手机号/邮箱/OpenIDUnique Indexauth_typeINT授权类型1:手机, 2:邮箱, 3:微信...复合索引项user_idBIGINT关联 User 表的主键Normal Indexauth_statusTINYINT认证状态0:未通过, 1:已通过-用户注册发起注册与校验用户操作在注册页面输入手机号点击“发送验证码”。后端校验系统查询User_auth表确认该手机号未被注册。生成凭证若手机号可用系统生成用户ID在User_auth表中插入一条状态为“待验证”的记录。发送验证码缓存与发送系统生成随机验证码存入Redis以手机号为Key并调用第三方接口发送短信。验证与激活用户操作用户输入收到的验证码并提交。后端比对从Redis取出验证码进行比对。若一致将User_auth表中的授权状态(auth_type)更新为“通过”。跳转设置页面提示“请设置密码”并跳转。完成注册用户操作用户输入初始密码并提交。写入数据系统在User表中插入用户账号数据默认用户名为“手机用户—{手机号}”注册流程结束。用户登录手机号和密码登录用户输入手机号和密码点击“登录”按钮发起请求。系统根据手机号在User_auth表中查询授权用户ID确认该手机号是否已注册。SELECT user_id FROM User_auth WHERE auth_id手机号 AND auth_typel系统根据用户ID在User表中查询存储的密码并与用户输入的密码进行比对。如果两次密码一致则验证通过用户登录成功。手机号和验证码登录:用户输入手机号点击发送验证码服务端查询手机号是否授权 auth_id 手机号AND auth_type1.已授权生成验证码保存在Redis发送短信给用户。用户输入验证码点击登录。校验验证码User表的status1表示已经登录。这里对于注册和登录分别实现当然也可以只实现登录发现用户没有注册则后台先注册后登录。登录态管理背景由于 HTTP 协议本身不具备“记忆力”服务端无法自动关联同一个用户的多次请求来共享数据。解决既然协议不记录就必须由客户端在每次请求中主动“自报家门”。Session本质服务端的一个存储结构类似哈希表保存用户会话期间的上下文信息。生命周期用户登录时创建退出或超时后销毁。存储内容用户ID、设备ID、IP地址。平台类型Android/iOS/PC、登录方式。创建/更新时间。核心流程该流程依赖Cookie客户端 与Session服务端 的配合客户端请求用户发起登录账号/验证码/扫码。服务端创建登录成功服务端在Redis中创建 Session并生成唯一的 SessionID。下发 ID服务端通过Set-Cookie: SessionIDxxx将 ID 发给客户端。携带 ID客户端后续请求自动在 Cookie 中携带该 SessionID。服务端校验命中查到 Session读取用户 ID正常处理请求。未命中判定未登录或超时要求重新登录。痛点cookie 存在客户端用户可随意修改 SessionID导致冒充他人风险。解决数字签名SessionID Secret生成服务端用加密算法如 MD5对 SessionID 加密取前 N 位作为签名。下发格式SessionIDsid-secret。校验服务端收到请求后重新计算签名。若计算结果 ≠客户端携带的secret→→ 判定为被篡改强制重新登录。优点服务端可控可主动踢人下线统计在线人数。缺点强依赖 RedisRedis 慢或网络抖动直接导致登录不可用。资源消耗海量用户下频繁查询 Redis 压力大浪费存储资源。令牌核心结构以32字节为例头部Header定义元数据如签名算法HMAC-SHA256。载荷Payload约24字节存放声明Claims。包含用户ID、设备ID、过期时间Exp等非敏感信息。签名Signature约8字节计算公式签名 算法(头部 载荷 密钥)。作用验证数据完整性防止被篡改。基本流程签发Login用户登录成功。构建与编码将Header算法信息和Payload用户信息分别进行Base64Url 编码。拼接用点号.将两者连接形成待签名字符串Data。签名利用密钥并调用指定的签名算法对Data进行计算生成签名值。组装将Data与Base64 后的签名值用点号再次拼接生成最终令牌Token返回。存储Store客户端浏览器/App将令牌保存在本地如 LocalStorage 或 Cookie。携带Request客户端发起后续请求时在请求头Header中携带令牌通常为Authorization:验证Verify服务端接收请求提取令牌。验签用同样的密钥重新计算签名对比是否与令牌中的签名一致确保未被篡改。验时检查过期时间是否大于当前时间戳。响应Response验证通过则解析出用户ID处理业务验证失败则返回 401 未授权。优点性能卓越服务端通过本地计算即可验证用户身份延时开销极低资源节约完全不依赖存储系统大幅降低基础设施成本缺点无法主动管理用户服务端无法主动踢用户下线只能等待令牌过期。令牌泄露风险一旦令牌泄露攻击者可在有效期内冒充用户长短令牌一、核心思想方案本质该方案通过“双层验证机制”将短令牌作为长令牌的高频访问缓存兼顾了高性能校验与服务端实时可控性。关键设计Short Token无状态令牌本质包含UID、DeviceID、ExpireTime及数字签名的加密字符串。生命周期短如 1 天。作用实现无状态快速校验降低 Redis/数据库压力。Long Token有状态 Session本质对应服务端 Redis 中的SessionID。生命周期长如 30 天。作用作为登录态的“最终裁决者”支持服务端强制下线。标准工作流程登录授权服务端校验凭证成功后生成long_token存入 Redis和short_token加密签名后同步下发至客户端。高频请求命中短令牌* 服务端优先校验short_token的签名与有效期。若有效直接放行无需查询 Redis性能极高。令牌续期短令牌过期若short_token过期服务端检查long_token。解析long_token并在 Redis 中查询对应的 Session。若 Session 存在且有效服务端自动签发新的short_token随响应返回客户端无感更新。异常处理若long_token失效过期或被删除则拦截请求要求重新登录。核心优势分析高性能与高可用绝大部分请求通过short_token本地校验完成极大地缓解了中心化存储Redis的带宽与 IO 压力。服务端强管控弥补了纯 JWT 方案无法主动失效的缺陷。通过删除 Redis 中的 Session可在short_token下一个过期周期内实现“强制下线”。用户无感续航只要用户在 30 天内有活跃操作系统会不断滚动更新短令牌避免了频繁登录的糟糕体验。总结登录认证方式账号密码登录这是最常规的登录方式用户体验一般。实现此登录方式的重点 是保障用户的账号密码不被泄露包括使用非对称加密算法加密账号密码明文 使用HTTPS加密通信链路以及使用单向加密算法存储密码。手机号登录和邮箱登录手机号和邮箱有易于验证使用者身份的优势所以此登 录方式需要下发动态验证码以及存储用户授权记录。登录态管理方案用户登录成功后如何识别后续请求的合法性是系统设计的关键方案一Session 模式有状态机制服务端 Redis 存储 Session 对象客户端 Cookie 携带SessionID。优点强管控。服务端可随时删除 Session 实现强制下线、限制多端登录。缺点高并发下 Redis IO 压力大增加请求延迟。方案二Token 模式无状态机制服务端通过密钥将用户信息签名生成 Token如 JWT客户端在 Header 携带。优点高性能。服务端仅需 CPU 计算校验签名无需查库/查缓存横向扩展性好。缺点不可控。Token 一旦签发在有效期内无法被服务端主动撤销。方案三长短令牌方案混合模式利用“短令牌缓存 长令牌持久化”短令牌AccessToken有效期短如 1 天采用 Token 模式负责高频请求的高性能校验。长令牌RefreshToken/SessionID有效期长如 30 天采用 Session 模式负责在短令牌过期时进行“续期”判定。核心逻辑只要 Session长令牌未被后台删除用户即可通过自动续期获得新的短令牌实现无感登录。