我一直在研究如何为一个旧的Web表单ASP.NET应用程序实现Azure AD，在尝试通过应用程序注册中的前端通道注销URL使用单次注销时遇到了一个问题。
默认情况下，由于Azure AD如何在iframe中加载请求，这将不允许在注销请求中发送Cookie，因此请求将触发，但它不会有用户关联，因为auth cookie不存在。
我看到一篇描述这种情况的文章：https://joonasw.net/view/aad-single-sign-out-in-asp-net-core
在这里，它描述了需要在auth cookie上将SameSite属性设置为None，以便它包含在注销请求中，这实际上是有效的，它能够注销发出请求的用户，并在从另一个Azure AD应用程序注销时从我的应用程序中清除他们的cookie：
app.UseCookieAuthentication(new CookieAuthenticationOptions(){ CookieSameSite = Microsoft.Owin.SameSiteMode.None });
我的问题是，这个修复似乎有些不对劲，这不会通过允许在任何请求中发送auth cookie来打开CSFR攻击吗？有没有其他解决方案或任何方法来保持SameSite严格，但以某种方式允许login.microsoftonline.com发送应用程序的auth cookie？
1条答案
按热度按时间uqdfh47h1#
这里有两种类型的cookie需要考虑：
第三方Cookie
Azure AD等身份系统发布的Cookie使用
SameSite=None。当Web应用程序执行OAuth登录操作时，这允许在浏览器URL中的顶级重定向when the user can view the identity domain中发送此类Cookie。这将适用于所有浏览器。如果这些cookie是从iframe或Ajax请求发送的，它们很可能会被删除，因为RFC6265bis中引入了限制，其中引入了Same Site cookie限制。这是一项保护用户隐私和防止不受欢迎的跟踪的举措。有些浏览器超出了规格。一个例子是Safari，如果它们在iframe或Ajax请求中发送，其默认设置将删除此类cookie。
因此，以前工作的一些OAuth流程，例如iframe上的后台令牌更新，会话管理和前通道单注销，不再可行。他们在iframe中使用cookie，用户不被告知，并且至少在某些浏览器中cookie会被删除。你无法在代码中做任何事情来使这样的流在所有浏览器中工作。
第一方Cookie
同时，Web应用程序自己的cookie应该使用最强的SameSite设置，以最好的保护防止跨站点请求伪造。因此，在您的ASP.NET应用程序中更喜欢此设置：