Ign*_*cio 11 c# asp.net authentication cross-domain asp.net-mvc-4
我有两个不同的Web应用程序用ASP.net MVC构建.这两个应用程序可能无法在同一服务器上运行,也不能在同一域中运行.
我想如果用户登录其中一个,则应自动登录另一个.同样适用于注销.
你认为哪种解决方案最好？你知道一些示例代码吗？
谢谢!
---编辑更多信息---
用例场景:
用户在选项卡上打开了Web应用程序A,并且在应用程序的某个位置存在将用户重定向到Web应用程序B的链接.如果他登录A,我想向他显示整页,如果不是,请将他重定向到登录表单.
为什么我需要这样做:
应用程序A和B已经构建.显然,访问B的唯一方法是单击位于A中的链接,只有在您之前已登录时才会显示该链接.问题是,如果您知道B的某个页面的URL (很长且很复杂,但仍然),您可以在浏览器上写入并访问B,这意味着存在安全问题.
我的答案可能不是最好的答案,但你可以使用一些棘手的机制
我假设您无法使用任何共享存储在应用程序A和B之间进行通信.(这可能允许一些共享会话实现).
更多的行业标准方式(OpenID Connect)就像其他一些答案所暗示的那样.我会尝试提供更多细节,让您走上正轨.
应用程序A和B都应该将身份验证过程中继到受信任的第三方(可以使用A,B或其他应用程序托管) - 让我们称之为C
当用户到达A或B时(无论B有奇怪的复杂URL,她总是可以为这些URL添加书签),他的请求应包含授权令牌.如果没有,她没有经过身份验证,将被重定向到C并提供一些登录机制 - 比如用户/传递表单.
成功登录后,她将被重定向回A/B(取决于她来自哪里),以完成她使用身份验证令牌所做的事情.现在,拥有身份验证令牌,她将通过身份验证.
如果她使用A进行身份验证然后重定向到B,则此重定向也应包含令牌,B将知道如何信任该令牌.
现在,如果他刚刚打开一个新的标签,B就不会看到任何标记,所以她会被重定向到C,只是被重定向回来(她已经过身份验证,还记得吗？)给B带有令牌,现在一切都很好.
我所描述的是使用OpenID连接的常见流程,如果使用.net,我真的建议使用Thinktecture的IdentityServer为您做好工作并成为您的"C".
另一个选择是支付托管为SaaS应用程序的"C" - 查看Auth0
| 归档时间： |
|
| 查看次数： |
4973 次 |
| 最近记录： |