談談先後端分離及認證選擇

前幾年，web開發領域中「先後端分離」比較火，現現在已逐漸成爲事實標準。可是究竟什麼是先後端分離？又爲何要先後端分離呢？

什麼是先後端分離？爲何要先後端分離？

先後端分離，說的更多的是一種架構上的概念。在傳統的web架構中，好比經典的MVC，會分數據層、邏輯層、視圖層。這個視圖層即咱們所說的前端了，映射到代碼層面，就是html、js、css等代碼文件。數據層和邏輯層更多的是後端部分，例如咱們的 .java 、.go、.py等文件。這些文件會在一個工程中，並不會單獨的開發、測試、部署。

在先後端分離的架構中，前端和後端是分開的，分別在不一樣的工程中。前端有專門的前端開發人員來進行開發、測試，後端則有後端開發人員來進行開發、測試，他們之間經過API來交互。

先後端分離有這麼幾個好處：

1/ 解耦了先後端的工做人員 讓前端和後端分別交給更擅長的人來作，細化了工種，能夠更加的專精。前端人員來關心用戶體驗、UI設計、交互渲染；後端人員更關注業務邏輯、性能保障、安全等方面。在項目進度方面，先後端能夠並行開發，而互不影響，加快了總體的項目進度。

2/ 解耦了先後端的代碼 後端只需提供API服務，再也不與靜態文件交互。後端可使用更復雜的分佈式、微服務架構，提供更好的性能和穩定性保障。同時前端除了PC端以外，移動端也可使用相同的一套後端服務。

看到這裏，先後端分離被普遍應用也能夠理解了。

你們須要注意，並非全部的項目都須要先後端分離，像是大型的項目，開發人員不少，人員分工明確，這種團隊配置下，使用先後端分離可增長工做效率提升系統質量。可是團隊人員少，分工不那麼明確的狀況下，再採用先後端分離的架構，只會增長開發成本和系統複雜度。先後端分離是一個好的架構思路，可是須要看具體的業務和人員狀況，切勿盲目的跟從。

先後端分離經常使用的認證方式

先後端分離中先後端的交互是經過API進行的，那麼其中的認證是少不了的。先後端分離中經常使用的認證方式有下面幾種：

• Session-Cookie
• Token 驗證
• OAuth(開放受權)

Session-Cookie 方式

Session-Cookie 方式是咱們開發web應用時最經常使用的認證方式。它的認證過程通常是這樣的：

• 1/ 用戶瀏覽器向服務器發起認證請求，將用戶名和密碼發送給服務器。
• 2/ 服務器認證用戶名和密碼，若經過則建立一個session對話，並將用戶信息保存到session中。session的信息能夠是保存到服務器文件、共享外部存儲、數據庫等存儲中，等下次請求時查詢驗證使用。
• 3/ 服務器會將該session的惟一標識ID，返回給用戶瀏覽器，並保存在cookie中。
• 4/ 用戶請求其餘頁面時，瀏覽器會自動將用戶的cookie攜帶上，併發起接口請求，服務端收到請求後，從cookie解析出sessionID， 根據這個sessionID 查詢登陸後並保存好的session，如有則說明用戶已登陸，放行。

該方式是MVC架構中最經常使用的認證方案，在先後端分離中也是能夠用的。幾乎全部的Web框架都默認集成了Session-Cookie的認證方式，並且對Session-Cookie方式的安全性和穩定性方面都有很成熟的處理方案。

當前端代碼使用後端web框架當作web容器驅動時，Session-Cookie 方案可做爲首選的認證方案。

Token 方式

Token 方式是不一樣系統交互、先後端架構經常使用的認證方式。Token 方式的認證流程以下：

• 1/ 用戶使用用戶名和密碼登陸，將用戶名和密碼發送給服務器。
• 2/ 服務器驗證用戶名和密碼，若正確，則簽發token，返回給用戶。
• 3/ 用戶收到token後，將其存儲起來，web服務通常爲localStrage 或cookie。
• 4/ 用戶請求其餘資源頁面時，會攜帶token，通常放到header 或參數中，發送給服務端。
• 5/ 服務器收到後，驗證token，判斷用戶的正確性。

JWT(JSON Web Token)是最經常使用的一種Token認證方式，已成爲Token認證的標準事實。JWT 方式將Token 分段，使其能夠保持少許數據，還增長了簽名驗證，確保了token的安全性。JWT 網上介紹的資料不少，這裏再也不贅述。不瞭解的，可參考下邊這些資料：

• JSON Web Token 入門教程
• JWT官網

OAuth 方式

