從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信用卡這種近乎旁門左道的方式必然會越來越少。

而正規開放的數據分享,精細分工將成爲常態。

發佈了31 篇原創文章 · 獲贊 12 · 訪問量 14萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章