PY_DGXH_2011

从安全的角度来讲《》介绍的Implicit類型的Autorization Grant存在这样的两个问题:其一,授权服务器没有对客户端应用进行认证因为获取Access Token的请求只提供了客户端应用的ClientID而没有提供其ClientSecret;其二,Access Token是授权服务器单独颁发给客户端应用的照理说对于其他人(包括拥有被访问资源的授权者)应该是不可见的。Autorization Code类型的Autorization Grant很好地解决了这兩个问题

Autorization Code是最为典型的Autorization Grant,它“完美”地实现了指定的OAut初衷:资源拥有者可以在向客户端应用提供自身凭证的前提下授权它获取受保护的資源如右图所示,Autorization Code类型的Autorization Grant具有完整的“三段式”授权流程接下来,我们还要针对“集成Windows Live

Token和Autorization Code均不存在于当前请求之中所以并不会执行任何操作。接下来CallengeAsync方法被执行浏览器被重定向到Windows Live Connect的授权页面(如果当前用户尚未登录到Windows Live Connect,在此之前会先被重定向到登录页面如果之前巳经完成了授权,授权页面不会再出现)

在取得了用户授权的情况下,授权服务器会生成一个Autorization Code并将其作为查询字符串附加到请求提供嘚重定向地址,然对针对这个URL实施重定向由于我们设置的重定向地址为“/webapi/api/demo”,所以最终进行重定向的目标地址为“/webapi/api/demo?code={autorizationcode}

我们提供的这个實例并没有演示如何获取Refres Token以及在Access Token过期的时候利用它来获取新的Access Token,有兴趣的读者朋友不妨将此功能一并实现在我们自定义的AutenticateAttribute之中

这里介绍嘚“客户端应用”是针对OAut 2.0授权角色而言,表示被授权的客户端应用从运行环境来讲,这个应用可以运行于单纯的客户端上下文(既包括運行于浏览器环境中的Web应用以及在客户端安装的各种App)也可以运行于服务器(比如Web应用中运行于Web Server的那部分程序)。


}

我要回帖

更多关于 丅H2011 的文章

更多推荐

版权声明:文章内容来源于网络,版权归原作者所有,如有侵权请点击这里与我们联系,我们将及时删除。

点击添加站长微信