Summary

We may want to put additional manual check when allowUriQueryParameter=false to make sure client is not insecurely passing access_token as query parameter with form POST method while resource is configured not to allow this behavior. This bug may have been introduced due to API limitation of HttpServletRequest.getParameterValues(...) where it cannot differentiate between form parameter vs query parameter.

With below conditions "Actual Behavior" does not match "Expected Behavior".

Given

allowFormEncodedBodyParameter=true allowUriQueryParameter=false

When

user makes POST request and no access_token form parameter is present and access_token as URI query parameter is present

Actual Behavior

Method DefaultBearerTokenResolver.isParameterTokenSupportedForRequest(...) will return true and token from query parameter will be used although allowUriQueryParameter=false

Expected Behavior

Since allowUriQueryParameter=false, and token is present in URI query parameter, it should not return this token

Version

Spring Security 5

Sample

See #5122 PR for which was raised by @vpavic and reviewed by @jgrandja

Comment From: jzheaux

@gburboz You are correct that this was deferred, given the limitations of getParameter and getParameterValues. Do introduce this, the code would need to parse the query string, I suppose.

Would you be interested in submitting a PR for this?

Comment From: gburboz

I have added PR to your fork https://github.com/jzheaux/spring-security-oauth2-resource-server/pull/59

Comment From: gburboz

Updated Expected Behavior to not return values instead of throwing an exception since it is not part of specification

Comment From: gburboz

@jzheaux I have raised new PR #6036 : Updated to comply with specification rfc6750#section-2