What are the challenges associated with the need to comply with local data protection regulations and how to overcome them?
Modern businesses need to win customers across multiple regions in order to grow and maximize their market opportunities. This results in application developers building digital services that could be used in multiple locations.
This presents significant challenges due to the need to comply with regulations related to data sovereignty and personally identifiable information (PII). Planning how to overcome these issues needs to be part of the architectural design.
Scaling Backend Components
An initial objective is often to achieve acceptable performance for all users. To ensure low latency of HTTP requests, it is common to host the backend system in multiple regions and use load balancing to route users to the nearest instance:
In some cases, companies may be required to store certain types of data in the user’s home region. Some countries may even block particular cloud providers. This can lead to software companies using multi-cloud as part of their global deployment strategy:
We will show how OAuth helps with design patterns for scaling web and API deployments and also enables data to be managed across legal boundaries.
Web Deployment and Security
Multiregion hosting for web content is quite simple and many companies use a content delivery network:
- Develop single page apps (SPA), to provide the best user experience.
- Deploy HTML resources to a content delivery network (CDN).
- The CDN deploys the content close to end users in 20 or so global locations.
- It is easy to switch to a different CDN if ever needed.
One area that can prevent the use of CDNs is web security, since these days it is recommended for web apps to only use secure cookies in the browser. This can lead to some companies choosing website-based OAuth solutions that require a particular runtime, such as Java, which may in turn restrict hosting options.
The best way to solve the web security problem requires insight, but it is done by implementing the OAuth work and cookie issuing in an API-driven manner. This ensures that the web security implementation does not affect your multiregion web deployment. (See this article on the backend for frontend pattern (BFF) for further details.)
Regional APIs and Data
Your real backend is of course your data and the components that go with it, which will include:
- APIs developed in your language(s) of choice
- Databases to store business data for each API
- Supporting components such as message brokers and monitoring systems
Aim to design API data storage so the API does not store sensitive information such as identity data, and to instead receive this data temporarily in tokens.
To deploy your backend globally, or to keep your options open, you should design early for multicloud, which involves keeping both your code and deployment portable. This leads many companies to use a cloud native solution that can be switched between providers quite easily:
- Deploy APIs, data stores and third-party components as Docker containers.
- Manage the containers in a hosting platform such as Kubernetes.
The preferred option is to let each region and its data operate largely as independent clusters, each with its own data. There are some tricky scenarios though, such as what happens when an Asian user is traveling in the USA:
The cleanest and most reliable way to deal with multiple regions is to control routing of API requests at a user level. A reverse proxy or API gateway is already placed in front of APIs as a security best practice. You just need to ensure that the proxy supports content-based routing.
You can then include a region claim in OAuth tokens issued to your apps. When API requests are received, the reverse proxy can then read this claim and route the user to an internal API URL in the user’s home region when required. This works even when the user is outside of their home region:
Managing OAuth Security
OAuth is the modern framework for securing web apps, mobile apps and APIs. By following recommended flows you will pass security reviews and have the best options for integrating with other systems.
A key building block is the authorization server, which implements security standards so your apps can externalize much of the difficult work. This component should continually add support for newer standards, and over time a software company will use it to implement many security solutions:
- Secure and user-friendly authentication, using standards such as WebAuthn
- Enabling a call center employee to perform actions on behalf of a user, via Client Initiated Backchannel Authentication (CIBA)
- Providing or using financial-grade connections to business partners
- Including domain-specific claims in access tokens so your APIs can authorize requests in the correct way, using digitally verifiable JWTs (JSON web tokens)
In a multicloud setup, you will want to use the same provider in all clouds, so many companies also use a cloud native authorization server, which is hosted alongside APIs:
It is recommended to use the authorization server as the source of truth for personally identifiable information. Aspects such as user consent and auditing of changes will then be managed for you, which will help to meet regulations such as GDPR.
The authorization server should enable you to keep PII only in the user’s home region, along with tokens issued and session-related information. Meanwhile, it should be easy to globally manage all the intricate OAuth client settings for your apps.
During authentication, it should be possible to dynamically route users in the same manner as for API requests so users always authenticate in their home region. This is more challenging to implement for OAuth requests, but this article, “Dynamic User Routing,” explains how it can be done:
Of course, the authorization server is a critical component for your software platform, so it should also have good support for modern availability patterns, including autoscaling and zero-downtime upgrades.
Further Details
At Curity, we are thought leaders on securing modern apps and designing for scale. See our resources for further details on the three key patterns recommended in this post:
- Use the backend for frontend approach to secure web apps to modern standards and also enable efficient deployment.
- Host a reverse proxy in front of APIs and include a region claim in access tokens, so API requests can be dynamically routed to the user’s home region.
- Use an authorization server that can run in multiple clouds, and also ensure that it has good extensibility features and support for the latest security standards.
Once these foundations are in place, you will have a globally designed architecture that provides business agility, making it much more straightforward to extend your solutions to new markets.
