用戶中心技術解密

最近研究了一下用戶中心的設計，寫了一個核心設計方案，與大家分享一下。

一、業務分析

由於業務的發展，出現了越來越多的系統，每個系統都有自己的用戶中心，這樣就導致了用戶在使用同一個公司的不同業務時，需要不斷的登陸系統賬號，極大的影響了用戶體驗，因此統一用戶中心就成了必不可少，其必須具有以下幾個特點：

二、方案設計

2.1 架構圖

系統入口提供了三種方式，H5登陸頁面，SDK調用，API調用

CDN層和路由層提供了數據緩存，和負載均衡的作用

業務邏輯層主要包括右邊幾大模塊

CAS+OAuth層提供統一認證服務，以及SSO服務

Cache層和DB層提供數據緩存和持久化。

所有層都支持集群化部署

以上主要是整個系統的分層結構，接下來重點介紹用戶中心的核心架構以及流程

2.2 SSO解決方案

SSO英文全稱Single Sign On，單點登錄。SSO是在多個應用系統中，用戶只需要登錄一次就可以訪問所有相互信任的應用系統。它包括可以將這次主要的登錄映射到其他應用中，用於同一個用戶的登錄的機制，這就解決了用戶跨域登陸的問題。

目前市面上最流行的SSO解決方案是由耶魯大學開發的CAS系統，具體結構和流程如下

用戶在瀏覽器中訪問應用

應用發現需要索要用戶信息，跳轉至SSO伺服器

SSO伺服器向用戶展示登錄界面，用戶進行登錄操作，SSO伺服器進行用戶

校驗後，映射出TGC

SSO伺服器向回調應用服務url，返回ST

應用去SSO伺服器校驗ST許可權及合法性

SSO伺服器校驗成功後，返回用戶信息

備註：

TGT：ticker granting ticket，用戶憑證票據，用以標記用戶憑證，用戶在單點登錄系統中登錄一次後，再其有效期內，TGT即代表用戶憑證，用戶在其它client中無需再進行二次登錄操作，即可共享單點登錄系統中的已登錄用戶信息

ST：service ticket，服務票據，服務可以理解為客戶端應用的一個業務模塊，體現為客戶端回調url，CAS用以進行服務許可權校驗，即CAS可以對接入的客戶端進行管控

TGC：ticket granting cookie，存儲用戶票據的cookie，即用戶登錄憑證最終映射的cookies

CAS基本流程如下圖。

2.3 OAuth架構

OAuth2協議，定義了一套用戶、第三方服務和存儲著用戶數據的平台之間的交互規則，可以使得用戶無需將自己的用戶名和密碼暴露給第三方，即可使第三方應用獲取用戶在該平台上的數據，最常見的場景便是現在互聯網上的各種使用XXX賬號登錄，這就解決了給第三方服務統一登陸的問題。目前最安全以及最完整的方式就是採用OAuth的授權碼模式。

它的步驟如下：

（A）用戶訪問客戶端，後者將前者導向認證伺服器。

（B）用戶選擇是否給予客戶端授權。

（C）假設用戶給予授權，認證伺服器將用戶導向客戶端事先指定的"重定向URI"（redirectionURI），同時附上一個授權碼。

（D）客戶端收到授權碼，附上早先的"重定向URI"，向認證伺服器申請令牌。這一步是在客戶端的後台的伺服器上完成的，對用戶不可見。

（E）認證伺服器核對了授權碼和重定向URI，確認無誤後，向客戶端發送訪問令牌（access token）和更新令牌（refresh token）。

以豆瓣網上用QQ賬號登陸為例，說明問題：

2.4 安全設計

所有的API介面協議設計採用標準RESTful方式提供服務，返回值均為json格式。採用的安全驗證機制就是access_token + 安全簽名演算法，access_token通過OAuth機制獲取。簽名演算法主要通過後台給第三方頒發的appsecret +appkey為基礎，簽名演算法可以根據自身安全等級規定。

本文介紹了幾個關鍵技術，希望有拋磚引玉的作用！

參考鏈接：

http://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！