Custom security is bad practice, and a huge security risk

[Toerktumlare]

Spring security 5 has full support for JWT tokens so there is no need to write a custom JWT filter.

https://docs.spring.io/spring-security/site/docs/current/reference/html5/#oauth2resourceserver-jwt-architecture

I would even go as far to say that this application is teaching bad practices. Writing custom security is bad practice. All it takes is one single bug in the custom security for all data that this application handles could be compromised.

Spring Security JWT support is fully tested, customizable and has been battle tested in thousands of production applications and should be the best practice choice.

This application should be either removed or rewritten to teach best practices.

https://github.com/Yoh0xFF/java-spring-security-example/blob/64c1fe800ed38228ff6afa8e713a63eec553c8a9/src/main/java/io/example/configuration/security/SecurityConfig.java#L113

[Yoh0xFF]

@Tandolf Thank you for sharing the information. This is really helpful.

I agree regarding the custom security configuration. We need to avoid it every time if possible. But JWT authentication provider was missing in Spring Security for an extended period, and custom configuration was the only option.

I am happy to see Spring Security fixed this in the new version.

JwtAuthenticationProvider Was introduced in version 5.1, which was released one year ago.

I'm afraid I have to disagree that this application needs to be removed. It demonstrates many other practices other than custom security configuration.

I agree it needs to be updated to reflect the latest changes introduced in the new Spring Security versions. I will definitely do this when I have some free time.

[Toerktumlare]

Spring Security 5.1 was released 21th of september 2018, that is almost 3 years ago, not 1 year ago, just want to point that out.

https://github.com/spring-projects/spring-security/releases/tag/5.1.0.RELEASE

[Ferdzz]

@Tandolf Would you happen to have a tutorial or sample project that use non-custom security implementations?

[Yoh0xFF]

I did shallow research around JwtAuthenticationProvider.

In our Spring Boot projects for security we add the dependency:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-security</artifactId>
</dependency>

If we run mvn dependency:tree, we will see that it pulls the following extra dependencies:

[INFO] +- org.springframework.boot:spring-boot-starter-security:jar:2.3.3.RELEASE:compile
[INFO] |  +- org.springframework:spring-aop:jar:5.2.8.RELEASE:compile
[INFO] |  +- org.springframework.security:spring-security-config:jar:5.3.4.RELEASE:compile
[INFO] |  \- org.springframework.security:spring-security-web:jar:5.3.4.RELEASE:compile

I checked and JwtAuthenticationProvider is part of the dependency, which isn't covered by spring-boot-starter-security:

<dependency>
    <groupId>org.springframework.security</groupId>
    <artifactId>spring-security-oauth2-resource-server</artifactId>
</dependency>

and it is used to set up OAuth 2.0 resource server using Spring Security 5. The sample application doesn't address this topic, it only demonstrates authentication/authorization with JWT token for SPA applications.

I was unable to find JwtAuthenticationProvider in spring-security-web dependency, so it seems to me custom implementation is the way to go for now.

Please feel free to correct me if I am wrong. @Tandolf @Ferdzz

[Toerktumlare]

No you are not wrong by saying it is in a different dependency. It is also declared in the spring security reference.

Your application has an API which means it is a resource server, as it is provieing resources to a SPA-application.

This class JwtTokenFilter

Should be completely removed, an replaced with the built in oauth2 resource server support.

.oauth2ResourceServer(oauth2 -> oauth2
    .jwt(jwt -> jwt
        .decoder(myCustomDecoder())
    )
);

and then use the spring supported Nimbus library for the decoding, and let spring handle the decoding.

public JwtDecoder myCustomDecoder() {
    return NimbusJwtDecoder.withSecretKey(this.key).build();
}

But best would to stop using JWTs like sessions as you have done here, JWTs are not meant to be used as a session tracker/nonce. It's not what they were designed for. I recommend reading up on this that was written in 2016 and still applies.

Stop using jwts for sessions Stop using JWT for sessions, part 2: Why your solution doesn't work

[Toerktumlare]

you wanted an example, here is a full example provided by spring themselfes.

https://github.com/spring-projects/spring-security-samples/tree/main/servlet/spring-boot/java/jwt/login

Here is the official spring documentation on jwts.

https://docs.spring.io/spring-security/reference/servlet/oauth2/resource-server/jwt.html

This tutorial and its blogpost should either be updated or removed.

[Toerktumlare]

The author of this repo and the article has completly ignored this and is seriously harming the community by providing bad security practices.

i have written comments on the article explaining why the tutorial is bad practice and the author has blatantly deleted all comments in order to avoid any responsability.

extremely unprofessional.

[Yoh0xFF]

Hi @Tandolf,

With all my respect, I disagree with your opinion stated above.

1. The author of this repo and the article have entirely ignored this and seriously harms the community by providing bad security practices. I didn't ignore your advice; I didn't have free time to update the article and the repository to reflect it during the last year. I will work on this when I have some free time.

2. I have written comments on the article explaining why the tutorial is bad practice, and the author has blatantly deleted all comments to avoid any responsibility. I don't have admin privileges on the Toptal blog platform or on Discus third-party service, which provides the comment section, and I cannot delete the comments there. If I wanted to delete comments, I could successfully delete this issue as well, but I keep it open and unresolved, so anybody can see and consider your advice here.

3. Extremely unprofessional. With this article, all I wanted was to help the community and not harm it. I haven't shown any disrespect to you or anybody, and I kept all my communication strictly professional.

Kind regards, Ioram

[Yoh0xFF]

@Tandolf, I updated the application. I will be working on the article a little bit later.

[lukasmakac]

Thanks for adressing this. I find your work precise and well explained

[Yoh0xFF]

Thank you @lukasmakac. I am happy to hear that!