跨域身份验证ASP.net MVC [英] Cross-domain authentication ASP.net MVC

问题描述

我有两个使用ASP.net MVC构建的不同Web应用程序.这两个应用程序可能不在同一服务器或同一域中运行.

I have two different web application built with ASP.net MVC. This two application may not be running in the same server nor in the same domain.

我希望，如果用户登录其中一个，则应自动登录另一个.注销时也应如此.

I would like that if a user login in one of them, automatically should be login in the other. The same should work with logout.

您认为哪个是最佳解决方案?您知道一些示例代码吗?

Which do you think is the best solution? Do you know about some example code?

谢谢！

---使用更多信息进行编辑---

--- EDITED WITH MORE INFO ---

用例场景:

用户在选项卡上打开了 Web应用程序A ，并且在该应用程序的某个位置，有一个链接将用户重定向到 Web应用程序B .如果他登录了 A ，我想向他显示整个页面，如果他没有登录，则将他重定向到登录表单.

The user has the web application A opened on a tab, and at some point of the app there is a link that redirects the user to the web application B. If he is logged in on A, I would like to show him the full page, and if he is not, redirect him to the login form.

为什么需要这样做:

应用程序 A 和 B 已构建.显然，访问 B 的唯一方法是单击位于 A 中的链接，只有在您之前登录时才会显示.问题是，如果您知道 B 某个页面的网址(虽然很长很复杂，但是仍然可以)，则可以在浏览器中编写它并访问 B 意味着安全问题.

Applications A and B are already built. Apparently, the only way of accessing B is clicking on the link located in A, that only is shown if you have previously logged. The problem is that if you know the URL of some page of B (are long and complex, but still) you can write it on the browser and access B, which it means a security problem.

推荐答案

我假定您无法使用任何共享存储在应用程序A和B之间进行通信.(这可能允许一些共享的会话实现).

I assume you cannot communicate between applications A and B using any shared store. (This could allow some shared session implementation).

更行业标准的执行方式(OpenID Connect)就像其他答案中暗示的那样.我会尝试提供更多详细信息，以使您步入正轨.

The more industry standard way (OpenID Connect) of doing that is like some of the other answers have hinted at. I will try and give more details to get you on the right track.

应用程序A和B都应将身份验证过程中继到受信任的第三方(可以与A，B或其他应用程序一起托管)-我们将其称为C

Both application A and B should relay the authentication process to a trusted 3rd party (which could be hosted in withe A, B or a different application altogether) - Let's call it C

当用户到达A或B时(无论B具有奇怪的复杂URL，她始终可以为这些URL加上书签)，他的请求都应包含一个授权令牌.如果没有通过，则她没有经过身份验证，将被重定向到C并提供某种登录机制-例如用户/通过表单.

When the user arrives at either A or B (no matter that B has weird complicated URLs, she can always bookmark those) his request should contain an authorization token. If it doesn't, she is not authenticated and would be redirected to C and presented with some login mechanism - say user/pass form.

成功登录后，她将被重定向回A/B(取决于她来自何处)以完成她对身份验证令牌所做的一切.现在，有了身份验证令牌，就可以对她进行身份验证.

After successful login, she is redirected back to A/B (depending on where she came from) to complete what ever she was doing with the authentication token. Now, having the authentication token present she is authenticated.

如果她通过A身份验证然后重定向到B，则此重定向也应包含令牌，B会知道如何信任该令牌.

If she is authenticated with A and then redirected to B, this redirect should contain the token as well, B would know how to trust that token.

现在，如果他只是打开，则会打开一个新标签，B将看不到任何令牌，因此她将被重定向到C，仅被重定向回C(她已经通过身份验证，还记得吗?).，现在一切都很好.

Now, If he just opens opens up a new tab, B would not see any token, and so she would be redirected to C, only to be redirected back (she is already authenticated, remember?) to B with the token, and now all is good.

我所描述的是使用OpenID connect的常见流程，如果使用.net，我真的建议使用Thinktecture的 IdentityServer 到为您辛勤工作，成为您的"C".

What I described is a common flow using OpenID connect, and if using .net, I really suggest using IdentityServer from Thinktecture to do the hard work for you and be your "C".

另一种选择是支付作为SaaS应用程序托管的"C"的费用-签出 Auth0

Another option, is to pay for such "C" hosted as a SaaS application - check out Auth0

这篇关于跨域身份验证ASP.net MVC的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！