其实Oauth不止是为了单点,它是其实是可以用来授予信息或操作权限。实现单点就是服务提供方把用户的基本信息(id、昵称、头像等)发给了应用方,应用方再将这个用户标记为登录状态。

因为看同行为集成个单点纠结好几天,而我也要做这个功能。想着好好学一下,一边学习一边写笔记。结果发现还挺简单的...

概念

官方文档:https://oauth.net/2/

OAuth2.0是一个开放标准,允许用户授权第三方应用程序访问他们存储在另外的服务提供者上的信息,而不需要将用户名和密码提供给第三方应用或分享他们数据的所有内容。

OAuth2.0协议的认证流程,简单理解,就是允许我们将之前的授权和认证过程交给一个独立的第三方进行担保

OAuth2.0有四种认证方式:授权码模式、简化模式、密码模式、客户端模式。其中最复杂的是授权码模式,也是最为常见的模式。授权码模式代表着在三方互不信任的情况下完成授权。

涉及方

  1. 服务提供方,用户使用服务提供方来存储受保护的资源,如照片,视频,联系人列表。
  2. 用户,存放在服务提供方的受保护的资源的拥有者。
  3. 应用

准备工作

第三方应用向服务提供商成功申请到了AppID和AppSecret。

第三方应用具备一个用于处理单点信息的后台接口。

操作流程

1. 引导用户登录

第三方应用引导用户访问服务提供方进行身份验证,并在请求中携带验证成功后要重定向的地址(第三方应用的单点接口)。 引导是个很宽泛的形容,可以重定向到服务提供方的登录页,或者弹出服务提供方的二维码。

服务提供方验证成功身份,会重定向到第三方应用提供的接口地址,并携带授权临时票据 code

2. code换取token

第三方应用通过 AppIDAppSecret 及刚刚拿到的 code ,通过服务提供方提供的接口换取access_token

这里是所有开发者最搞不清状况的步骤,为什么上一步不直接反回 token ?其实是为了保证对方是一个有后台的、完整的系统。因为重定向或者弹出二维码这个操作对于浏览器的静态页面也是可以完成的,而发请求是一定需要后台的,服务提供方可以获取到第三方应用的ip等信息。杜绝了第三方应用是个皮包应用😂。

3. 获取资源

凭借 access_token 调用服务提供方的接口,获取用户基本信息或帮助用户实现基本操作。

通常就是获取信息并根据这个信息自动为用户登录,但其实并不止这些。

比如github在授权一些服务器厂商(腾讯云、vercel)后,厂商可以获取你的私有仓库中的代码以实现自动部署。

再比如评论插件 giscus 被授权后可以自动在 github 的某个仓库发布公告。(我想起 github 在有公告前,大家都是使用 issue 来记录评论信息,你也许会遇到一个项目拥有望不到边际的 issue 😂)

参考

微信扫码登录的流程图

微信扫码登录

Last Updated: