Oauth1.0 和 2.0中都要先获取request token再去获取access token。为什么不能直接返回access token呢。拿Oauth2.0来说,
1、先把用户引导至登陆授权页面,(夹带参数client_id,redirect_uri,scope,response_typ=code)
2、用户授权后返回到回调url,并把request token作为参数返回
3、通过request token(客户端secret key以及其他参数)去获取access token
4...
...
为什么不能在第二步直接返回access token呢,是出于什么考量。

解决方案 »

  1.   

    我也跟楼主有同样的疑惑。我自己想到一个理由,但不是很确定,供参考:从“授权页面”到“回调url”这个过程,是能够被浏览器用户看到的(当然也就能被很多其它人、其它设备、其它程序看到),如果直接传输 access token 的话,容易泄密。而换取 access token 的过程只发生在应用服务器和授权服务器之间,安全一些吧。
    ————————————————————————————————
    基于CSDN论坛提供的插件扩展功能,自己做了个签名档工具,分享给大家,欢迎技术交流 :)
      

  2.   

    因为request token一直是未授权的,直到用户同意以后才变成授权的,授权的request token就可以被我们来使用去获取access token访问相应用户资源,这是出于安全机制才做成这样子的。http://blog.sina.com.cn/s/blog_4696b3760100m340.html
    讲的不错
      

  3.   

    没太看明白唠叨兄所指出的问题要点在哪里。一般应用拿到 access token 后,应该都是保存到自己的数据库中,需要的时候随时拿出来用,是吧?那么,如果不涉及安全问题的话,无论是第2步回调url直接带回来 access token,还是在第3步换取到 access token,应该都是一样的。
    ————————————————————————————————
    基于CSDN论坛提供的插件扩展功能,自己做了个签名档工具,分享给大家,欢迎技术交流 :)
      

  4.   

    很高兴有人回复~
    你说的理由我也有考虑过。但是这里回调url必须是客户端在服务提供方注册的时候填写的域名或是其根域名下的url,否则引导过去的时候会提示出错的。当我们引导用户到登陆页面的时候,该页面会先对传递过来的参数进行判断以及保存然后显示登陆页面,如果我们在第一步也把secret key传递过去的话,就算别人知道了我的参数好了,我也想不出可以拿来做什么坏事,因为回调url是有限制的。
      

  5.   

    我不太理解你话里面的因果关系。我拿腾讯的Oauth2.0来说,它的第四步还要拿access token去获取open id,而这个open id是跟腾讯用户唯一对应的。
      

  6.   

    我不理解为什么要有这一步。如果直接不要这一步,当用户同意授权的时候直接给我access token。会发生什么问题呢?
      

  7.   

    比如,你办公室的局域网上有人安装了一个窃听软件,它会检查所有的网络数据流。那么,如果在回调的时候携带了 access token,这个 access token 就会被那个恶意者拿到,他就会在他自己的服务器上发起进一步的请求,来访问你在资源服务器上的受保护资源。
      

  8.   

    按照 OAuth2 的处理逻辑,能够被局域网监听到的只有 request token,用这个换取 access token 的时候需要 app secret key,而换取过程发生在“应用服务器”和“授权服务器”之间,用户端局域网上监听不到。

    ————————————————————————————————
    基于CSDN论坛提供的插件扩展功能,自己做了个签名档工具,分享给大家,欢迎技术交流 :)