Built in JWT filter based authentication

[ah1508]

Summary

It would be nice to have a builder that enables authentication for web API with JWT. I know that ResourceServer and AuthorizationServer exist but they require a clear understanding of oauth and related concepts. Even if it is just a few lines of code, the point is not only to have something that works but also to understand the underlying mechanisms.

For the time being we have two choices : oauth and ResourceServer and AuthorizationServer or custom filters boilerplate.

Issue #368 is now closed but I think this feature should be considered so stateless api authentication would be at par with website authentication (formlogin(), etc...)

Actual Behavior

Authentication based on user password and jwt token (provided to the client after a successful username/password authentication) requires custom filter implementations.

One filter intercept POST on /authentication (for example) and returns a a JWT authorization token or HTTP 401.

One filter intercept all requests and rebuild a SecurityContext based on Authorization header.

Just a few elements are specific : authentication path (/authentication in my example), secret, algorithm, username property, password property, expiration, custom claims (other than authorities).

The configure method looks like that :

http
.csrf().disable()
.cors()
.and()
	.sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS)
.and()
	.exceptionHandling().authenticationEntryPoint((req, rsp, e) -> rsp.sendError(HttpServletResponse.SC_UNAUTHORIZED)) 	
.and()
	.addFilter(new MyUsernamePasswordAuthenticationFilter(authenticationManager())) 
	.addFilterAfter(new MyJwtTokenAuthenticationFilter(), UsernamePasswordAuthenticationFilter.class)

Expected Behavior

Default implementations of these two filters could be provided out of the box, like for formLogin() or cors().

Default settings could apply for path, username property, password property and the builder would just ask for the secret and the algorithm. About the claims, a common use case is to store the authorities in a property named 'authorities'.

sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS) could also be applied automatically.

If these 2 filters are added in the framework, they should be enabled independently, for instance we may want to keep the control on username & password authentication with a custom filter or @PostMapping endpoint.

It could look like this

http.enableJwt("mysecret", SignatureAlgorithm.HS512)
  .withUsernamePasswordAuthentication()
  .withAuthorizationHeaderAuthentication();

default settings :

