先後端分離場景下的另類登陸認證方案

在咱們平常開發中，一般會接入第三方的登陸，好比QQ、微信、微博等。在公司內部，也會介入公司的內網登陸。一般狀況下，咱們的方案是：

當應用檢測到沒有用戶信息時，就會跳轉到(302)第三方服務，用戶在第三方服務登陸後返回應用時會帶上用戶的信息(Session)，這就是通常狀況下咱們的登陸認證過程。

---

在先後端分離的場景下，通常作法是中間層(Node)檢查用戶請求的Header中是否存在用戶信息，若是不存在則向第三方服務請求認證(302)，認證成功後返回當前的登陸用戶的信息，再進行其餘業務邏輯的處理。

既然標題有另類一詞，咱們確定不能侷限於「通常作法」。在咱們的先後端分離場景中，由Node充當中間層，Java提供HTTP Restful接口，咱們場景不一樣點在於第三方服務（一般是集團登陸認證服務）不支持Node接口，只提供Java接口。因此咱們必須經過 Node去請求Java，由Java去請求認證服務而後返回Node。方案以下：

看上面流程圖，咱們的方案不過是在Node和Auth Server中增長了Java Server，並無其餘異處。只因這個方案和通常先後端分離場景的認證不太同樣，裏面的須要注意的細節較多，能夠記錄一下。

首先是用戶經過url的輸入，訪問頁面的過程，流程以下：

講解以前注意：

在咱們的場景中：

Node與Java Web的Ajax要麼帶有效cookie，要麼帶tickets(一次有效)。

咱們的頁面是 http://localhost

瀏覽器經過url訪問Node服務器(即頁面請求)，Node會檢測用戶的請求裏面是否帶有用戶信息的Cookie。若是沒有，則向Java Web發出用戶信息的請求，因爲沒有有效cookie，Java Web斷定當前用戶未登陸，返回 {code:302, url: xxx}。Node接收到302後，直接 redirect 到剛纔的url上。這個url一般是: http://www.xxx.com?redirect=http://localhost

用戶在Home(第三方登陸認證服務)完成登陸過程後，會返回咱們的localhost，而且帶有tickets: http://localhost?tickets=asdfasdfasdfasdf。

第二次，咱們又回到了頁面請求的步驟，同理Node檢測不到用戶請求中的用戶信息有效Cookie，會向Java Web出用戶信息的請求，不一樣之處在於會帶上剛纔Home返回的url上的tickets。Java Web發現請求中沒有cookie可是有tickets，因而拿着tickets去向Home認證，此tickets是否有效，有效Home會返回用戶信息，Java Web存儲此用戶信息而且返回給Node。Node拿到用戶信息後，當即往response裏面寫入用戶cookie，同時redirect到/(做用是，去掉url上的tickets)。

第三次瀏覽器向Node發出頁面請求，因爲Node檢測到請求中有cookie，就會直接返回頁面給瀏覽器。以後用戶的全部行爲操做的ajax請求，都會帶上cookie，因此都是合法的。

---

思考：

上面認證方案中，其實只須要發出兩次頁面請求，也就是訪問兩次 localhost。咱們第三次redirect的緣由是，去掉url的tickets。若是不去掉也沒有影響，可是會出現用戶手動去刷新頁面的狀況，手動刷新頁面的tickets是不可用的，java會返回403，影響用戶使用。

總結：

咱們的認證登陸方案，和傳統的方案並沒有差異，不過多了中間Node和Java的交互而已。須要注意的就是cookie的寫入時機和tickets的去除。

原創文章，歡迎轉載。轉載請註明：轉載自Fs21 ' s Home，謝謝！
原文連接地址：先後端分離場景下的另類登陸認證方案