這是一個老話題了，當前各門戶一般也都實現了多個業務之間的單點登錄。下面根據 我經歷過的項目，談一下我自己的看法。
為什麼需要單點登錄：
產品剛上線時，一般由於用戶量少，所有的功能都放在一起，一般也不需要具體的單 點登錄。隨著用戶量和業務發展的需要，要求逐步將產品按功能或性能分為相應獨立的站 點，並分開部署，這就需要在各個站點之間進行單點登錄，以達到用戶一次登錄，就可以 使用多個站點。
單點登錄的實現：
簡單方法： 在同一個域內的站點，可以簡單的通過共享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時 ，就可以直接通過算法來驗證合法性，只有算法驗證通過後，再進行下一步的操作。
以上只是從整體上描述統一認證的設計，中間還有很多細節沒有描述出來，需要了解 的我們可進一步討論。
下一篇，准備寫一下認證中心內部，如何實現分布式認證系統，支持高並發、防攻擊 等方面內容。
