印象中工作以来还从来没搞过一次 OAuth2 的接入- -，似乎只停留在愉快的使用阶段。比如现在很多网站都接了 wx 二维码扫码登录或者微博登录。所以一直只是享受着这样的便利，却没有机会自己来搞一搞把里面的技术细节打通。
首先找到 阮一峰老师的一篇古老的文章介绍了一下 OAuth 协议。
归根到底 OAuth 要做的事情就是在没有完整用户用户密码的情况下，通过用户授权访问第三方原本提供给用户的服务。
比如我要去上知乎，但是我不想注册一个知乎的账号，通过 OAuth 我可以通过微博的账号去访问知乎，但是注意这里有一点不太一样，就是当你这么做的时候，通常第三方服务商都会将你 OAuth 的账号和他们平台上的自动创建的账号进行绑定，这样能对你的身份进行确认。这是现在最广泛的用法，还有一种就是只通过你的授权去访问第三方的有限的服务。
RFC 6749 标准 OAuth2 流程如下：
（A）用户打开客户端以后，客户端要求用户给予授权。
（B）用户同意给予客户端授权。
（C）客户端使用上一步获得的授权，向认证服务器申请令牌。
（D）认证服务器对客户端进行认证以后，确认无误，同意发放令牌。
（E）客户端使用令牌，向资源服务器申请获取资源。
（F）资源服务器确认令牌无误，同意向客户端开放资源。
通常流程 B 有很多种实现的方法，我这里看了好几家的文档 最常用的应该是授权码模式。
可能因为授权码是最完整，流程最严密的授权模式。它的特点就是通过客户端的后台服务器与服务提供商的认证服务器进行互动。
（A）用户访问客户端，后者将前者导向认证服务器。
（B）用户选择是否给予客户端授权。
（C）假设用户给予授权，认证服务器将用户导向客户端事先指定的"重定向URI"（redirection URI），同时附上一个授权码。
（D）客户端收到授权码，附上早先的"重定向URI"，向认证服务器申请令牌。这一步是在客户端的后台的服务器上完成的，对用户不可见。
（E）认证服务器核对了授权码和重定向URI，确认无误后，向客户端发送访问令牌（access token）和更新令牌（refresh token）。
一个标准的协议在 A 步骤中包含了
response_type：上面谈到的授权类型，由于是授权码所以这里是 "code"
client_id: 标示客户端的应用id
redirect_uri：验证通过之后需要重定向到的 URI 通常会进行 url encode
scope：表示申请权限的范围。
一个拼好的正常的 url 可能会长这样
https://oapi.ggsimida.com/connect/qrconnect?client_id=xxx&response_type=code&scope=snsapi_login&
state=STATE&redirect_uri=http%3A//uisensor.hundun.cn/dashboard/
通常访问该地址之后我们会被带到第三方授权公司的认证服务器，要求用户进行授权。用户通过 qrcode 或者账号密码登录进行授权之后，会重定向到上面的 redirect_uri 填写的地址并且带上第三方应用发放的 state 和 授权权码。
这个时候就到了 D 步骤，D 步骤通过这个授权码，并附上重定向 URI 像第三方服务器的鉴权系统申请临时访问令牌，然后认证服务器核对信息之后发放 ac令牌和 rr更新令牌，到此便完成了认证。
这里要多说一句的是，dingding 的文档上好像并不是提供的标准 OAuth2 协议，虽然看上去很像但是并不是标准的。包括上面 A 步骤的链接里，dingding 需求一个叫 appId 的东西来替代 client_id ，并且当我们获得授权码之后，便无需再请求 token ，而是直接使用授权码+应用id+应用密钥当作身份就可直接通过接口认证请求用户信息了。
如果使用的服务是只支持标准的 OAuth2 协议的话，似乎无法无缝切换 dingding 的这个服务。
但是总有解决办法，我的选择是通过后端服务器包一层，将整个 OAuth2 的标准流程方在包装层，然后由包装层和 dingding 服务器进行交互，这样也能实现。
Reference:
http://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html
https://ding-doc.dingtalk.com/doc#/serverapi3/mrugr3 dingding 二维码登录文档
https://www.sensorsdata.cn/_manual/oauth_client.html sensors 标准 OAuth 文档