因此，多年来，我一直在使用各种用户检查，以最大限度地提高安全性。
我现在正在考虑开发跨不同服务器的会话系统，并且想知道这是否仍然相关。
考虑到 Oauth 不使用任何这些额外检查并且被广泛使用，会话令牌本身是否被认为是可靠的？谷歌和 Facebook 似乎会这么认为。
如果存在攻击线，IP 和用户浏览器信息等额外检查都可以像 cookie 一样容易被盗。
因此，是否可以专注于格式良好的会话令牌而不是添加额外的措施。
本页列出了使用PHP 会话安全的典型额外措施
在开始之前，我了解了 Oauth 的工作原理，但最终它会在会话存在后生成一个用于验证的会话令牌。
如果您使用 cookie 来存储会话 ID，只需确保将其设置在具有 Secure 和 HttpOnly 属性的 cookie 中。尽可能限制域和路径属性。确保没有不受信任的 Web 应用程序托管在可能发起会话固定攻击的相关域上。为会话设置合理的过期时间。通过 HTTPS 提供您的所有页面，因为混合内容可能会泄露您的会话 ID。尝试限制外部加载的 JavaScript 库以最小化攻击面。
一些应用服务器（如 Tomcat）允许您使用 SSL 会话 ID，而不是存储在 cookie 中的会话 ID。这些 SSL 会话 ID 得到了更好的保护，但在您的情况下，您应该能够在多个服务器上共享 SSL 会话。
可以在此处找到更多提示：会话管理备忘单
编辑：
他们没有通过公私钥和签名将会话 ID 等令牌绑定到客户端。在此处阅读 RFC 。它需要一些时间才能被主要浏览器供应商采用，但就将会话 ID 绑定到客户端而言，这似乎解决了所有问题。当然，有一些密钥生成和签名开销，您需要客户支持才能使其正常工作。
您需要确保
如果您想进一步限制谁可以进行身份验证，请使用客户端证书（因为无论如何您都将使用 HTTPS） - 它们的扩展性可能比 IP 过滤更好。
正如你所提到的，代币对于谷歌和其他大玩家来说已经足够好了。因此，它们对我来说也足够好。
会话令牌仅在通过安全协议（如 ）传输时才有用https://。没有安全协议的会话令牌确实很容易被窃取。
这对于对 Silvers 答案的评论来说太长了，但它使用了他发布的链接中的信息并非常具体地回答了我的问题。
将会话 ID 绑定到其他用户属性
为了检测（并且在某些情况下防止）用户的不当行为和会话劫持，强烈建议将会话 ID 绑定到其他用户或客户端属性，例如客户端 IP 地址、用户代理或客户端- 基于数字证书。如果 Web 应用程序在已建立的会话中检测到这些不同属性之间的任何变化或异常，这是会话操纵和劫持尝试的一个很好的指标，并且这个简单的事实可用于警告和/或终止可疑会话.
尽管 Web 应用程序不能使用这些属性可靠地防御会话攻击，但它们显着提高了 Web 应用程序的检测（和保护）能力。但是，熟练的攻击者可以通过共享相同的网络（在 NAT 环境中很常见，如 Wi-Fi 热点）或使用相同的出站 Web 代理（在公司环境），或者通过手动修改他的用户代理使其看起来与受害用户完全一样。
这突出了什么是混合信息。一方面，建议存储和交叉检查用户信息以标记明显的黑客攻击，但承认熟练的攻击者可以欺骗这些信息。
因此，您必须得出结论，如果您想防范熟练的黑客，谁不认为这些交叉检查虽然让您感觉更好，但实际上不会提供更多保护。