Ask HN: Do you store permissions in a JWT?
2 comments
If the number of possible permissions is small enough, sure. Otherwise it ends up being a huge token that gets sent over the wire for each request.
One "hybrid" approach that seems to work well is pulling permissions from the DB but then caching them in-memory on the server. That way you can still keep them granular but you'll only hit the DB on the first request or if the cache expires. It also lets you immediately kill access (rather than waiting for the JWT to expire) if you can send a message to your servers to clear the cache for that user.
One "hybrid" approach that seems to work well is pulling permissions from the DB but then caching them in-memory on the server. That way you can still keep them granular but you'll only hit the DB on the first request or if the cache expires. It also lets you immediately kill access (rather than waiting for the JWT to expire) if you can send a message to your servers to clear the cache for that user.
It just seems that storing permissions doesnt scale and quickly. If you have even just 3 or 4 crud endpoints, you end up with read:this, write:this, read:that, write:that, etc etc.
Makes me think the DB call needs to be made (and yea, can be cached).
Makes me think the DB call needs to be made (and yea, can be cached).
Is the overhead of a database query for permissions worth the security gain of instantly able to change permissions? (IE use JWT for authentication, check permissions for authorization on each request)
What is the general consensus these days on handling permissions WRT JWTs?