本篇講Session與Token，在此之前有必要了解一下訪問應用服務器的方式。目前有兩種常用的方式訪問應用服務器：
1）通過瀏覽器直接訪問應用服務器
2）通過APP或者Web服務器訪問應用服務器
通過瀏覽器或者APP訪問應用服務器的方式我們很熟悉，那么通過Web服務器訪問應用服務器是怎么一回事呢？其實就是我們通常說的前后端分離。HTML作為一種前端資源，不在與應用服務器一塊部署，而是單獨部署到一個WebServer上，比如Nodejs。前后端分離的架構中，用戶直接訪問的是WebServer，通過WebServer去訪問應用服務器，最終拿到數據。
與這兩種方式相對應，產生了兩種處理認證的方式：Cookie-Session方式；令牌（Token）方式。如圖所示：
1）Cookie-Session方式
基於服務器Session實現的保存用戶登錄信息的方式：用戶登錄成功后，認證的信息存在服務器的Session中。用戶通過瀏覽器去請求服務的時候，每次服務器都會檢查瀏覽器的Cookie里面是否存在JSESSIONID。如果不存在JSESSIONID，那么在服務器上新建一個Session，並把新建的這個Session的id寫到瀏覽器的Cookie里面，每次用戶通過瀏覽器去發請求的時候，服務器會根據這個id找到相應的Session，取到用戶認證信息。
2）令牌（Token）方式
原理跟Cookie-Session方式類似，都是給用戶一個唯一標識，Cookie-Session方式是往瀏覽器Cookie里寫一個JSESSIONID，令牌方式是直接發給用戶一個Token，用戶每次訪問的時候帶着該令牌。應用服務器不再把用戶信息存儲在Session里，而是根據用戶每次請求帶着的令牌來判斷它是誰，它有什么權限，能干什么，令牌就是一個字符串。
通過上面的介紹，我們可以得知瀏覽器直接訪問應用服務器的時候適合使用Cookie-Session方式，因為瀏覽器默認處理了Cookie信息。其實使用APP或者前后端分離也可以使用Cookie-Session方式，理論上只要發送HTTP請求的時候能夠處理Cookie就可以，但是這樣做會出現問題：
1）開發繁瑣。
每一個APP都要自己處理Cookie，每次APP關閉再打開后，之前的Cookie數據都是空的，需要自己寫邏輯處理之前存的用戶信息。
2）安全性和客戶體驗差。
Session超時設置長JSESSIONID容易被別人盜取，不安全；設置短又會使用戶頻繁登錄，用戶體驗差。
3）有些前端技術不支持Cookie
APP和WebServer處理Cookie時雖然繁瑣，但總算支持Cookie。微信小程序不支持Cookie，無法使用Cookie-Session方式。