一、OAuth 2.0 是什么?
OAuth 是一个授权的网络标准。我们经常会遇见和使用到它。比如我在码云页面登录时：
可以选择 QQ 授权登录，点击后进入如下页面：
大家可以看到该 URL 中含有 oauth2.0 的字符，也就意味着使用的是 OAuth 2.0 授权机制，稍后我们再来详细的解析这些参数的意义。
点击头像登录后，会被要求完善码云账户信息：注册一个新的账号或者绑定一个已有的码云账号
码云这里是强制要求将用户的 QQ 账号和码云自有的用户体系的对应账号绑定，这是大部分系统和服务都会采取的做法。以自有的用户体系为主，其他的第三方的绑定为辅，两者相互绑定后，可以获取 QQ 头像、昵称和性别等资料，也可以直接使用 QQ 登录。
二、OAuth 2.0 的原理
假设我们要开发一个软件或者应用。或者干脆直白粗暴点：假如我们现在就开发一个“码云”。首先在版本 v1.0 时，我们会建立我们自己的用户体系，使用我们自己的用户名和密码来登录，我们称“码云”为我们的 Application ，普通使用者即为用户 “User” 。而在版本 v2.0 时，我们希望把 QQ 登录、微信登录、微博登录等其他登录方式增加进来，进一步提升用户体验。我们以 QQ 为例， 称 “QQ” 为 API。 在 API 里，又会有授权服务器和资源服务器。如下图：
对应如下：
在码云中使用 QQ 登录时，用户需要输入自己的 QQ 用户名和密码
是不是意味着码云这里会保存着用户的 QQ 用户名和密码？
大家如果注意观察可以看到，上图页面所显示的 URL 地址其实不是码云的地址，而是归属 QQ 的域名地址，是以 https://graph.qq.com 打头的，而码云并没有获取到用户输入的用户名和密码，所以用户如果号被盗了，可不关码云的事。
URL 后面这一大长串的参数，分别代表什么意思呢？
which=Login&display=pc&client_id=101284669&redirect_uri=https%3A%2F%2Fgitee.com%2Fauth%2Fqq_connect%2Fcallback&response_type=code&state=634f9a59186e66a9f79686ff2838b501a67d88fd0154d96d
以上的 client_id、redirect_uri、response_type 和 state 以及这里没有出现的 scope 参数是 OAuth 2.0 常用参数，而其他参数则是 QQ 自定义的，用作区分或其他目的。
response_type：必选，表示授权的类型
client_id：必选，表示Application（也叫客户端，其实这里就是码云）的唯一标识，是 QQ 用来给码云的一个标识
redirect_uri：可选，重定向的 URI ，就是成功登陆后的页面跳转到哪里去，如上
https%3A%2F%2Fgitee.com%2Fauth%2Fqq_connect%2Fcallback 是码云的地址
scope：可选，表示申请的权限范围，也是 QQ 区分客户权限的，比如可能有 VIP、VVIP 之类的
state：可选，可以任意设置，QQ 会原封不动的返回，表示 客户端的状态
好了，形象的例子看完了，我们来看抽象的图：
还是以 码云 和 QQ 为例，整个流程如下：
- 用户（User）访问码云，点击 QQ 授权登录；
- 码云（Application）带参数跳转到 QQ 登录页；
- 用户（User）输入用户名和密码，发送 Authorization Request 给 QQ 的授权服务器（Authorization Server）；
- QQ 的授权服务器（Authorization Server）给码云（Application）授权（Authorization Grant）；
- 码云 Application 去拿授权（Authorization Grant）换取 Access Token；
- 码云 Application 拿 Access Token 访问资源服务器（Resource Server）获取所需资源（例如本例中的头像、昵称和性别），至此 OAuth 2.0 整个流程走完。
OAuth 2.0 实际上定义了四种授权方式，以上的例子只是介绍了其中最常见的一种（授权码模式），四种授权方式具体如下：
- 授权码模式（authorization code）
- 简化模式（implicit）
- 密码模式（resource owner password credentials）
- 客户端模式（client credentials）
由于时间关系，其他三种方式以后再做介绍，感谢各位看官，晚安~
Comments