Behind 'Cloud Native Data Security with OAuth': Highlights from the Authors

We recently spent over a year writing a consumer-focused book on the big picture of modern application security. O’Reilly has now published the book, Cloud Native Data Security with OAuth, which explains a number of security requirements, along with design patterns to meet them. In this article, we give a taste of what the book is about.

Data Security Design

Organizations commonly utilize APIs to expose business data. Applications (clients) call APIs and provide a user interface for end users. Meanwhile, users operate clients to access and create business data. Data security must be protected against unauthorized access, including cyberattacks. On top of that, data security also needs to deal with other complexities like user privacy and the user experience.

Securing data access sometimes feels like a burden to organizations. Stakeholders like business owners or architects may only have a partial vision of how secure access should work for the next five years. Ideally, they should have a plan to accommodate API growth and business initiatives like expanding to new regions and meeting their privacy regulations.

When your data security lacks a future-proof design, expensive problems arise, such as:

Security vulnerabilities and data breaches.
Lack of visibility or governance of security events.
Overly complex API and application code that impacts the time to market.
An inability to modernize technology due to dependencies on legacy security.

However, there are a set of API-first security design patterns that you can apply:

Separate concerns to enable easier-to-change security with gradual modernization.
Plug in advanced security implementations with up-to-date protections.
Use an architecture that serves API and application teams and simplifies code.
Enable the people who care most about data security to govern it.

The OAuth authorization framework can help to enable these behaviors. Unlike other security frameworks, OAuth is centered on API access. Therefore, OAuth suits modern businesses very well and is the de facto standard for implementing access control.

OAuth Technical Choices

Many technical people know about OAuth. However, there are often several gaps in their understanding. The heart of the protocol is the correct use of access tokens to deliver business security context to APIs. A component called the authorization server issues access tokens to clients. Clients must include access tokens in their API requests, and APIs must base access control on the access token and its associated data.

To get the most out of OAuth, you should have a solid understanding of these foundations. You should also know about the different flows and when to use them. Finally, you should understand how customization works to avoid future blocking issues.

Unfortunately, it is too easy to make suboptimal choices when getting started and fail to deliver the right business outcomes. Much online OAuth material is accompanied by vendor-specific terminology or marketing which adds to the confusion for developers and architects. Without care, security can harm the developer experience and also the business time to market:

Some security frameworks use old technologies, hide OAuth security behaviors from developers or use unnecessary complexity, leading to bugs or productivity problems.
Developers may have some success, such as getting a user login working, but then run into deeper problems, like APIs receiving incorrect or insufficient authorization data.
Teams may have to manage authorization server limitations, like deployments that do not match APIs or an inability to integrate with existing infrastructure.

In some cases, people may blame OAuth for these issues. However, the root cause is usually a lack of understanding of how such a system should serve the business. Done right, OAuth should integrate cleanly into your existing API architecture.

A Unique OAuth Book

Cloud Native Data Security with OAuth aims to fill in OAuth gaps for readers so that they can plan for the future and understand how OAuth scales alongside APIs. The book explains the important characteristics of the protocol and operates within a cloud-native environment, so that you can combine OAuth and cloud-native design patterns.

The book presents a journey that consists of 4 parts:

Part 1: Introducing Cloud Native OAuth
Part 2: Securing APIs with Tokens
Part 3: Operating Cloud Native OAuth
Part 4: Securing API Clients

Part 1 starts with a business rationale for OAuth. It also explains the types of security components you should consider and ways to design identity data storage, like user accounts. Part 2 is the deepest part of the book and focuses on how best to use access tokens and communicate them from clients to APIs. Part 3 dives into some deployment and security hardening topics. Finally, Part 4 covers mobile and web applications and user authentication techniques.

Many OAuth-related resources primarily focus on user authentication, while this book covers the ambition of OAuth, its role in a modern security architecture, and the synergies with cloud-native environments. It intentionally ends with user authentication so that you understand API security and other topics before tying everything together.

The book backs up the theory with accompanying code examples that run production-like deployments on local machines so that readers can easily study the concepts without relying on external infrastructure. In this way, it showcases a secure and productive developer experience, since the developer experience is closely related to the business time to market.

Key Takeaways: Three OAuth Design Patterns

To enable this type of developer experience and a future-proof security architecture, start with three particular security design patterns.

1. Use JWT Access Tokens in APIs

Access tokens are a unifying technology. Regardless of the client, APIs should validate JWT access tokens and implement authorization using access token data. Ensure that you have a data setup that allows you to customize access tokens and include the values your APIs need. Also, do some thinking about designing access tokens with good manageability. Then, use a zero-trust approach where every API request requires a JWT access token:

The main API security task for developers is business authorization. JWT access tokens should set up API logic to authorize in productive ways. You can use access tokens to implement various authorization models, from role-based access control and relationship-based access control to attribute-based access control.

The book dives deep into authorization strategies to make business rules easier to change and to enable auditing of API access. It also provides a code example that shows how to use JWT access tokens and apply authorization to enforce business rules. It includes suggestions on how to write tests against APIs, so that teams can frequently verify all of their security.

2. Use a Code Flow in Applications

When an application needs to authenticate users, it should run a code flow to get an access token. Developers only need to write the code for two HTTP requests (and their responses). These are called the front channel request and the back channel request. The following flow visualizes them:

It is important that OAuth developers understand the HTTP message details. Therefore, the book shows how to write the precise code to handle the two HTTP requests and responses for web and mobile apps.

You should be able to use or implement any possible user authentication method, ranging from integrations with legacy systems to the newest authentication protocols. For this reason, the book also shows how to upgrade to passkeys to harden security and modernize the user experience.

The real power of the code flow is the business agility after integration. The authorization server should allow you to extend user authentication behaviors without application changes. For example, you can present custom compliance and regulatory forms to users and externalize that complexity from development teams.

3. Use Token Translation in the API Gateway

Finally, clients sometimes run in hostile environments where you must protect against threats like malicious code execution or malicious applications that impersonate the real client. To mitigate threats, clients must apply environment-specific best practices, which can result in client-specific message credentials.

Use an API gateway to translate incoming message credentials to a JWT access token for APIs. This keeps API security code focused only on JWT access tokens and business authorization.

The book shows how to implement the phantom token pattern so that clients receive confidential access tokens. Further, it explains how clients should transport access tokens to APIs as part of environment-specific best practices and highlights how to implement the token handler pattern to combine single page application (SPA) development with strong browser security. These patterns simplify application code and improve the developer experience.

Conclusion

Cloud Native Data Security with OAuth enables readers to implement strong security for APIs and clients with modern design patterns. The reading sequence provides a thought process to help understand the current and future security requirements for your own systems.

By reading the book, you will also gain an appreciation for how OAuth and cloud-native design patterns can help with deeper requirements in areas like compliance, regulations, and future business expansions. Finally, you should see how all of an organization’s people roles get a shared vocabulary when they discuss security topics.