[gboone]

I figure unencrypted should be useful to the frontend, but use encrypted for authentication or authorization.

Unencrypted: maybe a user preference, or first name, or something that adds value but does not overlap with auth. Like if a frontend could serve the same functionality across three departments but the styling is different, the token's unencrypted claims could determine which style set to use.

Encrypted: user uuid, roles, maybe other known settings, things the backend can handle. Someone stealing a token will just try it anyway whether they can see claim or not, but because it's encrypted it will get decrypted so it's also a different logic flow than unencrypted and could trigger a process i.e. did it come from an accepted ip address or range? Does the ip match the previous? Does the ip match the other known ip for a websocket? So also in this sense we wouldn't want anyone to know what else we might check.

[dkarl]

The front end almost always needs to know what a user is authorized to do, because it is reflected in the UI. Which edit/delete buttons are visible and active? Is there a link to the admin page? Is there a link to a supervisor dashboard? Most apps send that information to the front end in a way that maps 1-to-1 to how they model authorization on the back end, often using exactly the same language, in which case you don't gain much by encrypting it in the JWT. But if you are taking measures not to leak your authorization model in the front end, then it makes sense not to expose it in an unencrypted JWT.

[Aeolun]

> But if you are taking measures not to leak your authorization model in the front end

How would you do that? At the end of the day the front-end needs to know what you can access somehow.

I guess you could add a compile step that rewrites all your permission checks into validating opaque uuid’s.