Skip to content

User Permissions

Context and Problem Statement

Authorization is used to check if a user is allowed to perform some specific operations in the PSS®X application.

ABP framework extends ASP.NET Core Authorization by adding permissions as auto policies and allowing authorization system to be usable in the application services too.

So, all the ASP.NET Core authorization features and the documentation are valid in an PSS®X application.

Often implementing a simple differentiation between two types of users - "Admin"/"Private" and "Not-Admin"/"Public". Creating an OAuth2 scope to represent the "admin" permission is very simple. When an Admin user logs in, the authentication layer adds the admin scope into the JSON Web Token (JWT), and every call to a protected resource checks the JWT for this "admin" scope.

In short, OAuth2 scopes are not a substitute for application-level permissions - Scopes define the level of access that a client has to a protected resource, but they do not provide the granularity necessary to define what the client can do with that resource. Here, the crucial difference between OAuth2 scopes and application-level permissions comes in.

As your application develops, simple concepts such as "Admin"/"Private" and "Not-Admin"/"Public" become insufficient, as they quickly lead to over-permissioning, which can result in data breaches or unauthorized access to resources.

The amount of different roles, resources, and actions is likely to grow exponentially along with your application. The size of a JWT is limited by the maximum size of an HTTP header, which is typically 8KB.. If we need to give a user access to 1000 files, the JWT length changes from 239 characters to 20,057 (and that’s considering a simple file name). With the full path, it’s even longer.

OAuth2 does not account for changes in access requirements over time. Once a client application is granted a scope, it retains that scope until it is revoked. This can become a problem when access requirements change and the same scope is no longer sufficient. For example, if an application adds a new feature that requires more granular access control, it may be challenging to implement this change without breaking backward compatibility. In such cases, developers may need to create new scopes, which can be confusing for users and may lead to scope proliferation.

Different resources in an application may require different levels of access depending on the context. For instance, a user may have read-only access to some resources but require write access to others. Scopes do not account for such context-specific access requirements, which can lead to over-privileging or under-privileging users.

Access control policies often involve complex logic, such as role-based access control (RBAC) or attribute-based access control (ABAC). OAuth2 scopes are not designed to support such complex policies, which can lead to significant security vulnerabilities

Considered Options

  • Manage permission with OAuth2 scopes
  • Manage permission with Policy Information Point.

Decision Outcome

Chosen option: "Policy Information Point" because,

  • All user permissions cases will not be managed due to the nature of OAuth2.