這是一個老話題了，當前各門戶一般也都實現了多個業務之間的單點登錄。下面根據我經歷過的項目，談一下我自己的看法。
爲什麼需要單點登錄：
產品剛上線時，一般由於用戶量少，所有的功能都放在一起，一般也不需要具體的單點登錄。隨着用戶量和業務發展的需要，要求逐步將產品按功能或性能分爲相應獨立的站點，並分開部署，這就需要在各個站點之間進行單點登錄，以達到用戶一次登錄，就可以使用多個站點。
單點登錄的實現：
簡單方法： 在同一個域內的站點，可以簡單的通過共享Cookie（將登錄用戶名存放Cookie中）來實現單點登錄。這種方法實現簡單，安全性方法可以通過將Cookie值加密方式加強，但對不同域下及不同開發語言下（如A站點C#，B站點C）實現麻煩。
推薦方法：建立統一的認證中心，認證中心提供：
1、用戶登錄認證（認證用戶名和密碼），如果成功，返回表示本次登錄的登錄Token
2、登錄Token認證（認證Token是否正確），如果成功，返回當前登錄的用戶名
3、延長Token有效期
4、退出（使Token失效)
認證中心獨立於各個站點，單點流程一般場景如下：
1、用戶在站點A輸入用戶名和密碼點擊登錄
2、站點A將用戶名和密碼轉發給認證中心進行認證，認證中心返回Token
3、站點A將當前登錄用戶和Token存入Session（或Cookie)
4、在站點A上點擊連接訪問站點B，通過URL參數方式，將Token帶給站點B
5、站點B將Token轉交到認證中心，認證正確，返回當前用戶名。
6、站點B將當前登錄用戶和Token存入Session(或Cookie)，完成登錄流程
這樣的設計下的Token，還可以用在異步使用Ajax去訪問服務器端的接口（接口可能獨立部署在不同的站點下），這樣只需要帶上Token，服務器端的接口認證Token通過後，直接返回這個登錄用戶的相應用戶信息。
安全性考慮：
1、用戶登錄認證接口，可增加認證頻率、認證IP等限制，防止暴力攻擊
2、Token其實就是一串表示本次登錄的唯一字符串，可以生成字符串時，增加摘要信息。如Token的組成爲：A+MD5(A+PWD) 的方式，A爲隨機生成的GUID，這樣在驗證Token時，就可以直接通過算法來驗證合法性，只有算法驗證通過後，再進行下一步的操作。
以上只是從整體上描述統一認證的設計，中間還有很多細節沒有描述出來，需要了解的我們可進一步討論。
下一篇，準備寫一下認證中心內部，如何實現分佈式認證系統，支持高併發、防攻擊等方面內容。
------------------------
轉發請保留出處。謝謝
呵，我的項目不是金融領域。因爲Token是有一定時效的，不過這個設計上確實如果Token在傳輸過程被截獲，就可以使用用戶身份登錄了。
這個設計在安全上的前提是用戶的信息傳輸是安全的，假設Token被截獲了，我想其它信息也同樣會被截獲，除非所有站點都使用https。
我想這樣的設計，用於一般門戶網站是可以的。