我正在尝试通过API令牌创建会话。
请求被成功发送，我在响应中得到了3个cookie，但它们的到期日期与发送请求的时间相同，会立即使它们无效。
例如，如果请求在2020年4月20日00:24:29成功发送，这就是响应：
Set-Cookie: persistent=XXXX; path=/; expires=Thu, 19-Mar-2020 00:24:30 GMT; secure; HttpOnly
Set-Cookie: onelogin.com_user=XXX; domain=.onelogin.com; path=/; expires=Mon, 20-Apr-2020 00:24:30 GMT; secure; HttpOnly
Set-Cookie: sub_session_onelogin.com=XXXXXXX; path=/; secure; HttpOnly
创建会话以便在Onelogin上使用的第二个cookie已过期。
有什么地方做错了吗？任何帮助都将不胜感激
我正在使用HTTPS
获取会话令牌(注意，不是cookie)的初始API请求是从应用程序到OneLogin API的后端调用，因此它在用户浏览器中不可见，但您可以看到API调用向客户应用程序返回超时2分钟的JWT令牌。您可以导航到https://jwt.io/然后单击"调试器"进行验证。右侧会有一个过期区域，您可以将鼠标悬停在上面查看过期情况。总是有一个2分钟的超时与之相关。
然后，您的应用程序有责任指导用户的浏览器将HTTP有效负载中的令牌发送到OneLogin的"/session_via_api_token"，以便向浏览器提供会话cookie。您可以在浏览器中使用SAML Tracer扩展来捕获要验证的SAML跟踪，方法是查看POST行中"session_via_api_token"的"HTTP"选项卡。注意：设置了3个cookie，其中2个是持久的，并立即设置为过期，因此它们没有任何用途。因此，不要强调这两个cookie已过期的事实，因为它与此无关。密钥cookie是"subsession_onelogin.com"，它是一个会话cookie，因此没有过期时间。它用于跟踪会话超时。
如果用户随后试图访问OneLogin资源，则它包含新的"subsession_OneLogin.com"cookie，因此被视为已通过身份验证。OneLogin随后发布该cookie的更新版本，您可以在"sub_session.OneLogin.com"Set cookie区域的GET行的SAML Trace中看到该版本。
CORS方法在这个API中的工作方式似乎与表单-post方法略有不同，API团队已经意识到了这一点，因为Dev文章可能会更新，说明建议使用表单-posts方法。
此外，根据我的测试，似乎有些浏览器的反应不同，所以测试其他浏览器肯定会有更多的启示。这是特定于浏览器的，因此与API调用无关。当Safari上的"创建会话"请求启用默认设置"防止跨站点Cookie跟踪"时，我注意到Cookie会按预期返回，但浏览器拒绝接受。浏览器控制台中没有警告或错误。目前尚不清楚Safari为什么会这样做，也找不到任何关于它的文档，所以这是我们无法控制的浏览器特定问题。
浏览器让它变得更难，所以我们的API团队可能会在未来几个月更新我们的最佳实践指南，说要使用表单后重定向，而不是CORS。表单post方法应该适用于任何和所有浏览器，因为它们处理它的方式与CORS方法不同。
API文档中的第一个链接是https://developers.onelogin.com/api-docs/1/login-page/create-session-via-token以及使用它的第二个链接https://developers.onelogin.com/api-docs/1/login-page/create-session-login-token.然后您可以使用https://jwt.io/然后单击"调试器"进行验证。它工作正常，有效期为2分钟，这是正确的。密钥cookie是"subsession_onelogin.com"，这是一个会话cookie，因此其中没有到期时间，因为它用于跟踪会话超时。
在我的测试中，我已经验证了肯定有2分钟的寿命，这正是它应该如何工作的。在我的示例测试中，它显示API响应声明在16:19:04到期，这与jwt.io解码器匹配(该站点对此很有用)。测试的第二部分返回了标头DATE参数，该参数显示发布时间为16:17:04；即到期前2分钟。这是正确的。
我想你遇到的问题是由你的应用程序如何引导用户的浏览器调用"/session_via_api_token"调用引起的——如果应用程序使用CORS，那么显然你需要包括相关的头部。然而，似乎即使有了这个头，一些浏览器也不会发送CORS请求(可能是由于浏览器安全设置)，因此会话永远不会建立。至少在测试中使用示例自定义登录页面时，我可以看到这一点。注意：第一个调用是REST API调用(即Postman的优点)，但第二个请求是常规浏览器请求。