从51信用卡到OAuth2协议



一个网站不能触碰其他网站的密码，应该说是一种常识，更不要说去保存对方的密码了。

在1999年我就曾与当时中网新空气论坛进行了用户漫游。当时还没有OAuth协议跟不要说OAuth2了。

A网站用户要漫游到B网站，当时的大致流程如下：
1.在B网站，点“用A网站用户漫游到B网站”
2.B网站将用户浏览器引导到A网站预设的授权url，
3.A网站提示用户输入用户名密码
4.用户完成后，A网站即可知道当前登录是用户C
5.A网站生成并保存一个随机的令牌A（随机字符串），并将令牌A与用户C关联
6.A网站引导用户浏览器到B网站预设漫游入口url，并附上令牌A
7.B网站拿到令牌A之后，在服务端向A网站请求预设认证url并附上令牌A
8.A网站验证令牌A有效，然后可将令牌A关联的用户C的必要信息（不包括密码）返回给B网站
9.B网站此时可以确认当前浏览器就是B网站用户C在使用，记录并设置上自己的cookie，
随后A网站用户C即可像B网站注册用户一样操作了。

基本上除了细节与OAuth2基本一致，流程看起来有些繁杂，

远不如用户向B网站提交A网站的用户密码，然后B网站再向A网站验证密码来的简单直观，

但是，但是对一个但凡有一点点常识的互联网从业人员来说，绝对无法接受这种简单直观。

所以当年在只有ASP的情形下，我们不厌其烦的使用delphi编写com组件让ASP调用来实现这一流程。

如今各大网站基本都支持OAuth2.0协议了，除了基础的用户漫游外，其主要目的就是为了共享资源，
比如一个照片存储服务商可以让用户授权一个照片打印商访问用户自己的私密相册，而无需先将自己照片下载下来然后再上传到照片打印商的网站上。

所以51信用卡面临的问题，其实已经有非常成熟的技术解决方案。
银行完全可以将自己拥有的用户资料信息整理出来，让用户自己授权给第三方网站使用。
这些信息本来就属于用户而非银行。既然银行无法更好的管理用户的信用卡账单，银行就应该允许用户授权其他能更好管理用户账单的服务商来访问账单。

那么银行为何没有提供类似OAuth2的服务呢？
一个是技术能力有限（中国银行你懂的），另一个是理念的落后。

正像有些人会认为，一个blog服务商，假如让用户可以授权第三方方便的获得他blog的列表与详细内容（无需解析HTML，而是直接提供格式化好的数据），

甚至通过第三方来发布用户blog，会损害blog服务商的利益。对于这些人只能用眼光短浅，心胸狭隘来形容。

如果某个传统银行能以开放的心态，将自己不擅长的领域开放给其他第三方，自己就可以专注于银行最擅长的业务，

对于用户而言使用该银行将获得更佳的用户体验。这难道不是一种更高层次的竞争力吗？

自己做不好也不让别人来做，无非是以前多年传统思维的惯性使然，我是老大我为何要把数据开放给你？

当然这种开放不能是无条件的，必须对接入的第三方做必要的审核。把数据给你，你却乱来怎么办？

可以预见随着互联网的深入发展，特别是随着用户自身素质的提高，51信用卡这种近乎旁门左道的方式必然会越来越少。

而正规开放的数据分享，精细分工将成为常态。