Cognito with multi tenant domain and single user pool

0

Hi, I’m working on an application where the frontend is a static React app, and the backend is an API Gateway with Lambda functions. For authentication, I’m using Amazon Cognito with a Single User Pool.

The application URL is structured like this: [tenant].my.app.com.

My issue is that Cognito App Client callback URLs don’t support wildcards, so I can’t directly use dynamic subdomains for each tenant.

One idea I had was to redirect the authentication flow to a fixed endpoint like auth.my.app.com, handle the code validation there, and then redirect users back to their specific [tenant].my.app.com.

I’m wondering:

  • Is it possible?
  • Is this a good approach?
  • Are there better ways to solve this problem?

Any suggestions would be greatly appreciated!

1 Answer
0

Yes, your idea of using a fixed endpoint like auth.my.app.com for handling the callback and then redirecting users back to their specific tenant subdomain is a valid and commonly used approach. Here's a more detailed breakdown of how this can work and considerations for your setup:

  1. Is It Possible? Yes, this is definitely possible. The approach you're considering is a typical pattern when using Cognito with multi-tenant applications where the subdomains are dynamic (e.g., tenant1.my.app.com, tenant2.my.app.com). Cognito App Clients don't support wildcards for redirect URIs, but you can still implement a solution by handling the redirect flow manually.

  2. Is This a Good Approach? This is a solid approach, as it simplifies the handling of the callback URL in a multi-tenant scenario. By redirecting to a fixed authentication endpoint (e.g., auth.my.app.com), you can centralize the logic for handling the callback URLs, which makes it easier to validate the user’s session and then redirect them to their specific tenant URL.

Key Steps in this Approach: Frontend: Users initiate the authentication process by going through the Cognito login flow. After the login flow, Cognito redirects to a fixed URL (auth.my.app.com). Backend (auth.my.app.com): On the server-side (Lambda function behind API Gateway), you extract the tenant information from the request or session.

Once the callback URL (Cognito redirect) is received, you use the provided authorization code to exchange it for tokens (access token, ID token). After token validation, you then redirect the user to their specific tenant subdomain (e.g., tenant1.my.app.com). This centralizes the authentication flow, allowing you to avoid managing multiple different redirect URLs in Cognito.

  1. Are There Better Ways to Solve This Problem? While your approach is perfectly valid, here are a few alternatives and things you might consider:

Dynamic Redirect URLs via Cognito Triggers (Post Authentication Lambda) You can leverage Cognito Triggers to automate the process of directing users to their correct tenant URL. Specifically, the Post Authentication Lambda Trigger can be used to customize the flow after successful authentication.

Lambda Trigger: After a user is authenticated via Cognito, you can use a Lambda function triggered by the "Post Authentication" event to inspect the user's identity and decide which tenant subdomain to redirect them to.

For example, the Lambda can: Check the user's attributes (like tenantId). Dynamically construct the redirect URL based on this tenant information. Perform any additional logic or validation if needed. However, this approach still requires some way to map the tenant information to subdomains or URLs within the Lambda trigger.

Custom Authentication Flow If you need even more flexibility, you can implement Cognito Custom Authentication Flows (using AWS Lambda triggers). With custom flows, you could control the entire authentication experience, allowing you to include tenant-specific logic in the authentication process.

However, building a custom flow is more complex than using the standard Cognito hosted UI, and it could require handling multi-step authentication processes manually, such as verifying MFA or dealing with custom sign-up/sign-in steps.

  1. Other Considerations Security: Ensure that any tenant-specific logic is well-validated in the backend (especially if redirecting users dynamically to different subdomains). Make sure that there’s no possibility for users to be redirected to unauthorized tenant subdomains or unauthorized pages.

Caching/State Management: When redirecting users, make sure you correctly handle session persistence and state across subdomains, as this could potentially break if the user is not redirected correctly.

Domain/Subdomain Management: If you’re redirecting to subdomains dynamically, consider handling CORS (Cross-Origin Resource Sharing) and any necessary cookie or session management to ensure smooth user experience across subdomains.

Suggested Architecture: Frontend (React App): User initiates login via Cognito hosted UI, which redirects to auth.my.app.com.

Backend (auth.my.app.com): Lambda function: Receives the callback, validates tokens, and extracts tenant-specific information from the Cognito tokens or the request. Redirects the user to the correct subdomain based on the extracted tenant info (e.g., tenant1.my.app.com).

Tenant Subdomain: The user lands on their specific tenant URL with the correct session or token.

regards, M Zubair https://zeoendge.com

answered a month ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions