英文:
How can I prevent RequestCache from being overriden
问题
我正在使用Spring授权服务器（OAuth 2.0）实施多因素身份验证。基本上，我有三个端点：
/login
/verify-otp
/oauth2/authorize?{oauth_params}（默认的Spring授权服务器端点）
当用户尝试登录时，他们将被重定向到**/oauth2/authorize并传递所需的参数。Spring授权服务器检查用户是否已经通过身份验证。如果没有，用户将被重定向到另一个端点/login**。此时，RequestCache会缓存来自oauth2端点的请求参数。
除非已重定向到登录页面的用户尝试在未经身份验证的情况下访问**/verify-otp端点，否则一切正常。在这种情况下，RequestCache会缓存来自/verify-otp的请求参数，并再次将用户重定向到/login**端点，这意味着oauth2缓存的参数将被覆盖。结果，当用户再次尝试使用OTP登录时，他们将不会被重定向到OAuth的重定向URI。
是否有一种方法可以防止RequestCache被覆盖，或者是否有更好的解决方案？
英文:
I am implementing multi-factor authentication using Spring Authorization Server (OAuth 2.0). Essentially, I have three endpoints:
/login
/verify-otp
/oauth2/authorize?{oauth_params} (default Spring Authorization Server endpoint)
When a user attempts to log in, they are redirected to /oauth2/authorize with the required parameters. Spring Authorization Server checks whether the user has been authenticated. If not, the user is redirected to another endpoint, /login. At this point, the RequestCache caches the requested parameters from the oauth2 endpoint.
Everything works fine unless a user who has been redirected to the login page tries to access the /verify-otp endpoint without being authenticated. In this case, the RequestCache will cache the requested params from /verify-otp and redirect a user to /login endpoint again, which means that the oauth2 cached params will be overridden. As a result, when the user tries to log in with OTP again, they will not be redirected to the OAuth redirect URI.
Is there a way to prevent RequestCache from being overriden or any better solutions.
答案1
得分: 1
我有一个mfa-sample分支，其中包含一个mfa-authorizationserver示例，演示了一个可行的MFA设置。
注意： 这是一个较旧的分支，与1.0 (main) 不同步。
它基于Spring Security的mfa示例。
目前，Spring Security没有官方的MFA支持，所以要做到这一点有点棘手。
关键元素包括设置自定义的TrustResolver和授权规则，这些规则允许根据用户在登录流程中所处的状态而授予访问权限。
用户在登录流程中的状态可以通过在每个流程步骤的AuthenticationSuccessHandler和每个自定义@Controller端点中设置新的SecurityContext来改变。
看一下这个示例。需要注意的一点是，我的分支是基于Spring Security 5.7的，当SecurityContext设置在SecurityContextHolder上时，它会自动持久化一个SecurityContext。如果你使用Spring Boot 3开始，你将使用Spring Security 6，它要求显式保存SecurityContext（例如securityContextRepository.save(securityContext);）。
（我想在我的示例分支和官方Spring Security示例中添加更多重要文件的链接，但我在星期五晚上打字时GitHub崩溃了...所以我要去做点有趣的事情，而不是不停地刷新等待500错误停止。祝你好运！）
英文:
I have an mfa-sample branch with an mfa-authorizationserver sample that demonstrates a working MFA setup.
Note: It is an older branch and is not up to date with 1.0 (main).
It is based on Spring Security mfa sample.
Currently, Spring Security does not have official MFA support, so it is a bit tricky to get right.
The key elements are setting up a custom TrustResolver and authorization rules that allow access based on the state the user is in while they are going through the login flow.
The state the user is in during the login flow can be changed by setting up a new SecurityContext in the AuthenticationSuccessHandler and each custom @Controller endpoint during each step of the flow.
Take a look at the sample. One thing to watch out for is my branch is based on Spring Security 5.7, which automatically persists a SecurityContext when it is set on the SecurityContextHolder. If you start with Spring Boot 3, you'll be using Spring Security 6, which requires the SecurityContext to be saved explicitly (e.g. securityContextRepository.save(securityContext);).
(I'd like to add more links to important files in my sample branch and the official Spring Security sample, but as I type this GitHub is down on a Friday night... so I'm gonna go do something fun instead of repeatedly refresh waiting for the 500s to stop. Cheers!)
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论