首先貼一下看過的文章：
1.2.
3.4.jwt demo ：
5. 這裡面有幾篇比較好的算是官方推薦的
6. 基於timestamp和nonce的防止重放攻擊方案
公司目前的web設計都是基於http basic auth，一直覺得會有很大的安全問題，重放攻擊就很簡單實現。
引用第一篇文章的一段話：http basic auth簡單點說明就是每次請求api時都提供使用者的username和password，簡言之，basic auth是配合restful api 使用的最簡單的認證方式，只需提供使用者名稱密碼即可，但由於有把使用者名稱密碼暴露給第三方客戶端的風險，在生產環境下被使用的越來越少。因此，在開發對外開放的restful api時，盡量避免採用http basic auth。
覺得採用token的方式實現web和api的認證。 json web token 算是比較成熟的解決方案，因此採用json web token。 json web token的基本介紹請看 文章開頭的後面3個連線。
jwt解決了：
1.作為token驗證使用時解決了使用者直接輸入賬號和密碼的進行認證的問題。
2.部分資料安全傳輸的問題（例如第2個鏈結的文章，是新增關注，伺服器生成的連線，可以安全的通過郵件傳送給目標客戶，而不暴露操作使用者的相關資訊）。
作為token使用，jwt的payload需要有關於使用者資訊的字段，不然怎麼知道是哪個使用者在操作，一般不要填寫敏感資訊，如使用者密碼等，因為是通過base64編碼，是可以破解的。使用者登入和獲取token的介面是需要https加密的，否則使用者賬號和密碼是會暴露的，也就沒有什麼安全性可言了。
請求時token的上傳可以用以下方式：
1.通過cookie
2.通過http authorization head中
3.get/post方法，直接通過引數形式。
安全性：
1.首先要保證登入和獲得token的介面需要https加密
2.防止重放攻擊:目前想到的 客戶端和伺服器間有乙個共享的秘鑰，在呼叫api時需要將api的方法、引數、token做一次簽名（可用jwt）。伺服器首先驗證方法、引數、token的簽名是否正確，然後驗證token的簽名是否正確。第一次簽名時保證即使請求被劫持，劫持者也沒有辦法假冒其它請求或者修改引數，在一定程度上保證了安全性。 第二次簽名驗證主要是驗證token的有效性，驗證使用者身份。
以上步驟需要伺服器上儲存兩種秘鑰，第一種是生產token的秘鑰，這個只有伺服器程式知道。第二種秘鑰是針對每個使用介面的開發者的共享秘鑰，這個秘鑰只需要伺服器和開發者知道（開發者可以登入**，在申請使用介面時，自定義自己的共享秘鑰）。
3.共享秘鑰的儲存：共享秘鑰需要安全的儲存，不能被洩漏。
-----------------------以下拷貝自第6個鏈結------------------------------------------
以前總是通過timestamp來防止重放攻擊，但是這樣並不能保證每次請求都是一次性的。今天看到了一篇文章介紹的通過nonce（number used once）來保證一次有效，感覺兩者結合一下，就能達到乙個非常好的效果了。
重放攻擊是計算機世界黑客常用的攻擊方式之一，所謂重放攻擊就是攻擊者傳送乙個目的主機已接收過的包，來達到欺騙系統的目的，主要用於身份認證過程。
首先要明確乙個事情，重放攻擊是二次請求，黑客通過抓包獲取到了請求的http報文，然後黑客自己編寫了乙個類似的http請求，傳送給伺服器。也就是說伺服器處理了兩個請求，先處理了正常的http請求，然後又處理了黑客傳送的篡改過的http請求。
基於timestamp的方案
每次http請求，都需要加上timestamp引數，然後把timestamp和其他引數一起進行數字簽名。因為一次正常的http請求，從發出到達伺服器一般都不會超過60s，所以伺服器收到http請求之後，首先判斷時間戳引數與當前時間相比較，是否超過了60s，如果超過了則認為是非法的請求。
假如黑客通過抓包得到了我們的請求url：
其中$sign=md5($uid.$token.$stime);
// 伺服器通過uid從資料庫中可讀出token
一般情況下，黑客從抓包重放請求耗時遠遠超過了60s，所以此時請求中的stime引數已經失效了。
如果黑客修改stime引數為當前的時間戳，則sign引數對應的數字簽名就會失效，因為黑客不知道token值，沒有辦法生成新的數字簽名。
但這種方式的漏洞也是顯而易見的，如果在60s之內進行重放攻擊，那就沒辦法了，所以這種方式不能保證請求僅一次有效。
基於nonce的方案
nonce的意思是僅一次有效的隨機字串，要求每次請求時，該引數要保證不同，所以該引數一般與時間戳有關，我們這裡為了方便起見，直接使用時間戳的16進製制，實際使用時可以加上客戶端的ip位址，mac位址等資訊做個雜湊之後，作為nonce引數。
我們將每次請求的nonce引數儲存到乙個「集合」中，可以json格式儲存到資料庫或快取中。
每次處理http請求時，首先判斷該請求的nonce引數是否在該「集合」中，如果存在則認為是非法請求。
假如黑客通過抓包得到了我們的請求url：
其中$sign=md5($uid.$token.$nonce);
// 伺服器通過uid從資料庫中可讀出token
nonce引數在首次請求時，已經被儲存到了伺服器上的「集合」中，再次傳送請求會被識別並拒絕。
nonce引數作為數字簽名的一部分，是無法篡改的，因為黑客不清楚token，所以不能生成新的sign。
這種方式也有很大的問題，那就是儲存nonce引數的「集合」會越來越大，驗證nonce是否存在「集合」中的耗時會越來越長。我們不能讓nonce「集合」無限大，所以需要定期清理該「集合」，但是一旦該「集合」被清理，我們就無法驗證被清理了的nonce引數了。也就是說，假設該「集合」平均1天清理一次的話，我們抓取到的該url，雖然當時無法進行重放攻擊，但是我們還是可以每隔一天進行一次重放攻擊的。而且儲存24小時內，所有請求的「nonce」引數，也是一筆不小的開銷。
基於timestamp和nonce的方案
那我們如果同時使用timestamp和nonce引數呢？
nonce的一次性可以解決timestamp引數60s的問題，timestamp可以解決nonce引數「集合」越來越大的問題。
我們在timestamp方案的基礎上，加上nonce引數，因為timstamp引數對於超過60s的請求，都認為非法請求，所以我們只需要儲存60s的nonce引數的「集合」即可。
假如黑客通過抓包得到了我們的請求url：
其中$sign=md5($uid.$token.$stime.$nonce);
// 伺服器通過uid從資料庫中可讀出token
如果在60s內，重放該http請求，因為nonce引數已經在首次請求的時候被記錄在伺服器的nonce引數「集合」中，所以會被判斷為非法請求。超過60s之後，stime引數就會失效，此時因為黑客不清楚token的值，所以無法重新生成簽名。
綜上，我們認為一次正常的http請求傳送不會超過60s，在60s之內的重放攻擊可以由nonce引數保證，超過60s的重放攻擊可以由stime引數保證。
因為nonce引數只會在60s之內起作用，所以只需要儲存60s之內的nonce引數即可。
我們並不一定要每個60s去清理該nonce引數的集合，只需要在新的nonce到來時，判斷nonce集合最後一次修改時間，超過60s的話，就清空該集合，存放新的nonce引數集合。其實nonce引數集合可以存放的時間更久一些，但是最少是60s。
驗證流程
//判斷stime引數是否有效
if( $now - $stime > 60)
//判斷nonce引數是否在「集合」已存在
if( in_array($nonce,$noncearray) )
//驗證數字簽名
if ( $sign != md5($uid.$token.$stime.$nonce) )
//判斷是否需要清理nonce集合
if( $now - $noncearray->lastmodifytime > 60 )
//記錄本次請求的nonce引數
$noncearray.push($nonce);
//開始處理合法的請求
《PHP JWT建立API介面使用者認證token》
安裝過程 composer require firebase php jwttoken使用 當使用者登入時，如果有 token 並且沒有過期，則得到使用者資訊，如果 token過期，或者是新使用者，則生成乙個token toke生成 public function gettoken 返回結果 上面生...
CDH安全認證及使用
clourdea安全機制官網 cdh基於kerberos身份認證和基於sentry的許可權控制功能的測試 cloudera發布hadoop開源元件sentry 提供細粒度基於角色的安全控制 cdh基於kerberos身份認證和基於sentry的許可權控制功能的測試示例 基於sentry實現資料訪問許...
使用koa搭建web應用api詳解
koa 基於nodejs的web應用框架，由express的原班人馬打造，致力於提供乙個輕量級的框架，幾乎所有功能都需要第三方的中介軟體來輔助完成，使用了node的新特性，比express更簡潔，更輕量 express與koa對比 koa相對於express更加年輕，意味著express生態更加成熟...