OAuth2.0是OAuth协议的延续，但如果OAuth1.0不向后兼容，OAuth 1.0将被彻底废除。 OAuth 2.0关注客户端开发人员的简单性。 要么组织资源所有者和HTTP服务提供商之间的授权交互来代表客户，要么允许第三方应用代表客户获得访问权限。 同时为Web应用、桌面应用和手机、客厅设施提供了专门的认证流程。 2012年10月，OAuth 2.0协议作为RFC 6749正式发布。 auth2.0的作用:首先说一下为什么需要auth2.0。auth2.0是一个开放平台的互联协议，所以我们可以知道，A在业内是一个两手空空的小众；b是行业大佬，财大气粗，人(客户)多；这时，A需要借用B的客户群信息，在自己的项目中构建一个功能。但是出于对资源的保护和各种原因，B并不信任A，也不会让A访问自己的信任体系。a无法直接获取B的客户群的客户名称和密码。同时，A想借用B的客户群信息来完善自己项目中的一些功能。这时候就需要auth2.0作为中介。通过少量的业务流程实现A的客户群的直接信息(账号和密码)而不用B，就可以间接得到其余的信息(除了客户名称和密码，比如客户昵称等。)的B的客户群。至于信息发达程度，就看b了。 说白了就是在没有B客户群密码和账号的情况下，如何让A获取B客户群的其余信息。auth2.0就是为了处理这样的问题。 事实上，很多拥有大量资源信息的网站或公司都有自己的开发平台，用于开放自己的少量资源信息，而拥有大量资源信息的网站或公司与开发者之间的双赢，可以通过auth2.0等少量妥协手段实现，因为拥有大量资源信息的网站或公司可以根据开发者开发的应用类型定向判断客户类型，这样一来， 拥有大量资源信息的网站或公司，可以根据客户类型做大数据分析，同时开发者也可以达到开发自己完整应用的目的，真正的双赢。 实际上，auth2.0有几种工作模式:简化模式、密码模式、客户端模式和授权码模式，其中使用最多的是授权码模式。这里我就分析一下qq开放互联网平台使用的授权码模式，如下图:首先定义角色，user-gent:客户(或者客户浏览器)；客户端:第三方网站或应用程序；授权服务器:认证服务器，不归第三方网站或应用所有，而是放入原所有者(如腾讯)；资源拥有者:资源(比如腾讯的qq客户群，归腾讯所有)存放的地方，它可以和授权服务器进行通信；总共有四个对象。 流程是这样的:步骤A:首先，用户代理访问客户机。客户端需要确定用户代理是谁，但是客户端没有用户代理客户端和密码，所以无法验证客户端。因此，user-agent会通过步骤A被重定向(定向)到authorization-server(如果客户端通过qq对客户进行认证，那么客户会发现自己的浏览器跳转到qq登录界面)，重定向过程中会附带少量信息，方便后续操作。这一步中最重要的信息是两个参数:重定向url和客户端标识符。步骤B(用户认证):客户在登录界面向授权服务器输入客户名称和密码，授权服务器会发现客户名称和密码正确无误。如果发现该客户确实存在，它将询问该客户是否可以被授权向该客户提供对其个人信息的访问。步骤C:获得客户的许可后，授权服务器会根据步骤A中获得的重定向url将客户重定向到客户端，同时携带授权码和少量其他信息到客户端。前面的步骤对客户是可见的，但是后面的步骤对客户是不可见的；步骤d:此时客户端会来到客户端界面，此时客户端会获取授权码。如果该参数存在，则意味着客户端已经被授权，客户端将使用授权码和重定向url访问身份验证服务器。访问令牌步骤e:如果授权码无效，授权服务器将向客户端发送访问令牌。同时，访问令牌是有时间限制的步骤f: Cleint将携带获得的访问令牌访问资源所有者。因为资源所有者和授权服务器可以互操作，所以资源所有者可以验证访问令牌是有效的还是过期的。如果有效且未过期，将允许客户端访问以前客户的少量信息。 附上OAuth 2.0的另一个详细解释:http://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html