Download your copy of our State of Authorization: Playbook Edition Get it now »

OAuth and Authorization: A duo in securing access to API-based services

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

What is authorization?

Authorization, also referred to as fine-grained access control, is the process of ensuring users have access to resources and allowing them to perform relevant actions on the resources – but only to the extent allowed by policies and constraints imposed by the organization’s business, legal or any other categories of requirements. These rights can be as simple as viewing a file (a grant permission) or denying the ability to view a file (a deny permission).

A traditional authorization architecture is role-based access control (RBAC), in which a user has a specific role assigned to their account allowing them different permissions in the system. RBAC is only supported by a static authorization methodology that can’t expand access beyond a role alone. Not to mention, it is also not content-aware so it can’t cater to time, location or risk.

Attribute-based access control (ABAC) is the fine-grained and context-aware approach to authorization compared to RBAC. ABAC relies on various attributes (and their value) of entities involved in the process combined with authorization policies to express 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. It enables more fine-grained, relationship-based and contextual authorization.

ABAC 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 their login credentials.

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.

Let’s take a deeper dive into this by considering the flow below

Let’s imagine a user, Alice. Alice wants to use a financial tracking app. Let’s call that app Basil. Alice banks with AcmeBank and uses ezTradeInc for investments. In a pre-OAuth world, if Alice wanted to share her financial data with Basil, she’d have to share her AcmeBank and ezTradeInc credentials with Basil. Basil would have to store those. This is called the password anti-pattern. Not only does it give Basil Alice’s credentials (and opens her credentials to theft), it also gives Basil the same level of access as Alice on her services.

The fix? Use OAuth so that Alice can grant Basil constrained (scoped) access to her accounts at AcmeBank and ezTradeInc. That access can be tailored and revoked at any time.

To achieve the use case, OAuth provides several flows. The most popular is the OAuth Authorization Code Flow is as follows:

The OAuth code flow was originally designed for websites, and involves all four parties. It is a two-step flow, beginning when the client forms an authorization request URL and opens it in the system browser. The resource owner then authenticates at the authorization server, so the client never sees the user credentials.

As a result of the grant, an authorization code is returned to the client in a browser response. This is sent back to the authorization server in an HTTP POST back-channel request, and an access token is returned. This two-step process avoids revealing tokens directly to the browser history or server logs.1

Diagram showing the code flow of authorization.

How ABAC relates to OAuth

While OAuth provides mechanisms to allow a third party to selectively access parts of a user’s data (in the form of ‘scopes’) inside another service, the actual process it facilitates is more about access delegation than full-blown authorization. It’s an authorization that basically proves that the user has authorized the consuming entity to access the target service on their 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 the consumer or later when the access token is presented as well. That’s because the service provider’s inner workings are out of scope (no pun intended) for OAuth.

The service provider must implement and enforce its own authorization policies (or logic) that get triggered when anyone 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.

A diagram that shows the flow of OAuth with Axiomatics.

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

Access Token is VALID and
Access Token TTL is VALID and
Scope is VALID

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 richer policy.

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

Access Token is VALID and
Access Token TTL is VALID and
Scope is VALID
ConsumerTier is "GOLD" and
DailyAPIsInvoked is <10000
ConsumerTier is "SILVER" and
DailyAPIsInvoked is <5000
ConsumerTier is "BRONZE" and
DailyAPIsInvoked is <2500

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.

Looking into the future of OAuth and ABAC

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.

Importantly, the specification does not cover how the decision of whether a consumer’s access request should or shouldn’t be permitted. This decision is based on finer grained policies that capture authorization requirements arising from regulatory or business needs. ABAC enables the service provider to both model and enforce such authorization requirements.

There is ongoing work under the OAuth umbrella to extend its capabilities towards authorization. This includes Rich Authorization Requests,transaction tokens, and OpenID Foundation’s latest Working Group, AuthZEN.

Additionally, at Axiomatics, we can expand traditional identity providers (e.g. Okta), use their platform hooks to call out to an authorization engine and use the policies there to generate claims dynamically that can then be inserted into the OAuth token returned from the IdP to the client. This is sometimes referred to as dynamic claims management or token enrichment. Combining a policy-driven authorization solution such as Axiomatics with OAuth authorization services extends that service’s authorization abilities.

Clearly, ABAC plays a complementary role to OAuth in securing access to API-based services. Our policy-driven authorization solution provides best in class support for your organization’s ABAC-OAuth integration needs. Reach out to us for a 30 minute demo where our team can show you why some of the world’s best-known brands have combined policy-driven authorization and OAuth services to extend that service’s authorization abilities.

1 “OAuth 2.0 Overview.”

Have 30 minutes? Let's show you a demo!

See how our award-winning solution can help you meet today's access control and Zero Trust needs.

Request a demo

  Join us on LinkedIn for more insights
Archived under:
About the author

As Chief Technology Officer, David has experience leading the design and development of Salesforce’s identity offering including customer identity and access management (CIAM). He is a founding member of IDPro, a co-author of the OASIS XACML standard, and an expert on standard-based authorization as part of an overall IAM implementation.