OAuth目前已经成为互联网标准协议之一
字面意理解：open authorization 开放授权，允许用户让第三方应用访问该用户在某一网站上存储的私密的资源（如照片，视频，联系人列表），而无需将密码等数据提供给第三方应用。
原版：OAuth is a security protocol that enables users to grant third-party access to their web resources without sharing their passwords.
例如：
在认证和授权的过程中涉及的三方包括：
服务提供方，用户使用服务提供方来存储受保护的资源，如照片，视频，联系人列表。用户，存放在服务提供方的受保护的资源的拥有者。客户端，要访问服务提供方资源的第三方应用，通常是网站，如提供照片打印服务的网站。在认证过程之前，客户端要向服务提供者申请客户端标识。OAuth的参与者至少有以下四个：
RO(Resource Owner)：资源所有者，对资源具有授权能力的人。其实来讲就是用户，如上文的小明。RS(Resource Server)：资源服务器，它存储资源，并处理对资源的访问请求。如上文的新浪微博资源服务器。Client：第三方应用，它获取RO的授权后就可以访问RO的资源。如上文的第三方客户端。AS(Authorization Server)：授权服务器，它认证RO的身份，为RO提供授权审批流程，并最终颁发授权令牌(AccessToken)。AS和RS的功能可以由同一个服务器来提供。简单的来讲就是用户、第三方客户端、服务器。这个服务器有两个工作：授权和提供资源。
OAuth在Client和RS之间设置了一层授权层。Client不能直接登录RS，只能利用令牌来登录授权层，而且这个令牌有权限范围和有效期。
有两个关键的东西，一个是用户同意授权的授权证据，一个是用授权证据进一步请求拿到的访问令牌。
上面讲到用户给客户端授权这一步是关键。客户端必须得到用户的授权才能获得令牌。Auth2.0定义了四种授权方式：
授权码模式 简化模式 密码模式 客户端模式
授权码模式是功能最完整、流程最严密的授权模式。其特点是通过Client的后台服务器与AS进行互动。
1、客户端初始化协议的执行流程，通过HTTP 302来重定向用户代理到服务器。这里的用户代理基本上就是指浏览器。客户端申请认证的URI包含以下参数：
response_type：授权类型，此处的值固定为“code”(必选)client_id：客户端的ID(必选)redirect_uri：重定向URI(可选)scope：申请的权限范围(可选)state：客户端的当前状态，可指定任意值，认证RS会原封不动地返回这个值2、服务器认证用户身份证，并提供页面供用户决定是否批准或拒绝客户端的此次请求。
3、若请求被批准，服务器使用步骤(1)中客户端提供的redirect_url重定向用户代理到指定页面。redirect_uri必须包含authorization_code，也就是我们前面所说的比较重要的授权证据。以及步骤(1)中Client提供的state。若请求被拒绝，AS将通过- redirect_uri返回相应的错误信息。
code：授权码(必选)。该码的有效期应该很短，通常设为10分钟，客户端只能使用该码一次，否则会被授权服务器拒绝。该码与客户端ID和重定向URI是一一对应的关系。state：如果客户端的请求中包含这个参数，认证服务器的回应也必须一模一样包含这个参数。4、客户端拿authorization_code去访问服务器以交换所需的access_token，也就是前面所说的访问令牌。客户端请求信息中应包含用于认证客户端身份所需的认证数据，以及上一步请求authorization_code时所用的redirect_uri。
grant_type：授权模式，此处的值固定位“authorization_code”(必选)code：上一步获取的授权码(必选)redirect_uri：重定向URI，必须与步骤(1)中的该参数值保持一致(必选)client_id：客户端ID(必选)5、服务器收到authorization_code时需要验证客户端的身份，并验证收到的redirect_uri与步骤(3)请求authorization_code时所用的redirect_uri相匹配。如果验证通过，AS将返回access_token以及refresh_token。
access_token：访问令牌token_type：令牌类型token_type：表示过期时间refresh_token：更新令牌，用来获取下一次的访问令牌scope：权限范围，如果与客户端申请的范围一致，此项可省略如果Client的访问令牌过期，则需要使用更新令牌申请一个新的访问令牌。 Client发出更新令牌的HTTP请求，包含以下参数：
grant_type：授权模式，此处的值固定为“refreshtoken”refresh_token：之前收到的更新令牌scope：申请的授权范围，不可以超出上一次申请的范围，如果省略该参数，则表示与上一次一致而这种授权无需将用户提供用户名和密码提供给该第三方网站。 这句话的意思很明显，就是简书服务器是没法拿到你在微信服务器中的用户名和密码的，但是的确能够让你登陆简书服务器
既然第三方(简书)无法拿到你的用户名和密码，那肯定是由服务商(微信)来进行验证，那么第三方肯定要和服务商有一种机制来进行辨识: 在认证过程之前，第三方(简书)需要先向服务商(微信)申请第三方(简书)服务的唯一标识 因此第三方(简书)填写本公司相关信息，提供本公司账号，域名等信息，并且花三百块钱给服务商(腾讯)进行审核。服务商腾讯收到钱，并且审核通过后，会给第三方(简书)两个编号:AppID和appSecret(及其重要，不能泄露)。通过这两个编号，就能确认唯一性了。当然过程是很复杂的。 第三方[服务器]和服务商[服务器]之间的通信： 既然第三方(简书)用通过服务商(微信)来验证用户(你)身份的合法性，那么肯定涉及到：一旦服务商(微信)确认用户(你)的合法身份后，如何将信息传递给第三方(简书) 很简单，通过第三方(简书服务器)提供的回调URL，服务商(微信服务器)将相关数据以参数形式写入到第三方(简书服务器)提供的回调URL,第三方(简书服务器)解析服务商(微信服务器)发过来的信息抽取出来就OK了！ 那在微信公众号的申请中，有要求第三方(简书)提供回调地址
