解密淘宝开放平台的认证授权机制（一）-InfoQ

在所有的开放平台中，安全的问题都是平台和开发者要一起面对的一个难题，尤其是对于淘宝开放平台（TaoBao Open Platform，简称TOP）这样一个电子商务的开放平台来说，保护用户的隐私数据安全和平台本身的安全显得更为重要。同时考虑到平台的开放性，以及淘宝网这种上亿级别的访问量，这就给TOP 的安全机制带来了更大的挑战。

TOP 机制主要包含两个方面，一是业务的安全，包括认证、授权等；二是系统的安全，包含流量控制、系统监控等，这里主要讨论的是前者，业务的安全，也就是对于应用的认证和授权。

要让第三方开发的应用，通过 TOP 来获取用户的数据，必须经过用户和 TOP 的双重授权。在传统的平台中，如果第三方应用需要获取用户的相关数据，需要向第三方应用提供自己的用户名和 PIN 码，如下图：

例如，在不少的 SNS 网站上，如果要获取用户的 MSN 好友信息，需要用户把自己的用户名和 PIN 码提交给这些 SNS 网站，SNS 网站作为用户的代理，向 MSN 服务端发送请求来获取用户的好友信息。虽然这些 SNS 网站一再声称不会保存用户的 PIN 码，但这种方式，天然是有着安全缺陷的。

而在各大互联网公司推出的开放平台中，上面的三角关系变成了下面这种：

用户首先在平台进行登录认证，认证通过之后，平台会颁发给用户一个 Token，用户将这个 Token 授权给第三方应用之后，第三方应用就可以使用这个 Token 来向平台获取用户的相关数据了。目前 OAuth、Facebook Connect、Flickr Auth，包括 TOP 也都是使用的这种方式。

在 TOP 中，一个第三方应用如果要获取用户数据，是需要两方面的授权的：

来自 TOP 的授权 在开发者向 TOP 申请开发一个应用的时候，TOP 会对开发者的资质进行审查，应用要申请的权限越高，对与开发者的资质要求就越高。在 TOP 中，每个应用（Application）都会对应一个或多个角色。例如对于交易类的 API，TOP 分为买家应用、卖家应用、商家应用、高级应用、专业应用等角色，普通的开发者能够比较容易的申请到买家应用和卖家应用的角色，这两种角色已经能够满足绝大多数的需要，而对于商家应用、高级应用、专业应用，则需要相对比较高的资质要求。

如果开发者声明应用只是自己使用的，就比较容易申请到比较高的权限，这样，开发者申请到的 Application 就只能通过 API 访问开发者自己的隐私数据，是无法获取其他人的隐私数据的。
来自用户的授权 在 TOP 开放的 OpenAPI 中，API 分为三类：一是公开查询类的 API，例如查询淘宝类目信息，这些 API 是不需要用户授权即可调用的；二是隐私类 API，例如上传商品，这些 API 必须要获得用户的授权才可以调用；还有一类 API，既包含用户隐私信息，又包含用户公开信息，例如查询用户信息这个 API，如果只是获取用户的公开信息字段，包括 nick、注册时间等，就不需要用户授权，而一旦要查询用户的隐私信息字段，如收货地址等，就必须获得用户的授权。

用户授权的过程就如前面所讲的，用户从 TOP 获取到 Token，然后将 Token 授予第三方应用，应用使用这个 Token 就能够调用隐私类的 API 了。这个 Token 绑定了两个方面的信息，一是用户，即使用这个 Token 只能访问被绑定用户的隐私信息，不能访问其他用户的隐私信息；二是应用，即这个 Token 只能被绑定的应用所使用，不能被其他的应用使用。这样就能保证只有真正被用户授权的应用，才能访问这个用户的隐私信息。

当然，这个 Token 是有有效期的，Token 的有效期也分为这样几类：

1）根据访问进行延迟的 Token，类似于 Session，每次应用使用这个 Token 访问一次 OpenAPI，TOP 就会将这个 Token 的有效期延迟一个固定的时间；

2）固定时限的 Token，由用户指定一个固定的过期时间，这个 Token 只能在这个有效的期限内使用；
3）一次性的 Token，使用一次即失效的 Token，即授权一次，就只能使用一次；
4）通知失效 Token，授权之后就能一直使用的 Token，直到用户通知这个 Token 失效。

对于如何获得用户的 Token，一直是开发者关注的焦点。在 TOP 中，提供了两种获取用户 Token 的方式：

URL 回调方式，对于 Web 类的应用，TOP 会要求开发者提供一个回调 URL。用户在 TOP 发起访问指定第三方应用的请求，TOP 验证用户是否已经登录，如果已经登录，则会给出一个提示性页面，告诉用户要访问的应用信息，以及可能的风险，如果用户确认继续访问，TOP 会通过这个回调 URL 将当前的上下文信息，以及用户的 Token 传递给应用，当然，传递给应用的信息中还包含一个 TOP 的签名信息，对于开发者，也有保护用户隐私信息的义务，所以开发者需要对这个签名信息进行验证，否则应用是不能通过 TOP 的上线审核的。
授权码方式，对于这种方式，存在比较多的争议，其原因是需要用户手工复制粘贴一个授权码到应用中。但是对于桌面端应用，这种方式则显得非常必要，因为用户要使用的是桌面端应用，但是唯一能够信任的淘宝登录方式，是一个网页，只能在浏览器窗口中打开，所以必须要用户从浏览器窗口获取到授权码，然后粘贴到桌面端应用中，应用得到这个授权码之后，会向 TOP 请求当前的上下文以及用户的 Token 和 TOP 的签名，这些参数的格式，和前面 URL 回调方式获得的参数的格式是一致的。

应用获取到 Token 之后，就能够通过 OpenAPI 获取相关的数据了。而在整个过程中，用户并没有把自己的口令暴露给第三方的应用，应用就能获取到用户的授权访问用户隐私数据。是不是皆大欢喜呢？

当然不是，对于某些关键操作，例如交易付款，TOP 并没有提供相应的 API，而是提供了交易付款页面，将这种页面以服务的形式提供给第三方来使用，对于这类的服务，安全性要求更高，TOP 是怎么解决的呢？且听下回分解。

给 InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。