How to Design Scalable SaaS API Security
Software as a Service (SaaS) is becoming the norm for many organizations providing digital services. Data is served by APIs and consumed by user-facing applications or made available to partners. Solutions can be rolled out to many tenants using the features of the cloud platform. Customers only need to run apps and do not need to manage any infrastructure.
Yet APIs do not stand alone. They depend on components that provide vital supporting roles to ensure key behaviors in deeper areas, like availability and scalability. One area that must be designed early on is security. For the best results, it is recommended to externalize the complexity of security from application components. Otherwise, things will become significantly more complicated as the number of components and people grow. When designing SaaS solutions, a security-first approach enables the best business outcomes. I’ll explain how below.
Security Requirements
Security must be a key consideration early in any modern architecture design. If security is not taken into account, designs become difficult to retrofit later and may become exposed to threats that could have been mitigated with the proper infrastructure from the onset.
A solution must enable APIs to share data securely to the internet and restrict access according to the organization’s business rules. It also needs to protect against common API threats. This design needs to scale effectively to many APIs as your organization adds products and services.
To integrate with APIs and access secure data, client applications must be able to authenticate users. There are many possible ways to do this, which differ in terms of security and user experience. The client application must then receive an API message credential that identifies the user and locks down backend access based on the user’s identity and business rules.
A key characteristic of the security design is that it must scale effectively as the number of clients, APIs, development teams and business partners grow. This can include dealing with multiple tenants or expanding the business to new markets, where security and legal requirements may differ.
The OAuth 2.0 Authorization Framework
OAuth 2.0 is a family of specifications that map to security use cases for organizations. It also provides the best current capabilities for securely connecting systems. This is done by introducing a central component called the authorization server to manage the lower-level security. End-to-end security flows are then straightforward to integrate into clients and APIs in any technology stack with minimal code.
The basics are that the client runs a code flow, which can authenticate the user in many possible ways. Adding new authentication methods to the client does not require any code changes. The client is then issued a least privilege access token, which locks down its backend access.
APIs receive the access token in an unforgeable JSON Web Token (JWT) format. They cryptographically verify the JWT on every request, and then apply claims-based authorization using straightforward code. This enables a modern zero trust architecture (ZTA) that protects against both internal and external threats.
The more subtle advantage of OAuth 2.0 is its scalability. For example, an organization should follow scope and claims best practices as it adds more APIs. Scopes enable access tokens to flow easily between related APIs while ensuring access is immediately denied if the token is sent to an unrelated API. Similarly, a tenant_id claim could be issued to ensure an immediate forbidden response if a user from one tenant attempts to access resources owned by another tenant.
The authentication and authorization best practices are easy for people to learn. Once understood, the patterns can be applied the same way across many components and the teams working on them, without increasing complexity.
Choosing an Authorization Server
Once the SaaS organization has a clearer idea of how it wants its end-to-end security to work, the next step is to choose an authorization server. When using SaaS for APIs, it is common to lean toward using a SaaS provider for the authorization server. An example might be the cloud provider’s built-in implementation. But choosing an authorization server without sufficient care and attention can lead to expensive rework later.
First, the security behaviors of the product should be reviewed along with its support for OAuth standards. Clients and APIs should be coded in a standards-based way so that security only ever needs minimal rework in the future. Also, pay particular attention to access token design to ensure that the correct scopes and claims can be issued and used across multiple APIs. The correct authentication method(s) must also be supported, and the login user experience should be reviewed.
Next, consider the viewpoint of people. This includes engineers who sometimes need to run end-to-end security flows on their local computers. DevOps teams are often responsible for production deployments to update the authorization server’s configuration settings. In a worst-case scenario, a failed authorization server can result in downtime for digital services. Prepare for this by reviewing the authorization server’s troubleshooting capabilities. Avoid a setup where you rely on support engineers from a third-party SaaS provider to resolve technical issues.
SaaS APIs need supporting components to function reliably at scale. In addition to the authorization server, other key third-party components may be required, such as those for observability. For behaviors that are crucial to the correct backend architecture, aim to use best-of-breed components.
Designing Cloud Deployments
When designing SaaS API architectures, do some early thinking about deployment locations. For instance, the authorization server should always operate next to your APIs for performance reasons. It should also be deployable across multiple regions, each with its own cluster. This should not require duplicating all of the authorization server’s security settings. When high isolation is required, partitioning identity resources by the tenant must also be possible.
Different regions can have varying legal requirements, which may affect the hosting design, such as the choice of cloud provider for that region. The ability to store sensitive data in each user’s home region might be necessary in some business use cases. This can be enabled by issuing a region claim to access tokens and then routing API requests accordingly. This may lead an organization to design a global deployment that includes the following components.
Portability is, therefore, an essential quality to aim for when designing API architectures. This could be managed using serverless or cloud native technologies for the APIs themselves. For supporting components, many best-of-breed implementations are cloud native. They can, therefore, be run identically in any cloud or on premises. Deployment options can vary from simple virtual machines to full-fledged Kubernetes clusters.
A model for deploying anywhere also empowers development teams. They can spin up their own instances wherever needed, including on local workstations.
Conclusion
Some upfront design thinking is recommended when organizations plan their SaaS API architecture. An early focus on security and deployment can prevent blocking issues or expensive rework later. When choosing critical supporting components, avoid taking dependencies on third-party SaaS components since they may limit deployment options and introduce dependencies on third-party people to support the system.
Instead, empower development and DevOps teams with the best setup, deployment and operational features. At Curity, we provide many resources for integrating security while achieving the best all-around architecture. The designs and deployments scale to many components without adding complexity. Regardless of the authorization server you choose, our website has extensive learning resources to help your teams on their identity journey:
