客户端如何存储认证令牌？明文存储是否需额外防护服务器？

一、客户端明文存储session-token时的服务器防护措施 #

结合你给出的背景（TLS传输、1天token有效期、请求限流），已经具备了基础安全防护，但客户端被攻陷后，攻击者拿到明文token就能直接以合法用户身份访问服务器，仍需补充以下措施降低服务器风险：

• 绑定客户端特征：将session-token与客户端设备指纹（如硬件标识哈希、操作系统版本哈希等）绑定，服务器校验请求时同时验证token和对应特征。注意特征需做哈希处理，避免明文传输或存储，且选择不易伪造的标识。
• 快速吊销机制：提供用户主动注销功能，同时后台支持手动吊销指定token。一旦用户发现客户端异常，可立即失效涉事token，缩短危害窗口。
• 最小权限原则：为session-token分配完成业务所需的最小权限，比如仅赋予数据读取权限而非全量操作权限，限制token泄露后的危害范围。
• 异常行为监测：监控token的使用模式，比如陌生IP访问、请求频率偏离用户常规习惯等，触发异常后自动告警或强制失效token。

二、关于签名session-key存储方案的分析 #

你提出的方案存在几个核心问题：

1. 逻辑混淆：签名本身是不可逆的验证机制（如RSA签名仅能验证合法性，无法还原原始内容），如果要实现"解密恢复session-key"，实际是加密而非签名操作。但无论加密还是签名，客户端存储的加密/签名后的数据被窃取后，攻击者依然可以通过你的解密API获取有效session-key，本质上和明文存储token的风险没有区别。
2. 新增攻击面：解密API需要额外的认证逻辑来验证请求合法性，否则攻击者可拿着窃取的加密数据反复请求解密，反而增加了系统复杂度和潜在风险点。
3. 未解决核心问题：客户端被攻陷后，攻击者总能利用存储的凭证（不管是明文token还是加密/签名后的密钥）向服务器获取有效访问权限，服务器无法区分合法请求与攻陷后的请求。

更优的免重复认证方案 #

• 采用Refresh Token机制：服务器返回短期有效的session-token（即你当前的access token）和长期有效的refresh token。客户端将refresh token存储在平台提供的安全容器中（如iOS Keychain、Android Keystore），当session-token过期时，用refresh token请求新的session-token。这种方式既避免了频繁认证，又将长期凭证的风险限制在安全存储层面。
• 使用客户端安全存储：不要明文存储token，优先利用系统提供的加密存储API，这类存储仅对你的应用开放访问，能大幅降低token被直接窃取的概率。

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