Just like any other 'tokens', JSON Web Tokens (JWT) is a form of secret that's used for authentication (who you are) and authorization (what you ca...
For further actions, you may consider blocking this person and/or reporting abuse
Symmetric signing with public & private keys is not necessary for JWT. You can use a simple secret-based signing with an HMAC algorithm.
Not hard to manage, even on distributed environments. Most cloud providers offer secret management services that can easily be attached to most or all compute service. They also offer services to abstract away public/private keypair management, if you do need them.
In my experience, JWT is way easier to implement and manage in comparison to sessions. The first is stateless, the former is stateful...
Not to mention with JWT becoming the standard on many, many new commercial/open source projects, there is an increasing dev and code base geared towards this tech. There are reasons why you don't necessarily want all your data self-contained, but they're not particularly the reasons mentioned in this article imo.
There is something iffy about using same key for verifying and issuing tokens.
Having used both JWTs and traditional session ids, I agree that JWTs are probably not the best tool for a typical project. Where I have found them very useful is when passing a user's credentials between several back-end systems that all trust the server that granted the JWT and each want to do their own authentication or authorization.
Indeed. Between backend systems we don't expose to the public sending all the data self-contained makes sense. However, you really have to wonder if sending all your data upfront to the browser is the best call, though it's a common pattern.
We migrated from a simple JWT-based solution to a SessionID-to-JWT solution, where we store a session ID on the frontend, the backend validates it and replaces it to a JWT token with short expiration time and all the other services - which are running in our trusted environment - using this JWT token to authorize the requests.
With this solution:
...but the dark side is:
In addition, we use a double session ID solution:
With this we can reduce the possibility of XSS and XSRF.
The hybrid solution and the duo-session solution are both very interesting! Thanks for sharing.
I go with JWT, because for every sessionID i want to hit database which is costly and time consuming.
Yes there is no way to revoke the jwt once it is issued.
This problem can be rectified if you can store the token in redis or any other mem-cached database. To verify the token fetch token from mem-cached database and verify it. to revoke just remove the token from redis.
SessionIDs can be blazing fast if you hookup Redis to it, mitigating the complexities of jwt blacklisting. Blacklisting tokens is the inverse of storing SessionIDs, you could end up with a huge list of blacklisted tokens.
Also, jwt payloads are much bigger then transporting SessionIDs. Use case dependent factors to keep in mind.
You can store any information you want in the Claims of a Token. Given this, it is trivial to revoke the Token. It's the exact same mechanism as revoking a Session ID.
Another big difference is that you probably want to store SessionIDs in Strict/Lax HTTP-Only cookies, making it hard to (XSS) hijack someones authenticated session, while JWTs are unbound and purposely accessible to (all) JavaScript.
JWTs are also flexible. They can be stored in a secure, samesite, httponly cookie so as to mitigate XSS. This is done when the token is used for auth; you could also split the JWT to give the js only the payload and not the signature. (But also, if this is a concern for your use case, maybe JWTs are not for you - someone else said in this thread JWTs shine in the back end when APIs call other APIs).
In general though I would agree, most of the time people just pass the token to the client and then JS has access to it until it expires. And every http request they just tack that token in the authorization header as a bearer token.
Some may consider it early optimization, but JWT’s can be easier to scale than traditional session ID’s. The latter requires a single data store for session ID’s to serve potentially many application nodes. This creates a single point of failure, which will require some failover mechanism, and in general more complexity.
This complexity is easily reduced using JWT’s, which does not require this unified data store, and is available immediately as application nodes are scaled up or down.
You mentioned "JWT requires you to properly store and distribute private / public keys"
Your Auth Server signs JWT with its private key (that needs not to be distributed).
The AuthServer Public Key (for validating the signature) can be retrieved by the URL, no need to distribute/store it.
It is quite possible to revoke a JWT. Just as a Driver's License can be revoked before it's expiration the same thing can be done to a JSON Web Token. Store a unique identifier in the JWT and provide a revocation list when checking the signature of the JWT. This provides all of the benefits of a Session ID, without having to store all of the Session Information in the database.
Only use JWT's as short-lived one-time tokens. For everything else, use session cookies. If you need to make a database lookup to validate the JWT then the purpose of them is defeated.
Don't use JWTs, sessions are your friend.
cryto.net/~joepie91/blog/2016/06/1...