Why use subdomains to designate tenants in a multi-tenant web application?

Solution 1:

There are several ways to determine tenant on HTTP level:

• domain - tenant is determined by whole Host header
• sub-domain - sub-domain part of Host header,
• path based - path segment, usually by prefix host.com/tenantId/...
• cookie based - cookie value contains tenant id (good framework encrypts this!)
• user based - user session or some data records on server

Here are an answers to your questions:

1. (Sub-)domain multi-tenancy is good if you want to give an user a perception of fully isolated tenancy. The customer may want custom welcome and login page, separate user-base etc. On the other hand the path based multi-tenancy is good for the users who are not fixed to single tenant namespace. It is mostly used by social networks like Facebook, GitHub etc.

2. (Sub-)domains can give you better isolation and security control for cookies, cross-origin resources sharing (CORS). It makes cross-tenant CSRF or XSS a bit harder. Moreover if you have control over DNS or Load-balancer you can assign tenants to different IPs (think geo-routing) or to various versions of application (e.g. beta tenants). You can assign a separate app instance or server for your most important tenants. This way you get a cheap tool to control risk of single point of failure and all eggs in one basket.

3. Any web-framework which gives you an access to HTTP headers (Host) is sub-domains capable. Any serious MVC web-framework should give you sub-domain as action parameter directly or by plugin.

4. It is definitely a design choice. If you want to know the best way think what level of isolation you want for your tenants. If you decide but you will find that the way is not right then you can migrate to another level with help of HTTP 301 redirection.

Solution 2:

1. See below.
2. Cookies would be the most obvious, with the second being that you can change DNS settings for a subdomain but not for a path
3. No
4. Partially, see above.