token 認證的來龍去脈
前後端分離使用 token 登入解決方案
理解cookie和session機制
基於 cookie/session 的認證方案
cookie
cookie的工作原理
由於http是一種無狀態的協議，伺服器單從網路連線上無從知道客戶身份。怎麼辦呢？就給客戶端們頒發乙個通行證吧，每人乙個，無論誰訪問都必須攜帶自己通行證。這樣伺服器就能從通行證上確認客戶身份了。這就是。
cookie指的就是在瀏覽器裡面儲存的一種資料，僅僅是瀏覽器實現的一種資料儲存功能。
cookie的儲存時間，可以自己在程式中設定。如果沒有設定儲存時間，應該是一關閉瀏覽器，cookie就自動消失。
cookie實際上是一小段的文字資訊。客戶端請求伺服器，如果伺服器需要記錄該使用者狀態，就使用response向客戶端瀏覽器頒發乙個cookie。客戶端瀏覽器會把cookie儲存起來。當瀏覽器再請求該**時，瀏覽器把請求的**連同該cookie一同提交給伺服器。伺服器檢查該cookie，以此來辨認使用者狀態。伺服器還可以根據需要修改cookie的內容。
注意：cookie功能需要瀏覽器的支援。如果瀏覽器不支援cookie（如大部分手機中的瀏覽器）或者把cookie禁用了，cookie功能就會失效。不同的瀏覽器採用不同的方式儲存cookie。ie瀏覽器會以文字檔案形式儲存，乙個文字檔案儲存乙個cookie。
cookie的不可跨網域名稱性
cookie具有不可跨網域名稱性。根據cookie規範，瀏覽器訪問google只會攜帶google的cookie，而不會攜帶baidu的cookie。瀏覽器判斷乙個**是否能操作另乙個**cookie的依據是網域名稱。
session
session是另一種記錄客戶狀態的機制，不同的是cookie儲存在客戶端瀏覽器中，而session儲存在伺服器上。客戶端瀏覽器訪問伺服器的時候，伺服器把客戶端資訊以某種形式記錄在伺服器上。這就是session。客戶端瀏覽器再次訪問時只需要從該session中查詢該客戶的狀態就可以了。
如果說cookie機制是通過檢查客戶身上的「通行證」來確定客戶身份的話，那麼session機制就是通過檢查伺服器上的「客戶明細表」來確認客戶身份。
session 也是類似的道理，伺服器要知道當前發請求給自己的是誰。為了做這種區分，伺服器就要給每個客戶端分配不同的「身份標識」，然後客戶端每次向伺服器發請求的時候，都帶上這個「身份標識」，伺服器就知道這個請求來自於誰了。對於瀏覽器客戶端，大家都預設採用 cookie 的方式，儲存這個「身份標識」。
伺服器使用session把使用者的資訊臨時儲存在了伺服器上，使用者離開**後session會被銷毀。這種使用者資訊儲存方式相對cookie來說更安。
cookie與session的區別和聯絡
cookie資料存放在客戶的瀏覽器上，session資料放在伺服器上；
cookie不是很安全，別人可以分析存放在本地的cookie並進行cookie欺騙，考慮到安全應當使用session；
session會在一定時間內儲存在伺服器上。當訪問增多，會比較占用你伺服器的效能。考慮到減輕伺服器效能方面，應當使用cookie；
單個cookie在客戶端的限制是3k，就是說乙個站點在客戶端存放的cookie不能超過3k；
cookie和session的方案雖然分別屬於客戶端和服務端，但是服務端的session的實現對客戶端的cookie有依賴關係的，上面我講到服務端執行session機制時候會生成session的id值，這個id值會傳送給客戶端，客戶端每次請求都會把這個id值放到http請求的頭部傳送給服務端，而這個id值在客戶端會儲存下來，儲存的容器就是cookie，因此當我們完全禁掉瀏覽器的cookie的時候，服務端的session也會不能正常使用。
基於token的認證方式
在大多數使用web api的網際網路公司中，tokens 是多使用者下處理認證的最佳方式。
以下幾點特性會讓你在程式中使用基於token的身份驗證
1.無狀態、可擴充套件
2.支援移動裝置
3.跨程式呼叫
4.安全
token的起源
在介紹基於token的身份驗證的原理與優勢之前，不妨先看看之前的認證都是怎麼做的。
基於伺服器的驗證
我們都是知道http協議是無狀態的，這種無狀態意味著程式需要驗證每一次請求，從而辨別客戶端的身份。
在這之前，程式都是通過在服務端儲存的登入資訊來辨別請求的。這種方式一般都是通過儲存session來完成。
基於伺服器驗證方式暴露的一些問題
1.seesion：每次認證使用者發起請求時，伺服器需要去建立乙個記錄來儲存資訊。當越來越多的使用者發請求時，記憶體的開銷也會不斷增加。
2.可擴充套件性：在服務端的記憶體中使用seesion儲存登入資訊，伴隨而來的是可擴充套件性問題。
3.cors(跨域資源共享)：當我們需要讓資料跨多台移動裝置上使用時，跨域資源的共享會是乙個讓人頭疼的問題。在使用ajax抓取另乙個域的資源，就可以會出現禁止請求的情況。
在這些問題中，可擴充套件行是最突出的。因此我們有必要去尋求一種更有行之有效的方法。
基於token的驗證原理
基於token的身份驗證是無狀態的，我們不將使用者資訊存在伺服器中。這種概念解決了在服務端儲存資訊時的許多問題。nosession意味著你的程式可以根據需要去增減機器，而不用去擔心使用者是否登入。
基於token的身份驗證的過程如下:
1.使用者通過使用者名稱和密碼傳送請求。
2.伺服器端程式驗證。
3.伺服器端程式返回乙個帶簽名的token 給客戶端。
4.客戶端儲存token,並且每次訪問api都攜帶token到伺服器端的。
5.服務端驗證token，校驗成功則返回請求資料，校驗失敗則返回錯誤碼。
image
tokens的優勢
無狀態、可擴充套件
在客戶端儲存的tokens是無狀態的，並且能夠被擴充套件。基於這種無狀態和不儲存session資訊，負載負載均衡器能夠將使用者資訊從乙個服務傳到其他伺服器上。
tokens自己hold住了使用者的驗證資訊。
安全性請求中傳送token而不再是傳送cookie能夠防止csrf(跨站請求偽造)。即使在客戶端使用cookie儲存token，cookie也僅僅是乙個儲存機制而不是用於認證。不將資訊儲存在session中，讓我們少了對session操作。
token是有時效的，一段時間之後使用者需要重新驗證。
可擴充套件性
tokens能夠建立與其它程式共享許可權的程式。
多平台跨域
我們提前先來談論一下cors(跨域資源共享)，對應用程式和服務進行擴充套件的時候，需要介入各種各種的裝置和應用程式。
需要設定有效期嗎？
對於這個問題，我們不妨先看兩個例子。乙個例子是登入密碼，一般要求定期改變密碼，以防止洩漏，所以密碼是有有效期的；另乙個例子是安全證書。ssl 安全證書都有有效期，目的是為了解決吊銷的問題。所以無論是從安全的角度考慮，還是從吊銷的角度考慮，token 都需要設有效期。
那麼有效期多長合適呢？
只能說，根據系統的安全需要，盡可能的短，但也不能短得離譜
然後新問題產生了，如果使用者在正常操作的過程中，token 過期失效了，要求使用者重新登入……使用者體驗豈不是很糟糕？
一種方案，使用 refresh token，它可以避免頻繁的讀寫操作。這種方案中，服務端不需要重新整理 token 的過期時間，一旦 token 過期，就反饋給前端，前端使用 refresh token 申請乙個全新token 繼續使用。這種方案中，服務端只需要在客戶端請求更新 token 的時候對 refresh token 的有效性進行一次檢查，大大減少了更新有效期的操作，也就避免了頻繁讀寫。當然 refresh token 也是有有效期的，但是這個有效期就可以長一點了，比如，以天為單位的時間。
時序圖表示
使用 token 和 refresh token 的時序圖如下：
1）登入
image
2）業務請求
image
3）token過期，重新整理 token
image
上面的時序圖中並未提到 refresh token 過期怎麼辦。不過很顯然，refresh token 既然已經過期，就該要求使用者重新登入了。
專案中使用token總結
使用基於 token 的身份驗證方法，在服務端不需要儲存使用者的登入記錄。大概的流程是這樣的：
1.前端使用使用者名稱跟密碼請求首次登入
2.後服務端收到請求，去驗證使用者名稱與密碼是否正確
3.驗證成功後，服務端會根據使用者id、使用者名稱、定義好的秘鑰、過期時間生成乙個 token，再把這個 token 傳送給前端
4.前端收到 返回的token ，把它儲存起來，比如放在 cookie 裡或者 local storage 裡
7.服務端收到請求，然後去驗證前端請求裡面帶著的 token。沒有或者 token 過期，返回401。如果驗證成功，就向前端返回請求的資料。
8.前端得到 401 狀態碼，重定向到登入頁面。
401: 『使用者登陸狀態失效，請重新登陸。』
APP介面開發token安全之請求校驗規則
1在過濾層實現securityfilter類 在實際開發過程中傳入資料發現存在 號無法進行解密，需要進行urldecoder.decode進行解碼 if sign.indexof 1 判斷請求是否超過60秒，超過60秒則次請求鏈結失效，返回登入失敗，可根據網路情況適當延長或者縮短時間 if diff...
php介面的安全設計要素 Token,簽名,時間戳
後端以api的方式將資料來源呈現出來是目前的趨勢，可以用在前後端分離的架構中，前後端分離之後，前後端人員能夠更加專注於自己板塊的東西 也可以用在後端與後端相互呼叫中。拿到介面後，前台就可以通過鏈結獲取介面提供的資料，而返回的資料一般分為兩種情況，xml和json,在這個過程中，伺服器並不知道，請求的...
前端安全 關於token
1.將荷載payload，以及header資訊進行base64加密，形成密文payload密文，header密文。2.將形成的密文用句號鏈結起來，用服務端秘鑰進行hs256加密，生成簽名.3.將前面的兩個密文後面用句號鏈結簽名形成最終的token返回給服務端 1.使用者登入校驗，校驗成功後就返回to...