时间戳

首页 > 解决方案 > 通过 API Token 创建会话设置过期 cookie

api - 通过 API Token 创建会话设置过期 cookie

问题描述

我正在尝试通过 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。

标签： apiauthenticationsessiontokenonelogin

解决方案

获取会话令牌（注意，不是 cookie）的初始 API 请求是从应用程序到 OneLogin API 的后端调用，因此它在用户浏览器中不可见，但您可以看到该 API 调用返回的 JWT 令牌带有客户应用程序超时 2 分钟。您可以导航到https://jwt.io/并单击 Debugger 进行验证。右侧会有一个过期区域，您可以将鼠标悬停在此区域上以查看过期时间。总是有一个 2 分钟的超时与之关联。

然后，您的应用程序负责指示用户的浏览器将 HTTP 有效负载中的令牌发送到位于“/session_via_api_token”的 OneLogin，以便向浏览器提供会话 cookie。您可以在浏览器中使用 SAML Tracer 扩展来捕获 SAML 跟踪以进行验证，方法是查看“session_via_api_token”的 POST 行的“HTTP”选项卡。注意：设置了 3 个 cookie，其中 2 个是持久的并立即设置为过期 - 因此它们没有任何作用。所以不要强调这 2 个 cookie 已过期，因为它不相关。关键 cookie 是“subsession_onelogin.com”，它是一个会话 cookie，因此没有过期时间。它用于跟踪会话超时。

如果用户随后尝试访问 OneLogin 资源，则它包含新的“subsession_onelogin.com”cookie，因此被视为已通过身份验证。OneLogin 然后发布该 cookie 的更新版本，您可以在“sub_session.onelogin.com”Set-Cookie 区域的 GET 行上的 SAML 跟踪中看到该版本。

看来，该 API 的 CORS 方法的工作方式与 form post 方法略有不同，并且 API 团队已经意识到，因为 Dev 文章可能会更新为建议使用 form post 方法。

此外，根据我的测试，某些浏览器的反应似乎不同，因此测试其他浏览器肯定会更清楚。那是特定于浏览器的，因此与 API 调用无关。当启用“防止跨站点 Cookie 跟踪”的默认设置时，在 Safari 上创建会话请求时，我注意到 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/并单击 Debugger 进行验证。它在 2 分钟到期后正常工作，这是正确的。关键 cookie 是“subsession_onelogin.com”，它是一个会话 cookie，因此它没有过期时间，因为它用于跟踪会话超时。

在我的测试中，我已经验证肯定有 2 分钟的生命周期，这正是它应该如何工作的。在我的示例测试中，它显示 API 响应声明在 16:19:04 到期，这与 jwt.io 解码器匹配（该站点对此很有用）。测试的第二部分返回headers DATE参数，显示发布时间为16:17:04；即到期前2分钟。这是对的。

我想您遇到的问题是由您的应用程序如何引导用户的浏览器调用“/session_via_api_token”调用引起的 - 如果应用程序使用 CORS，那么显然您需要包含相关的标头。但是，似乎即使使用该标头，某些浏览器也不会发送 CORS 请求（可能是由于浏览器安全设置），因此会话永远不会建立。至少这是我在测试中使用示例自定义登录页面时可以看到的。注意：第一个调用是 REST API 调用（即 Postman 擅长的），但第二个请求是常规浏览器请求。

推荐阅读