使用 Spring 和 JWT 基于令牌的身份验证

Question

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

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

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

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

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

Answer 1

除了缺少clientid和secret之外，您描述的内容与oauth的密码流程基本相同。 accesstoken 尤其是刷新令牌永远不应该转发到实际的应用程序，无论是应用程序还是 Web 应用程序。

始终在前后通道中思考。 前端通道是您的应用程序运行的地方。 不受信任的环境，例如手机、客户端呈现的应用程序等。

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

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

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

例如：

1. 如果用户登录，他会得到一个会话 cookie 作为回报。
   
2. 之后，他还可以为特殊客户端（在本例中为您的资源服务器或 zuul 代理）以及“read_profile、make_payments”等范围获得一个名为 authCode 的此类。
3. 此 authCode 现在发送到您的资源服务器或（位于端点前面的 zuul 代理）
4. 资源服务器本身拥有自己的客户端凭据，现在针对身份验证服务器进行身份验证并获取访问令牌以交换身份验证代码。

在任何情况下，您的用户都将基于双方的会话进行身份验证，并且您的资源服务器持有用户的访问令牌。