我正在使用Spring Authorization Server（OAuth 2.0）实现多因素身份验证。
/login
/verify-otp
/oauth2/authorize?{oauth_params} (default Spring Authorization Server endpoint)当用户尝试登录时，他们将被重定向到**/oauth2/authorize**，并带有所需的参数。Spring Authorization Server将检查用户是否已通过身份验证。如果没有，用户将被重定向到另一个端点**/login**。此时，RequestCache将缓存从oauth2端点请求的参数。
除非已重定向到登录页的用户尝试在未经身份验证的情况下访问**/verify-otp端点，否则一切正常。在这种情况下，RequestCache将缓存来自/verify-otp的请求参数，并再次将用户重定向到/login**端点，这意味着oauth2缓存的参数将被覆盖。因此，当用户再次尝试使用OTP登录时，他们将不会被重定向到OAuth重定向URI。
是否有办法防止RequestCache被覆盖或任何更好的解决方案。
1条答案
按热度按时间xxhby3vn1#
我有一个mfa-sample分支，其中有一个mfa-authorizationserver示例，演示了一个工作的MFA设置。
**注意：**这是一个较旧的分支，尚未更新到1.0（
main）。它基于Spring Security mfa sample。
目前，Spring Security还没有官方的MFA支持，所以要正确使用它有点困难。
关键要素是设置custom
TrustResolver和授权规则，这些规则允许根据用户在登录流程中所处的状态进行访问。用户在登录流程中所处的状态可以通过在流程的每个步骤中在
AuthenticationSuccessHandler和每个自定义@Controller端点中设置新的SecurityContext来更改。看一下这个例子。注意的一件事是我的分支基于Spring Security 5.7，当
SecurityContextHolder上设置了SecurityContext时，它会自动持久化。如果你从Sping Boot 3开始，你将使用Spring Security 6，它要求显式保存SecurityContext（例如securityContextRepository.save(securityContext);）。（我想在我的示例分支和Spring Security官方示例中添加更多重要文件的链接，但是当我输入这个GitHub时，它在周五晚上关闭了......所以我打算做一些有趣的事情，而不是反复刷新，等待500秒停止。干杯！）