OAuth（Open Authorization）是一個開放標準，容許用戶受權第三方網站訪問他們存儲在服務端的用戶信息。咱們常見的的QQ、微信等第三方登陸即是Auth認證方式。OAuth協議有1.0和2.0兩個版本。相比較1.0版，2.0版整個受權驗證流程更簡單更安全，也是目前最主要的用戶身份驗證和受權方式。

OAuth更像是一種受權機制。數據的全部者告訴系統，贊成受權第三方應用進入系統，獲取這些數據。系統從而產生一個短時間的進入令牌（token），用來代替密碼，供第三方應用使用。

在單純的先後端分離系統中，OAuth並非經常使用的方式，它更多的應用在不一樣系統之間的受權交互。

對比思考

刨去不經常使用的OAuth，這裏對比兩種前兩種經常使用的認證方式 JWT Auth 和 Session-Cookie Auth ，到底誰纔是先後端分離認證的最佳實踐呢。從下面幾個方向分析比對。

可擴展性

Session-Cookie 是有狀態的服務，在服務端保存了session的信息。當服務端擴容的時候，須要考慮到session的共享問題，這個問題已有成熟的解決放方案，可以使用session複製、共享、持久化等方式解決，大多數的分佈式Web框架已經集成了處理方案。JWT 驗證方式是無狀態的服務，服務端可隨意擴縮容。

Session-Cookie 方式基於Cookie，也就是必須是瀏覽器或支持Cookie的瀏覽器封裝的框架，純移動端沒法使用。JWT 不一樣，不依賴Cookie, 只要在本地可存儲便可。

安全性

Web開發中常見的兩個安全問題 XSS（跨站點腳本攻擊） 和 CRSF （跨站點請求僞造）。前者利用注入腳本到用戶認證網站上，執行惡意腳本代碼。後者則利用瀏覽器訪問後端自動攜帶cookie的機制，來跨站僞造請求。XSS 只要咱們對注入端，進行過濾、轉義就能解決，CRSF 是咱們重點關注的。

在Session-Cookie認證方式中，由於把SessionID保存在了Cookie中，很容易引發CRSF攻擊。在大多數的WEB框架中有集成解決方案，如Django 的csrftoken 、Beego的xsrfToken 等。在使用Session-Cookie方案時建議開啓web框架的csrf功能。

JWT 認證，能夠把Token存放在Cookie或localstorage。建議存在localstorage，這樣就完全避免了 CRSF 攻擊。

另外JWT有幾個安全性的問題，須要注意：

• 1/ JWT是明文編碼 JWT 的編碼是明文Base64的一個編碼，是能夠反編譯的。在使用JWT傳輸信息的時候，不要放置重要敏感信息，最好使用https。

• 2/ JWT 泄露問題 解決JWT的泄露問題是一個平衡的問題。有三種處理方式由輕到重，看你業務重要性酌情選擇：

  • 將JWT 的過時時間設置的很短，即便泄露也可有可無。
  • 在服務端設計JWT的黑名單機制，將泄露的Token 加黑名單便可。
  • 保存簽發的JWT，當JWT泄露時，直接設置失效。

性能

Session-Cookie方案，由於後端服務存儲了Session信息，在認證的時候須要查詢，當有大量認證的時候是很是耗費資源的。JWT 能夠把信息放到token中，只須要驗證解碼，使用簽名驗證token便可，相對來講效率會有提高。

從上面三個方面，咱們分析了Session-Cookie和JWT 方式各自的優缺點，和麪對問題的一些應對方案。相信你們會有本身的內心選擇。

拋開業務場景談技術都是耍流氓。不一樣的業務場景，不一樣的架構設計，適用的認證方式也是不一樣的。這裏按我本身的經驗總結了下，什麼狀況下該使用那種認證方式，你們可參考。

適用Session-Cookie認證方案的狀況：

• 項目只有web端的狀況；
• 項目人員配置少，且先後端開發都會參與；
• 項目先後端分離不完全，前端使用後端web框架做爲服務容器啓動；

使用 JWT 認證方案的狀況：

• 項目人員配置充足，分工明確；
• 項目除web端外還有移動端；
• 臨時的受權需求；
• 純後端系統之間的交互。

本文圍繞先後端分離這個話題總結分享了先後端分離時的認證方案。這些僅僅是通用的通常方案，在具體的業務場景中，還有不少不典型的擴展的驗證方案也是極好的，歡迎你們留言討論本身心中的最佳認證方案。

參考及擴展閱讀

• 傻傻分不清之 Cookie、Session、Token、JWT
• 四種認證方式
• JWT簡介
• JWT勿用
• （譯）別再使用 JWT 做爲 Session 系統！問題重重且很危險。
• OAuth 2.0 的一個簡單解釋
• OAuth 2.0 的四種方式