Oauth入门学习

在一些网站总是看到调用其他网站的信息的实例，比如在人人网中导入MSN联系人，在Facebook中导入gmail，yahoo mail好友，第三方网站不需要总知道你的密码，对于应用的授权完全交给你自己，这种用户账号安全问题的策略使用了Oauth认证。

如下一个的案例： 如果一个用户拥有两项服务：一项服务是图片在线存储服务A，另一个是图片在线打印服务B。如下图所示。由于服务A与服务B是由两家不同的服务提供商提供的，所以用户在这两家服务提供商的网站上各自注册了两个用户，假设这两个用户名各不相同，密码也各不相同。当用户要使用服务B打印存储在服务A上的图片时，用户该如何处理？法一：用户可能先将待打印的图片从服务A上下载下来并上传到服务B上打印，这种方式安全但处理比较繁琐，效率低下；法二：用户将在服务A上注册的用户名与密码提供给服务B，服务B使用用户的帐号再去服务A处下载待打印的图片，这种方式效率是提高了，但是安全性大大降低了，服务B可以使用用户的用户名与密码去服务A上查看甚至篡改用户的资源。

 

一个典型的OAuth应用通常包括三种角色，分别是：

  Consumer：消费方

Service Provider：服务提供者

User：用户

 下面是Oauth的认证过程，以及相关的参数：

 

 A. 使用者（第三方软件）向OAUTH服务提供商请求未授权的Request Token。向Request Token URL发起请求，请求需要带上的参数见上图。

B. OAUTH服务提供商同意使用者的请求，并向其颁发未经用户授权的oauth_token与对应的oauth_token_secret，并返回给使用者。

C. 使用者向OAUTH服务提供商请求用户授权的Request Token。向User Authorization URL发起请求，请求带上上步拿到的未授权的token与其密钥。

D. OAUTH服务提供商将引导用户授权。该过程可能会提示用户，你想将哪些受保护的资源授权给该应用。此步可能会返回授权的Request Token也可能不返回。如Yahoo OAUTH就不会返回任何信息给使用者。

E. Request Token 授权后，使用者将向Access Token URL发起请求，将上步授权的Request Token换取成Access Token。请求的参数见上图，这个比第一步A多了一个参数就是Request Token。

F. OAUTH服务提供商同意使用者的请求，并向其颁发Access Token与对应的密钥，并返回给使用者。

G. 使用者以后就可以使用上步返回的Access Token访问用户授权的资源。

然而由于Oauth1.0签名算法太复杂,获取token的方式单一,性能和可伸缩性比较差等缺点，Oauth2.0问世。该机制将认证服务器和资源服务器分开,使用HTTPS安全通道，AccessToken Refresh机制和采用固定的回调。新的标准在认证和授权方面，涉及到四个角色：

Resource Owner:  能够对受保护资源进行访问许可控制的实体。

Resource Server: 能够接受和响应受保护资源请求的服务器。

Protected Resource: 能够使用Oauth请求获取的访问限制性资源。

Client: 获取授权和发送受保护资源请求的应用。

其认证的流程为：

 

(A) 客户端从资源拥有者那里请求授权。授权请求能够直接发送给资源拥有者，或者间接地通过授权服务器这样的中介，而后者更为可取。
(B) 客户端收到一个访问许可，它代表由资源服务器提供的授权。
(C) 客户端使用它自己的私有证书到授权服务器上验证，并出示访问许可，来请求一个访问令牌。
(D) 授权服务器验证客户端私有证书和访问许可的有效性，如果验证通过则分发一个访问令牌。
(E) 客户端通过出示访问令牌向资源服务器请求受保护资源。
(F) 资源服务器验证访问令牌的有效性，如果验证通过则响应这个资源请求。

Oauth2.0有许多种流程，分别适应不同的第三方应用，并且这些流程数目还在不断增加和完善中，一个网站可以实现一种或多种流程，以下是6种全新的流程：

  　　User-Agent Flow – 客户端运行于用户代理内（典型如web浏览器）。

　  　Web Server Flow – 客户端是web服务器程序的一部分，通过http request接入，这是OAuth 1.0提供的流程的简化版本。

　  　Device Flow – 适用于客户端在受限设备上执行操作，但是终端用户单独接入另一台电脑或者设备的浏览器

　  　Username and Password Flow – 这个流程的应用场景是，用户信任客户端处理身份凭据，但是仍然不希望客户端储存他们的用户名和密码，这个流程仅在用户高度信任客户端时才适用。

　  　Client Credentials Flow – 客户端适用它的身份凭据去获取access token，这个流程支持2-legged OAuth的场景。

　  　Assertion Flow – 客户端用assertion去换取access token，比如SAML assertion。 　　

可以通过使用以上的多种流程实现Native应用程序对OAuth的支持（程序运行于桌面操作系统或移动折本）。