前幾年，web開發(fā)領(lǐng)域中「前后端分離」比較火，現(xiàn)如今已逐漸成為事實(shí)標(biāo)準(zhǔn)。但是究竟什么是前后端分離？又為什么要前后端分離呢？

什么是前后端分離？為什么要前后端分離？

前后端分離，說的更多的是一種架構(gòu)上的概念。在傳統(tǒng)的web架構(gòu)中，比如經(jīng)典的MVC，會(huì)分?jǐn)?shù)據(jù)層、邏輯層、視圖層。這個(gè)視圖層即我們所說的前端了，映射到代碼層面，就是html、js、css等代碼文件。數(shù)據(jù)層和邏輯層更多的是后端部分，例如我們的 .java 、.go、.py等文件。這些文件會(huì)在一個(gè)工程中，并不會(huì)單獨(dú)的開發(fā)、測試、部署。

在前后端分離的架構(gòu)中，前端和后端是分開的，分別在不同的工程中。前端有專門的前端開發(fā)人員來進(jìn)行開發(fā)、測試，后端則有后端開發(fā)人員來進(jìn)行開發(fā)、測試，他們之間通過API來交互。

前后端分離有這么幾個(gè)好處：

1/ 解耦了前后端的工作人員 讓前端和后端分別交給更擅長的人來做，細(xì)化了工種，可以更加的專精。前端人員來關(guān)心用戶體驗(yàn)、UI設(shè)計(jì)、交互渲染；后端人員更關(guān)注業(yè)務(wù)邏輯、性能保障、安全等方面。在項(xiàng)目進(jìn)度方面，前后端可以并行開發(fā)，而互不影響，加快了整體的項(xiàng)目進(jìn)度。

2/ 解耦了前后端的代碼 后端只需提供API服務(wù)，不再與靜態(tài)文件交互。后端可以使用更復(fù)雜的分布式、微服務(wù)架構(gòu)，提供更好的性能和穩(wěn)定性保障。同時(shí)前端除了PC端之外，移動(dòng)端也可以使用相同的一套后端服務(wù)。

看到這里，前后端分離被廣泛應(yīng)用也可以理解了。

大家需要注意，并不是所有的項(xiàng)目都需要前后端分離，像是大型的項(xiàng)目，開發(fā)人員很多，人員分工明確，這種團(tuán)隊(duì)配置下，使用前后端分離可增加工作效率提高系統(tǒng)質(zhì)量。但是團(tuán)隊(duì)人員少，分工不那么明確的情況下，再采用前后端分離的架構(gòu)，只會(huì)增加開發(fā)成本和系統(tǒng)復(fù)雜度。前后端分離是一個(gè)好的架構(gòu)思路，但是需要看具體的業(yè)務(wù)和人員情況，切勿盲目的跟從。

前后端分離常用的認(rèn)證方式

前后端分離中前后端的交互是通過API進(jìn)行的，那么其中的認(rèn)證是少不了的。前后端分離中常用的認(rèn)證方式有下面幾種：

•  Session-Cookie
•  Token 驗(yàn)證
•  OAuth(開放授權(quán))

Session-Cookie 方式

Session-Cookie 方式是我們開發(fā)web應(yīng)用時(shí)最常用的認(rèn)證方式。它的認(rèn)證過程一般是這樣的：

•  1/ 用戶瀏覽器向服務(wù)器發(fā)起認(rèn)證請(qǐng)求，將用戶名和密碼發(fā)送給服務(wù)器。
•  2/ 服務(wù)器認(rèn)證用戶名和密碼，若通過則創(chuàng)建一個(gè)session對(duì)話，并將用戶信息保存到session中。session的信息可以是保存到服務(wù)器文件、共享外部存儲(chǔ)、數(shù)據(jù)庫等存儲(chǔ)中，等下次請(qǐng)求時(shí)查詢驗(yàn)證使用。
•  3/ 服務(wù)器會(huì)將該session的唯一標(biāo)識(shí)ID，返回給用戶瀏覽器，并保存在cookie中。
•  4/ 用戶請(qǐng)求其他頁面時(shí)，瀏覽器會(huì)自動(dòng)將用戶的cookie攜帶上，并發(fā)起接口請(qǐng)求，服務(wù)端收到請(qǐng)求后，從cookie解析出sessionID， 根據(jù)這個(gè)sessionID 查詢登錄后并保存好的session，若有則說明用戶已登錄，放行。

