领导力大挑战
在实施Scrum项目的过程中，Scrum Master的角色是相当关键的，因为他是团队的推动者。本文围绕什么是仆人式领导、仆人式领导的起源、如何将领导力传达给团队、Scrum Master作为仆人式领导者的角色展开叙述，同时重点阐述仆人式领导者应有的基本内外特征。
文章
该内容已经被标记书签！
标记书签错误，请重试！
解密淘宝开放平台的认证授权机制（一）
作者 林涛 发布于 2009年9月29日
在所有的开放平台中，安全的问题都是平台和开发者要一起面对的一个难题，尤其是对于淘宝开放平台（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中文站用户讨论组中与我们的编辑和其他读者朋友交流。
写的真简单啊
发表人
Zhao Jeffrey
发表于
Re: 写的真简单啊
发表人
wang yazhen
发表于
Re: 写的真简单啊
发表人
Jin Wright
发表于
Re: 写的真简单啊
发表人
chan king
发表于
写的真简单啊
发表人
Deng Allen
发表于
Token到底是用来干什么的?
发表人
王 霖
发表于
个人感觉是这样的。
发表人
马 一哥
发表于
Re: 个人感觉是这样的。
发表人
李 志峰
发表于
-
感觉详细点才好。
-
能写多点吗？太少了点，没看懂.......
-
同感～
-
这种认证其实同CAS有点类似没有什么可写的
-
这点东西还要下回分解啊
-
TOP会验证第三方调用是否包含用户授权的Token,但是通过OpenAPI的消息是受Token保护的吗?
-
所谓
。在传统的平台中，如果第三方应用需要获取用户的相关数据，需要向第三方应用提供自己的用户名和PIN码
也就是 第三方代码使用 用户名 口令 模拟客户的动作 完成操作。所以是不安全。
现在的方式 就是 用户首先用 帐号 密码进行登录
登录成功以后 按照每个功能 会给你多个session key,
依靠每个session key 可以对应 你的帐号 和某个权利。
比如你用帐号 ’马一哥‘ 登录成功以后
给你3个session key
分别是
aaaa
bbbb
cccc
aaaa 就是 帐号 马一哥的 查看 余额的session key
bbbb 就是 帐号 马一哥的 查看往来账户的session key
cccc 就是 帐号 马一哥的 查看转账的session key
到底给你几个seesion key 是按照 你申请的时候 定的。
然后你把session key 给 第三方软件
它靠这个key 和 api 去淘宝 调用相应的操作。 比如你只给它aaaa key ,那么它就只能做查余额。
就这样，没什么稀奇的。 你如何将aaaa bbbb 这样的key 传给 第三方 就是那2种方法。
说白了 就是把操作分了下权限吧。 不算太大改进。 而且实际操作仍然会非常麻烦 -
通过短信方式回路可行。
8 条回复
关注此讨论 回复