4 ms·
Yes for basic websites simple DB based session might be enough. And if you think about these sessions they are essentially opaque and stateful tokens pointing t
by maxpert 4y ago
Yes for basic websites simple DB based session might be enough. And if you think about these sessions they are essentially opaque and stateful tokens pointing to a row in DB containing the information you need. But saying JWT sucks in plain generic terms is out of context statement, in large micro-service environment if every front-end service starts hitting an identity service the fan out is gonna kill you! You keep a basic set of information in token that is most often used, not every service will need user phone number, and all of his roles. 95% of your read traffic will need some basic ID, email, and basic roles that can be satisfied from JWT token. What OKTA is suggesting essentially is gonna push all the load onto a DB or some sort of datastore, so that it becomes SPOF, and now you have shifted problem to scaling that DB/Datastore. Answer IMO is it depends.
- vore 4y agoThe article calls this out: > If you’re building any type of service where you need three or more parties involved in a request, JWTs can also be useful. In this case the requesting party will have a token to prove their identity, and can forward it to the third (or 4th … nth) service without needing to incur a real-time validation each and every time. But it doesn't seem like a good idea to expose the JWTs to the user directly: what if a user updates their phone number? This won't be reflected in already generated JWTs. It seems like a better idea to, at the frontend, generate any JWTs you need to pass to backends and use those to avoid fan-in to whatever identity service, rather than handing those JWTs directly to the client.
- eurasiantiger 4y agoTo be honest, if your JWT access token expiry is over ten minutes from creation and you have no way of invalidating tokens, you are doing it wrong.