This entire JWT implementation is bad practice

[Toerktumlare]

Spring security has had full JWT-support since 2017.

Writing a custom security solution with some sort of custom security filter is bad practice. Thats why there are security standards, to avoid writing custom security solutions.

The spring security documentation has clear instructions on how to handle JWTs and this is not it.

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

[ramazansakin]

Hi @Tandolf , Yes it shows basic flow of the JWT Auth, but it sometimes needs to be overridden regarding what you need to integrate to the flow and how it needs to be behaved regarding specific needs.

[Toerktumlare]

Hi @ramazansakin

Please provide such an example were spring securitys implementation does not fullfill the needs.

[ramazansakin]

@Tandolf As I mentined it needs to be overridden by specific needs like mentioned below :

Let's say you have a web application that needs to authenticate users not only based on their username and password, but also based on some additional custom attributes such as their employee ID, job title, or department. While Spring Security supports custom authentication mechanisms, it may not be enough to fulfill this specific requirement. In this case, you might need to extend Spring Security by creating a custom authentication provider that authenticates users based on these additional attributes. This would involve implementing the AuthenticationProvider interface, and writing the logic to authenticate users based on their custom attributes.

Another example could be if you have a requirement for a more complex authorization mechanism than what Spring Security provides out of the box, such as attribute-based access control (ABAC) or role-based access control (RBAC) with dynamic or hierarchical roles. In such cases, you may need to customize the Spring Security configuration and write your own implementation of the AccessDecisionManager interface to provide the required functionality.

[Toerktumlare]

@ramazansakin the implementation in this repository handles authentication and authorization by using a JWT, it is reimplementing something that already exists in spring security but in a worse manor.

I have no idea, why you feel the need to tell me about other usercases that the code in this repository also doesn't handle.

Needless to say, if you need to cover the usercaases you have mentioned, there is absolutely no problems in using the already built in functionality of spring security and then expand on that, than building everything from scratch Not invented here.

[Toerktumlare]

I wrote my last comment here in april and now it is november. The oauth2 specification has now officially deprecated the implicit flow meaning that jwt tokens should not be handed out directly to browsers.

it has (as i suspected) come now to my attention that the author of this repository has no intention at all to adhere to security practices, and that this repository is still up because im guessing it is his most popular one.

Very unprofessional behaviour.

[sunnypaul19999]

I wrote my last comment here in april and now it is november. The oauth2 specification has now officially deprecated the implicit flow meaning that jwt tokens should not be handed out directly to browsers.

it has (as i suspected) come now to my attention that the author of this repository has no intention at all to adhere to security practices, and that this repository is still up because im guessing it is his most popular one.

Very unprofessional behaviour.

Please point to the repo which I could view with the practices in place you mentioned

[Toerktumlare]

I wrote my last comment here in april and now it is november. The oauth2 specification has now officially deprecated the implicit flow meaning that jwt tokens should not be handed out directly to browsers. it has (as i suspected) come now to my attention that the author of this repository has no intention at all to adhere to security practices, and that this repository is still up because im guessing it is his most popular one. Very unprofessional behaviour.

Please point to the repo which I could view with the practices in place you mentioned

A repo? and what do you expect this repo to contain. An implementation of what? Please provide a full list of all your requirements and all all your use cases. When this is supplied, i'm a available for hire to implement said repository to your demands for the proper fee. My job is not to try to find "free code" for you.

I have linked the specification stated by the ietf.

Here is more information: https://oauth.net/2/oauth-best-practice/

[sunnypaul19999]

I wrote my last comment here in april and now it is november. The oauth2 specification has now officially deprecated the implicit flow meaning that jwt tokens should not be handed out directly to browsers. it has (as i suspected) come now to my attention that the author of this repository has no intention at all to adhere to security practices, and that this repository is still up because im guessing it is his most popular one. Very unprofessional behaviour.

Please point to the repo which I could view with the practices in place you mentioned

A repo? and what do you expect this repo to contain. An implementation of what? Please provide a full list of all your requirements and all all your use cases. When this is supplied, i'm a available for hire to implement said repository to your demands for the proper fee. My job is not to try to find "free code" for you.

I have linked the specification stated by the ietf.

Here is more information: https://oauth.net/2/oauth-best-practice/

Oh, marvelous! I didn't realize I stumbled upon a rare breed of consultant who requires a comprehensive dossier of my desires before deigning to grace me with their services. Your dedication to avoiding actual work is truly inspiring.

[Toerktumlare]

Please explain what is preventing you from reading the information provided and updating