• 授权模式一共四种:
  1.客户端模式(Client Credentials)
  2.密码模式(User Credentials)
  3.简化模式(Implicit)
  4.授权码模式(Authorization Code)

授权模式

1.客户端模式(Client Credentials) 直接用app_id+secret

这是最简单的一种方式, 不需要得到用户ws授权,只要资源服务方qq空间对第三方应用paint发放一个client_id和client_secret, 第三方应用访问资源时通过刚才的id和secret进行验证后即返回access_token.
当然,这样对用户ws有些不公平,但实际上,在第三方应用paint所访问的资源与用户ws关系不大时就比较方便了.
此时,paint能从qq空间获取任意图片,只需要向qq空间认证,因为这些图片与具体某个用户无关.

2.密码模式(User Credentials) 直接使用用户密码

用户ws将自己的用户名密码直接告知第三方应用paint, paint即可使用这个密码向资源服务方qq空间获取图片.
这个方法就是刚才说过的很不安全的方法.但仍然有其适用的范围.
就是在用户ws与第三方应用paint更相熟情况, 也就是ws完全信任paint,放心的把密码交给paint使用.
此时,paint仅能获取用户ws的图片, 不能获取ws2,ws3等用户的图片,所以paint一定要取得ws的信任拿到密码.

3.简化模式(Implicit) 跳转登录回调url返回token

paint要得到access_token并且,不必知道ws的具体密码.
paint会访问qq空间某一api接口时,告知client_id, user_id, redirect_url,qq空间收到请求后将页面跳转到认证页面,
然后浏览器跳转至qq空间的认证页面,用户ws在此页面输入用户名密码,在qq空间认证成功后.
qq空间将浏览器跳转到paint提前指定的redirect_url上,传入access_token. 这时paint即可得到access_token.

注:
这里的access_token如何能被paint得到? 就是解析redirect_url的参数.
比如这样 ,直接取url参数得到access_token为abcdefg.
http://my.redirect_url.com?access_token=abcedfg

在一些移动应用的程序内部实现时,即使redirect_url是一个错误的地址,也能解析到access_token.
因为应用内部会收到302跳转的数据,只要从中解析到token后,不执行跳转动作即可.
这个问题,困惑了我好久.经过朋友帮助才终于理解.

4.授权码模式(Authorization Code) 跳转登录回调url返回code,再用code获取token

授权码模式与简化模式的过程是一样的.
不同之处在于,qq空间跳转到paint的redirect_url时,不直接返回access_token,而是返回一个code.
paint需要再将code发到qq空间,请求对应的access_token.
为什么要多此一举?
简化模式适用于paint是移动客户端应用的情况, 这个应用请求access_token后, 可直接获取到access_token.并且这个access_token是在url参数后的.
也就是如果客户端能显示出网址,用户就能看见access_token. 此时access_token是相对公开的不安全.
而授权码模式适用于paint是移动客户端应用,而且拥有自己的公网服务器, 那么它可以在请求到access_token时, 首先是公网服务器(通过redirect_url)得到code,
由公网服务器使用code请求access_token. 这时paint的公网服务器直接向qq空间请求照片,然后再将照片转发到paint移动客户端应用.
整个过程客户端是没有得到access_token的.相对来说更安全.

授权码模式时序图（引用自腾讯）
(user: 用户ws App:第三方应用paint Auth_svr:认证服务器,qq空间)

image

[图片上传失败...(image-80dddb-1534923444277)]

四、总结

上面就是自己的浅见,本人实践过程仅搭建了一个简单的OAuth2.0服务器,用于其他合作伙伴访问我们的api时进行权限认证.
是一个比较简单的应用.
在学习理解OAuth2.0过程,参考了阮老师的文章.他的语言文字描述更准确透彻,且容易理解. 可以点击此处查看.
另外,OAuth2.0官网上的教程一步一步搭建OAuth2.0服务器对我帮助也很大.
官网有好几种实现方式,都是开源贡献者的精华,我只详细看了php的实现,就已经深深佩服.
一个看似简单的功能,竟然能实现的非常灵活, 仅需要很少的改动就能完整实现上述的4种认证授权模式,并且还有本文没有提到,但是标准中定义的很多其他细节.

五、参考资料：

0. 如何选择OAuth2.0各种授权类型

https://github.com/thephpleague/OAuth2-server/wiki/Which-OAuth-2.0-grant-should-I-use%3F

1.OAuth1.0 OAuth2.0的实现原因及安全性问题， 是PPT内容。

张天琪——oauth security.pdf
[图片上传失败...(image-ebfbd4-1534923444277)]

2.关于OAuth2.0的规范详细理解。

理解OAuth 2.0 作者： 阮一峰
http://www.ruanyifeng.com/blog/2014/05/OAuth_2_0.html

3.其他网站使用OAuth2.0授权认证的接口文档

关于OAuth2.0的详细介绍，请参考OAuth2.0协议标准。
腾讯 （这个有时序图，讲的比较清晰。当然要配合”理解OAuth 2.0”一起理解）
http://wiki.open.t.qq.com/index.php/OAuth2.0%E9%89%B4%E6%9D%83#.E8.8E.B7.E5.8F.96accesstoken.E7.9A.84.E4.B8.A4.E7.A7.8D.E6.96.B9.E5.BC.8F
人人网
http://wiki.dev.renren.com/wiki/Authentication
来往
http://open.laiwang.com/docs/authentication.html
微信认证的接口使用方法.
http://mp.weixin.qq.com/wiki/index.php?title=%E8%8E%B7%E5%8F%96access_token

4.帮你深入理解OAuth2.0协议

http://blog.csdn.net/seccloud/article/details/8192707
OAuth协议实例化描述
下面我以实例化方式来帮助读者理解授权码类型的授权协议的运行过程。假设:
(1) Alice有一个有效的Google帐号；
(2) Facebook.com已经在Google Authorization Server上注册了Client身份，已经获得(client_id, client_secret)，注意client_secret是Client与AS之间的一个共享密钥。
(3) Alice想授权Facebook.com查看她的联系人列表(https://www.google.com/m8/feeds)。
图3展示了Alice、Facebook.com、Google资源服务器、以及Google OAuth授权服务器之间的协议运行过程。

[图片上传失败...(image-69e460-1534923444277)]

image