開放 API 接口簽名驗證，讓你的接口從此不再裸奔 ！
Java技術(shù)棧
www.javastack.cn
關(guān)注閱讀更多優(yōu)質(zhì)文章
接口安全問題
請求身份是否合法？
請求參數(shù)是否被篡改？
請求是否唯一？
AccessKey&SecretKey （開放平臺）
請求身份
為開發(fā)者分配AccessKey（開發(fā)者標(biāo)識，確保唯一）和SecretKey（用于接口加密，確保不易被窮舉，生成算法不易被猜測）。
防止篡改
參數(shù)簽名
按照請求參數(shù)名的字母升序排列非空請求參數(shù)（包含AccessKey），使用URL鍵值對的格式（即key1=value1&key2=value2…）拼接成字符串stringA；
在stringA最后拼接上Secretkey得到字符串stringSignTemp；
對stringSignTemp進(jìn)行MD5運算，并將得到的字符串所有字符轉(zhuǎn)換為大寫，得到sign值。
請求攜帶參數(shù)AccessKey和Sign，只有擁有合法的身份AccessKey和正確的簽名Sign才能放行。
這樣就解決了身份驗證和參數(shù)篡改問題，即使請求參數(shù)被劫持，由于獲取不到SecretKey（僅作本地加密使用，不參與網(wǎng)絡(luò)傳輸），無法偽造合法的請求。
重放攻擊
雖然解決了請求參數(shù)被篡改的隱患，但是還存在著重復(fù)使用請求參數(shù)偽造二次請求的隱患。
timestamp+nonce方案
nonce指唯一的隨機(jī)字符串，用來標(biāo)識每個被簽名的請求。通過為每個請求提供一個唯一的標(biāo)識符，服務(wù)器能夠防止請求被多次使用（記錄所有用過的nonce以阻止它們被二次使用）。
然而，對服務(wù)器來說永久存儲所有接收到的nonce的代價是非常大的。可以使用timestamp來優(yōu)化nonce的存儲。
假設(shè)允許客戶端和服務(wù)端最多能存在15分鐘的時間差，同時追蹤記錄在服務(wù)端的nonce集合。
當(dāng)有新的請求進(jìn)入時，首先檢查攜帶的timestamp是否在15分鐘內(nèi)，如超出時間范圍，則拒絕，然后查詢攜帶的nonce，如存在已有集合，則拒絕。
否則，記錄該nonce，并刪除集合內(nèi)時間戳大于15分鐘的nonce（可以使用redis的expire，新增nonce的同時設(shè)置它的超時失效時間為15分鐘）。關(guān)于Redis系列文章干貨可以關(guān)注公眾號Java技術(shù)棧獲取閱讀。
實現(xiàn)
請求接口：http://api.test.com/test?name=hello&home=world&work=java
客戶端
生成當(dāng)前時間戳timestamp=now和唯一隨機(jī)字符串nonce=random
按照請求參數(shù)名的字母升序排列非空請求參數(shù)（包含AccessKey)
stringA="AccessKey=access&home=world&name=hello&work=java×tamp=now&nonce=random";拼接密鑰SecretKey
stringSignTemp="AccessKey=access&home=world&name=hello&work=java×tamp=now&nonce=random&SecretKey=secret";MD5并轉(zhuǎn)換為大寫
sign=MD5(stringSignTemp).toUpperCase();最終請求
http://api.test.com/test?name=hello&home=world&work=java×tamp=now&nonce=nonce&sign=sign;
服務(wù)端 
Token&AppKey（APP）
在APP開放API接口的設(shè)計中，由于大多數(shù)接口涉及到用戶的個人信息以及產(chǎn)品的敏感數(shù)據(jù)，所以要對這些接口進(jìn)行身份驗證，為了安全起見讓用戶暴露的明文密碼次數(shù)越少越好，然而客戶端與服務(wù)器的交互在請求之間是無狀態(tài)的，也就是說，當(dāng)涉及到用戶狀態(tài)時，每次請求都要帶上身份驗證信息。
Token身份驗證
安全隱患：Token被劫持，偽造請求和篡改參數(shù)?！?a target="_blank" data-itemshowtype="0" tab="innerlink" data-linktype="2">設(shè)計一個安全的對外接口》這篇也推薦閱讀一下。
Token+AppKey簽名驗證
與上面開發(fā)平臺的驗證方式類似，為客戶端分配AppKey（密鑰，用于接口加密，不參與傳輸），將AppKey和所有請求參數(shù)組合成源串，根據(jù)簽名算法生成簽名值，發(fā)送請求時將簽名值一起發(fā)送給服務(wù)器驗證。
這樣，即使Token被劫持，對方不知道AppKey和簽名算法，就無法偽造請求和篡改參數(shù)。再結(jié)合上述的重發(fā)攻擊解決方案，即使請求參數(shù)被劫持也無法偽造二次重復(fù)請求。
實現(xiàn)
登陸和退出請求
后續(xù)請求
客戶端
和上述開放平臺的客戶端行為類似，把AccessKey改為token即可。服務(wù)端
版權(quán)聲明：本文為博主原創(chuàng)文章，遵循 CC 4.0 BY-SA 版權(quán)協(xié)議，轉(zhuǎn)載請附上原文出處鏈接和本聲明。
本文鏈接：blog.csdn.net/qq_18495465/article/details/79248608
關(guān)注Java技術(shù)?？锤喔韶?/strong>
