【51CTO.com快譯】眾所周知，在不同系統(tǒng)的不同應(yīng)用場(chǎng)景中，開發(fā)人員經(jīng)常會(huì)用到截然不同的專有認(rèn)證方法。本文將向您介紹在REST API和微服務(wù)領(lǐng)域中常用的四個(gè)認(rèn)證方法。

身份驗(yàn)證與授權(quán)的概念

在深入介紹認(rèn)證方法之前，先讓我們從概念上來(lái)了解一下身份驗(yàn)證與授權(quán)。

• 身份驗(yàn)證是指實(shí)體證明自己的身份。換句話說(shuō)，為了證明自己所聲稱的身份，請(qǐng)求者持有由受信任的機(jī)構(gòu)所頒發(fā)的身份證明，并將作為證據(jù)提供出來(lái)。
• 授權(quán)則是一個(gè)完全不同的概念，簡(jiǎn)單來(lái)說(shuō)，授權(quán)是指實(shí)體需要證明自己有權(quán)去訪問。換句話說(shuō)，為了證明自己有權(quán)提出請(qǐng)求，您通過持有某張工作卡，來(lái)打開工作區(qū)域中的一部分門禁，但并非全部。

綜上所述：身份驗(yàn)證是要證明正確的身份;而授權(quán)則是要允許某種行為。例如：某個(gè)API雖然能夠認(rèn)證您的身份，但無(wú)法授權(quán)您發(fā)出某種特定的請(qǐng)求。

四種常用的認(rèn)證方法

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

HTTP基本認(rèn)證方案

HTTP協(xié)議的安全認(rèn)證方案包括如下：

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

HTTP的基本身份驗(yàn)證是一種最直接且最簡(jiǎn)單的方法。發(fā)件人將經(jīng)過了Base64編碼的用戶名和密碼放入請(qǐng)求的header。其中，Base64編碼技術(shù)可將用戶名和密碼轉(zhuǎn)換為64個(gè)字符集合，以確保傳輸?shù)陌踩?/p>

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

以下是一個(gè)請(qǐng)求header中基本認(rèn)證(Basic Auth)的示例：

Authorization: Basic bG9sOnNlY3VyZQ== 

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

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

在向受保護(hù)的資源發(fā)出請(qǐng)求時(shí)，客戶端必須在認(rèn)證的header中發(fā)送該令牌：

Authorization: Bearer <token> 

承載認(rèn)證方案最初是作為RFC-6750中OAuth 2.0的一部分被創(chuàng)建的。不過，有時(shí)它也會(huì)被單獨(dú)地使用到。

與基本身份驗(yàn)證類似，承載身份驗(yàn)證需要通過HTTPS(即SSL)來(lái)實(shí)現(xiàn)。

API的各種密鑰

在REST API安全中，業(yè)界廣泛地使用到了各種API密鑰。當(dāng)然，此類方法仍不被視為安全措施的優(yōu)秀實(shí)踐。

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

在實(shí)際應(yīng)用中，許多API密鑰是被作為URL的一部分，放在查詢字符串中發(fā)送出去的。而這些敏感的密鑰信息恰恰容易被網(wǎng)絡(luò)中不該訪問的人所剽竊到。因此，更好的選擇是將API密鑰放在認(rèn)證header中。其對(duì)應(yīng)的標(biāo)準(zhǔn)示例為：

Authorization: Apikey 1234567890abcdef. 

不過，在具體實(shí)踐中，API密鑰也可能會(huì)出現(xiàn)在如下不同的部分中：

• 授權(quán)Header
• 基本認(rèn)證
• Body數(shù)據(jù)
• 自定義Header
• 請(qǐng)求字符串

由于API密鑰非常簡(jiǎn)單，因此我們可以將其作為單個(gè)標(biāo)識(shí)符，運(yùn)用到某些用例中。例如，我們可以通過限制某個(gè)API只具備“讀取”權(quán)限，而禁止它調(diào)用編輯、修改或刪除等安全相關(guān)的命令。

不過，由于任何請(qǐng)求服務(wù)的人都需要發(fā)送其密鑰，而從理論上說(shuō)，該密鑰在網(wǎng)絡(luò)傳輸?shù)倪^程中可能會(huì)被任何不安全的節(jié)點(diǎn)所接收到，因此這勢(shì)必存在著密鑰被暴露、甚至是被替換的風(fēng)險(xiǎn)?？梢?，您在設(shè)計(jì)REST API的相關(guān)認(rèn)證機(jī)制時(shí)，需要通過安全測(cè)試，來(lái)檢查各種常見的漏洞。

OAuth(2.0)

雖然OAuth 2.0規(guī)范比起其先前的OAuth 1.0和1.0a版本要復(fù)雜得多，但是它不再需要使用keyed哈希，來(lái)簽名每一個(gè)調(diào)用了。其中，常見的OAuth實(shí)現(xiàn)方式會(huì)用到如下一到兩種令牌：

• 訪問令牌：就像發(fā)送API密鑰一樣，它允許應(yīng)用程序訪問用戶的數(shù)據(jù)。當(dāng)然，我們也可以設(shè)置訪問令牌的到期時(shí)間。
• 刷新令牌：作為OAuth流的一部分，刷新令牌會(huì)在過期時(shí)，去檢索新的訪問令牌。由于OAuth2結(jié)合了身份驗(yàn)證與授權(quán)，因此它允許更為復(fù)雜的、范圍與有效性的控制。

