We are currently in the process of building a service (a REST API) which is called on by our primary application. The primary application contains a users/permissions/roles set up which is used to verify if the user is able to complete tasks on the application. The user-roles relationship is one-to-many.
The third party API has various end points. We are now required to implement a roles/permissions type system for the endpoints. For example role A might be able to call a create/update endpoint but not destroy.
The question lies within where the roles/permissions should be stored and verified for the REST API service. We already have a roles/permissions set up on the primary application and adding finance specific roles to this set up seems like the wrong choice. It also means that the logic would not be contained on the REST API service so if we were to call the endpoints from other services later down the line this service would also require a roles/permission set up.
The question in general is
Should the roles/permissions tables and logic be stored on the REST API service (the REST API service) - I am almost certain this is the correct/best approach.
How to assign the API services roles/permissions to the users of the primary application. Maybe it requires the set up of additional tables that contain service specific roles (this still feels dirty as we would have two different places where users relate to the roles)
Another option is to have a roles_users table on the REST API service which relates the primary user ID to roles within the service.
Other considerations are that the primary application will need to check these permissions almost every page load to check if certain menu information should be displayed - we can obviously cache this information since it should not be changed often.
The framework is Laravel but I do not think this is relevant to the question. Included it just in case.