Hosting APIs in Multiple Regions
Global Users and Business Data
These days many companies want to host their software in multiple regions, which may sometimes be necessary to do business in new markets. However, several difficult requirements may then need to be satisfied:
In the past, I would probably have designed a solution via separate URLs, with data stored regionally, as required by Data Sovereignty regulations in some countries. This includes placing a reverse proxy in front of API servers as a security best practice:
Using separate internet URLs can be problematic, however. Users have to know particular URLs, and it's challenging to manage these URLs over time as legal boundaries change.
I’ve recently changed my thinking. Now, I prefer managing multi-region aspects centrally, using a single internet URL for end users.
The reverse proxy can continue to use region-specific internal URLs. We can then take closer control of the routing of API requests by making better use of the features of the reverse proxy:
As illustrated above, users could be routed outside of their home region if they are abroad or if the load balancer misbehaves. The reverse proxy can use Content Based Routing to read OAuth access tokens from HTTP requests, extract a region claim, then re-route the HTTP request correctly.
Global Users and Identity Data
It was fairly easy to understand how to route API requests, but I struggled to understand how I would manage routing of the actual OAuth requests and getting the user’s region into tokens.
The Identity Server manages Personally Identifiable Information (PII), so I wanted to also use the same type of regional data separation and request routing during the actual OAuth requests:
These were the main technical issues:
How would the reverse proxy read user region information from OAuth requests since there are many different types of messages?
How would I deal with authentication requests, and avoid login errors, since users are initially unknown and could be routed to a region where their credentials do not exist?
It turns out that there are three essential steps to solving this problem:
The user’s region must be made available in HTTP messages during both front channel and back channel requests. This information must be readable by the reverse proxy, and this must not compromise security.
Authentication must be implemented in two stages. The first stage must identify the user, which can happen in any region. The second stage must then re-route the user to their home region so that credentials can be verified.
During the identification stage, some custom logic needs to be implemented to determine the user’s region. This could be done in multiple ways and will require extensibility to meet a company's specific use case.
Therefore, a prerequisite is an Identity Server to configure the above behavior. After which, the difficult part of the solution is done.
Reverse Proxy Implementation
Once the region data is included in OAuth requests, the only thing left to do is use a reverse proxy or API gateway with support for content-based routing. The logic to read the zone from HTTP requests can then be easily implemented.
There are many mature, free, or commercial options for performing content-based routing, in systems such as NGINX, Kong, and Cloud Gateways. The coding can usually be done in a high-level programming language such as LUA, after which you have a full solution.
Curity's Solution
New features were released in version 6.2 of the Curity Identity Server, which can be combined with previous functionality to enable customers to build this type of solution:
Once the user is identified, a Zone Transfer action can be triggered during authentication.
Wrapped JWTs can be used for authorization codes, access tokens, and refresh tokens.
Operating a global software platform remains a complex problem, but these features can better control runtime behavior. Further information is available in these resources:
