CODEWITHSUNDEEP
node.jsexpressauthenticationjwtauthorization
OysterD3
OysterD3

Reputation: 282

Best practice to check user permission in RESTful API

I am developing an internal Management System for my company. Some API route will be check for the user's role, and the rest of routes will check for the user's permission.

Currently, how am I doing is storing user's permission in JWT token

{
  "user": {
    "name": "Oyster Lee",
    "role": "root",
    "image": ""
  },
  "OMS": 2147483647,
  "WMS": 4095,
  "iat": 1566536007,
  "exp": 1567140807,
  "iss": "Test"
}

My permission is using a bitwise operator. But it can only use up to 31 types of permission in each system. I have more than 31 so the bitwise operator will need to be replaced.

Besides that, after I assign the user new permission or role, he has to log out and log in again and again.

I am thinking should I check the database for user's permission each time they are sending a request to the route. Will it cause the application heavier? Are there any pros and cons? By the way, I am MySQL as our database.

Front-end also need to render conditionally base on user's permission or role. I am using Nuxt.js SPA as front-end.

Upvotes: 6

Views: 6930

Answers (1)

David Brossard
David Brossard

Reputation: 13834

The system you are building is suffering from multiple problems:

  • first of all it will lead to role explosion / permission explosion. Right now you've thought of several roles and permissions. But there could be more in the future. Would you have to redesign your permissions?
  • Secondly, you cannot elegantly handle relationships (what if access is based on the fact the user and the object are in the same department / region?)
  • Thirdly, you're hardcoding your own logic using My permission is using a bitwise operator. But it can only use up to 31 types of permission in each system. I have more than 31 so the bitwise operator will need to be replaced. That just won't scale
  • Lastly, you are forced to log in / log out for changes to take effect.

What you need is decouple and externalize authorization logic from the Internal Management System API. There is a pattern called attribute-based access control (ABAC) that achieves just that. With ABAC, you have an interception-based model whereby a Policy Enforcement Point (PEP) intercepts the call to your API and checks against a Policy Decision Point (PDP) whether the caller (Alice) should be allowed to get access to whatever they are requesting (a document, a record...).

Attribute Based Access Control

The PDP is configured with policies that use attributes to describe what can or cannot happen. For instance:

  • A user with role == "manager" can do action == "view" on object of type == "record" if user.department == record.department.

There are two standards to write such policies: and . There are several implementations of the ABAC architecture both open source (AuthZForce, AT&T...) and commercial (Axiomatics). Do check them out. I've also written a lot on this issue in other SO posts such as this one.

Upvotes: 9

Related Questions