java - 使用 Spring 和 JWT 基于 token 的身份验证

Question

我正在使用 spring security 和 JWT 来实现我的移动应用程序的身份验证/授权系统，我对系统的实际设计有一些疑问。这是允许用户访问安全 REST API 的身份验证/授权流程:

1. 移动应用程序使用基本身份验证方案向/auth/token 端点发送请求以及用户的用户名和密码。服务器对返回 JWT 访问和刷新 token 的用户进行身份验证。

2. 对端点/api/** 表示的 protected 资源的所有后续请求都是通过访问 token 执行的，该 token 由服务器验证和信任。验证和信任 token 的逻辑由在 Spring 的 BasicAuthenticationFilter 之前执行的 token 过滤器执行。

3. 如果 token 不再有效，客户端会将刷新 token (JWT) 发送到/auth/refresh 端点，该端点将验证此 token ，如果该 token 可信，则返回新的访问 token 。/auth/refresh 端点是公开公开的，但它依赖于 JWT 签名必须有效且可信的事实。

我也在考虑使用 OAuth，但我想知道这种架构设计是否可以使用，或者它是否会存在漏洞或可扩展性问题。我对身份验证系统还很陌生，我正在尝试了解无需使用 OAuth 即可实现身份验证系统的正确方法。

Answer 1

除了缺少 clientid 和 Secret 之外，您所描述的内容与 oauth 的密码流程基本相同。永远不要将访问 token (尤其是刷新 token )转发到实际应用程序，无论是应用程序还是 Web 应用程序。

始终考虑后 channel 和前 channel 。前端 channel 是您的应用程序运行的地方。不受信任的环境，例如移动电话、客户端呈现的应用程序等。

这些环境可能会受到损害。
因此，您的访问 token 应始终保存在服务器端。

但是:您不一定需要 jwt 来描述用例。
如果您只需要登录，那么使用启用了 csrf 验证检查的 session 登录机制会更安全。

但是，如果您想使用 JWT，我建议您使用 OAUTH 的代码流或确保您的访问 token 存储在受信任的服务器端。

例如:

1. 如果用户登录，他会得到一个 session cookie 作为返回。
   
2. 之后，他还可以为特殊客户端(在本例中为资源服务器或 zuul 代理)获取名为 authCode 的信息以及“read_profile、make_ payments”等范围。
3. 此 authCode 现在已发送到您的资源服务器或(位于端点前面的 zuul 代理)
4. 资源服务器本身拥有自己的客户端凭据，现在根据身份验证服务器进行身份验证，并获取访问 token 以换取身份验证码。

在任何情况下，您的用户都将通过基于 session 的双方身份验证，并且您的资源服务器保存用户的访问 token 。