http://note.youdao.com/share/?id=a76c568759eb061e46d457519c809f14&type=note
oauth2.0是一套标准.
一、问题
这个标准解决了这样的一个问题.
允许用户让第三方应用访问该用户在某一网站上存储的私密的资源（如照片，视频，联系人列表），而无需将用户名和密码提供给第三方应用。
第三方应用--比如一个绘图的小软件"paint"
访问用户--比如"我的qq空间账号ws"
私密信息--比如我qq空间中的照片
资源服务方-qq空间
认证服务器-qq空间
正常情况下,要访问用户ws的qq中的照片, 需要将账号和密码发送到qq空间的认证服务器验证身份.
但是第三方应用要访问, 怎么办呢?
把账号密码告诉第三方应用paint,肯定不行
这就相当于把密码告诉别人,而且还是我不认识的人.不安全.paint只需要一个照片,但把密码都给他了,他连我的日记都能看了.paint如果把密码公开或者泄露给别人的,那我怎么办.
二、解决
oauth2.0是怎么解决的呢?
给第三方应用paint一个临时密码,过期作废,而且这个密码的访问权限可由我随时取消.这样就足够安全了.
这个临时密码就是access_token.
当然发放access_token的方法就多种多样了,这些方法叫做授权模式
授权模式一共四种:
1.客户端模式(Client Credentials)
2.密码模式(User Credentials)
3.简化模式(Implicit)
4.授权码模式(Authorization Code)
三、授权模式
1.客户端模式(Client Credentials)
1.客户端模式(Client Credentials)
这是最简单的一种方式, 不需要得到用户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)
paint要得到access_token并且,不必知道ws的具体密码.
paint会访问qq空间某一api接口时,告知client_id, user_id,qq空间收到请求后将页面跳转到认证页面,
然后浏览器跳转至qq空间的认证页面,用户ws在此页面输入用户名密码,在qq空间认证成功后.
qq空间将浏览器跳转到paint提前指定的url上,传入access_token. 这时paint即可得到access_token.
注:
这里的access_token如何能被paint得到? 就是解析redirect_url的参数.
比如这样 ,直接取参考得到access_token为abcdefg.
|
http://my.redirect_url.com?access_token=abcedfg
|
像一些移动应用的程序内部实现时,即时一个错误的地址,也能解析到access_token.
因为应用内部会收到302跳转的数据只要,从中解析到token后,不执行跳转动作即可.
这个问题,困惑了我好久.经过朋友帮助才终于理解.
4.授权码模式(Authorization Code)
授权码模式与简化模式的过程是一样的.
不同之处在于,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空间)
四、总结
上面就是自己的浅见,本人实践过程仅搭建了一个简单的OAuth2.0服务器,用于其他合作伙伴访问我们的api时进行权限认证.
是一个比较简单的应用.
在学习理解OAuth2.0过程,参考了阮老师的文章.他的语言文字描述更准确透彻,且容易理解. 可以
点击此处查看.
五、参考资料：
0. 如何选择oAuth2.0各种授权类型
![张天琪——OAuth Security.pdf]()
另外,OAuth2.0官网上的教程
一步一步搭建OAuth2.0服务器对我帮助也很大.
官网有好几种实现方式,都是开源贡献者的精华,我只详细看了php的实现,就已经深深佩服.
一个看似简单的功能,竟然能实现的非常灵活, 仅需要很少的改动就能完整实现上述的4种认证授权模式,并且还有本文没有提到,但是标准中定义的很多其他细节.
五、参考资料：
0. 如何选择oAuth2.0各种授权类型
1.OAuth1.0 OAuth2.0的实现原因及安全性问题， 是PPT内容。
2.关于OAuth2.0的规范详细解决。
3.其他网站使用Auth2.0授权认证的接口文档
关于OAuth2.0的详细介绍，请参考OAuth2.0协议标准。
腾讯 （这个有时序图，讲的比较清晰。当然要配合"理解OAuth 2.0"一起理解）
人人网
来往
132
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
