“回到过去”在 oauth 之前，我们真的没有任何标准，一切都是手工卷制和定制的。（例如，photobucket API 提供了自己的直接身份验证机制。）通常使用 API 密钥（甚至是普通凭据）进行基于令牌的身份验证。）

当时，大多数在线服务都是它们自己的“孤岛”，在数据交换或单点登录方面并没有真正提供太多。

在更“严重”的情况下（例如信用卡交易。）它通常是白名单 IP、身份验证令牌和自定义 POST-BACK URL 的组合。

与今天相比，20 年前的网络是一个非常非常非常不同的地方。

除了 OAuth，还有几种技术仍在使用。

• API 密钥/服务密钥
• 将 IP 列入白名单
• 用户/密码登录
• 令牌登录（非 OAuth）... 例如。自定义实现。
• 没有，只是一个“秘密”网络端点。

并且通常是它们的组合。

您经常看到的是白名单和其他技术之一的组合。

OAuth 旨在通过实施令牌和身份验证系统（不基于用户信息）来限制用户登录凭据的猖獗“泄露”

它甚至在设计时考虑到替换传统的用户名/密码系统。（与 openid 结合使用，它通过其他机制做类似的事情，它们可以惊人地协同工作）。

请记住，在 web 0.99 中，这个想法是对资源的访问保持一定程度的控制。因此，作为中间件开发人员，您将获得一个用户+密码组合，该组合将通过许多不同的传输方案唯一标识您的请求（互联网不仅仅是 www ）。这个想法不仅扩展到登录的行为，数据本身还有一个模式，在你花钱购买访问之前，这种模式可能不那么可读。xml 和转换样式表是最终结果——它们是基于标记的 ASN.1 和 BER 等价物。

现在，单点登录服务的长期目标已经渗透到整个生态系统，并且随着可用/人类可读信息共享（json！）的传播，导致了 openid/oauth 组合作为一种能够处理审计的手段信息使用和访问的目的。