Separate user data residency for data privacy law compliance

## Problem

In some countries, there are geographical limit on the registered server used to store the user data.

For example in China, the Personal Information Protection Law (PIPL) demand that the personal information of a Chinese Citizen including the mobile number the user used to log in should be stored in a server registered in China.

For an application that serves customers across countries, this means that according to a enduser’s identity

- their user infos should be stored into different locations
- The endusers will need to agree on a different set of terms and conditions

## Research

In this section, we will look at how some MNCs approach this problem

**NIKE International**

- Show region in the signup/login screen
- Enduser should select the correct region by themselves
- If region is not China, `+86` numbers cannot be registered

**Apple**

- Region of an enduser is determined based on their IP address at first signup, user can also change their region
- If the enduser’s region is in China, their info is stored in China

## Solution

**Overview**

Let’s say a user want to serve both customers from both China and other countries.

For PIPL compliance, the user can set up two servers in China and, for example, HK respectively

- There will be 2 set up sign-up and login pages. One served from the HK server and one from China.
- Before signup, the app should determine which region the user located, this can be based on
- Asking the user before triggering signup
- IP Geolocation
- Phone number country code prefix
- Then the user will be brought to the corresponding server for authentication
- In the HK server, `+86` numbers should be blocked
- In the CN server, all phone numbers are allowed
- In the middle of signup, if the user is determined to be very likely from China, e.g. using email address ending by `qq.com` `163.com` , if they are using the HK server, ask the user to restart the signup process in the CN server.
- If the user later change their region, their data should be migrated from the HK server to the China server. A Migration API will be available for this feature.
- After data migration, all existing sessions of the user will expire and the user should re-login using the China Server.
- When signup, both servers should be check so no duplicated users will be created.
- If the phone number is found in the another server, redirect them to that server for login.
- When login, after the user enters their phone number, both servers should be checked for looking up the user. And the user should be directed to the correct server.
- In the mobile app, 2 sets of endpoints and client ids are set in the SDK.


**Note**

If the Chinese users are expected to use the app from outside China, their network speed may be affected by the Chinese network. A tunnel is recommended communicate to the China server.

**Benefits of this approach**

- Guarantee the data are separated between HK and China server, including the cache, logs, phone numbers
- Also it has low latency because DB is only query once. No need to query both DB for each operations.
- No need a centralized storage for indexing and caching.
- The approach is simple and relatively easy to do. Which means it’s less error-prone.
- Easy to change the config in only one isolated server when the compliance requirements change in the future.

### Support in Authgear

- In the **Portal**, add a page called **User Data Residency** for these configurations
- In this page, user can set the endpoint for other servers, and specify in what criteria to redirect the user
- Both Authgear projects should know the criteria of determining the region so they can redirect the users at the right moment
- the projects should know the endpoints of the other server. So servers can talk to each other for
- Checking if user exist
- Migration
- For example:
- In the HK server, add a China server **connection**
- Set up rules, if signup with email address ending by `qq.com` `163.com`, redirect the user to the China Server
- In the **Admin API**:
- Add the mutation to migrate the user from the current server to another connected server
- In the **SDK**:
- Support redirect to another endpoint
- In the **AuthUI**:
- support the relevant message for wrong region and redirection.

## Rabbit Holes
- unless a 2-phase-commit-like protocol is implemented, otherwise it is possible that we will have race conditions between sign up, and there will be multiple users of identical login ID created in multiple regions. But a 2-phase-commit will significantly degrade signup throughput if it has to be coordinated between multiple region servers.