該方式是MVC架構(gòu)中最常用的認(rèn)證方案，在前后端分離中也是可以用的。幾乎所有的Web框架都默認(rèn)集成了Session-Cookie的認(rèn)證方式，而且對(duì)Session-Cookie方式的安全性和穩(wěn)定性方面都有很成熟的處理方案。

當(dāng)前端代碼使用后端web框架當(dāng)做web容器驅(qū)動(dòng)時(shí)，Session-Cookie 方案可作為首選的認(rèn)證方案。

Token 方式

Token 方式是不同系統(tǒng)交互、前后端架構(gòu)常用的認(rèn)證方式。Token 方式的認(rèn)證流程如下：

•  1/ 用戶使用用戶名和密碼登錄，將用戶名和密碼發(fā)送給服務(wù)器。
•  2/ 服務(wù)器驗(yàn)證用戶名和密碼，若正確，則簽發(fā)token，返回給用戶。
•  3/ 用戶收到token后，將其存儲(chǔ)起來，web服務(wù)一般為localStrage 或cookie。
•  4/ 用戶請(qǐng)求其他資源頁面時(shí)，會(huì)攜帶token，一般放到header 或參數(shù)中，發(fā)送給服務(wù)端。
•  5/ 服務(wù)器收到后，驗(yàn)證token，判斷用戶的正確性。

JWT(JSON Web Token)是最常用的一種Token認(rèn)證方式，已成為Token認(rèn)證的標(biāo)準(zhǔn)事實(shí)。JWT 方式將Token 分段，使其可以保持少量數(shù)據(jù)，還增加了簽名驗(yàn)證，確保了token的安全性。JWT 網(wǎng)上介紹的資料很多，這里不再贅述。不了解的，可參考下邊這些資料：

•  JSON Web Token 入門教程
•  JWT官網(wǎng)

OAuth 方式

OAuth（Open Authorization）是一個(gè)開放標(biāo)準(zhǔn)，允許用戶授權(quán)第三方網(wǎng)站訪問他們存儲(chǔ)在服務(wù)端的用戶信息。我們常見的的QQ、微信等第三方登錄便是Auth認(rèn)證方式。OAuth協(xié)議有1.0和2.0兩個(gè)版本。相比較1.0版，2.0版整個(gè)授權(quán)驗(yàn)證流程更簡單更安全，也是目前最主要的用戶身份驗(yàn)證和授權(quán)方式。

OAuth更像是一種授權(quán)機(jī)制。數(shù)據(jù)的所有者告訴系統(tǒng)，同意授權(quán)第三方應(yīng)用進(jìn)入系統(tǒng)，獲取這些數(shù)據(jù)。系統(tǒng)從而產(chǎn)生一個(gè)短期的進(jìn)入令牌（token），用來代替密碼，供第三方應(yīng)用使用。

在單純的前后端分離系統(tǒng)中，OAuth并不是常用的方式，它更多的應(yīng)用在不同系統(tǒng)之間的授權(quán)交互。

對(duì)比思考

刨去不常用的OAuth，這里對(duì)比兩種前兩種常用的認(rèn)證方式 JWT Auth 和 Session-Cookie Auth ，到底誰才是前后端分離認(rèn)證的最佳實(shí)踐呢。從下面幾個(gè)方向分析比對(duì)。

可擴(kuò)展性

Session-Cookie 是有狀態(tài)的服務(wù)，在服務(wù)端保存了session的信息。當(dāng)服務(wù)端擴(kuò)容的時(shí)候，需要考慮到session的共享問題，這個(gè)問題已有成熟的解決放方案，可使用session復(fù)制、共享、持久化等方式解決，大多數(shù)的分布式Web框架已經(jīng)集成了處理方案。JWT 驗(yàn)證方式是無狀態(tài)的服務(wù)，服務(wù)端可隨意擴(kuò)縮容。

