OAuth2Login should process authenticated requests

[wangzw]

Use case:

We have a system A use OAuth2Login to implement user login(Code flow). And another system B works as OAuth2 provider.

Step 1: A supervisor login system A. Everything works well.
Step 2: Supervisor close browser without logout. System A session is still available.
Step 3: A non-privilege user login system B to do something, Everything works well. Session of system B is reset to non-privilege user.
Step 4: The non-privilege user login system A from login page, but found that the login user is actually supervisor. (Reuse the previous supervisor session)

Expected: At step 4, since non-privilege user start a new login process from login page, we expected non-privilege user login finally.

After debug, we found that at step 4, the login process of system A have got the oauth2 code (Code flow) and redirected to the redirect url, but the redirect url is not processed correctly and skipped since the following code.

spring-security/config/src/main/java/org/springframework/security/config/web/server/ServerHttpSecurity.java

Lines 851 to 855 in b1195e7

	PathPatternParserServerWebExchangeMatcher loginPathMatcher = new PathPatternParserServerWebExchangeMatcher("/login/oauth2/code/{registrationId}");
	ServerWebExchangeMatcher notAuthenticatedMatcher = e -> ReactiveSecurityContextHolder.getContext()
	.flatMap(p -> ServerWebExchangeMatcher.MatchResult.notMatch())
	.switchIfEmpty(ServerWebExchangeMatcher.MatchResult.match());
	return new AndServerWebExchangeMatcher(loginPathMatcher, notAuthenticatedMatcher);

Since the existence of the previous session, the process of redirect url is skipped. And the previous session is reused incorrectly.

AFAIK the process of redirect url is used to validate oauth2 code and retrieve user/token info and cannot be skipped. So it looks a security issue.

And since the process of redirect url is skipped, the saved authentication request cannot be removed from (in memory) session and potential run out server memory.

[rwinch]

Thanks @wangzw! @jgrandja will take a look soon

[jgrandja]

@wangzw The one thing that I would like to point out (in case you are not aware) is that when a user authenticates via oauth2Login(), 2 sessions are created. The first session is with the provider and the second session is with the application.

Given your use case, if supervisor logs out of the application (but not with the provider) and a non-privilege user attempts to authenticate via the application than authentication will automatically happen given that there is an existing session cookie (in the browser) with the provider. This session cookie (created for supervisor) is used to authenticate the non-privilege user which than follows up with the auth-code flow to complete OpenID Connect authentication.

NOTE: This only happens when using the same browser session/window. I believe in your scenario, you are also testing this using the same browser/window session? Can you please test your scenario using a different browser (or new session window) and let me know your results?

FYI, we also introduced support (in 5.2.0.M2) for RP (Client) initiated logout via #5350, which would allow you to configure the application to logout at the provider whenever the user logs out of the application.

[wangzw]

@jgrandja

Thanks for your reply. I'm aware that two different sessions exist for application and provider.

At Step 3, a non-privilege user login system B (Provider), so the session of provider is for non-privilege user.

a non-privilege user attempts to authenticate via the application than authentication will automatically happen given that there is an existing session cookie (in the browser) with the provider.

Yes, it is expected.

But finally application shows that the login user is supervisor.

The reason is that since the session of system A (application) for supervisor still available during login process, the login process is aborted due to following code.

spring-security/config/src/main/java/org/springframework/security/config/web/server/ServerHttpSecurity.java

Lines 851 to 855 in b1195e7

	PathPatternParserServerWebExchangeMatcher loginPathMatcher = new PathPatternParserServerWebExchangeMatcher("/login/oauth2/code/{registrationId}");
	ServerWebExchangeMatcher notAuthenticatedMatcher = e -> ReactiveSecurityContextHolder.getContext()
	.flatMap(p -> ServerWebExchangeMatcher.MatchResult.notMatch())
	.switchIfEmpty(ServerWebExchangeMatcher.MatchResult.match());
	return new AndServerWebExchangeMatcher(loginPathMatcher, notAuthenticatedMatcher);

Since at step 4, the non-privilege user start a new login process to application, the login process should not be aborted no matter a previous session exists or not.

[wangzw]

Let me make the issue clear.

OAuth2 login has 3 steps (code flow):

1. Authenticate and get code from provider.
2. validate code and get access token.
3. validate token and get token/user information.

Current issue is that since there is a previous session, step 2 and 3 is skipped. And the existence session is reused.

I do not think that step 2 can be skipped in any case.

Two consequences:

1. If pervious session is for user A and user B start login process in same browser/window. Login process finish successfully but the session is still for user A. The action of reset session happen in step 2/3, but skipped.

2. At step 1, an authorization request is stored in (in-memory) session and expected be removed at step 2. But since step 2 is skipped, the authorization request is not removed from session. So it can be used to blow up server's memory.

[jgrandja]

@wangzw

The reason is that since the session of system A (application) for supervisor still available during login process, the login process is aborted due to following code.

In this scenario the login process is never started (or aborted) given that there is an established session from the supervisor on the previous step. Please keep in mind that the authentication process will not initiate if there is already an authenticated session.

Since at step 4, the non-privilege user start a new login process to application, the login process should not be aborted no matter a previous session exists or not.

Can you please provide details on exactly how you start a new login process with the non-privilege user? The fact that there is already an established session from supervisor and you do not log out, how do you start a new login process with non-privilege user without logging out supervisor first?

Also, this really isn't a valid real world use-case IMO. If a supervisor logs into an application and performs some tasks but than wants to log into the application with lesser privileges than they would typically logout first and than log back in using the non-privilege user.

At this point, I do not see any issues with the current implementation. This will likely get closed as Works as Designed but I'll wait for your reply.