OAuth2ClientAuthenticationToken should not be persisted across requests

[mbarringer]

Describe the bug
Sometimes the server returns a 500 error with the message:

java.lang.IllegalArgumentException: The class with org.springframework.security.oauth2.server.authorization.authentication.OAuth2ClientAuthenticationToken and name of org.springframework.security.oauth2.server.authorization.authentication.OAuth2ClientAuthenticationToken is not in the allowlist. If you believe this class is safe to deserialize, please provide an explicit mapping using Jackson annotations or by providing a Mixin. If the serialization is only done by a trusted source, you can also enable default typing. See spring-projects/spring-security#4370 for details

To Reproduce

I encountered the bug while testing a resource server in conjunction with a new Spring Authorization Server's authorization code flow. The API tool I use automatically does the OAuth2 authentication, using the same session cookie from last time when it gets a new token, and that then stops working due to the 500 error. This is a contrived example, but it does trigger the bug reliably:

1. Modify the sample authorization server, adding .redirectUri("https://oidcdebugger.com/debug") to the RegisteredClient and then run the server.

2. Open a browser, go to https://oidcdebugger.com/debug, open the network tab of the browser inspector.

3. Fill the form in, log-in, and get an authorization code.

4. Look in the browser inspector to get the JSESSIONID cookie from /oauth2/authorize.

5. I'm not sure how quickly the next steps need to be done, but now POST directly to the /oauth2/token endpoint. Run curl or your preferred API client:

export AUTHCODE="YOUR CODE HERE" && curl -X "POST" "http://127.0.0.1:9000/oauth2/token" \
-H 'Cookie: JSESSIONID=COOKIE FROM BROWSER' \
-H 'Content-Type: application/x-www-form-urlencoded; charset=utf-8' \
-u 'messaging-client:secret' \
--data-urlencode "grant_type=authorization_code" \
--data-urlencode "code=$AUTHCODE" \
--data-urlencode "redirect_uri=https://oidcdebugger.com/debug"

5. A token should be correctly returned.

6. Click "Start Over" in the browser, which will hopefully cause the browser to send the same JSESSIONID with the new call to /oauth2/authorize, and get the new authorization code. Try the POST again with the new code and the same JSESSIONID. It should return a 500 error, and in the logs will be the exception.

Expected behavior

I expected to get a new token, and if not, an error message rather than an exception.

[sjohnr]

Thanks for the report, @mbarringer.

I was able to reproduce this with the existing sample, and created a reproducible collection in postman. I don't yet have a reason for the issue, so more research is needed. I feel this is an issue we will need to solve because it seems like it could happen in a public client like a single page application from the browser, which would conceivably be reusing cookies on every request as your test does.

[edwardzjl]

I ran into the same issue.

I found that there's some difference on the attributes column of the oauth2_authorization table between the fresh request of an access token (no session yet, and will succeed) and the following requests (which will fail).

The fresh request will persist attibures with java.security.Principal of org.springframework.security.authentication.UsernamePasswordAuthenticationToken, and the following requests will persist attributes with java.security.Principal of org.springframework.security.oauth2.server.authorization.authentication.OAuth2ClientAuthenticationToken, which then causes the OAuth2ClientAuthenticationToken is not in the allowlist error.

[edwardzjl]

It seems that the attributes column is not properly (serialized and) deserialized. I'm interested in making a PR of this issue.

[sjohnr]

Thanks @edwardzjl. I believe that is likely the explanation for what's going on. Ultimately, there may be something we need to check to ensure consistency between requests, but I think it's reasonable for now to add the OAuth2ClientAuthenticationToken as a class that can be serialized. Take it away!

[colin-riddell]

Hi folks. Using @sjohnr's JpaOAuth2AuthorizationService gist I'm getting a similar, but slightly different issue (de)serializing OAuth2Authorization objects:

org.springframework.security.oauth2.server.resource.authentication.JwtAuthenticationToken is not in the allowlist. 

edit:

I'm using oauth2ResourceServer(OAuth2ResourceServerConfigurer::jwt) in my chain and looks like it's being passed through and into one of the OAuth2Authorization's attributes under the key java.security.Principal. The value is of course an instance of JwtAuthenticationToken which it's having trouble deserializing.

toObject takes the authorization that's been queried from the db and tries to re-build the OAuth2Authorization object. That's where it comes across the JwtAuthenticationToken in the attributes and fails to deserialize.

Is this something you want more info on in a separate issue @sjohnr - if it's something the core team believes would be useful to be able to serialize, am happy to contribute that mixin.

[edwardzjl]

Thanks @edwardzjl. I believe that is likely the explanation for what's going on. Ultimately, there may be something we need to check to ensure consistency between requests, but I think it's reasonable for now to add the OAuth2ClientAuthenticationToken as a class that can be serialized. Take it away!

Thanks for the feedback. I opened #507 with code working in my project, but it may contain unnecessary mixins which the core team don't want. Once I have your guidance I'll improve the code and get this done. Thanks!

[shanzhaozhen]

When can it be updated to the release version? I look forward to it

[sjohnr]

Is this something you want more info on in a separate issue @sjohnr - if it's something the core team believes would be useful to be able to serialize, am happy to contribute that mixin.

Hi @colin-riddell. Since that is not something that's happening out of the box (e.g. in the existing sample), probably not at this time. However, it may be required in the future. As a current example, when using the UserInfo endpoint you need to enable oauth2ResourceServer().jwt(). So it's very close to a core requirement, but not enabled out-of-the-box as of yet.

Thanks for the feedback. I opened #507 with code working in my project, but it may contain unnecessary mixins which the core team don't want. Once I have your guidance I'll improve the code and get this done. Thanks!

Awesome. Thanks for the heads up! I will review it as soon as I can and get back to you with that feedback.

[jgrandja]

@mbarringer I was not able to reproduce the issue based on your detailed steps. Each time I clicked "Start Over", I was able obtain a token each time.

I really don't see how OAuth2ClientAuthenticationToken is saved in the OAuth2Authorization. This is the only place where Principal.class.getName() is saved as an OAuth2Authorization.attribute:

spring-authorization-server/oauth2-authorization-server/src/main/java/org/springframework/security/oauth2/server/authorization/authentication/OAuth2AuthorizationCodeRequestAuthenticationProvider.java

Line 422 in 8defe2e

.attribute(Principal.class.getName(), principal)

The principal instance in the sample would be UsernamePasswordAuthenticationToken and for any custom application it would be a user-based principal instance NOT a client-based principal instance, which OAuth2ClientAuthenticationToken is. The OAuth2ClientAuthenticationToken is only meant to be used for client authentication and it should never be persisted or serialized. It's meant to be transient and only used to authenticate the client in the current flow. I'm very curious how OAuth2ClientAuthenticationToken is being serialized in the flow you're testing. Are you able to provide more detail? Can you provide a full stacktrace of the exception?

@edwardzjl

... and the following requests will persist attributes with java.security.Principal of org.springframework.security.oauth2.server.authorization.authentication.OAuth2ClientAuthenticationToken, which then causes the OAuth2ClientAuthenticationToken is not in the allowlist error.

Can you also provide more detail on your flow and how OAuth2ClientAuthenticationToken is being saved to OAuth2Authorization.attribute.

[jgrandja]

@mbarringer @edwardzjl
I was able to reproduce with the help of @sjohnr. This is an interesting find !

I'll get back to you after I find a fix.