【51CTO.com快譯】眾所周知，在不同系統的不同應用場景中，開發人員經常會用到截然不同的專有認證方法。本文將向您介紹在REST API和微服務領域中常用的四個認證方法。

身份驗證與授權的概念

在深入介紹認證方法之前，先讓我們從概念上來了解一下身份驗證與授權。

• 身份驗證是指實體證明自己的身份。換句話說，為了證明自己所聲稱的身份，請求者持有由受信任的機構所頒發的身份證明，并將作為證據提供出來。
• 授權則是一個完全不同的概念，簡單來說，授權是指實體需要證明自己有權去訪問。換句話說，為了證明自己有權提出請求，您通過持有某張工作卡，來打開工作區域中的一部分門禁，但并非全部。

綜上所述：身份驗證是要證明正確的身份;而授權則是要允許某種行為。例如：某個API雖然能夠認證您的身份，但無法授權您發出某種特定的請求。

四種常用的認證方法

理解了身份驗證的定義，下面讓我們看看在REST API中常用的四種認證方法。

HTTP基本認證方案

HTTP協議的安全認證方案包括如下：

• 基本(Basic)
• 承載(Bearer)
• 摘要(Digest)
• OAuth和其他......

HTTP的基本身份驗證是一種最直接且最簡單的方法。發件人將經過了Base64編碼的用戶名和密碼放入請求的header。其中，Base64編碼技術可將用戶名和密碼轉換為64個字符集合，以確保傳輸的安全。

由于此方法只用到了HTTP header本身，而并非cookie、會話ID、登錄頁面、以及其他專業的方案，所以它不需要通信握手、或其他復雜的響應系統。

以下是一個請求header中基本認證(Basic Auth)的示例：

Authorization: Basic bG9sOnNlY3VyZQ== 

由于固有的安全漏洞，HTTP的基本身份驗證如今已很少被建議使用了。

承載認證(也稱為令牌認證)是一種涉及到承載令牌(一種安全令牌)的HTTP認證方案。此處“承載認證”可以被理解為“允許訪問的令牌”，即：允許訪問某個資源或URL，甚至是一個加密的字符串。它通常是由服務器響應某個登錄請求而生成的。

在向受保護的資源發出請求時，客戶端必須在認證的header中發送該令牌：

Authorization: Bearer <token> 

承載認證方案最初是作為RFC-6750中OAuth 2.0的一部分被創建的。不過，有時它也會被單獨地使用到。

與基本身份驗證類似，承載身份驗證需要通過HTTPS(即SSL)來實現。

API的各種密鑰

在REST API安全中，業界廣泛地使用到了各種API密鑰。當然，此類方法仍不被視為安全措施的優秀實踐。

創建API密鑰是為了補足HTTP基本身份驗證、及其系統在認證早期所碰到的各種問題。在該方法中，系統為每個首次訪問的用戶生成并分配一個唯一值，以表示用戶已被系統所認識。因此，當用戶嘗試重新進入系統時，他們持有的唯一密鑰(有時是由其硬件的組合、IP相關的數據、以及已知服務器的時間隨機因子所生成)可用于證明他們的確與之前的注冊用戶是同一個人。

在實際應用中，許多API密鑰是被作為URL的一部分，放在查詢字符串中發送出去的。而這些敏感的密鑰信息恰恰容易被網絡中不該訪問的人所剽竊到。因此，更好的選擇是將API密鑰放在認證header中。其對應的標準示例為：

Authorization: Apikey 1234567890abcdef. 

不過，在具體實踐中，API密鑰也可能會出現在如下不同的部分中：

• 授權Header
• 基本認證
• Body數據
• 自定義Header
• 請求字符串

由于API密鑰非常簡單，因此我們可以將其作為單個標識符，運用到某些用例中。例如，我們可以通過限制某個API只具備“讀取”權限，而禁止它調用編輯、修改或刪除等安全相關的命令。

不過，由于任何請求服務的人都需要發送其密鑰，而從理論上說，該密鑰在網絡傳輸的過程中可能會被任何不安全的節點所接收到，因此這勢必存在著密鑰被暴露、甚至是被替換的風險?？梢?，您在設計REST API的相關認證機制時，需要通過安全測試，來檢查各種常見的漏洞。

OAuth(2.0)

雖然OAuth 2.0規范比起其先前的OAuth 1.0和1.0a版本要復雜得多，但是它不再需要使用keyed哈希，來簽名每一個調用了。其中，常見的OAuth實現方式會用到如下一到兩種令牌：

• 訪問令牌：就像發送API密鑰一樣，它允許應用程序訪問用戶的數據。當然，我們也可以設置訪問令牌的到期時間。
• 刷新令牌：作為OAuth流的一部分，刷新令牌會在過期時，去檢索新的訪問令牌。由于OAuth2結合了身份驗證與授權，因此它允許更為復雜的、范圍與有效性的控制。

OAuth 2.0是目前識別個人用戶帳戶、并授予適當權限的合適選擇。在該方法中，用戶在登錄某個系統時，該系統的請求用戶會以令牌的形式提供身份認證的信息。然后，用戶將此請求轉發給身份驗證服務器，該服務器進而做出拒絕或允許的判斷。接著，請求者就可以在任何時刻、僅通過令牌驗證與檢查的方式，在嚴格限制的范圍與有效期內使用目標系統了?？梢?，由于令牌可以在使用一段時間之后被撤銷，因此該機制比其他的API服務訪問控制方法來說，更加安全也更加有效。

