没有OAuth的时代：
如果我们有这么一个场景：有三个角色。各自是“用户”。“第三方应用”。“服务提供商。比方google”
用户有非常多照片都存放在googleserver。这时候，用户须要借助第三方应用“云冲印”，将存放在googleserver的照片打印出来。那么此时我们正处于没有OAuth的时代，这时候，用户登录第三方应用“云冲印”之后。就得须要将用户在google的帐号和password提供给“云冲印”，这时候“云冲印”拿着用户提供的google帐号和password。登录到googleserver，再而获取用户的照片。接着兴许的打印工作。
那么上面是一个模拟的场景，在没有OAuth的时代，我们也仅仅能这么做。那么会导致什么样的问题发生。缺陷例如以下：
严重缺点:
（1）云冲印全然保存用户password，导致用户的google帐号不安全；
（2）client获取用户存储在googleserver的全部资料，用户没法限制第三方应用“云冲印”的授权范围和有效期。
（3）用户仅仅有改动password，才干收回赋予第三方应用“云冲印”的权利；
（4）最为严重：“云冲印”网站遭遇攻击，用户password泄露，意味着用户在google的信息泄露；
基于以上几个缺陷。OAuth诞生了。OAuth作用：就是让"client”（第三方应用：上文的云冲印）安全可控地获取"用户"的授权，与"服务提供商"进行互动。
眼下OAuth有三个版本号：OAuth1.0，OAuth1.0a。OAuth2.0
OAuth1.0
用一副图来解释OAuth1.0的整个执行流程如图1所看到的：
图1：OAuth1.0流程图
这是相关“雅虎”网站进行OAuth认证的整个执行流程：
參与者：Application，YAHOO!。User
（1）client在自己网站实现YAHOO!的第三方认证之前，须要到YAHOO!服务提供商申请帐号Consumer Key，YAHOO!通过申请之后。并发放Consumer Key已经相应的Consumer Secret的一套认证帐号，这时候说明该client已经增加了YAHOO服务提供商的认证服务。
（2）获取Request Token，须要传递參数：
oauth_consumer_key：应用ID
oauth_nonce：client生成的随机数
oauth_signature_method：签名方式（眼下有：HMAC-SHA1、RSA-SHA1与PLAINTEXT等三种）
oauth_timestamp：时间戳
oauth_version：OAuth版本
xoauth_lang_pref(optional)：
oauth_callback：
YAHOO!验证用户參数合法。通过验证，允许发放Request_Token，返回client參数：
oauth_token：请求令牌
oauth_token_secret：令牌相应的密钥
oauth_expires_in：令牌过期时间
xoauth_request_auth_url：
oauth_callback_confirmed=true
（3）client接收到Request_Token，此时将用户导向YAHOO!认证页面，并传递參数：Request_Token
oauth_token：请求令牌
此时服务提供商接下来“询问用户是否给予授权”。用户允许授权，服务提供商将用户重定向client事先传递的oauth_callback（重定向URI）地址。并以GET方式传递授权码（oauth_verifier）
（4）client使用Request_Token以及OAuth_Verifier向服务提供商交换Access_Token：传递參数：
oauth_consumer_key：应用ID
oauth_signature_method：签名方式（眼下有：HMAC-SHA1、RSA-SHA1与PLAINTEXT等三种）
oauth_signature：签名（注意。这一步骤用到了签名，OAuth签名的生成，详看服务提供商OAuth签名生成文档，此处提供金山快盘签名生成）
oauth_timestamp：时间戳
oauth_version：OAuth版本
oauth_token：Request_Token请求令牌
oauth_nonce：client生成的随机数
oauth_verifier：授权码
服务提供商确认签名匹配。參数准确无误。授予Access_Token以及Access_Secret，返回client參数：
oauth_token：Access_Token訪问令牌
oauth_token_secret：令牌相应密钥
oauth_session_handle：用于刷新过期訪问令牌
oauth_expires_in：令牌过期时间
（5）令牌过期，又一次刷新令牌
与(4)差别唯一參数：oauth_session_handle，不须要传递授权码：oauth_verifier，YAHOO!又一次返回Access_Token以及密钥Access_Token_Secret
注意：这里的oauth_timestamp和oauth_nonce是为防止重放攻击而设置的。详细的来讲：请求者不能在一段时间（server同意的client和服务端的时间差）内发送相同的请求两次或以上，假设在这个时间段之后再次发生这个请求。则会由于超出服务端同意的时间差而被拒绝。
2009 年 4 月 23 日。 OAuth 宣告了一个 1.0 协议的安全漏洞。该漏洞影响了 OAuth 1.0 核心规范第 6 节的OAuth 的认证流程（也称作 3 阶段 OAuth ）， OAuth Core 协议 1.0a 版本号攻克了这一问题。
OAuth 1.0可能公布地太快了，因此广受批评。之后非常快就出现了与之竞争的WRAP（Web资源授权协议），它非常快地进行了标准化，成为OAuth的对手。从那时開始，OAuth工作小组就開始着手创建OAuth 2.0。
OAuth2.0：
腾讯，百度，新浪等开放平台都广泛使用了OAuth2.0
关于OAuth2.0的术语：
（1） Third-party application：第三方应用程序，又称”客户端”（client）；
（2）HTTP service：HTTP服务提供商。简称”服务提供商”。；
（3）Resource Owner：资源全部者，又称”用户"（user）；
（4）User Agent：用户代理，指浏览器；
（5）Authorization server：认证server，服务提供商专门用来处理认证的server；
（6）Resource server：资源server，服务提供商存放用户资源的server。
它与认证server能够是同一台server，也能够是不同的server；
执行流程： （例如以下图2所看到的）
（A）用户打开client以后。client要求用户给予授权。
（B）用户允许给予client授权。
（C）client使用上一步获得的授权。向认证server申请令牌。
（D）认证server对client进行认证以后，确认无误。允许发放令牌。
（E）client使用令牌。向资源server申请获取资源。
（F）资源server确认令牌无误。允许向client开放资源。
图2：OAuth2.0执行简易流程
B（授权）为最关键的步骤！
client的授权模式（4种）：
（1）授权码模式（authorization code）
（2）简化模式（implicit）
（3）密码模式（resource owner password credentials）
（4）客户端模式（client credentials）
当中：
授权码模式（authorization code）是功能最完整、流程最严密的授权模式。
它的特点就是通过client的后台server，与"服务提供商"的认证server进行互动。
当然，并非全部人对OAuth2.0都投赞成票。有兴趣能够看看：OAuth 2.0对Web有害吗？
关于OAuth1.0和2.0的相关差别小结：
(1)1.0每次请求都须要签名，2.0更简洁，不须要签名了
(2)1.0:Request_Token->Authorization_Code; Authorization_Code->Access_Token 2.0:Authorization_Code->Access_Token
(3)1.0每一个token都须要加密，2.0则不须要。这样不就不安全了。可是2.0要求使用https（是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议。假设不是登陆到一些帐户和密码时，没什么用，仅仅有须要登录password时这样候它的作用就很大了。
）协议，安全性更高一筹
(4)2.0有4种授权模式，1.0仅仅有1种