单页Web应用与受限API服务是否适合采用基础永久Token认证？

核心结论：完全可用，但需做好风险管控 #

DRF的基础Token认证完全适配你的场景，文档里提到它适合客户端-服务端架构（比如原生桌面/移动客户端），但这并不排斥SPA应用——本质上SPA也是运行在浏览器中的客户端，认证逻辑没有本质区别。

适配你需求的合理性 #

• 满足无刷新、永不过期的要求：DRF基础Token默认永久有效（除非手动在后台吊销），刚好匹配你无法使用Session/JWT的限制。
• 同时支持SPA与自定义客户端：不管是SPA在请求头中携带Token，还是用户自有脚本/客户端传入Token，认证逻辑完全一致，无需额外适配两套体系。
• 注册/登录路由的兼容性：注册路由本就无需认证，登录路由可保留用户名密码校验逻辑，校验通过后返回Token给前端存储（如Cookie或localStorage），流程顺畅。

必须重视的风险防护点 #

由于Token永久有效，一旦泄露就等于账号完全失控，务必做好以下防护：

• 强制HTTPS加密：所有请求必须走HTTPS，防止Token在传输过程中被拦截。
• 安全存储Token：SPA中避免用localStorage存Token（易被XSS攻击窃取），改用带HttpOnly、Secure属性的Cookie存储，同时开启DRF自带的CSRF防护并配置到位。
• 提供Token吊销功能：给用户开放手动注销Token的入口，万一Token泄露能及时失效。
• 细化Token权限粒度：如果API有不同权限等级，给Token绑定对应权限范围，避免单Token获取全量权限。

为什么多数文章聊JWT而非基础Token #

JWT的流行源于它支持无状态、可自定义过期时间、适配分布式架构，但你的场景刚好不需要这些特性——你要的是永不过期，而JWT的过期是硬编码在Token内的，即便设极长过期时间也徒增复杂度。所以基础Token反而更贴合你的需求，没必要跟风用JWT。

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