進入了SPA的世界中，這算是目前前端的趨勢。以前都沒有寫過SPA，SPA的好處在網路上寫了很多，我個人認知的就是更好的UX，使用起來更像native， 另外就是很好的前後端分離，讓後端更著重在model的部分。不過介紹SPA不是這篇文章的重點，就不多贅述。
原本是想寫Oauth在SPA的一些處理心得，但是爬一爬文章就寫了一下Session與Token-based認證的比較。
先介紹State
中文直譯就是狀態，在react裡面也有用到，代表的就是UI的狀態，譬如說isOpenNav...，而這邊所提的是HTTP的狀態，HTTP屬於stateless的協定，
簡單分類的話就是伺服器會不會記得你所做的事情，假設你在網站中修改了個人檔案的姓名發送request，然後接著修改個人檔案的大頭貼另外又發送一個request，
兩個request之間沒有任何關係，server也不會記得每個request你做了什麼，這樣就屬於一種stateless。
Session
具有狀態性(Stateful)，由於Session是你與server的連線紀錄，儲存在server端。
scalable較麻煩
試想若是後端有做loadbalance的機制，第一次進入登入頁面被導入server1，登入後Session儲存在server1，結果進入頁面後按了某個功能被導到server2，
但此server沒有你的Session就可能重新回到登入頁面，當然有一些其他的解決方案(Redis等...)
CORS問題
若是使用Session則通常你的client與server要設在同一個domain或sub domain(因為你可能要在cookie裡面傳送東西，cross domain不好處理)，
例如app.example.com的網頁，發送請求給api.example.com的server，但若是使用token-based，則可以很好的解決這個問題(因為user data會隨著http header而非cookie)
低耦合性 & Stateless
不需要將你的認證綁住server端，只要有一組token，每個server，每個api都可以使用。並且屬於無狀態性，要做scalable很容易，大家都使用統一的token。
Mobile friendly & no CSRF
在沒有cookie的地方非常好使用(如native app)，並且不使用cookie，不會有CSRF的問題發生。
效能up
簡單來說，token裡面可以夾帶user訊息(新式token如JWT)，這樣可以省去查詢DB的時間。另外Session通常記在memory中，對於大型網站的伺服器也是種負擔。
結論:與SPA一樣，現在的Token-based也是一個更主流的開發方式，可以更好的分離程式之間的關聯性，不過前端就要額外做一些事情來處理token囉，結果前端更忙了(無誤)。