1.1 登錄驗證

1. 客戶端向服務(wù)器第一次發(fā)起登錄請求（不傳輸用戶名和密碼）。

2. 服務(wù)器利用RSA算法產(chǎn)生一對公鑰和私鑰。并保留私鑰， 將公鑰發(fā)送給客戶端。

3. 客戶端收到公鑰后， 加密用戶密碼，向服務(wù)器發(fā)送用戶名和加密后的用戶密碼； 同時另外產(chǎn)生一對公鑰和私鑰，自己保留私鑰, 向服務(wù)器發(fā)送公鑰； 于是第二次登錄請求傳輸了用戶名和加密后的密碼以及客戶端生成的公鑰。

4. 服務(wù)器利用保留的私鑰對密文進(jìn)行解密，得到真正的密碼。 經(jīng)過判斷， 確定用戶可以登錄后，生成sessionId和token， 同時利用客戶端發(fā)送的公鑰，對token進(jìn)行加密。最后將sessionId和加密后的token返還給客戶端。

5. 客戶端利用自己生成的私鑰對token密文解密， 得到真正的token。

1.2 登錄保持

? ? ? 在最原始的方案中， 登錄保持僅僅靠服務(wù)器生成的sessionId: 客戶端的請求中帶上sessionId, 如果服務(wù)器的redis中存在這個id，就認(rèn)為請求來自相應(yīng)的登錄客戶端。 但是只要sessionId被截獲， 請求就可以為偽造， 存在安全隱患。

? ? ? ?引入token后，上述問題得到解決。 服務(wù)器將token和其它的一些變量， 利用散列加密算法得到簽名后，連同sessionId一并發(fā)送給服務(wù)器； 服務(wù)器取出保存于服務(wù)器端的token,利用相同的法則生成校驗簽名， 如果客戶端簽名與服務(wù)器的校驗簽名一致， 就認(rèn)為請求來自登錄的客戶端。

1.3 TOKEN失效

用戶登錄出系統(tǒng)

失效原理：

在服務(wù)器端的redis中刪除相應(yīng)key為session的鍵值對。