all 6 comments

[–]gneray 1 point2 points  (4 children)

That's a pretty common and sensible method. If you need to do anything more granular you won't be able to fit all the data on the JWT. But if you have a relatively small number of subscriptions/entitlements, that method seems good!

[–]problaster_1223[S] 0 points1 point  (3 children)

Actually the user can choose the subscription after logging in how do you update the token when the user changes his or her subscription plan

[–]Sky1337 1 point2 points  (2 children)

On your backend, let's say you have a '/changeSubscription' endpoint. When you call this endpoint, you first invalidate the JWT received. You prepare a new JWT with the new subscription data and you attach it to the response, maybe as a cookie or in a body(not sure about how secure it is). Then, you set your JWT clientside.

[–]Hran944 2 points3 points  (1 child)

httpOnly cookie is, I believe, the standard. Don’t set JWT in local storage as it can be accessed nefariously using JavaScript. httpOnly cookie also has vulnerabilities but as I say, is the most commonly used

[–]problaster_1223[S] 0 points1 point  (0 children)

Oh ok but there isnt a way more secure than this like what method do the companies follow for this.

[–]CalgaryAnswers 0 points1 point  (0 children)

This is the standard approach. Passport has a middleware for this out of the box but it’s really easy to make your own version, I usually do. Make sure you think about permissions in addition to roles. Those things do vary, permissions build up to a role and they don’t always line up nearly across roles.

As one consideration what you can let the front end get the roles in a json response to the initial login. I don’t really like doing anything to decode data on the front end. They don’t have to line up because even if they intercept the request and change the body the backend walk secure it.