RobotFrameWork http/https oauth接口测试 （一）

      感觉自己最近销声匿迹快一个月了，应该总结下自己这个月学习的东西了~~~折腾完公司私有协议的接口测试（c++接口），开始折腾公司的http/https接口和webservice接口的测试，想着把所有的这些接口尽量的都放在RobotFrameWork内进行测试，其实这些接口，http/https接口和webservice接口之前已经能用SoapUI或者LoadRunner实现了测试，而且webservice接口我有专门用myeclipse结合TestNG框架和XFIRE框架搭建了数据驱动的自动化测试工具，但是前者没有实现自动化，参数写死在脚本内，后者技术性太强，一般测试不会用。而且测试里也没有详细的测试报告，于是我就想着全部移植到RF内。

     基于https协议的接口，是因为公司有部分业务采用了Oauth2.0协议来开发的，自己做的认证服务器，也做了资源服务器，主要是采用spring mvc、openjpa框架来实现的，底层的数据传输采用HTTPS协议，返回值数据格式采用的是标准JSON格式。

     首先：应该了解Oauth2.0协议的基本概念，基本应用场景

    OAUTH协议为用户资源的授权提供了一个安全的、开放而又简易的标准。与以往的授权方式不同之处是OAUTH的授权不会使第三方触及到用户的帐号信息（如用户名与密码），即第三方无需使用用户的用户名与密码就可以申请获得该用户资源的授权，因此OAUTH是安全的。oAuth是Open Authorization的简写。官方网址：http://oauth.net。

    常见应用场景：在京东上可以不注册用户，用户可以直接用qq号登陆即可。

    在Oauth当中有四个角色：

    A：Resource Owner(RO):资源所有者，资源可以类似于照片，文档，会员信息等等。对应于上面应用场景中的用户，用户拥有的资源都是被保护的资源。

    B: resource server资源服务器：保存资源的服务器.访问资源服务器就要出示 Access Token。对应上面场景中的京东，qq用户需要携带Access Token才能正常访问京东服务器（不然用其他APP的账号咋就不能登呢，嘿嘿）。

    C：client客户端：拿到Token授权后，可以代表资源所有者访问资源服务器。对应上面场景中的京东。

    D: authorization server授权服务器：对资源所有者进行认证，认证通过后，向 客户端发放 Access Token,对应上面场景中的qq服务器。

    然后：了解下oauth协议的总体处理流程。

    不同的公司，不同的授权模式，处理流程应该是不一样的，这里就以上面的应用场景为例，说明下大致的业务流程：

    Step1：申请接入，从腾讯获取appid和apikey；
    Step2：开发应用，并设置协作者帐号进行测试联调；
    Step3：放置QQ登录按钮；
    Step4：通过用户登录验证和授权，获取Access Token；
    Step5：通过Access Token获取用户的OpenID；
    Step6：调用OpenAPI，来请求访问或修改用户授权的资源。

    上面的业务流程主要还是来自http://wiki.connect.qq.com，腾讯官网提供给第三方应用使用的，从这里可以加深对oauth协议的了解，下面是官网里面的流程图

   

  简单点的可以看下面的图：

  

    最后：OAuth定义的4种授权类型

   第一种：Authorization Code授权码方式（最安全）：

   qq就是采用这种方式进行授权的，大致流程如下：

   

 

（A）用户访问客户端，后者将前者导向认证服务器。

（B）用户选择是否给予客户端授权。

（C）假设用户给予授权，认证服务器将用户导向客户端事先指定的"重定向URI"（redirection URI），同时附上一个授权码。

（D）客户端收到授权码，附上早先的"重定向URI"，向认证服务器申请令牌。这一步是在客户端的后台的服务器上完成的，对用户不可见。

（E）认证服务器核对了授权码和重定向URI，确认无误后，向客户端发送访问令牌（access token）和更新令牌（refresh token）。

  第二种：Implicit Grant隐式授权：相比授权码授权，隐式授权少了第一步的取Authorization Code的过程，而且不会返回 refresh_token。大致流程如下：

    

     （A）客户端将用户导向认证服务器。

    （B）用户决定是否给于客户端授权。

    （C）假设用户给予授权，认证服务器将用户导向客户端指定的"重定向URI"，并在URI的Hash部分包含了访问令牌。

    （D）浏览器向资源服务器发出请求，其中不包括上一步收到的Hash值。

    （E）资源服务器返回一个网页，其中包含的代码可以获取Hash值中的令牌。

    （F）浏览器执行上一步获得的脚本，提取出令牌。

    （G）浏览器将令牌发给客户端。

    第三种：Resource Owner Password Credentials资源所有者密码证书授权：这种验证主要用于资源所有者对Client有极高的信任度的情况，比如操作系统或高权限程序。只有在不能使用其它授权方式的情况下才使用这种方式。我做的这个项目就是采用的这种授权类型，主要流程如下：

   

     （A）用户向客户端提供用户名和密码。

    （B）客户端将用户名和密码发给认证服务器，向后者请求令牌。

    （C）认证服务器确认无误后，向客户端提供访问令牌。

     第四种：Client Credentials客户端证书授权：这种情况下 Client使用自己的 client证书（如 client_id及client_secret组成的 http basic验证码）来获取 access token，只能用于信任的client。

      

        

    （A）客户端向认证服务器进行身份认证，并要求一个访问令牌。

    （B）认证服务器确认无误后，向客户端提供访问令牌。

      对这个讲解很深入的可以参考http://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html