日常维护的 Sync 组件，依赖身份管理器。其中，鉴定完用户登陆后，最重要的一件事就是获取 access token，然后手持这个 token， 与 Sync 服务器通信。

后来与 Identity 团队交流后才知道，这种登陆和授权的方式，其实就是 OAuth 2.0。

能看出来，OAuth 2.0 的最大特点，就是免去了用户名和密码的重复输入。

这样无疑减少了密码泄露的风险，更加安全，用户使用上也更简单。

1. 从早期密码登陆开始

记得在我小的时候，那时还是互联网发展早期，很多网站要使用，就得先注册，然后登陆。

当时单独准备了一个本子记录各种账户和密码。

当时不了解密码强度的概念，为简化记忆，几乎所有网站都使用同一套密码。

容易泄露，容易忘记，每次登陆都需要重复输入，挺烦人的。

后来出现一种新的登陆方式，第三方登陆。比如，如果浏览器里已经登陆了一些账户，比如谷歌、Apple 等，可以使用这些账户，继续登陆其他受支持的网站，不再需要输入用户名和密码。

手机也是。App 登陆，可以借助微信或微博的一次跳转。这个过程大家可能更熟悉一些。

减少了密码设置、记忆和输入，很方便。

背后生效的技术，就是 OAuth 2.0。

简而言之，OAuth 2.0 解决的是一个在“不信任环境下实现信任”的问题。

2. OAuth 2.0 概念

根据维基百科的定义：

开放授权（OAuth）是一个开放标准，允许用户让第三方应用访问该用户在某一网站上存储的私密的资源（如照片，视频，联系人列表），而无需将用户名和密码提供给第三方应用。

OAuth 2.0 是 OAuth 协议的下一代版本，也是当前的主流版本。更加关注客户端开发者的易用性，同时为 Web 应用、桌面应用和移动端提供特定的授权流程（OAuth 2.0 focuses on client developer simplicity while providing specific authorization flows for web applications, desktop applications, mobile phones, and living room devices. ）。

OAuth 的诞生源于一个真实需求。

2006 年 11 月，布莱恩·库克正在实现 Twitter 上的 OpenID，一个去中心化的网上身份认证系统。同时，网站 Ma.gnolia 需要一个办法，允许使用 OpenID 的成员授权 Dashboard 访问他们的服务。

几个开发者聚在一起讨论后，得出一个结论：目前还没有能完成 API 访问委托的开放标准。

于是成立小组，开始撰写开放协议的草案。

伴随更多人的加入，OAuth 规范被不断完善。

2010 年 4 月，OAuth 1.0 协议发表为 RFC 5849。

2012 年 10 月，OAuth 2.0 协议发表为 RFC 6749。

3. 核心思想

在我看来，OAuth 2.0 的核心思想有两个：

• 信任传递
• 有限信任

传统的登陆方式，网站通过核对用户名和密码验证用户身份。对于不同网站，就需要不断地验证。这种反人类的设计，很容易让用户感到厌烦。不验证的话，又没有办法鉴定用户身份。

OAuth 2.0 实现了只验证一次，进而将该“信任传递”，兼顾安全，简化频繁的用户打扰，体验更好。

同时，信任的传递是有限的。比如第三方网站只能访问到用户名，对于身份证 ID 这类敏感信息无法获取。另外，传递的信任是有时效的，过期需要重新获取，而且随时可以撤销。

OAuth 2.0 运作过程中有四个不同角色：

角色	比喻	说明
资源所有者（Resource Owner）	用户本人	拥有数据的人
客户端（Client）	第三方应用	想使用数据的服务
授权服务器（Authorization Server）	信任代理	授权的颁发者
资源服务器（Resource Server）	数据仓库	实际保存用户数据的地方

在 Sync 的例子中，用户是资源所有者，Edge 是客户端。

用户登陆，请求的是微软的授权服务器。

授权服务器会返回一个临时授权凭证，即上文中提到的 access token。

客户端拿着这个 token 就可以访问位于资源服务器上的 Sync 数据。

整个过程，资源服务器提供资源给客户端，并不需要额外的显式登陆。

信任这个词，说起来抽象，落实在技术层面，就是一段字符段（access token）。

这是技术人的极简主义。

4. 实现

OAuth 2.0 的授权方式有很多种，这里只谈最常见的：授权码模式（authorization code）。

具体的流程有四步：

1. 用户请求授权。用户在 Client（第三方应用）上点击 “用 Google 登录”，Client 跳转：

   GET https://accounts.google.com/o/oauth2/v2/auth?
     client_id=xxx&
     redirect_uri=https://app.example.com/callback&
     response_type=code&
     scope=email+profile

2. 授权服务器提示用户登陆并确认。用户输入 Google 账户和密码（已登陆则可跳过），选择同意该 Client 访问自己的数据，于是 Google 附带授权码，重定向回 redirect_uri：

   https://app.example.com/callback?code=abcd1234

3. Client 通过授权码换取 access token。Client 通过后端安全地向授权服务器发起请求：

   POST https://oauth2.googleapis.com/token
   Content-Type: application/x-www-form-urlencoded
   
   grant_type=authorization_code&
   code=abcd1234&
   redirect_uri=https://app.example.com/callback&
   client_id=xxx&
   client_secret=yyy

   授权服务器返回：

   {
     "access_token": "ya29.a0ARrda...",
     "expires_in": 3600,
     "refresh_token": "1//0gabcdef",
     "scope": "email profile",
     "token_type": "Bearer"
   }

4. Client 使用 Access Token 访问资源服务器。

   GET https://www.googleapis.com/oauth2/v2/userinfo
   Authorization: Bearer ya29.a0ARrda...

   资源服务器验证 token 有效，返回数据。

5. 总结

与 GPT 的这段对话令我惊讶：

从哲学上看，OAuth2 是一种社会契约模型在技术领域的映射：

• 用户并不直接信任所有服务；
• 服务之间也不直接信任；
• 它们都信任一个中介（授权服务器）来“担保”彼此的行为边界。

这其实是把互联网变成一个“契约社会”：

信任不再是默认的，而是被设计、被限制、被审计的。

这种理念在今天几乎渗透了所有 Web 安全体系：

SSO、OIDC、API Gateway、微服务认证体系……

它们都在延续 OAuth2 的思想：用短期令牌代替长期信任。

互联网是一个完全开放，所有人平等的世界，除了善意，也有狡诈和欺骗。

没有办法无条件地信任对方，就像真实的社会一样。绝对信任换来的，有时是绝对伤害。

但完全失去信任同样寸步难行。

OAuth 2.0 提供的就是这样一个“临时、可撤销、可验证的信任桥梁”。

哪怕这个世界没有绝对信任，我们也可以通过某种约定，构建起秩序。

就像是法律一样。

（完）

参考

1. OAuth 2.0 — OAuth🔗
2. what-is-oauth-2🔗
3. 开放授权 - 维基百科，自由的百科全书🔗