在之前的工作中，總是接觸到這些概念，之前都是零散的理解，在此總結下，以方便以後查閱
一、token
1、避免使用者多次輸入密碼
2、實現自動登陸
3、避免在終端直接儲存使用者的密碼
4、標示客戶端的請求是否合法
5、其他（暫時沒想到）
我們需要引入token機制，基於token的驗證流程一般是這樣的：
客戶端使用使用者名稱跟密碼請求登入
服務端收到請求，去驗證使用者名稱與密碼
驗證成功後，服務端會簽發乙個 token，這個token是與使用者名稱一一對應的，token一般可以儲存在快取或資料庫中，以方便後面查詢出來進行驗證。再把這個 token 傳送給客戶端
客戶端收到 token 以後可以把它儲存起來，比如放在 cookie 裡或者 local storage 裡
客戶端每次向服務端請求資源的時候需要帶著服務端簽發的 token
服務端收到請求，然後去驗證客戶端請求裡面帶著的 token，如果驗證成功，就向客戶端返回請求的資料
token存在過期時間，在token生成的時候可以打上乙個時間戳，驗證token的時候同時驗證是否過期，並告知終端。終端接收到token過期的返回後，則要求使用者重新輸入使用者名稱跟密碼，進行登入。
使用者的一些操作需要從新請求服務端下發token，如退出、修改密碼後重新登入。
二、加密解密
在客戶端與伺服器進行互動時，必然涉及到互動的報文（或者通俗的講，請求資料與返回資料），如果不希望報文進行明文傳輸，則需要進行報文的加密與解密。
所以加密的主要作用就是避免明文傳輸，就算被截獲報文，截獲方也不知道報文的具體內容。
我在平時用的比較多的加密演算法主要是對稱加密中的3des加密與非對稱加密中的rsa。對於這2個加密演算法的用法，可自行google。
三、簽名
為什麼要簽名？
1、在客戶端與伺服器進行互動時，報文雖然加密了，但我們並不能確認這個報文是誰發過來的。例如，與第三方伺服器b進行互動時，我方收到了乙個已加密的請求，但我方並不能確認是伺服器b傳送的這個報文，此時我們可以用數字簽名的方式來進行驗證。作用：認證資料**
2、如果我方收到乙個b伺服器簽名的請求，那麼b伺服器也無法否認這個請求，因為帶有它的簽名，作用：抗否認性。
3、我方收到乙個b伺服器簽名的請求，但我方並不能確認這個請求是否被篡改過（雖然報文加了密，也可能被篡改），此時即可用簽名，驗證簽名中的報文與傳過來的報文是否一致。作用：保證了資料的完整性
平時工作中用的最多的簽名演算法是：rsa。
遵循規則：公鑰加密，私鑰解密
總結：在實際開發工作中應該 先通過web filter 解密，解密後進行驗證簽名(返回資料時，過程反過來，先簽名再加密)；然後再springmvc的interceptor 中進行驗證token
簽名和加密
既然是加密，那肯定是不希望別人知道我的訊息，所以只有我才能解密，所以可得出公鑰負責加密，私鑰負責解密 同理既然是簽名，那肯定是不希望有人冒充我發訊息，只有我才能發布這個簽名，所以可得出私鑰負責簽名，公鑰負責驗證。這裡一共有 兩組四個 金鑰 a的公鑰 pub a a的私鑰 pri a b的公鑰 pub...
加密解密簽名
加密和解密 傳送方利用接收方的公鑰對要傳送的明文進行加密,接受方利用自己的 私鑰進行解密,其中公鑰和私鑰匙相對的,任何乙個作為公鑰,則另乙個 就為私鑰.但是因為非對稱加密技術的速度比較慢,所以,一般採用對稱 加密技術加密明文,然後用非對稱加密技術加密對稱金鑰,即數字信封 技術.簽名和驗證 傳送方用特...
簽名與加密
rsa加密 rsa密碼體制是一種公鑰密碼體制，加密演算法公開，以分配的金鑰作為加密解密的關鍵。一般來說，在一對公私鑰中，公鑰和私鑰都可以用來加密和解密，即公鑰加密能且只能被對應的私鑰進行解密，私鑰加密能且只能被對應的公鑰進行解密。但我們一般都用公鑰加密，私鑰解密，而且生成的私鑰往往會比公鑰蘊含了更多...