Similar to BasicAuthenticationFilter, BearerTokenAuthenticationFilter should check if authentication is required before proceeding.
As does BasicAuthenticationFilter, this would happen after the token is extracted from the header, but before the AuthenticationManager is invoked.
The same three checks that are done with BasicAuthenticationFilter would be performed with the slight change that instead of comparing usernames, BearerTokenAuthenticationFilter would compare token values.
Comment From: rwinch
This has been a source of problems for BasicAuthenticationFilter and just because we do it in one place doesn't mean we should do it it in another. Could you document why this is necessary?
Another note, if we do this perhaps it is just part of the matcher that determines if the filter is invoked.
Comment From: jzheaux
Actually, after thinking about this for some time more, the need for this is dubious, at least for the time being.
The challenge is when testing with JwtRequestPostProcessor. This post processor adds a Jwt, alleviating the need for a tester to add the bearer token header. However, doing so forces the tester to provide a CSRF token (since now the bearer token header is absent).
The goal with this ticket was ultimately to accommodate that circumstance. It's not great to add a feature that would only be invoked by tests and, in addition to your comment about it being a source of problems for BasicAuthenticationFilter, I think it's clear we leave this feature out for now until a more compelling reason is manifest.
Comment From: reda-alaoui
Hi,
I have a use case for this feature. I have an OIDC issuer and a Spring application. Among other security things, the Spring app needs to provide the following features: - it should control the session duration itself - protected images should be easy to load through an html img tag through their simple urls - it should provide an Authentication object containing attributes absent from the OIDC issuer JWT
To do that, on authentication, the Spring app converts the JWT token into another Authentication instance that contains information specific to the Spring app. This Authentication instance is saved in memory and referenced by a secured cookie sent back to the client browser (allowing for easy image fetching).
Because of that, the browser may send simultaneously the JWT and the app secured cookie to the Spring application. If the cookie references a non expired session in the Spring application, it must be used instead of the JWT.
What were the issues caused by this behaviour in BasicAuthenticationFilter ?