OAuth 2.0是目前識(shí)別個(gè)人用戶帳戶、并授予適當(dāng)權(quán)限的合適選擇。在該方法中，用戶在登錄某個(gè)系統(tǒng)時(shí)，該系統(tǒng)的請(qǐng)求用戶會(huì)以令牌的形式提供身份認(rèn)證的信息。然后，用戶將此請(qǐng)求轉(zhuǎn)發(fā)給身份驗(yàn)證服務(wù)器，該服務(wù)器進(jìn)而做出拒絕或允許的判斷。接著，請(qǐng)求者就可以在任何時(shí)刻、僅通過令牌驗(yàn)證與檢查的方式，在嚴(yán)格限制的范圍與有效期內(nèi)使用目標(biāo)系統(tǒng)了。可見，由于令牌可以在使用一段時(shí)間之后被撤銷，因此該機(jī)制比其他的API服務(wù)訪問控制方法來(lái)說(shuō)，更加安全也更加有效。

OAuth 2.0的各種流(flows)

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

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

OpenID Connect

OpenID Connect是在OAuth 2.0協(xié)議之上的簡(jiǎn)單身份層，它允許計(jì)算客戶端根據(jù)授權(quán)服務(wù)器所執(zhí)行的身份認(rèn)證，來(lái)驗(yàn)證最終用戶的身份，并且以互動(dòng)操作和類REST的方式，獲取最終​​用戶的配置文件信息。

在技​​術(shù)實(shí)現(xiàn)上，OpenID Connect使用了JSON作為數(shù)據(jù)格式，進(jìn)而指定了RESTful HTTP API。

[[273541]]

OpenID Connect允許包括基于Web、移動(dòng)、以及JavaScript客戶端在內(nèi)的一系列客戶端，去請(qǐng)求和接收經(jīng)過了身份驗(yàn)證的會(huì)話、以及最終用戶的信息。該規(guī)范套件是可擴(kuò)展的，能夠支持諸如：身份數(shù)據(jù)加密，OpenID Providers發(fā)現(xiàn)、以及會(huì)話管理等可選的功能。

OpenID Connect通過定義一套登錄流程，使得客戶端應(yīng)用程序能夠?qū)τ脩暨M(jìn)行身份驗(yàn)證，并獲取有關(guān)該用戶的信息(或“聲明”)，包括：用戶名、電子郵件等。同時(shí)，用戶身份信息會(huì)在安全的JSON Web Token(JWT)中予以編碼，被稱為ID令牌。

此處的JSON Web Token是一種開放的、行業(yè)標(biāo)準(zhǔn)(RFC 7519)的方法，可用于在各方之間安全地表達(dá)各種聲明。同時(shí)，JWT允許用戶進(jìn)行解碼、驗(yàn)證、以及生成JWT。雖然JWT已是通用標(biāo)準(zhǔn)，但是它實(shí)際上是由API所驅(qū)動(dòng)的身份驗(yàn)證管理公司--Auth()所開發(fā)。

OpenID Connect定義了一種名為OpenID Connect Discovery的發(fā)現(xiàn)機(jī)制，其中OpenID服務(wù)器會(huì)在一個(gè)公開的URL(通常是https://server.com/openid-configuration)上發(fā)布其元數(shù)據(jù)。

此處的URL會(huì)返回包括：OpenID/OAuth端點(diǎn)的JSON列表、支持的范圍和聲明、用作簽名令牌的公鑰、以及其他詳細(xì)的信息?？蛻舳丝梢允褂眠@些信息，去構(gòu)建針對(duì)OpenID服務(wù)器的請(qǐng)求。其中用到的字段名稱和值，則在OpenID Connect Discovery 規(guī)范中已作定義。

OpenAPI的安全方案

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

[[273542]]

因此，在現(xiàn)有的OpenAPI規(guī)范中，您可以選擇不同標(biāo)準(zhǔn)的身份驗(yàn)證協(xié)議，而每一種協(xié)議都有著自己的優(yōu)點(diǎn)與缺點(diǎn)。

1. 基本的API身份驗(yàn)證具有如下特征：

• 易于實(shí)施，能夠支持幾乎所有類型的Web服務(wù)器。
• 需要發(fā)送經(jīng)過base-64編碼的用戶名和密碼。
• 在缺少SSL時(shí)，無(wú)法被使用。
• 可以很容易地與其他安全方法進(jìn)行結(jié)合使用。

注意：當(dāng)沒有用到加密時(shí)，基本身份驗(yàn)證會(huì)很容易受到各種劫持、以及中間人的攻擊。因此，請(qǐng)將該認(rèn)證方法與SSL配套進(jìn)行使用。

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

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

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

當(dāng)前的OAuth2規(guī)范消除了對(duì)于加密簽名、密碼和用戶名的需求。

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

• 授權(quán)代碼流。
• 隱式流。
• 資源所有者的密碼流。
• 客戶端憑據(jù)流。

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

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

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

原文標(biāo)題：Four Most Used REST API Authentication Methods，作者：Guy Levin

【51CTO譯稿，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文譯者和出處為51CTO.com】