Before this commit, the DefaultBearerTokenResolver unconditionally
resolved the request parameters to check whether multiple tokens
are present in the request and reject those requests as invalid.
This commit changes this behaviour to resolve the request parameters
only if parameter token is supported for the specific request
according to spec (RFC 6750).
Closes gh-10326
This adds support for configuring NimbusJwtClientAuthenticationParametersConverter to any AbstractWebClientReactiveOAuth2AccessTokenResponseClient as an additional parameters converter, which in turns adds reactive support for jwt client authentication.
Closes gh-10146
Check for multiple access tokens on the ServerHttpRequest rather than get get first. If multiples are found throw a OAuth2AuthenticationException.
Closes gh-5708
Replace all usages of OAuth2IntrospectionClaimNames with
the suggested OAuth2TokenIntrospectionClaimNames.
There does not appear to be any further usages of OAuth2IntrospectionClaimNames,
so it should be suitable for removal when appropriate in accordance with the
deprecation policy.
The OpaqueTokenAuthenticationProvider now propagates the cause of
introspection exceptions in the same way that the reactive
OpaqueTokenReactiveAuthenticationManager does.
Fixed a final field warning on both OpaqueTokenAuthenticationProvider
and OpaqueTokenReactiveAuthenticationManager.
It appears Nimbus does not check the presence of the Content-Type
header before parsing it in some versions, and since prior to this
commit, the code is .toString()-ing the result, a malformed response
(such as that from a misbehaving cloud gateway) that does not include
a Content-Type would currently throw a NullPointerException.
In addition to this, I have added a little more information to the
log output for this module on the standard and reactive implementations
to aid in debugging authorization/authentication issues much more
easily.
Prior to this commit, the OAuth2 resource server code is failing any issuer
that is not a valid URL. This does not correspond to
https://datatracker.ietf.org/doc/html/rfc7662#page-7 which redirects to
https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.1, defining an
issuer as being a "StringOrURI", which is defined at
https://datatracker.ietf.org/doc/html/rfc7519#page-5 as being
an "arbitrary string value" that "MUST be a URI" only for
"any value containing a ':'".
The issue currently is that an issuer that is not a valid URL may be
provided, which will automatically result in the request being aborted
due to being invalid.
I have removed the check entirely, since while the claim could be invalid,
it is still a response that the OAuth2 introspection endpoint has provided.
In the liklihood that interpretations of this behaviour are different for
the OAuth2 server implementation in use, this currently stops Spring
Security from being able to be used at all without implementing a custom
introspector from scratch.
It is also worth noting that the spec does not specify whether it is
valid to normalize issuers or not if they are valid URLs. This may cause
other unintended side effects as a result of this change, so it is
safer to disable it entirely.
Prior to this commit ClaimTypeConverter returned the claims with the
original value for all the claims with a null converted value.
The changes allows ClaimTypeConverter to overwrite and return claims
with converted value of null.
Closes gh-10135
