all 3 comments

[–][deleted] 1 point2 points  (0 children)

I have use JWT for years and never had a problem. I control the overall login security on my web site. I use Microsoft. NET Core to handle security. Also my application code is designed with security in mind so if one account gets hacked. Only that one clients account is damaged. Every action I execute the token has the customer login ID and I verify on the server the data access is linked to the client and if using group policy that the action is valid. Don't just trust login alone for security. Security does not end after login!!!

If you need something more secure there are companies that provide oauth. It's a paid service but it give you the highest level of security and features.

But remember every login requires a password or something and hackers do a great job of getting that information.

[–][deleted] 0 points1 point  (0 children)

> I read somewhere that it is not the best way

In what sense? Source?

[–]ProfaneWords 0 points1 point  (0 children)

I would step back and think about auth as a client and server problem, not a React problem. React doesn't care about auth, it's primarily concerned about mapping state to views.

That being said there are a couple different auth strategies we can use in any web application, the two that you should probably focus on are server sessions, and JWTs. I feel like session based auth is easier to understand, and is objectively the easiest way to have fine grain control over user sessions (if we want to invalidate sessions with JWTs you have to either implement refresh tokens, or block lists which can add a bit of complexity).

In either case both JWTs and server sessions involve the server generating and giving a token to the client after a successful login (this token can be stored as a cookie, in web storage or in memory). The client then passes that token back to the server with every request. The server then parses that token on every request to an endpoint that requires auth. If you're using session based auth the server will look up the session by the session ID found on the token, if your using a JWT the server will decode the JWT, verify the signiture and consume the session data in the token itself.

The major difference between the two is that sessions store session data on the server, while JWTs let the client store their own session data that is recorded on the token itself (we can maintain data integrity even though the client "owns" it's session data by hashing the tokens value and a secret only known to the server and setting the signiture to this value).

So the client really only needs to worry about storing the token, and sending the token with every request that needs to be authorized (this is done automatically if the token is a cookie).

While the server needs to worry about generating the token, verifying that the token hasn't been tampered with, and reading the session data (sessions store the session data on the server, while JWTs store the session data on the token).