Fatal编程技术网
  • post/
  • Post 仅使用SameSite Lax Cookie实现SSO的可行性？ 背景

Post 仅使用SameSite Lax Cookie实现SSO的可行性？ 背景

post cookies single-sign-on

Post 仅使用SameSite Lax Cookie实现SSO的可行性？ 背景,post,cookies,get,single-sign-on,samesite,Post,Cookies,Get,Single Sign On,Samesite,今天我在玩弄如何为我的cookies实现SameSite。我已经有了HttpOnly和Secure，所以我认为这可能不是什么大问题 它为什么坏了 嗯，事实证明，一旦我实施了设置，很多东西都坏了。这发生在SameSite=Lax和SameSite=Strict两种情况下。我做了一些研究，发现这是由于SSO在Lax或Strict的相同站点设置下容易损坏（而不是None）： 我的主浏览器（Iron 70）是基于Chrome 70的，因此我以前从未遇到过在2月份推出Chrome 80用户

今天我在玩弄如何为我的cookies实现
SameSite
。我已经有了
HttpOnly
和
Secure
，所以我认为这可能不是什么大问题

它为什么坏了 嗯，事实证明，一旦我实施了设置，很多东西都坏了。这发生在
SameSite=Lax
和
SameSite=Strict
两种情况下。我做了一些研究，发现这是由于SSO在
Lax
或
Strict
的相同站点设置下容易损坏（而不是
None
）：

我的主浏览器（Iron 70）是基于Chrome 70的，因此我以前从未遇到过在2月份推出Chrome 80用户的更改，据说它将没有
SameSite
值的cookie默认为
Lax
。我安装了最新的Google Chrome Portable来查看它，有趣的是，这项功能目前（谢天谢地）似乎不像以前那样默认为
SameSite=Lax
——我的网站只有在我明确启用了以下标题后才出现故障：

标题编辑集Cookie^（.*）$$1；SameSite=Lax

这似乎是因为没有一个明确的
SameSite
，Chromium将其视为默认情况（我正在快速测试，所以在2分钟内）

即使使用了
Lax
，我所有的单点登录都被破坏了，我的实时聊天也不再有效——无论是使用WebSocket还是XHR请求。当我尝试单点登录时，不知何故，我最终退出了主网站，这也没有多大意义-基本上，一切都是一团糟

  • 是否有希望让XHR或Websockets再次使用
    Lax
    ？我在
    chat.example.com
    上聊天，但我也允许在
    sub.someotherdomain.org
    上的侧面板中访问它。我猜这里的答案是否定的，绕过它的唯一方法是在同一个域上提供一个URL，Apache只是在幕后指向同一个脚本。很烦人，但这是可以做到的——但还有别的办法吗

  • 我更大的问题是：单点登录是否与
    Lax
    和
    Strict
    天生不兼容？我在这方面还没有找到太多东西。所有的文章似乎都认为用
    Lax
    破坏SSO是不可避免的，甚至有一些图表解释了它为什么会破坏，但是SSO必须是这样吗

    • 主流解决方法 大多数网站都说要做
    SameSite=None
    来规避这个问题，并在所有用户代理中强制执行旧的行为。从技术上讲，这是可行的，但我想知道是否有希望使用
    Lax
    ？如何在不屈服于
    SameSite=None
    的情况下实现这一点

    TL；DR-是的，您可以使用
    SameSite=Lax
    （但不能
    SameSite=Strict
    ）而不中断SSO

    关于
    SameSite
    cookies，有两件事需要注意：

    • Lax禁止使用
      POST
    • Strict还禁止使用
      GET
    有益的总结：

    资料来源：

    Strict根本不起作用，因为它阻止任何类型的跨站点请求发送cookie，这使得SSO完全不可能<代码>严格甚至不是一个可行的候选人

    这就给我们留下了
    Lax
    和
    None
    （到目前为止，这一直是默认值，并且正在慢慢被
    Lax
    取代）

  • 是否有希望让XHR或Websockets再次使用
    Lax
    ？我在chat.example.com上聊天，但我也允许访问 在
    sub.someotherdomain.org
    上的侧面板中添加。我猜是 这里的答案是否定的，唯一能绕过它的方法就是 在Apache简单指向的同一域上可用的URL 同样的剧本在幕后。很烦人，但这是可以做到的——但是 还有别的办法吗
    • 否

    这里最好的解决方案是在幕后重写URL，这样就不需要维护重复的资源。使用Apache的
    mod_rewrite
    重写URL，或者简单地执行
    include（'path/to/file.php'）
    都是一个简单的解决方案。返回的内容将完全相同-但如果需要发送
    Lax
    cookies，浏览器必须将其发送到当前域的祖先域

  • 我更大的问题是：单点登录是否与
    Lax
    和
    Strict
    天生不兼容
    • 不，幸运的是，没有

    我真的没有发现太多的问题 这所有的文章似乎都将使用
    Lax
    破坏SSO视为 不可避免，甚至有一些图表解释了为什么会这样 中断，但SSO必须是这样吗

    许多SSO页面确实会因
    SameSite=Lax
    而中断，这是事实，但这种故障并非不可避免，而是特定于实现的。让我们将原始方法与与与
    SameSite=Lax
    cookies兼容的修订方法进行比较

    原始SSO过程（需要
    SameSite=None
    ）
  • 用户导航到
    sub.example.org
    -当前未登录，因为此网站上未设置cookie
  • 页面检测到未登录，并自动重定向到
    example.com
    上的SSO页面-如果用户未在该页面进行身份验证，则会重定向回去并给出用户名/密码提示。如果用户已通过身份验证，则继续
  • 在
    example.com
    上，读取用户的会话数据并为SSO调用创建唯一的令牌。将令牌转储到数据库中