：要有驗證機制（許可權控制）

：許可權/流程控制/校驗要在伺服器端做

對於網頁一般用OAuth 2.0

對於App, 一般用 Authorization Code flow

隨著資訊化程序的加快，現在的網站和APP應用很常見，對於普通使用者而言我們只能看到表現層（介面檢視層），而內部的的資料互動及處理靠的是一個個API來實現的。所謂的API是指應用程式介面，也就是將特定的業務功能封裝起來供第三方呼叫，現在的API有很多種形式，而Web API是最常見和便捷的。

既然API是提供給第三方呼叫的，這就存在一個問題：很多時候我們希望API只能由自家的產品去呼叫，防止他人呼叫，這該如何實現呢？這就得靠介面鑑權了。

正如上面所說，如果把API介面直接暴露在網際網路上是存在安全風險的，所以我們需要對API進行許可權劃分，對介面呼叫方做一個使用者鑑權，如果鑑權透過則允許此使用者進行API呼叫，反之則拒絕。

根據不同的業務場景，介面鑑權方案也有很多種，下面詳細給大家介紹。

這種機制是最為傳統的，特別是在網站中的登入模組靠的就是Cookie+Session來實現會話管理的。

1、實現原理

後臺為了標識請求是哪個客戶端發現的，會在服務端生成一個Session來儲存會話狀態，各個Session是靠具有唯一性的SessionID來標識的，SessionID儲存在客戶端的Cookie中；後續所有請求都會把Cookie傳到伺服器端，伺服器端解析Cookie後找到對應的Session進行判斷。

2、優點

技術實現方便。

3、缺點弊端

不適合分散式應用，跨平臺性差

Cookie傳輸會影響通訊效能

HTTP協議本身是無狀態的，而Cookie+Session機制硬生生的給加了狀態進去，不符合設計理念

存在安全風險：因為Cookie是儲存在客戶端的，客戶端可以隨意更改Cookie，存在偽造請求的風險

Token（令牌）是用來替代Session的新興鑑權方案，現在的Web API基本上離不開Token令牌。

1、實現原理

Token是伺服器端生成的一串加密串發放給客戶端，客戶端請求伺服器端所有資源時會帶上這個Token（透過GET/POST/Header來傳遞），由伺服器端來校驗這個Token的合法性。

2、優點

真正的無狀態，適合分散式，擴充套件性好

效能高，安全性好

3、Token的實現形式

Token令牌技術是一種技術方案統稱，具體的實現方案是有所差別的，最常見的Token種類有以下幾種：

自定義實現Token：應用開發者根據Token機制原理自行實現

JWT：Json Web Token，是一種主流的Token規範

Oauth：Oauth本質上是授權規範，其中也用到了Token

Web API是基於HTTP協議的，而HTTP協議本身就帶有認證機制。

HTTP協議的認證機制主要有兩種：

基本認證

摘要認證

但是這種機制日常很少使用，因為HTTP協議在傳輸資料過程中是明文傳輸的，所以這種認證機制本身就存在安全風險，除非配合HTTPS來實現。