續集3
前篇文章在前面發布，同學們可以自行找一下。
本篇文章將繼續通過實例來詳細講解如何將前端代理服務器（BFF）接入身份認證。我們將使用一個示例應用來演示 BFF 與身份認證的集成過程。
3 在 Full BFF 中接入認證平臺
本小節將介紹如何在 Full BFF 中接入身份認證平臺。Full BFF 不僅接管與身份認證平臺的令牌獲取過程，還接管了后續與資源服務器打交道的過程。通過使用 Full BFF，前端也不需要保存身份認證平臺頒發的令牌了，在這種架構下，這將由 BFF 來保存。前端和 BFF 之間通過 Cookie 維持其單獨的會話。
在數字化轉型浪潮中，公司或者機構組織被迫在可維護性和安全性之間做出權衡，雖然在架構中采用原始的樸素 Naive BFF 層，在實現上最簡單，維護起來也更省心，但這犧牲了安全性，在今天的自動化社會中，這種妥協是不可接受的。所以我們需要一個更安全的解決方案，這就是 Full BFF。
許多擁有單頁應用程序、在前端使用 access_tokens 并采用微服務架構的公司，現在正努力將身份驗證轉移到服務器端。這個服務器端本質上就是 Full BFF。
我們再來回顧一個目前可能會面臨的問題，假設一家公司已經實現了一套如圖所示的無BFF 應用架構。
在這種架構中，前端應用程序直接與身份認證平臺打交道，獲取令牌，然后將令牌發送到后端服務，后端服務再將令牌發送到資源服務器，獲取資源。即：
1前端應用程序：
·運行在瀏覽器中。
·通過將未經過身份驗證的用戶轉到身份提供者來發起對用戶的驗證。
·當用戶驗證之后，前端單頁面應用程序發起令牌請求。
·前端單頁面應用將令牌隨著 Authentication 頭發送到后端服務進行 HTTP 調用。
2身份提供者：
·是 OpenID Connect 服務器。
·頒發令牌。
·驗證用戶的憑據，即用戶在此處登錄。
3API/微服務：
·通過令牌保護。典型的是只有在令牌有效時才允許訪問 API。
·API 應用一個規則來決定一個用戶是否已經被授權來訪問/查看資源。換句話說，微服務，會實施訪問控制策略。
這種架構有什么問題呢？下面來看看。
1）在前端進行令牌交換暴露了不必要的攻擊向量
在這樣的架構下，當用戶登錄時，授權碼會發送到前端。前端必須拿這個授權碼來換取令牌。
理論上沒有辦法分辨是誰在拿著授權碼換取令牌。為了確保將令牌發送給想要發送的接收方，就需要使用客戶端密鑰。但是在這個架構下，沒有使用客戶端密鑰。
2）令牌可以被盜用
由于令牌存儲在前端，理論上很容易被盜用。
由于以上架構有著這樣的問題，因此我們更推薦下面的方案。一般來說，要緩解上面提到的架構的安全風險，就需要將驗證環節轉移到服務器端。
這樣的結果就是，解決方案架構會變得更加復雜（這也是在采納該方案時需要仔細權衡的原因）。
為了能夠在服務器端驗證用戶，就需要一個能夠跟蹤用戶會話的組件，這個組件就是 Full BFF，如圖所示。
上圖的架構圖包含：
1瀏覽器端的單頁面應用。
·運行在瀏覽器端。
·和 API 處于同一個域名下。
·并不是用戶驗證的發起方。
2 BFF。
·負責托管單頁面應用資源（index.html 和/dist 目錄）。
·暴露 API。
·擁有 HTTP 會話狀態。
·是驗證用戶的發起方（將用戶重定向到身份提供者）。
3身份提供者。
·是一個 OpenID Connect 服務器。
·頒發令牌。
·驗證用戶的憑據，即用戶在此處登錄。
4API/微服務。
· 被令牌保護。一般來說，只有在令牌有效時才允許訪問 API。
·API 應用一個規則來決定一個用戶是否已經被授權來訪問/查看資源。換句話說，微服務，會實施訪問控制策略。
為什么 Full BFF 架構會更安全呢？主要有以下兩個原因：
（1）令牌交換發生在服務器端。
對于攻擊者來說，沒有任何方式觀察到 BFF 是怎么獲取到令牌的，從而極難進行干預。
同時，由于驗證過程也發生在服務器端，因此在交換令牌的過程中可以安全地包含客戶端密鑰。
這就意味著身份提供者可以驗證究竟是誰正在獲取令牌。
（2）更安全的會話管理。
如果要將令牌保存在瀏覽器端，一般就是保存在一個安全 Cookie、本地存儲或者會話存儲中。
如果攻擊者找到了辦法復制它們，就基本上劫持了會話。要防止這樣的情況，前端就需要實現所有這些機制：預防會話劫持、防止 CSRF 攻擊、防止 XSS 攻擊等。
實現會話管理最好的方式是不要自行實現。微軟（或者其他大型公司）已經為我們完成了這向工作。
工作原理分析：簡單來說，BFF 就是一個反向代理服務器。但是 Full BFF 強調它不僅將流量傳遞到下游領域服務，它還在轉發請求時添加 Authentication 頭部。
Full BFF 會處理兩種類型的請求。多數請求是由單頁面應用發起的 API 請求。BFF 處理 API 請求的流程如圖所示。
Full BFF 會將請求轉發到 API，同時將令牌添加到 Authentication 頭部。API 會驗證令牌，然后返回響應。
Full BFF 還有網站托管能力，這意味著用戶可以通過瀏覽器訪問該 BFF。當用戶瀏覽至該 BFF時，有一個特殊的端點：/login 端點。通過該端點，用戶得以驗證。驗證用戶的處理流程可以使用圖來展示。
完結啦！BFF 的發展歷程，以及每個階段的 BFF 如何接入身份認證平臺，本篇文章就已經全部講清楚了。以后還會為大家帶來喜歡的干貨文章，請多多關注哦！
本文摘自《數字身份認證技術與實踐》，獲出版社和作者授權發布。
數字身份認證技術與實踐——jd
