Prevent JwtAuthenticationProvider from setting authentication details
when jwtAuthenticationConverter returned an authentication instance
with non null details.
Closes gh-11822
Before this commit splitting the authorities claim was done by a
hardcoded regex " ". This commit allows to configure to set any regex
to split the authorities claim while keeping the previously
hardcoded regex as a default.
Closes gh-12074
Before this commit splitting the authorities claim was done by a
hardcoded regex " ". This commit allows to configure to set any regex
to split the authorities claim while keeping the previously
hardcoded regex as a default.
Since Spring Security still needs these methods and classes, we
should wait on deprecating them if we can.
Instead, this commit changes the original classes to have a
boolean property that is currently false, but will switch to true
in 6.0.
At that time, BearerTokenAuthenticationFilter can change to use
the handler.
Closes gh-11932
Issue gh-11932, gh-9429
(Server)AuthenticationEntryPointFailureHandler should produce HTTP 500 instead
when an AuthenticationServiceException is thrown, instead of HTTP 401.
This commit deprecates the current behavior and introduces an opt-in
(Server)AuthenticationEntryPointFailureHandlerAdapter with the expected
behavior.
BearerTokenAuthenticationFilter uses the new adapter, but with a closure
to keep the current behavior re: entrypoint.
Adds configurable authentication converter for resource-servers with
token introspection (something very similar to what
JwtAuthenticationConverter does for resource-servers with JWT decoder).
The new (Reactive)OpaqueTokenAuthenticationConverter is given
responsibility for converting successful token introspection result
into an Authentication instance (which is currently done by a private
methods of OpaqueTokenAuthenticationProvider and
OpaqueTokenReactiveAuthenticationManager).
The default (Reactive)OpaqueTokenAuthenticationConverter, behave the
same as current private convert(OAuth2AuthenticatedPrincipal principal,
String token) methods: map authorities from scope attribute and build a
BearerTokenAuthentication.
Closes gh-11661
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
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.
Josh Cummings
Baljit Singh
Claudio Nave
Krzysztof Krason
Vedran Pavic
Marcus Kainth
ch4mpy
Patrick Walter
Daniel Garnier-Moiroux
Steve Riesenberg
Joe Grandja
Marcus Da Coregio
Rob Winch
Philipp Neuschwander
Darren Forsythe
Ashley Scopes