I was trying to create a Spring Microservice Project which makes use of the Jwt Bearer token. I have found this interesting resource: https://springframework.guru/jwt-authentication-in-spring-microservices-jwt-token/.
The issue here is that I do not see it implemented with Spring Security. I've been thinking about the code and I realized that this is a good alternative (even in prod) for authenticating WITHOUT using Spring Security.
Is this correct? Is it logically correct to provide this type of protection to the application, without Spring Security?
Moreover, I was thinking of the following pattern:
Since most of the answers here our either misinformed or outdated i will answer this with some references.
As of time of writing (november 2023) oauth2 has deprecated what is called the IMPLICIT GRANT which in short was the flow were you authenticated directly with an issuer using a username and password and directly got issued a token to the client due to this flow has been found to be vulnerable to access token leakage and access token replay attacks.
Take notice that the deprecation mentions tokens, this means both JWTs and opague tokens.
JWTs has since long been been not recommended to use as a replacement for sessions, or session tokens, since there are no ways of storing a token securely in the browser, OWASP has recommendation against storing tokens in browsers. they also have several recommendations for instance not using JWTs unless you actually server side store some reference to the JWT since tokens can not be logged out. SO you cant log out all devices or logout a token that has been stolen.
Several instances recommend against JWTs as session tokens:
https://developer.okta.com/blog/2017/08/17/why-jwts-suck-as-session-tokens
https://redis.com/blog/json-web-tokens-jwt-are-dangerous-for-user-sessions/
https://www.youtube.com/watch?v=JdGOb7AxUo0
http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/
There is no such implementation (showed in the linked tutorial in the question) in spring security, because it is not recommended to do such authentication. So there is has been an active choice to not have it.
But why do so many recommend that, well its a long story, but mostly that security is hard, someone found a way to write security that seemed easy and "sort of worked" and then others copied it.
So how should you build security?
Well it all depends on what your demands are.
Session based, FormLogin using cookies, with httpOnly and Secured flags set, use CORS and CSRF tokens.
Separate issuer/authorization server, build a BFF (backend for frontend), have cookies between BFF and frontend, the BFF authenticates against the issues using Authorization code flow with PKCE and stores the JWT in the backend, never hands out the JWT to the client. use CORS and CSRF
Same as above but this time follow the OpenIDConnect standard, hand out AT-token, RT-Token ID-Token all as cookies to the frontend instead of a cookie. Have several resource servers, supply the AT token from the fontend in requests and have a proxy that will exchange the cookie token for a JWT, the JWT is used only within the corporate network and never is exposed out on the internet.
Security isnt hard, as long as people read the standards and actually follows the standards and are not trying to invent custom home made security all the time. There is a reason there are standards, because they have been proven to be secure.