JWT (JSON Web Token) officially states the industry-standard RFC 7519 method for representing claims securely between two parties. With stateless, decentration, even small package size makes it more advantageous to other protocol. but according to my actual investigation, I found that there are many problems, So don’t use JWT in your project, then let’s talk about the reason:
JWT scenarios
JWT usage scenarios are very limited, and there are currently two types that are suitable for JWT:
1. One-time verification, such as mailbox verification, can include iss issuer and expired exp information in the payload
2. Restful API’s for stateless authentication, but unless you’re as big as Taobao, the session will be more suitable.
What about the advantages of a good JWT?
1, JWT has a compact structure, the use of improved BASE64 coding, the amount of data transmission is small.
This is relatively speaking, compared to the traditional Session scenario, the client only needs to pass a sessionid, JWT is not good as session solution.
2, JWT because of the auth information carried in the head of HTTP, has the cross-domain ability
The key problem is where you store your JWT token, if they are in cookie or localstorage, you can access them anyway by using javascript, if in the APP ,there is no cross-domain problem at all.
3, JWT protocol is more secure
Maybe you won’t believe it, using JWT is more insecure, with specific questions such as:
1) Although you can’t tamper the JWT content , but the content is clearly readable, BASE64 is only encoding, not encryption, so JWT can not carry sensitive information in payload.
2) If payload is not symmetrically encrypted, there will be additional performance overhead, and there is no advantage over modern WEB frameworks that use encrypted cookies, such as PHP’s Laravel framework.
3) JWT’s token cannot be revoked on the server, meaning that the token cannot be reclaimed once it is issued. If you plan to record JWT’s token token on the server, I recommend that you don’t try it, because JWT will go from stateless to state, contrary to the intention of JWT. If we use the token as a session, why not using the session at the first place.
4) Has a natural ability to resist CSRF
Let’s start with the description: because JWT’s token is added to http head or query_string, it attempts to cross-station forgery request attacks, because the real token cannot be got, so the attack is not valid.
It sounds reasonable, but it always feels wrong, and if you feel the same way, that’s right. As above, the source issue needs to be addressed, and for security reasons, JWT recommends that token be stored in localstorage, but that any script injection can read the localstorage information, which is not safe.
So do you think that if we store the information in cookies and then transmit it in the form of http://photos or https, yes, it’s really safe, so the question comes up, so why don’t we start with a combination of sessions and cookies?
5) Anti-replay attack capability is poor, at least as bad as the session solution, or worse.
You might argue that there isn’t a jti (JWTID) field in the JWT protocol, we change the ID every time, so we can’t replay it. Each time, this does prevent replay attacks, then the problem comes, how does the server check that this jti is correct, yes, to query the storage and make JWTa stated protocol.
4, stateless can scale-out, people like it
But you’re Going to Hit the Database Anyway
In many cases, the authorization process requires query the database for the privileges of the user, So even if JWT’s token solves the problem of who you are, they still need to confirm what you can do, which is the difference between Authentication and Authorization.
5, single point SSO login
Wouldn’t it be easier to carry additional information in the session, JWT doesn‘t have an advantage, CAS systems can do a good job of SSO single sign-on, as discussed in other articles about the backup of CAS systems.
The disadvantages of JWT
First of all, renew the token is not supported, because any content change will have token change problems, so the user can only be re-issued a new token, the traditional solution of the session is easy, just make the lifespan of the session longer and everything is done.
Second) You can revoke the token on the server-side, so the token can be used until it expires.
Further) JWT does not have the ability to control concurrency , many clients can use the same token at the same time.
And….
Summarize:
JWT’s scenarios are very limited, almost only for one-time mail verification scenarios, for our small and medium-sized projects, if not necessary, do not use.
please leave a comment below
