OAuth scopes and application roles & permissions

Question

Currently my application is verifying user's access based on the roles and permissions. For example, if a user is admin then he has all permissions.

However, now I am implementing OAuth 2.0 and OpenIdConnect for single sign on and token based authentication for web applications and REST API's.

OAuth 2.0 and Open id connect rely heavily on scopes for access control. Scopes such as account.write account.read account.delete are very similar to permissions "CanCreateAccount" "CanReadAccount" "CanDeleteAccounts" "CanAssignRolesToPermissions".

I don't understand what is the difference between the two. This separation forces my application to check the client's scopes when access REST API's and separate check for user's permission. This i believe leads to code duplication.

Am I right in thinking that OAuth 2.0 scopes and application permissions are same? If this is true, then instead of maintaining separate application permissions, should I just stick to scopes through out my application?

For example, currently the user is assigned to a role and role has permissions. If I replace permissions with scopes then I wound't have to duplicate the client/user scope/permission checking functionality.

You might be thinking why not replace scopes with permissions. That is because I want to stick to OAuth 2.0 spec and scopes are used throughout the spec.

Answer 1

Scopes are per Client app, while permissions are per user. In other words - one client app can have a scope(s) to access certain API(s), but the users of this client app will have different permissions in this api (based on their roles). Your application should not check for the scopes. IdentityServer (I see that you have used it as a tag, so I suggest that you are using this as an OAuth authenticator) will reject a client, that doesn't have the required scope(s). Your app must only check the user permissions.