樂猿社區,程序員的花果山程序員
在開放接口api的設計中,避免不了的就是安全性問題,由於大多數接口涉及到用戶的我的信息以及一些敏感的數據,因此對這些接口須要進行身份的認證,那麼這就須要用戶提供一些信息,好比用戶名密碼等,可是爲了安全起見讓用戶暴露的明文密碼次數越少越好,咱們通常在web項目中,大多數採用保存的session中,而後在存一份到cookie中,來保持用戶的回話有效性。可是在開放接口中,後端服務器在用戶登陸後如何去驗證和維護用戶的登錄有效性呢?web
###解決方法redis
接口的安全性主要有基於Token和Sign兩種機制展開設計,保證接口的數據不會被篡改和重複調用,下面具體來看:算法
用戶使用用戶名密碼登陸後服務器給客戶端返回一個Token(一般是UUID),並將Token-UserId以鍵值對的形式存放在緩存服務器中,並設置超時間。服務端接收到請求後進行Token驗證,若是Token不存在,說明請求無效。這種機制通常用內部系統間。後端
將Token和時間戳加上其餘請求參數就行MD5或SHA-1算法(可根據狀況加點鹽)加密,加密後的數據爲本次請求的簽名sign,並將該簽名存放到緩存服務器中並設置超時時間。服務端接收到請求後以一樣的算法獲得簽名,並跟當前的簽名進行比對,若是不同,說明參數被更改過,直接返回錯誤標識。同一個簽名只能使用一次,若是發現緩存服務器中已經存在了本次簽名,則拒絕服務。api
整個流程以下緩存
客戶端想服務器端一次發送用用戶認證信息(用戶名和密碼),服務器端請求到改請求後,驗證用戶信息是否正確。若是正確:則返回一個惟一不重複的字符串(通常爲UUID),而後在Redis(任意緩存服務器)中維護Token----Uid的用戶信息關係,以便其餘api對token的校驗。若是錯誤:則返回錯誤碼。安全
客戶端將全部的參數,包括Token和timestamp按照本身的算法進行排序加密獲得簽名sign服務器
將token、timestamp和sign做爲請求時必須攜帶的參數加在每一個請求的URL後邊(http://url/request?token=erdfasd341cdg×tamp=1512028717000&sign=ASDFDEWCRTWRE)cookie
服務端寫一個過濾器對token、timestamp和sign進行驗證
簽名機制的核心是簽名算法,經常使用的算法是將全部用戶請求的參數按照字母排序(包括timestamp,token),而後更具MD5加密(能夠加點鹽),所有大寫,生成sign簽名。固然算法越複雜,安全性相對也就越高,只道道高一尺魔高一丈,絕對的事老是不存在的。
道生一,一輩子二