相信你使用某些APP需要做登录操作，那么，有可能会出现“微信登录”的按钮。点击该按钮，会跳转到如下页面：
当然，我们的前提是通过H5页面登录。那么，此时只需要“确认登录”，那么，返回应用后该应用会获得你的部分微信账户信息，比如头像，用户名等。然后，在应用APP中，你可以看到自己的微信头像。
整个流程，就是一个OAuth 2.0登录。下面，我们从微信文档开始，开启OAuth 2.0之路。
1. 微信网页授权
文档链接：https://developers.weixin.qq.com/doc/offiaccount/OA_Web_Apps/Wechat_webpage_authorization.html
关于网页授权回调域名的说明
...
2、授权回调域名配置规范为全域名，比如需要网页授权的域名为：www.qq.com，配置以后此域名下面的页面http://www.qq.com/music.html 、 http://www.qq.com/login.html 都可以进行OAuth2.0鉴权。但http://pay.qq.com 、 http://music.qq.com 、 http://qq.com 无法进行OAuth2.0鉴权
可以肯定，微信网页授权采用的就是OAuth 2.0标准。
第一步：三方应用的H5页面向微信发起授权申请
https://open.weixin.qq.com/connect/oauth2/authorize?appid=APPID&redirect_uri=REDIRECT_URI&response_type=code&scope=SCOPE&state=STATE#wechat_redirect
-
appid就是三方应用在微信开发平台/公众号 注册的应用ID。只有是授权提供方的注册用户，三方应用才有可能使用授权能力。 -
redirect_uri指定了微信授权成功后，需要重定向到哪里
第二步：授权成功，微信重定向到 redirect_uri，并在URL上携带code。
H5通过接口将code传给服务端，最后，服务端通过code换取网页授权access_token，完成登录操作。
大多数三方应用，都有自己的用户系统。那么，微信授权之后，最终映射到应用的用户系统，完成
session和token的生成。
上面两个步骤的代码如下：
componentDidMount() {
const query = parseUrlSearch();
const { code } = query;
this.code = code;
if (!query) {
return;
}
if (isWechat()) {
this.componentDidMountForWechat(code);
}
}
componentDidMountForWechat(code) {
if (code) {
// 向服务端发起请求：先登陆，更新cookie，再拉取列表信息
wechatLogin(code, 'login,register,login').then(response => {
const { errorCode, data } = response.data;
if (errorCode === 0) {
setCookies('token', data.token);
setCookies('sessionId', data.session);
}
...
})
}
else {
const appid = 'xxxxxxxxx',
redirect_uri = encodeURIComponent(window.location.href),
scope = 'snsapi_userinfo',
state = Math.round(Math.random() * 1000000000)
window.location.href = `https://open.weixin.qq.com/connect/oauth2/authorize?appid=${appid}&redirect_uri=${redirect_uri}&response_type=code&scope=${scope}&state=${state}#wechat_redirect`;
}
}
2. 理解OAuth 2.0
有了微信网页授权的经验，那么，就不难理解OAuth 2.0了。
OAuth是一个关于授权（authorization）的开放网络标准
OAuth在"客户端"与"服务提供商"之间，设置了一个授权层（authorization layer）。
"客户端"不能直接登录"服务提供商"，只能登录授权层，以此将用户与客户端区分开来。
"客户端"登录授权层所用的令牌（token），与用户的密码不同。用户可以在登录的时候，指定授权层令牌的权限范围和有效期。
"客户端"登录授权层以后，"服务提供商"根据令牌的权限范围和有效期，向"客户端"开放用户储存的资料。
我们来看看OAuth 2.0运行流程：
- 资源拥有者(Resource Owner) - 用户
- 客户端(Client) - 三方应用
- 资源服务器(Resource Server) - 存放用户资源和信息
- 授权服务器(Authorization Server) - 给三方颁发授权令牌（access token）
一般，资源服务器和授权服务器是同一个服务
在上面讲到的微信网页授权登录的例子里，"客户端"是三方应用，"服务提供商"就是微信。
再看看它的授权流程：
- 用户打开应用程序，应用程序要求用户给予授权。
- 用户同意给予应用程序授权。
- 应用程序使用上一步获得的授权，向授权服务器申请令牌。
- 授权服务器对应用程序进行认证以后，确认无误，同意发放令牌。
- 应用程序使用令牌，向资源服务器申请获取资源。
- 资源服务器确认令牌无误，同意向应用程序开放资源。
是不是和微信网页授权流程一样呢？
3. OAuth 2.0授权方式
OAuth 2.0定义了四种授权方式。
- 授权码模式（authorization code）
- 简化模式（implicit）
- 密码模式（resource owner password credentials）
- 客户端模式（client credentials）
最常用的是授权码模式（微信授权登录采用这种模式），这里不再展开，可以参考老阮的文章：《OAuth 2.0 的四种方式》
4. OAuth 2.0和JWT(Json web token)
两者完全没有关系！这两个是两个完全不同的东西，根本没有可比性！
JWT是一种认证协议
JWT提供了一种用于发布接入令牌（Access Token),并对发布的签名接入令牌进行验证的方法。 令牌（Token）本身包含了一系列声明，应用程序可以根据这些声明限制用户对资源的访问。
在用户鉴权时，可以用JWT做Token认证，仅此而已。
小结
现在越来越多的应用都支持了三方登录，免除用户注册。只不过，授权登录成功后，大多应用强行用户填写手机号，这是为了补充用户信息。因为，授权服务一般不会提供用户手机号这种个人隐私信息。
那么，OAuth 2.0和单独登录（SSO）又有什么关系呢？卖个关子，后续聊。
总结文章参考登录（鉴权与授权）历史演进版