• path for authentication is /authentication
• request body for authentication is {"username":"...", "password:".."}
• name of the header is Authorization, its value has a prefix named Bearer
• issuedAt : now

Additional methods on the builders would allow to redefine these settings.

The builder could also provide a method that accepts a Function<Authentication, String> so the developer can keep full control on the token creation.

[rwinch]

Thanks for the report @ah1508!

Can you help me understand how your proposal differs from Resource Server support that was introduced in Spring Security 5.1? Specifically you can configure it using something like this:

http
    .authorizeRequests()
        .anyRequest().authenticated()
        .and()
    .oauth2ResourceServer()
            .jwt();

[ah1508]

Dear @rwinch ,

I was not aware of oauthResourceServer() method, thank you. But unless I missed something it seems that a idp server is required. In the doc, the property issuer-uri must be a valid uri. Here I am talking about a JWT security mechanism without oauth server and without federated authority.

Starting the application with only the code you gave results in an error message, saying that JwtDecoder bean is missing because a property is missing

Method springSecurityFilterChain in org.springframework.security.config.annotation.web.configuration.WebSecurityConfiguration required a bean of type 'org.springframework.security.oauth2.jwt.JwtDecoder' that could not be found.

The following candidates were found but could not be injected:
- Bean method 'jwtDecoderByIssuerUri' in 'OAuth2ResourceServerJwkConfiguration' not loaded because OpenID Connect Issuer URI Condition did not find issuer-uri property
- Bean method 'jwtDecoderByJwkKeySetUri' in 'OAuth2ResourceServerJwkConfiguration' not loaded because @ConditionalOnProperty (spring.security.oauth2.resourceserver.jwt.jwk-set-uri) did not find property 'spring.security.oauth2.resourceserver.jwt.jwk-set-uri'

By the way, there is a typo in the documentation(paragraph 6.8.2). The spring prefix is missing in the yaml.

[jzheaux]

@ah1508 The defaults do require a uri, but the defaults can be overridden. For example, you can decode the JWT yourself (i.e. using the library or configuration of your choice):

@Bean
public JwtDecoder jwtDecoder() {
    return encoded -> decodeAndVerifyHoweverYouWant(encoded)
}

The reason JWT authentication coordinates with an issuer is because it simplifies key rotation. But, 5.2 will ship with the ability to configure a key directly as an alternative to that.

Also, thank you for letting us know about the typo - would you be interested in submitting a PR?

[ah1508]

Dear @jzheaux , Indeed a JwtDecoder helps to work without a IDP server. It's great if these feature is built in in 5.2.

@httpBasic() helps for the first round-trip (the one where the client send username and password and get refresh tokens in return), oauth2ResourceServer() handle further requests which use bearer and access+refresh tokens.

The home made JwtDecoder can also check the tokens against a revocation list (ttl of elements in the revocation list = ttl of access tokens) before returning the Jwt object. No need for additional filters, this issue can be closed. However if 5.2 allows to give the key and obtain in return a pre-configured JwtDecoder it would be nice to have a way to apply a control on the token before the Jwt is created (example : throw an exception if the token is in a revocation list). Postprocessor (called after token extraction) ? UnaryOperator<String> ? Predicate<String> ?

I'll submit the PR for the typo in the documentation.

[jzheaux]

@ah1508 Good feedback, thanks. You might take a look at OAuth2TokenValidator (in 5.1) and see if that suits your revocation-list needs. Something like:

decoder.setJwtValidator(jwt -> checkRevocationList(jwt));

For even earlier access to the token, 5.2 will allow you to supply your own NimbusJWTProcessor instance in the constructor.

[jzheaux]

Also, @ah1508 would you mind clarifying how you are using httpBasic in this scenario?

[ah1508]

@jzheaux : OAuth2TokenValidator is probably useful when used with setJwtValidator method of the NimbusJwtDecoderJwkSupport class but it does not help with a custom JwtDecoder (which is the way to go for an application that handles jwt encoding and decoding without any IDP server).

Until now my @Bean JwtDecoder looks like this :

@Bean
public JwtDecoder jwtDecoder() {			
    byte[] signingKey = Base64.getEncoder().encode("mysecret".getBytes());
    return token -> {
	    	io.jsonwebtoken.Jws<Claims> jjwt = Jwts.parser()
			.setSigningKey(signingKey)
			.parseClaimsJws(token);
		 Date issuedAt = jjwt.getBody().getIssuedAt();
		 Date expiration= jjwt.getBody().getExpiration();
		 JwsHeader<?> headers = jjwt.getHeader();
		 Claims claims = jjwt.getBody();

		 Jwt jwt = new Jwt(s, issuedAt.toInstant(), expiration.toInstant(), headers, claims); 
		 return jwt;
    };
}

So I can throw an exception if the token is revoked, this exception results in a 403 error for the client which is fine. At this point OAuth2TokenValidator is not needed.

But if in 5.2 allows to configure a key directly I guess that it will eliminate the need for a custom JwtDecoder bean. But then the JwtValidator mut be plugged in.

I tried to add a @Bean OAuth2TokenValidator

@Bean
public OAuth2TokenValidator<Jwt> validator() {
	return token -> {
		// check if token is valid
		return OAuth2TokenValidatorResult.success();
	};
}

but it is never called.

For the httpBasic() scenario, it is just for the first request/response, when the user gives a user and password. It is a kind of handshake : a method receive the request (only if Authorization: Basic provides a valid username and password, otherwise spring security returns a 401) and returns a token (or 2 : refresh and access). The goal is to let spring security does his job instead of doing it with a custom username and password check.

[jzheaux]

@ah1508 Correct that if you are creating your own implementation of JwtDecoder, then you'd need to invoke any OAuth2TokenValidator yourself.

As for wiring a validator with the default decoder, please see the docs for more details. setJwtValidator needs to be called directly.

It sounds like you are on your way, then. Since it appears so far that oauth2ResourceServer suits your needs, I'll close this.