OAuth 2.0的各種流(flows)

OAuth 2.0通過提供了幾種適用于不同類型API客戶端的流，以方便它們從授權服務器處獲取訪問令牌：

• 授權代碼：這是一種常見的流，主要服務于服務器端和移動Web應用之間。它類似于用戶使用Facebook或Google帳戶注冊到其對應的Web應用的方式。
• 隱式：這個流會要求客戶端直接檢索訪問令牌。當用戶的憑證無法被存儲在客戶端代碼中時，第三方認證機制可以輕松地訪問到它們。因此，它適用于不包含任何服務器組件的Web、桌面、以及移動應用。
• 資源所有者的密碼：它需要使用用戶名和密碼來登錄，而且信任憑證將成為請求的一部分。這個流僅適用于受信任的客戶端(例如，API提供商發布的官方應用)。
• 客戶端憑據：適用于“服務器到服務器”的身份驗證。在大多數情況下，它提供了允許用戶在客戶端應用中，指定其信任憑據的方法，因此它能夠在客戶端的控制下訪問相應的資源。

OpenID Connect

OpenID Connect是在OAuth 2.0協議之上的簡單身份層，它允許計算客戶端根據授權服務器所執行的身份認證，來驗證最終用戶的身份，并且以互動操作和類REST的方式，獲取最終​​用戶的配置文件信息。

在技​​術實現上，OpenID Connect使用了JSON作為數據格式，進而指定了RESTful HTTP API。

[[273541]]

OpenID Connect允許包括基于Web、移動、以及JavaScript客戶端在內的一系列客戶端，去請求和接收經過了身份驗證的會話、以及最終用戶的信息。該規范套件是可擴展的，能夠支持諸如：身份數據加密，OpenID Providers發現、以及會話管理等可選的功能。

OpenID Connect通過定義一套登錄流程，使得客戶端應用程序能夠對用戶進行身份驗證，并獲取有關該用戶的信息(或“聲明”)，包括：用戶名、電子郵件等。同時，用戶身份信息會在安全的JSON Web Token(JWT)中予以編碼，被稱為ID令牌。

此處的JSON Web Token是一種開放的、行業標準(RFC 7519)的方法，可用于在各方之間安全地表達各種聲明。同時，JWT允許用戶進行解碼、驗證、以及生成JWT。雖然JWT已是通用標準，但是它實際上是由API所驅動的身份驗證管理公司--Auth()所開發。

OpenID Connect定義了一種名為OpenID Connect Discovery的發現機制，其中OpenID服務器會在一個公開的URL(通常是https://server.com/openid-configuration)上發布其元數據。

此處的URL會返回包括：OpenID/OAuth端點的JSON列表、支持的范圍和聲明、用作簽名令牌的公鑰、以及其他詳細的信息。客戶端可以使用這些信息，去構建針對OpenID服務器的請求。其中用到的字段名稱和值，則在OpenID Connect Discovery 規范中已作定義。

OpenAPI的安全方案

在OpenAPI規范中，各種API安全方案事先定義好了哪些API資源是安全、它們的具體含義，以及在具體API中適合使用安全機制類型。

[[273542]]

因此，在現有的OpenAPI規范中，您可以選擇不同標準的身份驗證協議，而每一種協議都有著自己的優點與缺點。

1. 基本的API身份驗證具有如下特征：

• 易于實施，能夠支持幾乎所有類型的Web服務器。
• 需要發送經過base-64編碼的用戶名和密碼。
• 在缺少SSL時，無法被使用。
• 可以很容易地與其他安全方法進行結合使用。

注意：當沒有用到加密時，基本身份驗證會很容易受到各種劫持、以及中間人的攻擊。因此，請將該認證方法與SSL配套進行使用。

2. OAuth1.0(摘要方案)具有如下特征：

• 是一款經過了長期測試且較為流行的協議。它不但支持安全簽名，而且有著明確的定義。
• 其加密簽名包含了令牌密鑰、隨機數和其他基于請求的信息混合。
• 在使用上并不依賴于SSL。

3. OAuth2(承載令牌方案)具有如下特征：

當前的OAuth2規范消除了對于加密簽名、密碼和用戶名的需求。

OAuth2適用于被稱為流的身份驗證方案，其中包括：

• 授權代碼流。
• 隱式流。
• 資源所有者的密碼流。
• 客戶端憑據流。

4. OpenID Connect Discovery具有如下特征：

• 基于OAuth 2.0協議。
• 用到了登錄流，允許客戶端的應用程序進行用戶身份的驗證和信息的訪問。
• 用戶信息能夠通過安全的JSON Web Token(JWT)進行編碼。

最后值得一提的是RestCase開發平臺，它允許您直觀地定義上述各種安全方案，允許用戶在沒有任何編碼知識的情況下，構建和定義整體的API。

原文標題：Four Most Used REST API Authentication Methods，作者：Guy Levin

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】