Description
Most of the opaque token support anticipates the use of the OAuth 2.0 Introspection specification. For example, the authentication provider is OAuth2IntrospectionAuthenticationProvider.
This really isn't true though, since the contract is simply String -> Map of attributes. It's sensible to hit any trusted API that will exchange something that is opaque to the resource server for an attribute map. Thus, something like OpaqueTokenAuthenticationProvider is more sensible.
This aligns with the DSL: jwt() configures a JwtAuthenticationProvider and now opaqueToken() would configure an OpaqueTokenAuthenticationProvider.
On the same note, OAuth2IntrospectionAuthenticationToken implies an OAuth 2.0 Introspection authentication strategy, which may not be true. Instead, let's use BearerTokenAuthentication.