OAuth 授权服务

　　在所有API 服务的实现架构中，授权均由OAuth 服务来完成。OAuth 是一种开放授权协议，可以实现资源拥有者在不暴露账户/ 密码的前提下，授权第三方访问它所拥有的特定资源。例如，如果某个应用需要提示您邮箱中有未读邮件，传统的实现方式下，它需要知道您的账户密码才能访问邮箱服务读取您邮件的信息，在广泛使用统一身份认证的今天，账户密码显然是一般应用系统无法获得也不应该获得的。如果这个应用是类似学校门户这样权威应用，我们可能可以提供其他手段让它能获取到任意用户的邮件信息，而如果只是一个第三方开发的普通应用，尽管它可能做得比门户要好的多，这条路也走不通。而在使用OAuth后我们就能做得更好，应用如果要访问您的邮件资源，那它首选需要通过OAuth 取得您同意它访问您邮件资源的授权，即access token，然后就能通过邮件API 服务读取您的邮件信息。一个access token 是被限制到具体的账户( 您) 和具体的操作( 读取邮件资源) 上的，是在资源的拥有者同意的情况下才能获得，资源的拥有者可以随时撤销它，因此OAuth 能够最大限度地保证用户资源不被非法访问。目前，OAuth 广泛的应用在互联网上，如新浪、淘宝、腾讯、Google 等都支持使用OAuth 进行授权，OAuth 同样是上海交通大学提供的一项基础服务。OAuth 授权的基本流程如下。

　　1. Resource Owner： 资源的拥有者，一般是用户，也可能是应用系统。2.Resource Server：提供资源存取服务的服务端，在这里就是API 服务。3.Authorization Server： 提供授权的服务端， 也就是OAuth 服务。4.Client：需要访问资源的第三方，如各种应用系统。

　　OAuth 授权的基本流程是当Client需要访问Resource Owner 的资源时，首先从Resource Owner 取得Authorization Grant，然后凭借Authorization Grant 从Authroization Server 取得Access Token，最后，Client 向Resource Server 出示Access Token 以访问最终的资源。

　　根据Client 的不同类型，OAuth 协议定义了4 种获取Authorization Grant 的方式，分别是：

　　1.Authorization Code： 适合有服务端的Web 应用；2. Implicit： 适合于无服务端的Web 应用；3.Resource Owner Password Credentials：适合于客户端应用；4. Client Credentials：适合于Client 就是Resource Owner 的场景。

　　四种方式的具体流程这里就不一一展开，对于File API 而言，由于它是提供给应用系统用来保存系统中使用到的文件数据，可以认为应用系统就是这些数据的拥有者，因此可以采用Client Credentials的方式。而实际实现上， 我们选择了Resource Owner Password Credentials 的方式，我们将应用系统也作为用户对待，为每个应用系统建立一个应用类型的账户，应用系统使用自己的账户和密码换取Access Token，这样做的好处是更灵活，如果两个应用系统需要共享存储，或者一个应用系统需要使用多个存储，就都可以实现了。

　　通过OAuth 和File API，我们搭建了新的存储非结构化数据的体系，通过这个体系，在简化应用系统管理文件数据的同时也成功屏蔽了对底层实际存储的依赖。目前已经有多个应用系统，如新媒体网站、工作流表单系统，成功地使用了这种方式来保存文件数据，将来还有更多的应用系统使用这种方式来保存文件数据。通过File API，云存储的服务范围已经从终端用户扩展到应用系统。

　　（作者单位为上海交通大学网络信息中心）