Session-Cookie 方式基于Cookie，也就是必須是瀏覽器或支持Cookie的瀏覽器封裝的框架，純移動(dòng)端無法使用。JWT 不同，不依賴Cookie, 只要在本地可存儲(chǔ)即可。

安全性

Web開發(fā)中常見的兩個(gè)安全問題 XSS（跨站點(diǎn)腳本攻擊） 和 CRSF （跨站點(diǎn)請(qǐng)求偽造）。前者利用注入腳本到用戶認(rèn)證網(wǎng)站上，執(zhí)行惡意腳本代碼。后者則利用瀏覽器訪問后端自動(dòng)攜帶cookie的機(jī)制，來跨站偽造請(qǐng)求。XSS 只要我們對(duì)注入端，進(jìn)行過濾、轉(zhuǎn)義就能解決，CRSF 是我們重點(diǎn)關(guān)注的。

在Session-Cookie認(rèn)證方式中，因?yàn)榘裇essionID保存在了Cookie中，很容易引起CRSF攻擊。在大多數(shù)的WEB框架中有集成解決方案，如Django 的csrftoken 、Beego的xsrfToken 等。在使用Session-Cookie方案時(shí)建議開啟web框架的csrf功能。

JWT 認(rèn)證，可以把Token存放在Cookie或localstorage。建議存在localstorage，這樣就徹底避免了 CRSF 攻擊。

另外JWT有幾個(gè)安全性的問題，需要注意：

•  1/ JWT是明文編碼 JWT 的編碼是明文Base64的一個(gè)編碼，是可以反編譯的。在使用JWT傳輸信息的時(shí)候，不要放置重要敏感信息，最好使用https。
•  2/ JWT 泄露問題 解決JWT的泄露問題是一個(gè)平衡的問題。有三種處理方式由輕到重，看你業(yè)務(wù)重要性酌情選擇：
  •   將JWT 的過期時(shí)間設(shè)置的很短，即使泄露也無關(guān)緊要。
  •   在服務(wù)端設(shè)計(jì)JWT的黑名單機(jī)制，將泄露的Token 加黑名單即可。
  •   保存簽發(fā)的JWT，當(dāng)JWT泄露時(shí)，直接設(shè)置失效。

性能

Session-Cookie方案，因?yàn)楹蠖朔?wù)存儲(chǔ)了Session信息，在認(rèn)證的時(shí)候需要查詢，當(dāng)有大量認(rèn)證的時(shí)候是非常耗費(fèi)資源的。JWT 可以把信息放到token中，只需要驗(yàn)證解碼，使用簽名驗(yàn)證token即可，相對(duì)來說效率會(huì)有提升。

從上面三個(gè)方面，我們分析了Session-Cookie和JWT 方式各自的優(yōu)缺點(diǎn)，和面對(duì)問題的一些應(yīng)對(duì)方案。相信大家會(huì)有自己的心里選擇。

拋開業(yè)務(wù)場景談技術(shù)都是耍流氓。不同的業(yè)務(wù)場景，不同的架構(gòu)設(shè)計(jì)，適用的認(rèn)證方式也是不同的。這里按我自己的經(jīng)驗(yàn)總結(jié)了下，什么情況下該使用那種認(rèn)證方式，大家可參考。

適用Session-Cookie認(rèn)證方案的情況：

•  項(xiàng)目只有web端的情況；
•  項(xiàng)目人員配置少，且前后端開發(fā)都會(huì)參與；
•  項(xiàng)目前后端分離不徹底，前端使用后端web框架作為服務(wù)容器啟動(dòng)；

使用 JWT 認(rèn)證方案的情況：

•  項(xiàng)目人員配置充足，分工明確；
•  項(xiàng)目除web端外還有移動(dòng)端；
•  臨時(shí)的授權(quán)需求；
•  純后端系統(tǒng)之間的交互。

本文圍繞前后端分離這個(gè)話題總結(jié)分享了前后端分離時(shí)的認(rèn)證方案。這些僅僅是通用的一般方案，在具體的業(yè)務(wù)場景中，還有很多不典型的擴(kuò)展的驗(yàn)證方案也是極好的。