在談這個問題之前，我們先來說說在webapi中保障介面請求合法性的常見辦法：
當然還有很多其它的，比如 openid connect （oauth 2.0協議之上的簡單身份層），basic auth ，digest auth 不一一例舉了
1、api key + api secret
resource + api key + api secret 匹配正確後，才可以訪問resource，通常還會配合時間戳來進行時效控制。這種鑑權方式有以下特點：
1）api key / api secret這種模式本質不是rbac，而是做的acl訪問許可權控制用的。
2）伺服器負責為每個客戶端生成一對 key/secret （ key/secret 沒有任何關係，不能相互推算），儲存，並告知客戶端。
3）一般是把所有的請求引數（api key也放在請求引數內）排序後和api secret做hash生成乙個簽名sign引數，伺服器後台只需要按照規則做一次簽名計算，然後和請求的簽名做比較，如果相等驗證通過，不相等就不通過。
4）為避免重放攻擊，可加上 timestamp 引數，指明客戶端呼叫的時間。服務端在驗證請求時若 timestamp 超過允許誤差則直接返回錯誤。
5）一般來說每乙個api使用者都需要分配一對api key / api secret的，比如你有幾百萬的使用者，那麼需要幾百萬個金鑰對的，資料量不大時一般存在xml中，資料量大時可以存在mysql表中。
優點：1）實現簡單。
2）占用計算資源和網路資源都很少。
3）安全性較好。
缺點：1）當api key / api secret足夠多時，服務端有一定的儲存成本
2）鑑權本身不能承載其它的資訊，服務端只能通過api key來區別呼叫者。
3）api secret一旦洩密，將是致命的。
適用範圍：
事實上，這種模式適用於大多數的webapi，除非你需要在token中承載更多的資訊，或者你的api key / api secret足夠多，多到能影響你服務端的佈署。
2、cookie-session認證
這是比較老牌的鑑權方式了，這種鑑權方式有以下特點：
1）為了使後台應用能識別是哪個使用者發出的請求，只能在後台伺服器儲存乙份使用者登陸資訊，這份資訊也會在響應前端請求時返回給瀏覽器（前端），前端將其儲存為cookie。
2）下次請求時前端傳送給後端應用，後端應用就可以識別這個請求是來自哪個使用者了。
3）cookie內僅包含乙個session識別符號而諸如使用者資訊、授權列表等都儲存在服務端的session中。
優點：1）老牌，資料多，語言支援完善。
2）較易於擴充套件，外部session儲存方案已經非常成熟了（比如redis）。
缺點：1）效能相於較低：每乙個使用者經過後端應用認證之後，後端應用都要在服務端做一次記錄，以方便使用者下次請求的鑑別，通常而言session都是儲存在記憶體中，而隨著認證使用者的增多，服務端的開銷會明顯增大。
2）與rest風格不匹配。因為它在乙個無狀態協議裡注入了狀態。
3）csrf攻擊：因為基於cookie來進行使用者識別, cookie如果被截獲，使用者就會很容易受到跨站請求偽造的攻擊。有興趣可以看下 。
4）很難跨平台：在移動應用上 session 和 cookie 很難行通，你無法與移動終端共享伺服器建立的 session 和 cookie。
適用範圍：
傳統的web**，且同時認證的人數不是足夠大（是足夠大）的都可以用這種方式，事實上，這種方式現在依舊在很各大**平台上活躍著。
3、oauth
oauth協議為使用者資源的授權提供了乙個安全的、開放而又簡易的標準。與以往的授權方式不同之處是oauth的授權不會使第三方觸及到使用者的帳號資訊（如使用者名稱與密碼），即第三方無需使用使用者的使用者名稱與密碼就可以申請獲得該使用者資源的授權，因此oauth是安全的。oauth是open authorization的簡寫。這種鑑權方式有以下特點：
1）oauth在"客戶端"與"服務提供商"之間，設定了乙個授權層（authorization layer）。
2）"客戶端"不能直接登入"服務提供商"，只能登入授權層，以此將使用者與客戶端區分開來。
3）"客戶端"登入授權層所用的令牌（token），與使用者的密碼不同。使用者可以在登入的時候，指定授權層令牌的許可權範圍和有效期。
4）"客戶端"登入授權層以後，"服務提供商"根據令牌的許可權範圍和有效期，向"客戶端"開放使用者儲存的資料。
優點：1）簡單：不管是 oauth 服務提供者還是應用開發者，都很容易於理解與使用。
2）安全：沒有涉及到使用者金鑰等資訊，更安全更靈活。
3）開放：任何服務提供商都可以實現 oauth ，任何軟體開發商都可以使用 oauth 。
缺點：1）需要增加授權伺服器。
2）token載體資訊單一，不利於服務端對呼叫者的統計等操作。
適用範圍：
常用於使用者的授權，如使用qq在其它**上快速登入。很明顯沒有第三方參與的場景是不適合用 oauth 的，這種情況可以使用api key + api secret或jwt。
關於oauth的詳細介紹，可以看大牛的文章 《
理解oauth 2.0》
4、jwt
這種鑑權方式有以下特點：
1）jwt常常被用作保護服務端的資源（resource）。
2）客戶端通常將jwt通過http的authorization header傳送給服務端。
3）服務端使用自己儲存的key計算、驗證簽名以判斷該jwt是否可信。
4）在web應用中，別再把jwt當做session使用，絕大多數情況下，傳統的cookie-session機制工作得更好。
4）jwt適合一次性的命令認證，頒發乙個有效期極短的jwt，即使暴露了危險也很小
5）由於每次操作都會生成新的jwt，因此也沒必要儲存jwt，真正實現無狀態。
優點：1）易於水平擴充套件（當訪問量足夠在時，相對於cookie-session方案而言的。如果把session中的認證資訊都儲存在jwt中，在服務端就沒有session存在的必要了。當服務端水平擴充套件的時候，就不用處理session複製（session replication）/ session黏連（sticky session）或是引入外部session儲存了）
2）無狀態。
3）支援移動裝置。
4）跨程式呼叫。
5）安全。
6）token的承載的資訊很豐富。
事實上，所有使用token的模式，都是無狀態、跨程式呼叫的。
缺點：1）如果jwt中的payload的資訊過多，網路資源占用較多。
2）jwt 的過期和重新整理處理起來較麻煩。這個可以參考業界主流做法，aws、azure 和 auth0 都是用 jwt 為載體，id token + access token + refresh token 的模式：
適用範圍：
jwt（其實還有saml）最適合的應用場景就是「開票」，或者「簽字」。
例如：員工張三需要請假一天，於是填寫請假條，張三在獲得其主管部門領導簽字後，將請假交給hr部門李四，李四確認領導簽字無誤後，將請假條收回，並在公司考勤表中做相應記錄。這樣張三就可以得到一天的假期，去浪。
在以上的例子中，「請假條」就是jwt中的payload（載荷就是存放有效資訊的地方），領導簽字就是base64後的數字簽名（signature），領導是iss（issuer / jwt簽發者），「hr部門的李四」即為jwt的aud（audience / 接收jwt的一方），aud需要驗證領導簽名是否合法，驗證合法後根據payload中請求的資源給予相應的許可權，同時將jwt收回。
總結
不要單純的為了用某種鑑權方式而去強行使用，可以根據實際需要進行修改、擴充套件，或者是幾個模式進行組合。總之，沒有最好的，只有最適合的。
webapi鑑權使用token令牌
一為什麼使用token驗證 證，那麼這就需要使用者提供一些資訊，比如使用者名稱密碼等，但是為了安全起見讓使用者暴露的明文密碼次數越少越好，我們一般在web專案中，大多數採用保 它的使用者資料儲存在本地，可以實現免登陸等，只在它拿資料的時候 提交認證資訊就行了 二什麼場景使用token驗證 現在很多基...
前後端常見的幾種鑑權方式
目前我們常用的鑑權有四種 token 驗證 oauth 開放授權 一.http basic authentication 這種授權方式是瀏覽器遵守http協議實現的基本授權方式,http協議進行通訊的過程中，http協議定義了基本認證認證允許http伺服器對客戶端進行使用者身份證的方法。認證過程 1...
前後端常見的幾種鑑權方式
每個專案產品都要加埋點，加500行埋點是不是會占用你一兩天的時間而且很容易犯錯,想只用一小時準確加完這500行埋點剩下一天喝茶聊天麼？來試試這520工具,高效加埋點，目前我們公司100號前端都在用，因為很好用，所以很自然普及開來了，推薦給大家吧 目前我們常用的鑑權有四種 token 驗證 oauth...