token认证方案的探讨
在API授权过程中，用户登录后生成一个键值对存储在Redis中是一种常见的做法。但对于如何避免token被截获和伪造，存在一些疑虑。
为了解决这个问题，有一种方案是在每次请求时使用(userid+token+时间戳+密钥+请求参数)进行签名，并由服务端验证token和签名。
疑虑：密钥泄露风险
疑问的重点在于密钥是否需要随token一起返回给登录接口。答案是不。
原因：
密钥是一个敏感信息，如果暴露可能会导致严重的安全性问题。服务端需要妥善保管密钥，防止其被截获。
改进方案：JWT扩展结合Redis
为了解决token可控失效的问题，可以在JWT的基础上进行扩展，配合Redis实现Token黑名单机制。这样，指定的Token可以在到期前失效。
Safe Exam Browser是一个安全的浏览器环境，用于安全地进行在线考试。该软件将任何计算机变成一个安全的工作站。它控制对任何实用工具的访问，并防止学生使用未经授权的资源。
HTTPS的安全性保障
为了防止token在传输过程中被截获，应使用HTTPS。HTTPS通过加密方式确保数据在传输过程中的安全性，即使token被截获也无法被解密。
客户端存储token的陷阱
将token存储在客户端的Cookie中存在被截获的风险。一种解决方案是将其存储在LocalStorage或SessionStorage中，但仍存在XSS漏洞的风险。
签名方案的可行性
使用(userid+token+时间戳+密钥+请求参数)进行签名是一个可行的方案，但对于移动端来说，需要始终携带密钥，存在密钥泄露的隐患。
最简化的解决方案
最可靠的解决方案往往是最简单的，即使用HTTPS。HTTPS可以有效防止token在传输过程中的截获，且无需额外的密钥管理和签名验证。
