问题描述
我的项目使用Azure AD登录(https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-v2-aspnet-core-webapp)。
我可能配置错误，但这对Safari不起作用，可能是因为SameSite Cookie问题。
您可以Google；Samesite Safari；或&Safari无限循环登录，然后向其中添加ASP.NET核心，并找到大量资源，告诉您通过将Cookie更改为使用SameSite None来修复此问题，以便Safari可以登录。
但这里是这样说的：
默认的MinimumSameSitePolic值为SameSiteMode.Lax以允许OAuth2身份验证。
https://docs.microsoft.com/en-us/aspnet/core/security/authentication/cookie?view=aspnetcore-5.0。
这在我看来不太对劲，因为我当前使用的是安全的、仅宽松的http，而且在Safari中不能很好地工作。
我为此而抓狂。在2021年使用Cookie进行外部提供商登录的正确方式是什么？
推荐答案
这里有几种不同的Cookie场景，下面解释标准设置。Cookie比乍看起来复杂得多。
授权服务器
Azure AD将对用于跨应用单点登录的SSO Cookie使用以下设置：
- 仅限HTTP
- 安全
- SameSite=无
基于网站的应用程序临时登录Cookie
.NET将在登录重定向之前发出包含状态参数的临时Cookie。这可能是导致您出现问题的原因-它应该有这些设置-严格将被删除：
- 仅限HTTP
- 安全
- SameSite=Lax
基于网站的app-Auth Cookie
您的.Net Web应用程序将在处理OAuth响应后发布其自己的Auth Cookie。理想情况下，您希望使用以下设置：- 仅限HTTP
- 安全
- SameSite=严格
丢失Cookie的几个已知原因：
在开发人员PC上使用HTTP URL意味着您需要在应用程序中设置SECURE=FALSE
使用在您计算机的Hosts文件-Safari中配置的假装主机名(如example.local)需要Internet后缀，如.com。
Cookie是加密的，解密失败是基于网站的应用中重定向循环的常见原因-当.Net尝试处理临时登录Cookie时可能会发生这种情况。
如果您的Auth Cookie使用SameSite=Stright，然后从电子邮件链接导航回您的应用程序，则Auth Cookie将被删除，从而导致新的OAuth重定向。这导致一些公司降级至SameSite=Lax。
单页应用
SPA可以使用Back End for Front End模式，以便只有在AJAX请求期间才需要安全Cookie。
这意味着应用程序永远不会受到导航问题的影响，因为Web请求永远不需要Cookie--它们只需要API请求。在此模型中，只有数据请求需要保护。
我的Quick Start Page上的SPA使用此选项，并且在Safari中运行良好。
这篇关于在2021年进行外部提供商登录的正确方式是什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持编程学习网！