[OAuth]OAuth2学习笔记

       本文根据http://tools.ietf.org/html/draft-ietf-oauth-v2-23 编写
        1.介绍
           先明确用例中的角色 

           受保护的资源  ：比如163相册的上的一副照片      

           资源拥有者      ： 本文的作者

            第三方             ：老婆大人

               OAuth2目的是让【第三方】 通过【资源拥有者】的授权可以访问到【受保护的资源】
           它的特色在于不必把【资源拥有者】的凭据(我的帐户和密码)明文透露给【第三方】
            OAuth2 与OAuth1不兼容且会取代后者
      2.本文中英文呢对照术语

          credential  凭据 http://en.wikipedia.org/wiki/Credential  

                              有人更专业的翻译为私钥。形象的说比如银行卡密码。

      3.原理阐述
          3.1OAuth2中定义了4个角色
                   client                           客户
                   resource owner       资源拥有者
                   authorization server 授权服务器
                   resource server       资源服务器
           3.2 协议流

                     A. 【client】 向【resource owner】              

                           发送  Authorization request  请求 ，毕竟是基于互联网的协议大概就是引导到一个登录页面

                    B.  【resource owner】 向【 client】            

                           返回   Authorization grant 授权信息，总应该返回点什么： 成功Authorization Code ,错误信息

                    C.  【client】向【authorization server】         

                           发送  Authorization grant  发送刚获得的授权给认证服务器 ,撑门面的行不行我说了算

                    D.  【authorization server】向【client】         

                          返回  access token 令牌 ， 终于通过!--了，获得一个临时居住证 

                     E.  【client】向【resource server】               

                           发送 带有access token的资源请求，带着我的临时居住证申请租房 买车

                     F.  【resource server】向【client】                

                           返回申请的资源 ，祈求上帝别是临时的多好。【resource owner】我汗！

           4.详解
               4.1 Authorization grant 授权
                      规范定义了4种授权类型

                      【authorization Code】：

                            是【client】和【resource owner】中介产物，

                            目的不透露【resource owner】的【credentials】凭证给【client】

                     【 implicit】：

                           没有【authorization Code】直接可以获得【access token】

                            通过什么方式呢？通过【redirection URI】重定向

                     【 resource owner password credentials】：

                            通过【resource owner】的【confidential】直接获得【access token】

                      【client credentials 】：

                             适用【client】和【resource owner】是同一个的情况下

               4.2  【Access Token 】和【refresh Token】

                       4.2.1 【access token】令牌

                                  是【authorization server】产生的由【resource server】消费的介质。

                                  它是个字符串。里面的信息哈哈构造可以研讨的 ：）

                       4.2.2 【refresh token】刷新令牌

                                   是当【access token】失效后【client】 引导到【authorization server】

                                  重新获得【access token】

          5. TLS Version 
                Transport  Layer Security 传输层安全版本，目前TLS1.0的较其他应用得更广泛
          6. 【client】
                  提供【client type】和【redirection URI】及【authorization server】需要的其他信息                                

                   6.1 【client type】

                           通过这个参数的设置【authorization server】可以提供一个单一接口管理复杂的客户端

                            6.1.1 【confidential】

                                          【client】需要与【authorization server】确立信任

                            6.1.2 【public】        

                                          【client】与【authorization server】无需建立信任。比如【client】

                                          以【native application】或【user-agent application】方式运行在

                                         【resource owner】的设备上。

                    6.2 【client identifier】客户端标识

                              【authorization server】需要标识【client】所用，有客户端产生不需要保密的字符串。

                    6.3 【client  authentication】客户端身份证明

                                如果【client type】是【credential】方式，它以可以使用【password】密码或者

                            【public/private key pair】公私密钥任何途径来确立与【authorization server】建立信任。

                                而对于【client type】是【public】方式，但是【authorization server】对此不进行回复

                        来识别【client】。既然从公共平台下载的软件或脚本如何识别你自己。

                     6.4 【client password】客户端密码

                               【authorization server】必须支持【HTTP/1.0】中的【Basic Access Authorization】

                             验证【client】提供的【password】密码 ,而且必须通过【TLS】及【HTTPS】进行。

                                当然【client】也可以使用【RFC2617】对密码进行hash加密。

                     6.5 【unregistered client】未注册的客户端

                               本规范不涉及此情况

                     

          7.协议应用的场景

              7.1【web application】

                      

                       【end-user】及【resource owner】

                        这种场景是否可以理解为基于服务器的客户把申请推送给【resource owner】让其登录浏览器进行授权，

                       【authorization code】 通过【user-agent】由客户端记录，之后的流程比较好理解。

              7.2【user-agent-based application】

                        

                         这种场景【resource owner】通过自己的设备上的【user-agent】通常是浏览器下载【client】

             7.3 【native application】

                        这种场景使用在【client】是一个公开的可安装和执行的原生应用。

                       协议数据和【credential】可以 访问【resource owner】，

                      也就是说安装了此程序的【client】可以获得【resource owner】的任何【credential】。

                       这种原生应用应该提供安全方面的保证。比如对敌对网站不应暴露【resource owner】

                       的【credential】，其他应用不能通过其访问【resource owner】的【redential】

          8.【Protocol endpoint】协议端

                   8.1【authorization endpoint】

                          × 通过【user-agent】的重定向引导【source owner】进行授权。

                          ×【authorization server】必须实现验证【source owner】的身份。但采取何种方式不在

                             此规范内。也就是说开发者要通过阅读【resource server】所提供资源相应的

                            【authorization server】定义的URI

                           ×【authorization server】必须采用【TLS】方式而且必须支持【GET】请求，在处理请求

                              时必须对参数无值的情况进行处理，必须忽略不支持的请求参数，请求响应的参数应该

                             仅出现一次

                           × 【authorization endpoint】适用与【authorization code】和【implicit】授权类型

                            ×【authorization request】

                                      必须包括【response_type】参数，如果没有应该按照规范中的定义在响应中描述

                  8.2 【token endpoint】

                            通过授权后可以交换到相应的【access token】端

                   8.3 【redirection endpoint】

                            通过【resource owner】的【user-agent】把【authorization server】的【credential】

                           返回给【client】 

                            ×在完成与【resource owner】进行授权交互后，【authorization server】应该引导

                              【resource owner】的【user-agent】返回到【client】。

                            ×【URI 】应该就是绝对路径，还可以在这个URI中加入【"application/x-www-form-urlencoded"】

                                方式的参数，但绝不能是并入URI串中

                            ×【URI】这个值应该是【client】在与【authorization server】注册时或请求时的传达给

                              【authorization server】的值

                            ×【URI】redirection应该使用【TLS】进行返回响应。但考虑到【client】部署【TLS】存在难度，

                                所以 并不在本规范中硬性规定。

                            ×对于【client】类型中【public】以及部分【confidential】(【Authorization grant 】类型为【implicit】)

                                的请求【authorization server】应该要求【client】提供完整的重定向URI，这个请求会使用

                                "state"这个参数给出。如果不在“state”给出，可以提供URI 使用【"application/x-www-form-urlencoded"】

                                 动态定为的方式

                           × 【authorization server】应该允许【client】注册多个【redirection endpoint】

                           ×  缺乏提供 重定向URI的请求可能是对【authorization server】的攻击