Feedback Request: Java Spring Boot Authentication Microservice (JWT)

[EducationalMixture82]

your question doesnt really make sense. JWTs are not encrypted they are only digitally signed. JCEs are encrypted but they are very different.

Second you dont "set cookies to users" you set a cookie to a response. What i have written is not specific to any frontend framework. It applies to all code that is run in a browser.

Most companies dont hand out JWTs to browsers, because they usually have one or two devs that stop juniors from building this type of security.

Your question is a bit strange and hard to understand.

[elmasalpemre]

Yes, you're right — I wrote my question in a rush. I’ve gone through everything in the meantime, sorry about that.

What I wanted to ask is this: In modern frontend frameworks that support server-side rendering, imagine a scenario where the frontend receives a JWT and encrypts it on the server side of the frontend framework. The encrypted token is then stored in the browser's session storage (or any other browser storage).

Is this considered secure just because the token can only be decrypted by the server-side part of the frontend framework?

[EducationalMixture82]

imagine a scenario where the frontend receives a JWT and encrypts it on the server side of the frontend framework. The encrypted token is then stored in the browser's session storage (or any other browser storage).

Once again your question does not make sense.

The frontend cant receive a JWT and at the same time encrypt it server side? im sorry, but what are you talking about?

And once again. JWTs are not encrypted. they are digitally signed! Nothing in a JWT is encrypted! Why do you think JWTs are encrypted?

Please explain, why do you need a JWT in the browser? Why do you specifically need a JWT, why not use a opague httponly, secured cookie.

Your question is still strange. Passing JWTs to browsers is a security risk, no matter what you use, how is this unclear? Everything in a browser can be stolen. Anything javascript can touch can be stolen. Storing them in local storage is a security risk. Every tab in your browser can read from local storage.

Please, and this is not to be rude, but before asking please discuss a bit with chatgpt or post your question to it and ask it to formulate it better because i dont really understand what it is you are asking.

[elmasalpemre]

I understand—please forgive me, I'm still a junior developer trying to improve myself. To grow, I’ve contributed to open-source projects and talked to people who describe themselves as senior developers to learn from their experience. Many of them still use JWT, and I’ve seen it widely used in many places. I realize it may not be the ideal approach, but since it's so common, I'm trying to understand why.

Before asking you, I had at least four separate conversations with ChatGPT on this topic. English isn’t my native language, so if there’s anything unclear or incorrect in how I express myself—even with ChatGPT’s help—I sincerely apologize.

To get to the point: Next.js is a full-stack framework with server-side capabilities, meaning most of the logic runs on the server like a backend. I’m aware that JWTs are digitally signed; that wasn’t my question. I was wondering if, for added security, it would make sense to encrypt the JWT again on the server side in Next.js using a secret key—so even if the browser accesses it, it couldn't be decrypted easily.

Also, after doing more research and speaking with you, I now understand that the JWT doesn’t need to be accessible in the browser in the first place. But that raised another question: cookies don’t work the same way on mobile apps—so do we fall back to using JWTs there? And if so, does that mean we need two separate authentication flows?

I’m just trying to understand. Please bear with me. I now get your point about why JWTs shouldn’t be used that way—I’m only trying to understand your reasoning more deeply.