APIs are a double-edged sword in terms of cybersecurity. On one hand, APIs can strengthen cybersecurity by improving monitoring or detecting suspicious behavior, for example. At the same time, APIs are well-known as the weakest link in the cybersecurity chain, occasionally enabling data breaches, offering more surface area for cybercriminals to attack, and providing access to unauthorized data and services if an API isn’t designed properly.

Read Cloud Native Data Security with OAuth

“Managing data security and privacy in APIs and API clients is a difficult problem that requires an architectural solution,” write Gary Archer, Judith Kahrer, and Michał Trojanowski in the Preface to Cloud Native Data Security with OAuth, a new handbook for designing and implementing scalable zero-trust architecture from O’Reilly Media written by members of Curity.

Cloud Native Data Security with OAuth is as excellent, thorough, and useful as you’d expect from three authors and developers who work with APIs and cybersecurity for a living. Even better still, the authors explain the principles behind scalable zero-trust architecture and how to implement it so that readers won’t be dependent on a particular vendor or platform.

At over 300 pages, Cloud Native Data Security with OAuth is packed with useful, interesting, actionable insights. The amount of excellent information is more than we can gather in one post. Still, we’ve pulled together some of our favorite advice to give you some idea of how cloud-native data security can benefit your APIs.

Why Use OAuth 2.0?

In the introductory chapter, the authors write, “A backend platform typically consists of multiple APIs, which serve data to web, mobile, and business-to-business (B2B) clients. As with websites, you need a way to authenticate and authorize requests to and between APIs… This is where OAuth comes into play.”

They go on to explain how OAuth 2.0, the authorization framework specified by RFC 6079, which is referred to simply as OAuth throughout the text, is necessary for implementing API-first security at scale. To start, OAuth saves you from having to create your own security tools. Secondly, OAuth is highly extensible, making it ideal for cloud-native data security. OAuth uses an authorization server, which authenticates users before delivering an access token.

Access tokens are the heart of OAuth, as well as cloud-native data security and zero-trust architecture in general. APIs and microservices need to validate every API call, which is why they recommend using OAuth. It also allows cloud-native API security to be platform agnostic since it’s built using open standards.

The Elements of OAuth 2.0

In Chapter 2, OAuth 2.0 Distilled, the authors break down an OAuth architecture into four main roles: the Resource Owner, the Resource Server, the Client, and the Authorization Server.

The Client is usually an application calling the API with an access token. The Resource Owner is the entity that gives access to resources, often from the Resource Server. The Authorization Server authenticates Clients and issues access tokens. Access tokens come in two varieties. Opaque tokens are random strings, requiring the API to call the verification server for every transaction. Structured tokens have a prescribed structure, on the other hand, making them less secure than opaque tokens. JSON Web Tokens (JWTs) are the most common form of structured tokens.

Why Cloud-Native Data Security Demands Zero-Trust Architecture

“Traditionally, security controls focused on the perimeter of the infrastructure. In that model, a strong border divides the infrastructure into external and internal parts. It assumes that internal parts are trustworthy and thus focuses only on external security threats,” the authors continue in a section introducing the concept of zero-trust architecture. Cloud computing blurs these boundaries, as even internal devices and services can use external resources. “Modern API security must therefore address both internal and external threats.”

Cloud Native Data Security with OAuth discusses three main designs for zero-trust architecture: zero-trust for APIs, zero-trust for clients, and zero-trust for users. For clients, the main risks are impersonation and securing the browser, which the authors call “a hostile environment for executing code since many attack vectors exist there.” For zero-trust for users, the authors advise using “more secure options such as WebAuthn, Passkeys and digital credentials,” which they believe will be the future of API security.

The Components of a Zero-Trust System

The authors point out how API users and developers are already using a modular architecture, as nearly every API ecosystem has an API gateway and is also likely to include other components for log aggregation and asynchronous communications.

