Best practice to check user permission in RESTful API

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...).

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: alfa and xacml. 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.