There are different options to decide which organization a user wants to work on.
Option A
Your mentioned option 1. is a valid choice, but if you don’t like the subdomain approach, here are the others.
Option B
In case of a single domain, let him select the organization via input field, similar to what Slack is doing (that’s not Auth0, but just to give you an example):
This would work, the effect is similar using a subdomain. You let the user preselect, however, a text input field isn’t that user-friendly, and you also don’t want to use a pre-filled drop down list revealing all the organizations in your system.
So, while an input field is an option, it’s still not the best imo.
Option C
This one here would be my preference - a bit similar to your option 2 but not exactly:
Let the user login first via single domain, include the organizations of which the user is a member of as custom claims in the JWT (ID Token).
For this, you could actually consider using RBAC (Role Based Access Control) and use group or roles to assign the organization to the user. I would actually suggest this approach.
So you would create different roles (org1, org2, org3, etc.) and respective permissions assigned to these roles (permission_org1, permission_org2, etc.). Remember to enable RBAC in the API registered in Auth0.
So, after the user has logged in to your application and you got the ID token, check the roles within the JWT and offer the user a choice via a UI/drop down list in which context he wants to work right now. This context switcher can happen entirely within your application.
I don’t see a need to use different JWT and also a need to add this org selection to a JWT. Based on the current context selected in your application, the calls to your backend API will contain the currently selected organization in each request (via request parameter, header, anything of your choice).
So, the JWT (access token) that the user has can be used in all contexts / for all organizations for which the user is a member of. You can validate the permissions in your backend based on the JWT permissions claim.
However, the choice for which organization the current API request is meant to be can be based simply on a request parameter or header, doesn’t have to based on a JWT claim. I also don’t see a security issue there.
This approach is imo the easiest.
Option D
If you prefer your original option 2 and want to get a separate JWT for each organization that a user is a member of, you can use Redirect Rules and a page you put in between for the user to select the organization. Based on his selection, you’d put his selected organization as custom claim in the JWT.
Here are some general resources on multi-tenancy: