你能阻止某人出售他们的密码来获得类似的访问权限吗？你认为你需要吗？这几乎是等价的。

你需要这样做吗？

根据我在具有期刊访问权的学术机构内部/外部的经验，总是有一些共享资源作为一种帮助（例如，“嘿，你能给我发一份这篇论文的 PDF 吗？”）。您将永远无法阻止它，因为它实际上是由合法用户在正确的机器上手动访问的。但是，我个人从未见过学生/教职员工试图以此赚钱。

监控

即使他们想像这样赚钱，我也不认为分享饼干是最好的方式——我肯定不会这样做！您可以添加到 cookie 系统的保护措施（例如，对用户的浏览器进行指纹识别并检查它是否保持不变等）不适用于其他方法。

相反（如果这确实是一个问题），一个合理且强大的解决方案是监控用户的使用模式。如果他们下载的资源是其他人的 100 倍，或者如果他们连续 250 小时持续获取资源（人类可以在不睡觉的情况下存活的时间最长），那么可能有多个用户或自动化系统在工作。

然而，这个监控解决方案不必从一开始就包括在内，它可以在以后添加 - 直到你有证据证明它确实是一个问题，我认为它应该在你要做的事情列表中很远。

你没有。

这个问题基本上是“我如何做 DRM 并让它工作？”的变体。答案是一样的。

我不确定为什么“销售持久性 cookie”似乎是您的主要威胁。通常用户只会将您的出版物重新发布到 SciHub。

Cookie 控制不是解决您的问题的好方法，它的定义不是很好。您可能会花费大量时间来阻止用户发送他们的 cookie，但您可能会阻止合法访问足够多的时间，以至于您将失去客户的善意，并且努力可能与收益不成比例。一些可能的替代策略是：

• 限制可以看到用户帐户登录的设备数量。如果您看到一个用户帐户在 3 台左右的设备上处于活动状态，这可能是滥用的迹象
• 地理位置跟踪，如果同时在波士顿和北京访问用户帐户，则可能会被滥用
• 引入某种类型的 2 因素身份验证，用户将不得不偶尔输入额外的代码。老实说，这是有问题的，设置和维护成本很高，而且你会让人们经常忘记他们的密码来获取令牌。从好的方面来说，您不能共享令牌生成器。有人仍然可以将他们的令牌代码发送给其他人，但这使得共享凭据变得更加困难
• 监控用户滥用模式，您可以在用户统计数据上使用某种机器学习算法，或者像@cloudfeet 建议的那样使用简单的旧阈值
• 有额外的安全问题需要个人信息作为答案。很少有人会相信其他人这些信息，通常与银行网站或类似网站上询问的信息相同，因此会阻止他们分享这些信息。这确实给您作为网站所有者带来了问题，因为您现在需要对更多个人信息负责
• 定期发送电子邮件提醒他们的义务，它不会阻止每个人，但温和，有礼貌的刺激会为一些人工作

我认为以上所有答案都是错误的。@Andy 可能回答了你的问题，尽管太含糊了。问题在于 (a) 您假设您的用户是威胁媒介（利用 cookie 获得未经授权的访问） (b) 您希望使用 cookie 作为身份验证机制的一部分。碰巧的是，您实际上想要实现的是一种零信任安全，这种模型表明在任何情况下都不应信任任何用户（起初这很难理解）。

本质上，这意味着您可以使用 cookie，但这些应该只是会话 cookie。英国学术机构的 Shibbeloth 和其他类似设计确实使用了会话 cookie、第三方身份验证（在该机构）和数据库主导的会话身份验证（与其他两者相比）的组合。事实上，它通常也会检查机构的用户权限（即，如果您正在学习计算机科学，则不需要医学图书馆等）。

因此，使用持久性 cookie 是您的问题，这绝对是禁忌。您似乎已经了解使用持久性 cookie 的风险，即它可能被盗（通常以明文形式）。因此，在最坏的情况下使用非持久会话 cookie。

在我看来，如果您要使用这种身份验证方法，您应该做的是定期撤销 cookie 并要求用户再次登录。正如我所解释的，Shibbeloth 在设计上是多因素的，因为它会将您的证书与您的大学持有的证书进行比较。更好的设计不仅会比较用户信息，而且需要多个凭证（例如，短信、电子邮件或网上银行中的秘密答案）。

实际上，大多数基于 Web 的应用程序都可以从无状态中受益匪浅（取决于应用程序和您的用户/系统要求）。因此，您几乎可以完全通过使用会话 cookie 直到该浏览器窗口关闭/时间过去或使用加密的客户端用户存储（更好的解决方案）。

在其他用户所说的其他缓解措施中，例如指纹浏览器和监控使用模式，您可以采用许多策略。您还可以使用 IP 白名单、反 DDoS、定期凭证翻转等。这些是互补的，但不是自己的解决方案。

您绝对不能做的是，为了改善用户体验而降低安全性和软件缺陷的优先​​级（顺便说一句，它们是同一回事）。如果你这样做，有一天你可能要为一场数据保护灾难负责（并可能入狱和/或损失很多钱）。

要完全实现您正在寻找的内容，请使用不需要安装的 Web 应用程序（可能基于 javascript）。应该对该应用程序进行编程以完全实现您的 API 并为用户完成所有繁重的工作。理想情况下，它应该对该 API 执行基于角色的访问控制 (RBAC)（因此确定您提到的不同用户组）。显然，RBAC 需要在服务器端实现。没有理由您的 API 不能直接提供或链接到此并存储直接发布的令牌，或通过其他渠道（例如基于文本消息的令牌 w）。

我希望这能给你一些关于你的设计的思考。