Option 1: Global FusionAuth Instance with Regional Profile Services

You can deploy a single global FusionAuth instance in one region (e.g., US or Japan) and store email addresses and authentication credentials there, while keeping other personal data (like names) in regional profile services.

In this model:

• FusionAuth handles authentication globally and issues access tokens
• Services in each region validate the access token locally
• User profile information is retrieved from the region-specific profile service instead of FusionAuth
• Users maintain a single identity across all regions without re-authentication

This approach works well when:

• Email addresses and authentication credentials can be stored globally
• Other personal identifiable information must remain in-region
• You need seamless cross-region access without re-login

Option 2: Separate FusionAuth Instances per Region (Physical Isolation)

For strict data residency requirements, FusionAuth recommends physical isolation where each region gets its own completely separate FusionAuth instance with its own database and web server. This approach:

• Guarantees no possibility of data intermixing across geographies
• Prevents downtime in one region from affecting others
• Fully satisfies compliance requirements where data must remain in specific geographies
• Works well for GDPR and other data sovereignty regulations

Tradeoffs: This is more expensive (servers scale linearly with regions), and cross-region reporting requires network calls. Users would also need separate accounts per region, which may not meet your "single identity" requirement.

To maintain consistent configuration across these separate instances, you can use Terraform to sync application and tenant configurations between deployments while keeping user data isolated.

Option 3: Identity Provider Hints

Another pattern involves using IdP hints to route users to region-specific authentication flows while maintaining a unified user experience. With IdP hints, you can bypass the login page and route users directly to the appropriate identity provider based on attributes like email address or domain. This can help direct users to region-specific instances based on their location or organization.

Recommendations

Before finalizing your architecture, consider:

1. Data classification: Clearly define which identity data must be region-specific vs. what can be stored globally. Under GDPR, email addresses and authentication credentials are considered personal data.

2. Token validation: Ensure your regional services can validate JWT tokens efficiently. FusionAuth supports distributed token validation where services in any region can verify tokens locally without calling back to the authentication server. See the guidance on JWT validation in microservices architectures.

3. Compliance review: Verify your chosen approach meets your specific regulatory requirements (GDPR, etc.). FusionAuth is designed with GDPR compliance in mind and supports features like data export, deletion, and consent management.

4. Cross-domain SSO: If using separate instances per region, note that FusionAuth supports cross-domain single sign-on through OAuth/OIDC flows, though users would still need to authenticate to each regional instance separately unless you implement additional federation layers.

This is a complex architectural decision that benefits from detailed discussion of your specific requirements.

Related Documentation

• GDPR Compliance in FusionAuth
• GDPR Developer's Guide
• Identity Provider Hints
• JWT Validation at Microservices Boundaries
• JWT Authorization in a Microservices Gateway
• Single Sign-On with FusionAuth
• Multi-Region Login Community Discussion
• Deployment Model Comparison