我们有一个有角度的网站，我们称它为https://webui.foo.com。我们正在将基础架构迁移到SOA（面向服务的体系结构），因此我们已将许多特定于业务的功能转移到各种服务器上基于Web api的端点上。
最近，我们从验证服务器（authsvc.foo.com）建立了对SSO（单点登录）的SAML2支持。标准流程是，webui为客户端提供了一个链接，该链接将客户端重定向到类似https://authsvc.foo.com/sso/saml2?idp=some-idp&redirectUrl=https://webui.foo.com/sso-response的位置。
认证服务在该端点上收到请求后，将查找第三方IDP（身份提供者），加载其元数据，并将质询重定向到IDP。然后，IDP将正确验证用户身份，并向验证服务返回一个断言，我们可以使用该断言来验证和识别用户。一旦发生这种情况，身份验证服务将设置一个仅适用于SSOToken的称为https://authsvc.foo.com/api/auth/sso的短期加密cookie，并在由webui发送的原始URL中将重定向发送到指定的redirectUrl。
接下来应该发生的事是/sso-response端点（有角度的端点）应该立即通过https://authsvc.foo.com/api/auth/sso cookie对SSOToken执行http GET操作，当authsvc看到该cookie并对其进行验证时，将以有效的JWT响应并刷新令牌以供我们的Web应用程序使用。
我们可以使用https://authsvc.foo.com/sso/saml2?idp=some-idp&redirectUrl=https://authsvc.foo.com/api/auth/sso这样的URL测试身份验证服务的组件，该URL在浏览器上（通过SAML进行身份验证之后）向我们显示了预期的JWT和刷新令牌...因此，这部分似乎正常工作。
但是...当我们从https://authsvc.foo.com/api/auth/sso角端点获取\sso-response时，我们得到一个401。调查该请求，我们发现SSOToken cookie根本不包含在请求中……这似乎很奇怪，因为它似乎应该从浏览器自动设置，但显然不是这样。
我们已经读过一些有关使用withCredentials的信息，但这似乎没有什么区别。也有一些关于CORS的讨论，但是我们没有收到任何CORS错误或警告...我们只是没有将Cookie附加到请求中，即使浏览器当然知道该Cookie。
这里发生了什么？我们做错了什么？抱歉，我不是一个笨拙的人（我在身份验证服务器上建立了SAML支持），所以我对前端需要做什么（或不希望发生什么）以使这项工作变得难以理解。
我们有一个有角度的网站，我们称之为https://webui.foo.com。我们正在将基础架构迁移到SOA（面向服务的体系结构），因此我们卸载了许多特定于业务的......>
如何设置cookie，以及哪些选项和配置？
Cookie具有一个“域”部分，该部分告诉浏览器它属于什么位置。如果您希望将其发送给所有子域（例如webui.foo.com和authsvc.foo.com），则需要像.foo.com这样的域之前在点之前设置cookie。
您的角度端点\sso-response可能不知道有一个cookie需要附加到请求中。