我目前有一个多租户SPA应用程序，它使用通配符URL来区分租户和数据库。例如https://tenant1.appname.com可能与数据库tenant1_db和https://tenant2.appname.com将绑定到数据库tenant2_db。
目前，前端SPA与后端.Net API托管在同一台服务器上。我使用仅HTTP cookie的cookie身份验证，因为所有东西都托管在同一个网站上——我不必处理CORS或类似的事情。
我正在探索使用OIDC从Azure AD进行身份验证的可能性。我的理解是，RFC规范规定必须对绝对URI进行OIDC回调。所以，我不能回拨https://tenant1.appname.com.
我读过一些关于使用state跟踪租户并在OIDC登录后重定向的地方。我只是好奇这在cookie和跟踪代币方面是如何工作的。如果回调URL为https://appname.com/callback然后SPA客户端转发到https://tenant1.appname.com，由于域不同，我的cookie/令牌现在似乎无效或无法访问。
有人能解释一下这是怎么回事吗？
这个问题很有趣，我想根据经验发布一些细节。不过，这可能不是一个完整的答案。
设计思想
我将从最简单的选择如何开始，基于我为投资银行提供的系统：
- 所有租户的所有用户共享相同的数据库、API和应用程序URL
- 租户ID声明包含在令牌中
- API确保租户A的用户永远看不到租户B的数据
对此不满意的客户可以支付额外费用来获得自己的专用服务器和URL，正如您所描述的。如果Cookie用于租户A，则它们不得用于租户B域。
这样做的一个关键好处是，您可以保持代码的简单性——一切都是标准的，包括您提到的回调URL问题。对于不同的租户，您可以使用不同的配置设置部署相同的代码。
AZURE AD
这可以为每个租户使用不同的OAuth URL，还可以将租户ID作为声明包含在令牌中。但这可能不是你想要的，因为并非所有租户都是一样的：
- 90%的租户可能很乐意共享同一个系统——这将是所有的小客户
- 10%的客户可能愿意。额外付费——这将是大客户
技术解决方案
希望大家都知道，这个问题通常不会有神奇的技术解决方案。在租户之间共享cookie或执行非标准的OAuth操作都可能导致漏洞利用。
路由解决方案
另一个需要考虑的选项是动态用户路由。您可以识别同一系统中的所有用户，然后动态地将他们路由到正确的URL。
大多数系统都不支持这一点，但如果它能给你一些想法，请看看Curity最近的这篇文章，特别是反向代理提供的可能性。