带有刷新令牌的 JSON Web 令牌身份验证逻辑

Question

在浏览器（网站后端）中运行的 Angular 4 应用程序，显示来自特定用户拥有的服务器数据。服务器：PHP+MySQL，Zend Framework 3 + Doctrine ORM

命名：

• access_token：生命周期短（1 分钟），允许访问个人资源，携带 user_id，base64 编码，json 网络令牌规范有效。
• refresh_token：长寿命（1 周）允许在不提供凭据的情况下检索新的 access_token，存储在数据库中，如果需要，管理员可以撤销。

使用 refresh_tokens 的要点是登录时间长于access_token短生命周期（如果refresh_token每次用户授权发生时更新过期时间，则可能永远），用户只需要在不活动时间长于refresh_token生命周期的情况下提供凭据。刷新令牌存储在 db 中，因此可以轻松撤销。

1. 浏览器尝试验证

要求：

• 用户名和密码
• 发送到/api/auth

回复：

验证用户名和密码并对照数据库检查

如果有效：

• access_token 生成的过期时间为 60 秒
• user_id 被编码为 access_token
• refresh_token 生成（随机字符串）并保存到db，过期时间1周，（refresh_token不包含在access_token中，它是一个单独的key）
• HTTP 200 正常

如果无效：

• HTTP 401 未经授权

行动后

如果有效：

• access_token 并refresh_token存储在浏览器中（身份验证服务的私有成员变量，浏览器的本地存储）。

看起来存储refresh_token在本地存储中不是一个好主意- 但这允许“保持登录状态”。如果仅将每个浏览器会话存储在私有成员变量中，则用户每次打开浏览器时都需要登录。有任何想法吗？

如果无效：

• 显示错误，建议重试

2. 浏览器向服务器请求受保护的数据

要求：

• 发送 access_token
• 到/api/资源

回复：

• 如果 access_token 有效，则发送 json 数据，HTTP 200 OK
• 如果 access_token 无效（例如无法解码），HTTP 400 错误请求
• 如果 access_token 过期，HTTP 401 Unauthorized

回应后的行动：

• 如果 HTTP 200：显示数据
• 如果 HTTP 400：重定向到登录页面
• 如果 HTTP 401：使用浏览器中存储的 refresh_token 重试获取新的 access_token

3.重试使用refresh_token认证（HTTP 401 Unauthorized后）

要求：

• 访问令牌
• 刷新令牌

回复：

• 验证access_token（除过期时间外的所有内容，使用 \Firebase\JWT）
• refresh_token对数据库进行验证（从 access_token 解码的 user_id、字符串和到期时间）

如果有效：

生成新的refresh_token，保存到数据库，更新ttl（或者应该是同一个token，只更新ttl？）生成新的access_token HTTP 200 OK

如果无效：

HTTP 401 未经授权

回应后的行动：

如果有效：

• 在浏览器中存储新的 access_key 和 refresh_key
• 使用新的 access_key 重试之前的资源请求

如果无效：

• 显示登录页面

问题

我不喜欢的关键点是 access_token 和 refresh_token 存储在同一位置并以相同的方式发送。也许有另一种方法可以做到？

• 这个逻辑合理吗？
• 假设这发生在网络应用程序中，是否存在任何安全漏洞？
• 我应该将这两个令牌存储在浏览器的本地存储中吗？
• 应该refresh_token编码在access_token？如果它们仍然保存在同一个地方，看起来它可能被合并到access_token中。有什么理由不这样做吗？
• 我应该什么时候更新refresh_token生命周期？
• 任何开源项目都可以看到类似的身份验证？
• 还有其他建议吗？

Answer 1

关于存储令牌的位置和安全缺陷（取自 Github 用户brettpostin https://github.com/IdentityServer/IdentityServer3/issues/2039#issuecomment-288135399）请记住：

• 在 localStorage 中存储令牌容易受到xss的影响。
• 在 cookie 中存储令牌容易受到csrf 的影响。

最好的选择是防止两者，如下所述： http ://www.redotheweb.com/2015/11/09/api-security.html

将您的令牌存储在仅 http 的 cookie 中，并按照此处的建议 使用合适的有针对性的csrf防御：https: //www.owasp.org/index.php/Cross-Site_Request_Forgery_ (CSRF)_Prevention_Cheat_Sheet

我应该什么时候更新refresh_token生命周期？

如果您询问何时更新刷新令牌，则取决于协议的实现，例如 Google Auth 服务器发出的刷新令牌永不过期，当用户撤销对应用程序的访问权限时，它们将被撤销。但我可以建议几周，这样你就不会失去对它的控制。

有没有开源项目可以看到类似的身份验证实际应用？

好吧，你可以下载任何使用 OAuth2 的项目，例如 github 上的这个项目： https: //github.com/authlib/example-oauth2-server

还有其他建议吗？

查看 OpenID Connect 和身份提供商 (IDP)，例如 Keycloack。

希望这对您有任何帮助。