News for hackers. Stuff that matters.
Re:JWT vs. Opaque Tokens by Aeolun on Thursday September 29, 2022 @08:32PM (#33029262)
Say you steal the token, what are you going to do with it? You could argue that you can now iterate all the tokens you steal, decode all of them, and find the ones with admin permissions. But if you have a frontend that wishes to know user permissions/access, you already have an endpoint for that too, so they can call that with all the tokens instead.

The thing is that you cannot change the payload of the token without invalidating it, so you couldn’t set the role to admin and then still have the server accept it.

Re:JWT vs. Opaque Tokens by dkarl on Friday September 30, 2022 @12:50PM (#33037257)
There's no concrete exploit that it enables, but in principle it's always a risk to leak information about your security implementation. My opinion is that it's a very low risk for almost everybody, worth trading away for extra reliability and scalability if you need it.

To answer the question in your other comment, the back end can, in principle, provide a boolean yes/no value for every authorization-related decision the front end needs to make: can_change_order_status, can_view_supervisor_dashboard, can_view_all_conversations, etc. That way you never leak the model (such as roles) underlying those decisions. In practice, I've never seen anybody bother. Instead they have the back end send the front end values that map 1:1 to the back end authorization model: is_supervisor, is_account_admin, etc. That's why I think for most applications it doesn't matter if users roles are encrypted in the JWT.