ruby on rails - OAuth2 and role-based access control -

i have rails app acting oauth 2.0 provider (using oauth2-provider gem). stores information related users (accounts, personal information, , roles). there 2 client apps both authenticate through app. client apps can use client_credentials grant type find users email , other things don't require authorization code. users can log in client apps using password grant type.

now issue we're facing users' roles defined globally on resource host. if user given admin role on resource host, user admin on both clients. question is: should have more fine-grained access control? i.e. user can editor app1 not app2.

i guess easy way change role names so: app1-admin, app2-admin, app1-editor, app2-editor, etc. bigger question is: implementing whole system correctly; is, should storing info on resource host, or should denormalize data onto client apps?

a denormalized architecture this: user data on resource host, localized user data on each client host. user@example.com have personal info on resource host , have editor role stored on client app1. if never uses it, app2 oblivious of existence.

the drawback denormalized model there lot of duplication of data (account ids, roles) , code (user , role models on each client, separate management interfaces, etc.).

are there drawbacks keeping data separate? client apps both highly trusted--we made them both--but add additional client apps, not under our control, in future.

the proper way use oauth , other similar external authorization methods see it, strictly authentication purposes. business/authorization logic should handled on server part @ times, , should keep central record of user, linking external info per external type of auth service.

having multilevel/multipart set of access, must, if want setup scalable , future-proof. standard design separate authorization logic , in direct relation business rules.

stackoverflow this, asking create actual account on site after login using external method.

update: if sites similar can subset design object per application keeps application specific access rules. object has inherit global object has global rules (thus can example impose ban application-wide or enterprise-wide).

i go objects contain acess settings, , roles can related instances of both application level settings , global settings automating/compacting assignment of access.

actually can use design if not similar. avoid redundant settings , meaningless (business-wise) roles. can identify role purely job title/purpose, , impose restrictions linking appropriate acess settings setup.