The components of a zero-trust architecture system should include an authorization server to centralize security policies. Also consider a policy engine as another tool to help govern security.

The Benefits of Access Tokens

Zero-trust architecture relies on access tokens for authorization. The authors provide an example of an access token payload:

{   
"sub": "556c8ae33f8c0ffdd94a57b7eab37e9833445143cf6847357c65fcb8570413c4",   "customer_id": "16771",   
"iss": "https://login.example.com",   
"aud": ["api.example.com"],   
"scope": "products",   
"membership_level": "1",   
"level_of_assurance": 3,   
"exp": 1721980485
 }

If any of these fields are inaccurate or compromised in any way, the token won’t be verified. You can also see how the access token dictates the scope of what data a user can access. It’s a good example of how proper architecture and implementation can solve many cybersecurity issues without requiring additional external resources. The authors recommend that each API configures a trusted URL to the authorization server to download a cryptographic public key for validating access tokens. That URL represents a trust relationship, where APIs only trust the authorization server.

How To Implement Zero-Trust Authorization in OAuth

We’ll finish up by showing you how to implement zero-trust authorization in OAuth-secured APIs, as it’s an excellent example of cloud-native data security in practice.

To start, Cloud Native Data Security with OAuth recommends that APIs receive JWT access tokens that contain business security context in a verifiable way. The authors advocate for sending signed JWTs in the HTTP authorization header. They also recommend using asymmetric token signing and strong cryptographic algorithms. They must also specify the user, audience, and expiration time.

Signed JWTs are made of three dot-separated base64-URL encoded parts, representing a header, a payload, and a digital signature. This is known as the JSON Web Signature Compact Serialization (JWS compact serialization). This prevents an asset from being tampered with, as the transaction is denied if the data is altered in any way.

When an API receives an access token, it must validate the JWT’s digital signature. This requires the algorithm that matches the kid field from the JWT header. This is usually handled by the authorization server, which makes its keys public in a JSON Web Key Set (JWKS). An example of JWKS looks like:

{
  "keys": [
      {
          "kty": "EC",
          "x": "EnhRQEJDziDD19UKkbwJum8jSlACmiwLFicOX4uaTWg",
          "y": "wy3S2TWVR9jq1SrD3f-HxEH0UlCVFLffjM0wwchgHnc",
          "crv": "P-256",
          "kid": "7791",
          "alg": "ES256"
      }
      ]
}

Your API should include a list of trusted issuers and then only accept keys from those sources. OAuth provides a key management solution that API should cope with seamlessly. You can periodically rotate token signing keys by adding a new one to the list. This setup allows you to rotate out the old JWKS key. For a brief time, you can set your API to accept both keys. To implement this properly, you should have your API contact the authorization server whenever it receives a key it doesn’t recognize, as it might have previously been valid.

In a zero-trust architecture, the authorization server stores user accounts, including personal data and various types of user credentials. This could range from the user’s name to biometric data like fingerprints or facial scans. Considering the sensitive nature of this data, the authors recommend that the authorization server be the single source of truth and that exposure be limited as much as possible.

Above all, OAuth should fit into your existing API and business flows, helping you to meet some of the deeper requirements. For example, since APIs are global, user data — including business transactions and personal data — may need to be stored in the user’s geographic region to comply with data sovereignty regulations.

Final Thoughts on Cloud Native Data Security with OAuth

As you have seen, cloud-native data security with OAuth is a vast topic with broad implications for API users and developers alike. Learning to think about the big picture of cloud-native data security should help you to think beyond paid solutions, preventing vendor lock-in while giving you the greatest control over your data and your API security.

It’s well worth taking the time to learn the master discipline and Cloud Native Data Security with OAuth from O’Reilly Media will help you do precisely that, with detailed chapter breakdowns and useful code snippets in the accompanying GitHub Repository. It’s a must-read for IT and cybersecurity professionals, API developers, or anyone looking to better grasp today’s decentralized world.