0

From a security perspective is it ok to store the permissions of a user inside the body of the Json Web Token? For example a jwt body like this:

{
   "username": "lukas",
   "isAdmin": true
}

The integrity of the body is verified by the signature of the token so I think it is no problem to use this technique but as it is really security relevant I want to ensure whether my thoughts are right.

TheProgrammer
  • 3
  • 1
  • Your thoughts are only on the threats in transmission and not the threats on the client. In principle, authorisation levels need to be not transmitted. – schroeder Feb 19 '20 at 20:05
  • @schroeder why? if the client changes the flag, the signature is invalid. – Josef Feb 20 '20 at 14:14
  • If you are doing that you should consider encrypting your token with RSA instead of a single token. – Maaaaa Feb 20 '20 at 15:13

3 Answers3

0

It depends on what scenarios are relevant in your case, it depends on architecture that you want to implement. Some examples:

1) If in your case the risk of compromising of account with low permissions is higher compared to accounts with high permissions, then sending permission info in the token increases your risks.

2) If in your case all accounts can be equally easy (or equally hard) compromised, then sending permission info doesn't change your risks: The attacker will compromise an account with high permissions (e.g. admin account) and, even if permission/authorization logic is embedded in the application not in the token, he will get all permissions of this account.

3) If in your architecture you want to have "slim" application modules / services, that provide as high performance as possible, as small response times as possible, use as little resources as possible, or if integration with authorization / permission system is too expensive, then may be you want to eliminate any logic related to authorization / permissions in the modules / services that implement business logic. On some nodes you can deploy authentication and authorization services. On many other nodes you deploy (or run containers, doesn't matter) services that implement some business logic. And you may want that these services don't care about permissions and just trust the tokens that the other part of your application issued. Then sending permissions within tokens could be a good approach.

mentallurg
  • 8,536
  • 4
  • 26
  • 41
0

It seems to be okay to store permissions like that on the web server (not the client side e.g. Browser).

Just make sure that the web server is hardened enough in terms of information security.

There is however more secure solutions as store it on the web server in an encrypted form. I am a .net programmer, I am aware of that kind of a solution. It depends on the framework/programming language you use, you may be able to store it in a more secure way on the server.

Dan Friedman
  • 121
  • 2
-1

if you are doing this just for UI and showing or hiding buttons, links or anything else, it is OK and there is now problem with that. but be sure you only check user permissions for doing actions on the server based on data which you have on the server not the data you are taken from client itself.

Soheil
  • 21
  • 2
  • JWT tokens are signed by **the server**. The client provides the data, but the only source it can obtain a valid piece of data is *from* the server. The client cannot modify the data without making it invalid. So as long as the signature is positively verified before the data is being trusted, all is fine. – marstato Feb 20 '20 at 08:20