严重缺点: 

（1）云冲印完全保存用户密码，导致用户的google帐号不安全； 

（2）客户端获取用户存储在google服务器的所有资料，用户没法限制第三方应用“云冲印”的授权范围和有效期； 

（3）用户只有修改密码，才能收回赋予第三方应用“云冲印”的权利； 

（4）最为严重：“云冲印”站点遭遇攻击，用户密码泄露，意味着用户在google的信息泄露；

用一副图来解释OAuth1.0的整个运行流程如图1所示：

 图1：OAuth1.0流程图

这是相关“雅虎”站点进行OAuth认证的整个运行流程：
参与者：Application，YAHOO!，User
（1）客户端在自己站点实现YAHOO!的第三方认证之前，需要到YAHOO!服务提供商申请帐号Consumer Key，YAHOO!通过申请之后，并发放Consumer Key已经对应的Consumer Secret的一套认证帐号，这时候说明该客户端已经加入了YAHOO服务提供商的认证服务。
（2）获取Request Token，需要传递参数：
          oauth_consumer_key：应用ID
          oauth_nonce：客户端生成的随机数
          oauth_signature_method：签名方式（目前有：HMAC-SHA1、RSA-SHA1与PLAINTEXT等三种）
          oauth_timestamp：时间戳
          oauth_version：OAuth版本号
          xoauth_lang_pref(optional)：
          oauth_callback：
     YAHOO!验证用户参数合法，通过验证，同意发放Request_Token，返回客户端参数：
          oauth_token：请求令牌
          oauth_token_secret：令牌对应的密钥
          oauth_expires_in：令牌过期时间
          xoauth_request_auth_url：
          oauth_callback_confirmed=true
（3）客户端接收到Request_Token，此时将用户导向YAHOO!认证页面，并传递参数：Request_Token
          oauth_token：请求令牌
          此时服务提供商接下来“询问用户是否给予授权”，用户同意授权，服务提供商将用户重定向客户端事先传递的oauth_callback（重定向URI）地址，并以GET方式传递授权码（oauth_verifier）
（4）客户端使用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：客户端生成的随机数
          oauth_verifier：授权码
      服务提供商确认签名匹配，参数准确无误，授予Access_Token以及Access_Secret，返回客户端参数：
          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是为防止重放攻击而设置的。具体的来讲：请求者不能在一段时间（服务器允许的客户端和服务端的时间差）内发送同样的请求两次或以上，如果在这个时间段之后再次发生这个请求，则会因为超出服务端允许的时间差而被拒绝。
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：认证服务器，服务提供商专门用来处理认证的服务器； 

（6）Resource server：资源服务器，服务提供商存放用户资源的服务器。它与认证服务器可以是同一台服务器，也可以是不同的服务器；

运行流程： （如下图2所示）

（A）用户打开客户端以后，客户端要求用户给予授权。 

（B）用户同意给予客户端授权。 

（C）客户端使用上一步获得的授权，向认证服务器申请令牌。 

（D）认证服务器对客户端进行认证以后，确认无误，同意发放令牌。 

（E）客户端使用令牌，向资源服务器申请获取资源。 

（F）资源服务器确认令牌无误，同意向客户端开放资源。

图2：OAuth2.0运行简易流程

B（授权）为最关键的步骤！
客户端的授权模式（4种）： 

（1）授权码模式（authorization code） 

（2）简化模式（implicit） 

（3）密码模式（resource owner password credentials） 

（4）客户端模式（client credentials）
其中：
授权码模式（authorization code）是功能最完整、流程最严密的授权模式。它的特点就是通过客户端的后台服务器，与"服务提供商"的认证服务器进行互动。
当然，并不是所有人对OAuth2.0都投赞成票，有兴趣可以看看：OAuth 2.0对Web有害吗？