魔高一丈道高一尺,開放接口安全性設計

樂猿社區,程序員的花果山程序員

問題

在開放接口api的設計中,避免不了的就是安全性問題,由於大多數接口涉及到用戶的我的信息以及一些敏感的數據,因此對這些接口須要進行身份的認證,那麼這就須要用戶提供一些信息,好比用戶名密碼等,可是爲了安全起見讓用戶暴露的明文密碼次數越少越好,咱們通常在web項目中,大多數採用保存的session中,而後在存一份到cookie中,來保持用戶的回話有效性。可是在開放接口中,後端服務器在用戶登陸後如何去驗證和維護用戶的登錄有效性呢?web

###解決方法redis

接口的安全性主要有基於Token和Sign兩種機制展開設計,保證接口的數據不會被篡改和重複調用,下面具體來看:算法

Token受權機制

用戶使用用戶名密碼登陸後服務器給客戶端返回一個Token(一般是UUID),並將Token-UserId以鍵值對的形式存放在緩存服務器中,並設置超時間。服務端接收到請求後進行Token驗證,若是Token不存在,說明請求無效。這種機制通常用內部系統間後端

簽名機制

將Token和時間戳加上其餘請求參數就行MD5或SHA-1算法(可根據狀況加點鹽)加密,加密後的數據爲本次請求的簽名sign,並將該簽名存放到緩存服務器中並設置超時時間。服務端接收到請求後以一樣的算法獲得簽名,並跟當前的簽名進行比對,若是不同,說明參數被更改過,直接返回錯誤標識。同一個簽名只能使用一次,若是發現緩存服務器中已經存在了本次簽名,則拒絕服務。api

整個流程以下緩存

  1. 客戶端想服務器端一次發送用用戶認證信息(用戶名和密碼),服務器端請求到改請求後,驗證用戶信息是否正確。若是正確:則返回一個惟一不重複的字符串(通常爲UUID),而後在Redis(任意緩存服務器)中維護Token----Uid的用戶信息關係,以便其餘api對token的校驗。若是錯誤:則返回錯誤碼。安全

  2. 客戶端將全部的參數,包括Token和timestamp按照本身的算法進行排序加密獲得簽名sign服務器

  3. 將token、timestamp和sign做爲請求時必須攜帶的參數加在每一個請求的URL後邊(http://url/request?token=erdfasd341cdg&timestamp=1512028717000&sign=ASDFDEWCRTWRE)cookie

  4. 服務端寫一個過濾器對token、timestamp和sign進行驗證

    • 判斷是否包含timestamp,token,sign參數,若是不含有返回錯誤碼。
    • 判斷服務器接到請求的時間和參數中的時間戳是否相差很長一段時間(時間自定義如半個小時,這個時間越短越安全,且最好與sign有效期一致),若是超過則說明該url已通過期(若是url被盜,他改變了時間戳,可是會致使sign簽名不相等)。
    • 判斷token是否有效,根據請求過來的token,查詢redis緩存中的uid,若是獲取不到這說明該token已過時。
    • 根據用戶請求的url參數,服務器端按照一樣的規則生成sign簽名,對比簽名看是否相等,相等則放行。
    • 此url攔截只需對獲取身份認證的url放行(如登錄url),剩餘全部的url都需攔截。

簽名機制的核心是簽名算法,經常使用的算法是將全部用戶請求的參數按照字母排序(包括timestamp,token),而後更具MD5加密(能夠加點鹽),所有大寫,生成sign簽名。固然算法越複雜,安全性相對也就越高,只道道高一尺魔高一丈,絕對的事老是不存在的。

道生一,一輩子二

相關文章
相關標籤/搜索