Spring Security:Why check if authentication token is set in authorization filter? - spring

Question

I'm trying to understand spring security. I came across following piece of code
public class JWTAuthorizationFilter extends BasicAuthenticationFilter {
public JWTAuthorizationFilter(AuthenticationManager authManager) {
super(authManager);
}
#Override
protected void doFilterInternal(HttpServletRequest req,
HttpServletResponse res,
FilterChain chain) throws IOException, ServletException {
String header = req.getHeader(HEADER_STRING);
if (header == null || !header.startsWith(TOKEN_PREFIX)) {
chain.doFilter(req, res);
return;
}
UsernamePasswordAuthenticationToken authentication = getAuthentication(req);
SecurityContextHolder.getContext().setAuthentication(authentication);
chain.doFilter(req, res);
}
// Reads the JWT from the Authorization header, and then uses JWT to validate the token
private UsernamePasswordAuthenticationToken getAuthentication(HttpServletRequest request) {
String token = request.getHeader(HEADER_STRING);
if (token != null) {
// parse the token.
String user = JWT.require(Algorithm.HMAC512(SECRET.getBytes()))
.build()
.verify(token.replace(TOKEN_PREFIX, ""))
.getSubject();
if (user != null) {
// new arraylist means authorities
return new UsernamePasswordAuthenticationToken(user, null, new ArrayList<>());
}
return null;
}
return null;
}
What is the need of
if (header == null || !header.startsWith(TOKEN_PREFIX)) {
chain.doFilter(req, res);
return;
}
Authorization will be done after authentication right ? In that case header will be set anyway.What am I missing?
And also what is chain.doFilter() doing exactly? It is used to proceed and hit the servlet eventually right? If user isn't authenticated why proceed with request?If it is to proceed to authentication filter then how come authorization filter invoked before authentication filter?

Answer 1

In spring security a filter chain is basically a linked list. So as you do a request, it will hit the first filter, that filter will then call the next chain in the link, then the next, the next, etc.
// Get a specific header (im guessing authorization header)
String header = req.getHeader(HEADER_STRING);
// If no such header was found, or the found header does not include a specific prefix
// (im guessing the string Baerer) which means that if this is not a
// authentication header containing a baerer token, then call the next filter in
// the chain.. The next filter will have the same call, etc.
if (header == null || !header.startsWith(TOKEN_PREFIX)) {
chain.doFilter(req, res);
return;
}
If a request is sent with no auth header and we proceed into the application, down the filter chain as we hit the actually endpoint, it will probably have an anotation saying that you need a specific role, which the user wont have, since it hasnt authenticated itself. And the result will be a 401 UNAUTHORIZED returned from the security framework.
If it on the other hand it finds an auth header with a bearer prefix it will try to extract out the token from the header, verify its integrity that no one has tampered with it, decode it, and get the subject field from the token. Using the subject it will create a UsernamePasswordAuthenticationToken and set this as the authenticated token in the security context. Basically setting the subject as the authenticated user.
If there is no subject in the token, filter will return null (which is sloppy coding and might crash the application, a 401 exception should be thrown).
Several bad things with this code:
String header = req.getHeader(HEADER_STRING); is called twice
default user case is to try to log in the user, should be the other way around, default case should be to throw a 401 unauthorised and all logic should try to prevent that.
if a authorization header containing the string bearer but no token is sent the parsing function will return a null value, and the filter will call setAuthentication with the value null which will probably result in a crash.
if a authorization header containing the string bearer the token does not contain a subject value the parsing function will return a null value, and the filter will call setAuthentication with the value null which will probably result in a crash.
Spring already includes support for Nimbus jwt library to encode and decode JWT's there is no need to pull in another library java-jwt as done in the example above.
Worth mentioning that from Spring 5 there is already a fully implemented JWT solution in spring security that only needs to be customised. So this entire custom filter is redundant.