title: OAuth scopes and application roles & permissions
body: <p>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. </p>
  
  <p>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.</p>
  
  <p>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".</p>
  
  <p>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. </p>
  
  <p>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? </p>
  
  <p>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. </p>
  
  <p>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.</p>