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

Five things developers need to know about APIs and authorization

It's becoming increasingly difficult to understand what APIs are exposed and how. Learn why policy-driven authorization can elevate your API security.

With the proliferation of APIs across an enterprise, it becomes increasingly difficult to fully understand what APIs are exposed and how. This is why a mature authentication & authorization layer is needed to securely expose your APIs and manage their access.

Here are five things developers need to know about policy-driven authorization and API security.

1. The heavy lifting is already done

You have already defined what the business object is for the API. For example, you have already decided you want to look at medical records and what you want to do with that record such as viewing it, deleting the record, etc. This means you are ready to write authorization policies. Having the API and underlying object model clearly defined makes the conversation with the security team or app team more straightforward.

2. Get fine-grained authorization without API sprawl

Let’s tackle the elephant in the room: who should be able to do what?

At this point, you are starting to look at the business use case from an authorization’s perspective and ideally in a fine-grained manner where it makes sense to start doing policy-driven authorization on your APIs. Following the example of protecting medical records, this allows you to think about who can do what to the medical records – can a patient view or edit their record, can the next of kin access the record, which level of staff member can delete a record, etc. Without authorization, the only other way to get this fine-grained with your APIs is to add more APIs which leads to API sprawl or more code inside your API which leads to spaghetti or bloated code.

Growth of APIs in the future

Source: devops.com

API sprawl is an issue that can occur when different teams create their own APIs to meet specific needs. This often results in a large number of APIs that are not properly managed, documented, or secured, which poses a significant security risk that should be addressed.

3. There are multiple ways to incorporate authorization into your API

Commonly, there are three different ways people implement authorization into APIs:

  1. Everything is done within the API and there isn’t any framework in place. This is the most common challenge, and, frankly, the worst case scenario. It is the worst-case as authorization is hard-coded into the API making it difficult to scale.
  2. You can leverage OAuth, however you still rely on the underlying API implementation to understand the scope or claim. This means the API is still coupled with the authorization logic within the application.
  3. You can fully decouple authorization from the application by calling an authorization solution from the application, API layer, or the API gateway. This means authorization isn’t hard-coded into the API or the application, so all of the updates to access control can be done independently. It also lets you get a clean audit trail that logs all of the accesses that have been granted or denied within the application.

4. Keep it simple

When writing policies, people still tend to think in terms of scopes, claims, groups, and roles. However, it is important to start thinking in terms of plain English when it comes to writing policies. Basing policies solely on a singular element such as roles is limiting as it does not address the modern cybersecurity landscape.

Role-based access control (RBAC) is a good starting point, however, it is coarse-grained and cannot capture the richness of an API ecosystem. But you can extend your RBAC strategy with attribute-based access control (ABAC) as it considers other elements such as compliance, geography, etc making it more fine-grained. By leveraging attributes you can define detailed access policies which enable organizations to align to complex and ever-changing security and compliance requirements.

When rethinking how we form authorization requirements, it is also important not to do a role engineering exercise. Writing policies requires a different thought process when compared to defining roles.

5. Policy-driven authorization can go either way with APIs

Generally, when we think about authorization for APIs, we tend to focus on the inbound channel, i.e. authorization as the request comes into the API (gateway). We’ll check a user’s token (authentication) and trigger an authorization check against a PDP. In a generic use case, assuming the API call is Alice GET /records/123. This might be translated into Can Alice GET record #123?. The PDP would then reply Permit or Deny.

Additionally, with policy-driven authorization you can also do authorization on the outbound channel, which is significant as this can’t be accomplished with OAuth. As the response flows back through that API gateway or interceptor in the app’s framework, you can have the gateway parse the response payload and ask whether the person (Alice in this example) can view section 1 (e.g. the billing part of the record), section 2 (the medical part…), etc. This enables advanced features like data redaction, masking, and filtering on the data that you are receiving from the backend of the API.

Diagram of how authorization works with API gateways.

Improve API security with policy-driven authorization

The benefits of using an authorization vendor to secure your APIs include scalability, fine-grained authorization, advanced use cases, and increased developer efficiency.

Ready to gain more knowledge on API and authorization? Here are some additional that look at authorization and APIs:

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 used policy-driven authorization to help secure their APIs.

State of Authorization: Playbook Edition

Get in-depth look at the challenges organizations are continually facing when considering authorization in our annual industry report.

Download the white paper

  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.