1、什么是OAuth认证
OAuth（开放授权）是一个开放标准，允许用户让第三方应用访问该用户在某一网站上存储的私密的资源（如照片，视频，联系人列表），而无需将用户名和密码提供给第三方应用。
例如，我自己的应用，希望使用用户（比如*恒）github上面某些文件，此时，用户同意我的应用使用github的文件，但是同时，不希望告诉应用他的github账户和密码，因为这样会造成用户的信息泄漏。而OAuth正是为了解决这个问题的一个标准，允许用户让第三方应用访问在某一网站上存储的私密的资源（如照片，视频，联系人列表），而无需将用户名和密码提供给第三方应用。
2、OAuth认证过程
1. 首先，我（应用提供者）。需要在github（隐私资源）中，注册自己的应用，此时要告知github，我的应用需要哪些权限。之后，github 会提供给我一个client_id，client_secret以及一个redirect_uri。
2. 认证过程。
用户使用我的应用时，点击获取google drive照片，或者使用google账户登陆的时候，我的应用会引导用户进入github的授权界面（此界面时github提供，和我的应用没有关系）。用户提供出client_id，github就知道用户是从我的应用让他过来，然后他就把我需要的权限告知用户，并询问用户是否同意。
// 用户登录 github，协商
GET //github.com/login/oauth/authorize
// 协商凭证
params = {
client_id: "xxxx",
redirect_uri: "http://my-application.com"
}
如果此时用户觉得我要求的太多，这些权限不想给我，那么此时认证过程就此结束。如果用户觉得ok，点击了授权，那么页面会跳转到预先设定的redirect_uri并且附带一个盖了同意章的code。
// 协商成功后带着盖了章的 code
Location: http://my-application.com?code=xxx
3. 告诉github，我要来取数据了。
上一步中，我获得了用户盖了同意章的code，但是，这个code只能表明，用户允许我从githhub上获取数据，但是同时还需要对我应用进行认证。此时需要使用client_secret。
// 网站和 github 之间的协商
POST //github.com/login/oauth/access_token
// 协商凭证包括 github 给用户盖的章和 github 发给我的门票
params = {
code: "xxx",
client_id: "xxx",
client_secret: "xxx",
redirect_uri: "http://my-website.com"
}
拿着用户盖过章的 code 和能够标识个人身份的 client_id、client_secret 去拜访 github，拿到最后的绿卡 access_token。
// 拿到最后的绿卡
response = {
access_token: "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
scope: "user,gist"
token_type: "bearer",
refresh_token: "xxxx"
}
4. 访问用户数据
// 访问用户数据
GET //api.github.com/user?access_token=xxxxxxxxxxxxxxxx
之后就可以访问用户的数据了。
上一步 github 已经把最后的绿卡 access_token 给我了，通过 github 提供的 API 加绿卡就能够访问用户的信息了，能获取用户的哪些权限在 response 中也给了明确的说明，scope 为 user 和 gist，也就是只能获取 user 组和 gist 组两个小组的权限。
整个流程到这里就结束了。
图示
3、例子
使用qq登陆豆瓣
点击使用第三方登陆
点击授权登陆
之后就成功使用qq登陆了豆瓣。
整个过程十分简单，对于用户来说，就是在豆瓣的网页上登陆了使用qq登陆，然后就可以正常使用豆瓣的功能了。
分析一下整个过程
简单来说，上述例子中的豆瓣就是客户端，QQ就是认证服务器，OAuth2.0就是客户端和认证服务器之间由于相互不信任而产生的一个授权协议。要是相互信任那QQ直接把自己数据库给豆瓣好了，你直接在豆瓣输入qq账号密码查下数据库验证就登陆呗，还跳来跳去的多麻烦。
就这这张图，来说一下上述例子中的三个步骤在图中的表现。所用到的请求路径名称都是虚构的，所附带的请求参数忽略了一些非重点的。
第一步：在豆瓣官网点击用qq登录
当你点击用qq登录的小图标时，实际上是向豆瓣的服务器发起了一个 http://www.douban.com/leadToAuthorize 的请求，豆瓣服务器会响应一个重定向地址，指向qq授权登录，浏览器接到重定向地址 http://www.qq.com/authorize?callback=www.douban.com/callback ，再次访问。并注意到这次访问带了一个参数是callback，以便qq那边授权成功再次让浏览器发起这个callback请求。不然qq怎么知道你让我授权后要返回那个页面啊。
至于访问这个地址之后，qq那边做出怎样的回应，就是第二步的事情了。总之第一步即对应了图中的这些部分。
第二步：跳转到qq登录页面输入用户名密码，然后点授权并登录
上一步中浏览器接到重定向地址并访问 http://www.qq.com/authorize?callback=www.douban.com/callback
qq的服务器接受到了豆瓣访问的authorize，在次例中所给出的回应是跳转到qq的登录页面，用户输入账号密码点击授权并登录按钮后，一定还会访问qq服务器中校验用户名密码的方法，若校验成功，该方法会响应浏览器一个重定向地址，并附上一个code（授权码）。由于豆瓣只关心像qq发起authorize请求后会返回一个code，并不关心qq是如何校验用户的，并且这个过程每个授权服务器可能会做些个性化的处理，只要最终的结果是返回给浏览器一个重定向并附上code即可，所以这个过程在图中并没有详细展开。现把展开图画给大家。
第三步：跳回到豆瓣页面，成功登录
用户在QQ登录页面点击授权登陆后，就直接跳转到豆瓣首页了，但其实经历了很多隐藏的过程。
首先接上一步，QQ服务器在判断登录成功后，使页面重定向到之前豆瓣发来的callback并附上code授权码，即 callback=www.douban.com/callback
页面接到重定向，发起 http://www.douban.com/callback请求
豆瓣服务器收到请求后，做了两件再次与QQ沟通的事，即模拟浏览器发起了两次请求。一个是用拿到的code去换token，另一个就是用拿到的token换取用户信息。最后将用户信息储存起来，返回给浏览器其首页的视图。到此OAuth2.0授权结束。
参考地址
网友评论