背景：在以HTTP爲協議的REST API服務中，我們業務核心代碼固然重要，但是如何保證api的安全性也是舉足輕重的，本文將從一般接口和資源接口兩方面進行講解。
1 資源接口
資源接口，一般採用主動詢問授權的方式，例如oauth2.0來保證資源的安全，這類接口注重資源的安全，不涉及複雜的業務代碼，在認證和授權的過程中涉及到三方：
1、資源提供方：提供資源的角色，如照片，視頻等。
2、用戶：資源的擁有者
3、客戶端：要訪問服務提供方資源第三方，通常是網站，在認證過程之前，客戶端要向服務提供者申請客戶端標識。
授權過程如下：
1 用戶想操作存放在服務提供方的資源。
2 用戶登錄客戶端向服務提供方請求一個臨時令牌。
3 服務提供方驗證客戶端的身份後，授予一個臨時令牌。
4 客戶端獲得臨時令牌後，將用戶引導至服務提供方的授權頁面請求用戶授權。在這個過程中將臨時令牌和客戶端的回調連接發送給服務提供方。
5 用戶在服務提供方的網頁上輸入用戶名和密碼，然後授權該客戶端訪問所請求的資源。
6 授權成功後，服務提供方引導用戶返回客戶端的網頁。
7 客戶端根據臨時令牌從服務提供方那裏獲取訪問令牌。
8 服務提供方根據臨時令牌和用戶的授權情況授予客戶端訪問令牌。
9 客戶端使用獲取的訪問令牌訪問存放在服務提供方上的受保護的資源。
（備註：OAuth 2.0是個全新的協議，不向後兼容OAuth,但是整體架構類似)
2 業務接口
此類接口主要負責核心業務，也就是我們常規意義上的接口，主要從三個方面來保證接口的安全性：
1、身份驗證： 是否有權限訪問接口。
根據控制的力度可以分爲2種，接口的身份驗證和用戶的身份驗證，其中接口的身份認證主要是看用戶是否有訪問接口的權限，用戶身份認證則是全局的認證，一般情況下只考慮全局的認證即可，可以使用token機制。
設計： 三層token ：
1 臨時token（有效期短）
2 長期token（有效期長） ，一般在登錄的時候獲取，臨時token失效後，通過長期token獲取。
3 用戶token（做混淆，可選）
備註：不限於三層token，根據業務，安全性和效率做出平衡。
2、防止篡改：解決水平越權的問題，參數被修改後，必須重新利用加密算法，生成新的sign，否則鑑權失敗。
設計： 前後端約加密算法，採用對稱加密或者非對稱加密，生成sign：
1 前端加密算法，生成csign
2 後端採用同樣的加密算法，生成ssign
3 對比csign和ssign，相同則放行，不同則拒絕
3、接口重放：最好接口一次有效，單位時間內有效根據實際業務場景看能否接受
設計： 根據業務和控制力度分爲三種,一次有效還是單位時間內有效，還是冪等設計
1 一次有效，則可以在參數中加入時間戳，並且納入到加密參數中去，後端採用緩存記錄sign，如果存在則拒絕，不存在則放行；
2 單位時間內有效，同樣的思路加入時間戳，後端判斷時間區間範圍（由於前後端時間不一致，有誤差）
3 冪等設計的話，允許重放，不影響最終結果。（注意加上版本號）
備註：http升級爲https，也可以作爲提升安全性的手段，移動端一定要做代碼混淆，防止加密算法泄漏，web端利用cookie，session等內存操作來保證安全（內存操作相對是安全的，黑客無法獲取用戶的內存信息），最後請記住，沒有決定的安全，關鍵是你爲你的應用安全提高多少門檻。