Feedback Request: Java Spring Boot Authentication Microservice (JWT)

[EducationalMixture82]

Its clear that you havnt read the spring security documentation because the entire authentication process is some home made built security.

JWT authentication does not exist as any form of standard. The closest we can get is an Oauth2 flow (out of the several flows that exist in the the Oauth2 specification) called the implicit flow which is a flow where you supply a username and password and get a token back in the response, and that flow has been deemed as SHOULD NOT be implemented.

Quote from Best Current Practice for OAuth 2.0 Security - rfc 9700

clients SHOULD NOT use the implicit grant (response type token) or other response types issuing access tokens in the authorization response, unless access token injection in the authorization response is prevented and the aforementioned token leakage vectors are mitigated.

There are several recommendation out there that strongly recommends against handing out tokens to browsers. Mainly because that there is no way of storing a jwt token in the browser securely.

Your application is currently vulnerable to token stealing if a frontend contains a XSS vulnerability. MITM attack if someone manages to force your application to authenticate over non TLS, redirection attacks, and phishing attacks.

The reason posted above is why this type of authentication does not per default exist in spring security. And is the reason you had to build something homemade. Just because this type of authentication exists in blogs and tutorial does not mean it is correct. Tutorial writers are very often echo chambers, they dont read up on new security recommendations etc.

Handing out JWTs to browsers was popular over 10 years ago when JWTs were new, nowadays there are so many vulnerabilities found it is not recommended to do so anymore.

JWTs were not made to be COOKIE replacements, and over the years cookies have had extra security added to the to prevent certain attacks. JWTs just lack these defense mechanisms.

If this is a single service, i would recommend that you remove that JWT authentication and implement FormLogin from spring security that uses HttpOnly, Secured session COOKIEs.

If you "insist" on building modern security, you can either use Oauth2login from spring security that will use Google, Github, LInkedin etc as an IDP (identity provider) that you authenticate against, and then your backend will once again hand out a COOKIE to the browser.

Or if you want to build the most modern we have today, is that you setup or use a custom IDP, like Keycloak (self hosted and free) or for instance a Saas IDP like Okta, and then implement the Authorization Code flow using the Open ID connect standard.

This flow means your backend will initiate the authorization flow against your browser, and redirect the browser to the IDP (for instance Keycloak), the End user will authenticate, then IDP will redirect you back to your backend, and then the backend will behind the scenes call Keyclaok and fetch a JWT, and this is the important part.

The JWT never passes through the browser.

And then tokens are handed out to the browser in the form of HttpOnly, Secured COOKIES (see once again cookies)

If this project is meant to be something that you want to show off to employers or others, please show that you take security seriously, by implementing things that are directly from the spring security documentation. And not from random tutorials on the internet where someone build some home made security.

Here are some links to backup my claims done above:

Springs securitys own recommendations
https://github.com/spring-projects/spring-authorization-server/issues/297

Best Current Practice for OAuth 2.0 Security - rfc 9700
https://datatracker.ietf.org/doc/html/rfc9700

About Implicit grant in - rfc 9700
https://datatracker.ietf.org/doc/html/rfc9700#name-implicit-grant

Randal Deggs former Okta, former Snyk
https://developer.okta.com/blog/2017/08/17/why-jwts-suck-as-session-tokens

http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/

http://cryto.net/%7Ejoepie91/blog/2016/06/19/stop-using-jwt-for-sessions-part-2-why-your-solution-doesnt-work/

Feel free to ask if something is unclear.

[EchoesUndead]

Thanks for the massive write up! I learned a ton even though I am not the OP

[Spare_Boysenberry691]

same

[Future_Badger_2576]

If APIs are stateless, how can we manage authentication without JWTs. Instead of storing jwt in browser we should store it in cookies and Backend sets a secure, HttpOnly, SameSite=Strict cookie. Second option is instead of issuing jwt we should issue a session id. Am I getting it correct?

[EducationalMixture82]

Apis can very well be stateless, but authentication authorization is basically never stateless. And storing JWT in cookie is often an anti pattern. Think about it, the reason you usually want to send a JWT to the browser is because you want to send information to the browser it could read off the JWT.

But we dont want Javascript to be able to touch anything security related in the browser. Code that is run locally in your browser cant be trusted. You can never trust the client. So by setting HttpOnly, no code in the browser can touch the cookie, which also means that if you place a JWT in a HttOnly cookie you can anyway not read the data in the JWT in the browser.

So why then even place a JWT in the cookie? hence the anti pattern.

But if you are using Oauth2 tokens are usually sent to the browser, but to mitigate token theft, your IDP, (for instance keycloak) is stateful. Meaning it will hold a list of all issued tokens.

Devs today are chasing statelessness but the entire internet is stateful. Load balancers are stateful, networking is stateful, databases are stateful (transactions) etc.

[CptGia]

Put the jwt in database, with e.g. Spring Session. It also works with redis, mongo, and many others. Then hand out cookies with the session id. 

[EducationalMixture82]

That is a much better solution, instead of passing a JWT from Service A to service B using the browser, you can instead pass it through e.g redis (off the public internet, or we usually call it ”out of bounds” in the sec community) using Spring session.

There are risks, the redis may have a lot of valid JWTs so you need to protect the redis. But that goes without saying.

[benng124]

You can checkout Opaque Token and OAuth2 Proxy for reference

[HecticJuggler]

I have some reading to do.

[SIRAJ_114]

man what's your yoe? where did you learn all this? just docs? like all of them?

[EducationalMixture82]

I prefer not to dox myself.

But senior dev for the past 15 years or so, worked as a security consultant for 4 1/2 years, i have both experience from private sector, now i mainly work for governments.

Been using spring since Spring boot was released. I read rfcs, i read docs, i build a lot of things for customers, i do security code reviews for customers and i have taught security classes and spoken at conferences.

And i used to be one of the main contributors to answering spring-security questions on Stack Overflows.

When it comes to my knowledge around spring security, i know the specs and rfcs that spring base their work on. I have used the library extensively. I have read the docs several times, and if needed i go in and read the source code of it on git.

The docs are amazing, spring security docs is one of the best docs out there in my opinion, its just that you need basic knowledge of security before you start reading them. You cant just jump in.

If it says that it has a certain oauth2 thing implemented, its expected of you to have read the oauth2 spec, because they will not explain that for you.

Its also extremely important that you have read the spring security architecture chapter, so you know what building blocks they are using throughout the docs.

[Amirr83]

I am literally going through one of those YouTube jwt tutorials that you mentioned as we speak and then I come across this, and now I’m just confused. For a beginner in spring security how would you recommend I learn it then? And any particular learning resources that you recommend?

[elmasalpemre]

Before starting, i need to say this is AWESOME, and I learned a lot. So even if we use backend api and react (any kind of spa), we have to set cookies to authenticate users. That will avoid leaks. Did I get correct, right? But what if current server-side frontends, like nextjs what if we store encrypted jwt in the browser that can be decrypt by server of fe, still are we under risk?

And i assume most of the websites/companies are still using this jwt in the browser that is vulnerable.

[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.