常見 Browser-Based Authentication 心得

搭啷 現在寫好像太遲了 不過還是等到專題發表完在PO這個主題好了
網路上每天都有各式各樣的新服務冒出來 自己開發新服務也很容易了
但是使用者可不想要一堆帳號密碼 記到自己都忘記了
所以如果可以結合大家常用的帳號系統
不但讓使用者更有意願去使用你的服務 也讓使用者比較相信你的服務
因為一般人不會喜歡一直申請新帳號 也怕申請莫名網站的新帳號的安全問題

這次專題我選擇了 Google, Yahoo, Microsoft 三家的帳號來做整合
其實最近好像 OpenID 正夯,以上三家的帳號也可以當作 OpenID 來用了
但是我還是沒有選擇 OpenID ,因為對於非本科系的使用者而言,這東西可能很陌生
所以還是選擇簡單的方式來做!

我覺得這種 Browser-Based Authentication 最大的缺點就是
成功確認身份登入之後,並沒有辦法得到一些基本的使用者資訊
所以只能拿得到的 token ,再利用各家的 API 找一些可以得到資訊的服務內容
這樣才能辨別使用者的身份,但是其實我們需要的資訊可能不是這麼多
或許我們只要使用者的 ID 而已,但卻要使用者同意我們使用他們的通訊錄、郵件?
使用者看到多少會對服務感到疑惑,或是就不敢使用了,連同學都有疑問了,那其他的人呢?

這邊簡述一下三家使用上的原理和心得。
Google AuthSub & Microsoft Windows Live ID 都是使用 REST 的方式
都是在 header 中加入認證的資訊和動作
而 Yahoo! BBAuth 是使用 SOAP 的方式,回傳的 Cookie 中友物件資訊
Google 的 AuthSub 可以指定回傳 JSON 的格式,使用上方便很多
Microsoft 的部份我就沒看到可以回傳 JSON
我想可能是微軟的東西都比較走企業化,所以提供 XML 來處理吧
Yahoo 的部份因為是使用 SOAP ,物件的操作上面很直覺,也很方便

因為三種都是要再使用 API 再獲得進階的使用者資訊,所以是一樣的麻煩
如果三種裡面只選一種來結合自己的服務的話,我會推薦 Google 的 AuthSub
處理起來我覺得是比較方便,實做的程式碼也比較短,說明文件也很清楚
而且 Google 的背後還有很多的服務都有提供 API ,登入之後可以使用,資源很多!
如果考慮到一般使用者帳戶的普及度,如果是提供給台灣的服務可以考慮微軟的 因為大家都有 MSN 帳號吧!
微軟的部份也有提供多種語言的 SDK 可以使用,甚至連登入登出的連結都是直接呼叫就可以了!
不過這樣想要某種程度的緊密結合自己的服務,可能就要至少看得懂 SDK 的原始碼
因為微軟的說明文件比較少提到原理,幾乎都是教你怎麼呼叫 SDK 得到你要的結果而已
所以我在看 SDK 的原始碼就花了一些時間了

我的心得大概就是這樣而已,老師還有提到 Facebook 的部份,我自己沒碰過
不過台灣以外的地方 Facebook 也是很夯,所以想做的人可以玩玩看嘍!