OAuth

本文约需 2 分钟阅读

OAuth 是一种授权协议，用于在不将用户密码交给第三方的情况下，安全地委托访问权限。它作为“使用 Google 登录”“使用 Twitter 登录”等社交登录功能的基础技术被广泛使用。OAuth 2.0 是定义了 Web 应用和移动应用所用流程的规范。截至 2025 年，OAuth 2.1 的制定正在推进，通过强制使用 PKCE、废除隐式流程等措施加强安全性。

OAuth 与 SSO 的区别

OAuth 和 SSO 是容易混淆的概念，但目的不同。 OAuth 是“授权”协议，处理权限的委托，例如“允许此应用访问我的照片”。而 SSO 是“认证”机制，目的是“一次登录访问多个服务”。在实际中，通过在 OAuth 之上添加名为 OpenID Connect (OIDC) 的认证层，将 OAuth 用作 SSO 基础的情况很常见。也就是说，OAuth 可以被视为实现 SSO 的技术组件之一。

OAuth 的运作机制

在 OAuth 中，用户在授权服务器上进行认证，并签发访问令牌。应用使用此令牌访问 API，绝不直接处理用户的密码。令牌被设定了作用域 (权限范围) 和有效期，仅授予最低限度的必要访问权限。使用刷新令牌，可以在无需用户重新认证的情况下更新访问令牌。

为什么令牌泄露不像密码泄露那样致命

理解 OAuth 设计的关键，在于凭据泄露时后果的差异。密码一旦泄露，攻击者就能以本人的全部权限无限期地行动，直到持有者更改密码为止。相比之下，访问令牌的权限被作用域收窄，过期后自动失效，因此即使泄露，可用的范围和时间都有上限。而且只要在授权服务器一侧取消关联，就能只让该应用的权限失效，无需更改密码。把密码本身交给应用的方式，做不到这种「部分交出、部分收回」。短有效期的访问令牌与刷新令牌的组合，正是在保持便利性的同时，从结构上限制泄露损害的机制。

OAuth 授权流程

实务中的注意事项与陷阱

使用 OAuth 时，将授予应用的权限保持在最低限度非常重要。对于要求“访问通讯录”“读取邮件”等不必要权限的应用需要警惕。实务中常见的陷阱是设置 OAuth 集成后将其放置不管。请定期检查不再使用的应用的集成，并撤销不必要的权限。此外，通过 OAuth 关联的主账户 (Google、Apple 等) 本身的安全也极为重要。如果主账户被劫持，将波及所有关联的服务。请用每个服务专属的强密码和两步验证来保护主账户。