How OAuth is related to Attribute-based access control

Axiomatics   ·   Monday, March 8th, 2021

What is Authorization?

Authorization, also referred to as Access Control, is the process that follows authentication (which checks your identity and ensures that you are who you say you are within a system) and which enforces the policy of what a specific user or service can do within a system.

What is ABAC?

Attribute-based access control (ABAC) is an authorization model that has gained prominence and wider adoption over the last few years as the evolution of the traditional Role-based Access control (RBAC).

While RBAC relies on roles associated with the user to model and express policy rules for authorization, ABAC relies on various attributes (and their value) of entities involved in the process to express the authorization policies and enforce access controls. 

The fundamental change in the approach of ABAC compared to RBAC is to recognize the fact that multiple attributes of users, systems and even the environment of operation would need to be considered when deciding whether to allow access.

ABC provides a framework that treats all such attributes equally and allows them to be used in decision-making and enforcement processes. 

What is OAuth?

OAuth is often described as a “delegated authorization standard/framework for REST/APIs.” 

It is an open-standard framework that describes how unrelated servers and services can safely allow authenticated access to their assets without the user having to actually share the single login credential.

It decouples authentication from authorization and allows applications and processes to authenticate and either act on behalf of the user or access parts of the user’s data without having direct access to their main authentication credentials.

Consider the flow below.

When a Consumer (C) application (e.g. Twitter Client) or service wants to get access to the service provided by Service Provider (SP) (e.g. Twitter), the consumer redirects the user to the SP endpoint to both authenticate and “authorizes” C to access the user’s information on the SP’s platform for specific actions.

SP can then internally redirect the flow to an Authorization Server which basically authenticates the user and checks the data and action being requested and provides an Authorization Code back to the Consumer to prove this authorization.

This Authorization Code is then presented by C to the SP to prove authorization and is, in turn, returned an Access Token, which can then be used by C during any later interactions (as long as the token is still valid) to perform actions at the SP.

How ABAC is related to OAuth

While OAuth provides mechanisms to selectively access parts of a user’s data (in the form of ‘scopes’), the actual process it facilitates is still authentication and a limited form of authorization – an authorization that basically proves that the user has authorized the Consumer to access SP on its behalf.

The OAuth framework does not go into the finer details of how the actual authorization is implemented at the Service Provider when the Authorization Code is presented by Consumer or later when the Access Token is presented as well.

The Service Provider needs to implement and enforce the authorization policies that get triggered when an OAuth Customer interacts with it.

The tokens presented by the OAuth customer can be considered as attribute values that will be used by the Service Provider to make an authorization decision based on the defined ABAC policies.

For example, a simple ABAC policy that the SP can use to make an authorization decision is below:

Of course, this is the simplest policy that can be enforced by the SP. Any other policy (regulatory, business or others) logic can be added to make this a more rich policy.

For example, one could implement a tiered usage model for accessing the SP’s API as follows:

As you can see, the finer logic of authorization that is implemented in the ABAC policy is not part of the OAuth specifications as the specification standard is orthogonal to the business policy (in this case) that the SP wishes to implement.

Conclusion

OAuth specification plays an important role in API-centric access and authentication.

However, the specification is meant to formalize the process flow in order to secure the delegated authentication and authorization process when a consumer interacts with the Service Provider on behalf of the End-user.

However, the specification does not cover how the actual decision of whether a consumer’s access request should be permitted or not based on finer grained policies that capture authorization requirements that arise from regulatory or business needs. Attribute-based access control is a framework that provides the service provider with the means of modeling and enforcing such authorization requirements.

ABAC thus plays a complementary role to OAuth in securing access to API-based services.

Axiomatics Policy Server, the flagship product of Axiomatics, the leading provider of externalized runtime authorization solutions, provides the best in class support for your organization’s ABAC-OAuth integration needs.