?譯者 | 陳峻

審校 | 孫淑娟

在軟件開發(fā)的早期，身份驗(yàn)證（也稱認(rèn)證）作為確保只有持有正確身份標(biāo)識(shí)的用戶，才能登錄應(yīng)用的基本手段，已成為了保障系統(tǒng)和數(shù)據(jù)安全的要素之一。如今，如果您正在構(gòu)建從SaaS產(chǎn)品連接到其他應(yīng)用平臺(tái)的原生集成，那么其中最棘手的問題莫過于：如何去認(rèn)證第三方應(yīng)用。有時(shí)候，您需要為自己的應(yīng)用單獨(dú)設(shè)置身份驗(yàn)證的方式，而有時(shí)候您則需要通過配置集成，以使用對(duì)方提供的身份驗(yàn)證模式。而無論處于哪種情況，了解用戶身份驗(yàn)證的基本工作原理，無疑能夠?yàn)槟?jié)省集成或二次開發(fā)的寶貴時(shí)間。

在與客戶合作的過程中，我的團(tuán)隊(duì)曾協(xié)助SaaS團(tuán)隊(duì)使用基本的身份驗(yàn)證、API密鑰、Open Auth 2.0（也稱為OAuth 2.0）、以及OAuth 2.0的非規(guī)范變體等，實(shí)現(xiàn)了原生的應(yīng)用集成。下面，我將和您討論三種主流的身份驗(yàn)證方法的工作原理，各自優(yōu)缺點(diǎn)，權(quán)限設(shè)置的難易程度，并深入研究在原生集成過程中的各項(xiàng)細(xì)節(jié)。

了解基本身份驗(yàn)證方法

基本身份驗(yàn)證方法使用的是經(jīng)典的用戶名和密碼的組合。雖然它們?cè)诂F(xiàn)代化的SaaS應(yīng)用中已不再常見，但是我們?nèi)匀豢梢栽谠S多歷史遺留系統(tǒng)中看到此類情況，包括：FTP、或基于HTTP的某些舊式應(yīng)用。

在HTTP中，最簡單的基本認(rèn)證用例是將用戶名和密碼以 : 分割，并使用??base64??對(duì)整體進(jìn)行編碼。接著，我們將整個(gè)base-64編碼過的字符串作為HTTP請(qǐng)求的頭（請(qǐng)參見如下代碼）：

curl <https://example.com> \\
  --header "Authorization: Basic bXl1c2VyOm15UEBzU3cwUmQ="

為了確保能夠符合標(biāo)準(zhǔn)，請(qǐng)始終使用帶有Basic {base64 encoded username:password} value的頭部作為Authorization前綴。

而更簡單的方法是將用戶名和密碼直接放在URL的開頭。例如：

curl https://myuser:myP%40sSw0rd@example.com

不過，由于是在公開環(huán)境中傳輸信任憑證，而且任何人都可以讀取到，因此該方式并非良好的安全實(shí)踐，不可被用于安全性較高的集成環(huán)境中。

SaaS團(tuán)隊(duì)為何使用基本身份驗(yàn)證方法進(jìn)行集成

基本身份驗(yàn)證的原理不但十分簡單而且容易實(shí)現(xiàn)，您只需解碼base64編碼的報(bào)頭，并驗(yàn)證用戶名和密碼的組合是否正確即可。由于其簡單性，當(dāng)您不使用API或第三方集成平臺(tái)，在內(nèi)部構(gòu)建自定義集成時(shí)，基本身份驗(yàn)證方法就能及時(shí)派上用場(chǎng)。

使用基本身份驗(yàn)證方法在集成時(shí)需考慮的事項(xiàng)

雖然基本認(rèn)證方法實(shí)現(xiàn)起來很簡單，但是存在著一些缺點(diǎn)：由于每個(gè)集成都獲得了相同的信任憑據(jù)，因此我們難以限制憑據(jù)的使用范圍。也就是說，由于每個(gè)集成都可以執(zhí)行憑證所允許的所有操作，因此您無法通過更改綁定的憑據(jù)，來實(shí)現(xiàn)細(xì)粒度的授權(quán)。而如果要更改憑據(jù)，則需要讓使用它們的每個(gè)集成，都被賦予新的憑據(jù)?？梢?，這種大量手動(dòng)設(shè)置和更新憑據(jù)的方法，并不適合大規(guī)模的身份驗(yàn)證集成。

了解API密鑰身份驗(yàn)證方法

API密鑰是一種可被用于識(shí)別與身份驗(yàn)證的單個(gè)字符串。它往往適用于在引用使用API（應(yīng)用程序編程接口）集成的時(shí)候?；贏PI密鑰的身份驗(yàn)證，在現(xiàn)代化SaaS應(yīng)用中十分常見。它們也通常被稱為基于令牌的身份驗(yàn)證（token-based auth）。

為了使用API密鑰的身份驗(yàn)證方式，應(yīng)用程序需要?jiǎng)?chuàng)建一個(gè)可供集成的密鑰。通常，你可以在應(yīng)用中創(chuàng)建一個(gè)“Settings”或“Profile”的菜單。

下面的代碼展示了在HTTP請(qǐng)求中的API密鑰示例：

curl <https://example.com> \\
  --header "Authorization: Bearer mF_9.B5f-4.1JqM"

您可能會(huì)注意到，該模式與前文用于基本身份驗(yàn)證的模式，所使用的Authorization頭部非常相似，唯一區(qū)別只是在此使用的是Bearer {token}的值。

當(dāng)然，API密鑰也可以作為某些API的參數(shù)被傳入，例如：

curl <https://example.com?token=mF_9.B5f-4.1JqM>

此外，您還可以為API密鑰使用自定義的頭部，例如：

curl <https://example.com> \\
  --header "x-acme-api-key: mF_9.B5f-4.1JqM"

SaaS團(tuán)隊(duì)為何使用API密鑰認(rèn)證方法進(jìn)行集成

雖然API身份驗(yàn)證方法比基本身份驗(yàn)證方法需要更多的設(shè)置，但它們實(shí)現(xiàn)起來并不復(fù)雜。通常，應(yīng)用程序會(huì)將生成的API鍵（或者是這些鍵的哈希值）存儲(chǔ)在一張表中，并將這些鍵與相應(yīng)的用戶予以匹配。

相比基本身份驗(yàn)證，使用API密鑰的優(yōu)勢(shì)在于開發(fā)者可以設(shè)置權(quán)限（授權(quán)）的范圍。您可以將單個(gè)令牌設(shè)置為僅對(duì)特定的資源具有只讀的訪問權(quán)限，同時(shí)設(shè)置另一個(gè)令牌可通過API訪問所有的資源。由此，您可以在每次集成中使用不同的令牌，這便保證了用戶就算更改了密碼，API密鑰仍然可以映射到該用戶名上。而且，如果您的集成不再需要訪問API，那么完全可以從應(yīng)用中刪除或禁用相應(yīng)的API密鑰即可。

可以說，如果您使用的是嵌入式集成平臺(tái)（也稱為嵌入式iPaaS），那么API密鑰非常適合與此類應(yīng)用相集成。

使用API密鑰身份驗(yàn)證方法在集成時(shí)需考慮的事項(xiàng)

用戶在將API密鑰從一個(gè)應(yīng)用復(fù)制粘貼到另一個(gè)應(yīng)用程序時(shí)，可選擇手動(dòng)的方式，不過一旦處置不當(dāng)，則可能會(huì)導(dǎo)致嚴(yán)重的問題。另一方面，由于API密鑰通常不會(huì)過期，一旦有人截獲了API密鑰，它將被用來繼續(xù)進(jìn)行作惡，直至有人發(fā)現(xiàn)，并進(jìn)入源應(yīng)用禁用或刪除之。

了解OAuth 2.0方法

已被廣泛使用的??OAuth 2.0??的設(shè)置是：讓用戶在點(diǎn)擊應(yīng)用A的某個(gè)按鈕后，由應(yīng)用A發(fā)送請(qǐng)求給應(yīng)用B，詢問您是否希望與應(yīng)用A共享某些內(nèi)容（如電子郵件等）。如果您單擊按鈕同意共享數(shù)據(jù)，那么應(yīng)用A將被授予訪問應(yīng)用B的相關(guān)權(quán)限。該表述可能過于簡單了，讓我們通過下面的邏輯圖，來了解其背后的復(fù)雜工作原理：

OAuth 2.0的工作原理

SaaS團(tuán)隊(duì)為何使用OAuth 2.0方法進(jìn)行集成

OAuth 2.0的強(qiáng)大之處在于：我們很容易對(duì)帳戶的訪問、聯(lián)系人的讀/寫等特定的訪問需求限定權(quán)限（授權(quán)）。即，每個(gè)集成都可以使用不同的訪問令牌，就算用戶更改了密碼，OAuth的訪問令牌仍然有效。

同時(shí)，由于撤銷和更新令牌都比較簡單，一旦訪問令牌被某種方式截獲，就能很快被設(shè)置過期或限制使用。而且用戶很難生成新的訪問令牌。

此外，由于用戶不需要額外輸入任何憑據(jù)或API密鑰等數(shù)據(jù)，而只需要批準(zhǔn)應(yīng)用程序之間的授權(quán)請(qǐng)求，因此OAuth在用戶體驗(yàn)上更為友好。

可以說，作為更強(qiáng)大、更安全的身份驗(yàn)證方法，OAuth 2.0非常適合開發(fā)者使用嵌入式集成平臺(tái)（嵌入式iPaaS）構(gòu)建與第三方應(yīng)用程序的集成。

使用OAuth 2.0方法在集成時(shí)需考慮的事項(xiàng)

總的說來，構(gòu)建OAuth 2.0的成本比上述基本身份驗(yàn)證或API密鑰都要多。您需要通過構(gòu)建基礎(chǔ)設(shè)施，來跟蹤使用OAuth 2.0的應(yīng)用客戶端的ID與客戶密鑰。此外，應(yīng)用的API也需要?jiǎng)?chuàng)建一個(gè)回調(diào)（callback）類型的URL，將授權(quán)代碼（Authorization Code）作為輸入，并將其交換成為訪問令牌和刷新令牌（如果適用的話）。最后，您還需要通過構(gòu)建cron任務(wù)或AWS Lambda等方案，來定期刷新訪問令牌。

小結(jié)

根據(jù)上文提到的用戶體驗(yàn)和內(nèi)置的保護(hù)機(jī)制，如果您需要在自己的應(yīng)用和第三方應(yīng)用程序之間構(gòu)建自定義的內(nèi)部集成的話，那么OAuth 2.0將非常適用。而API密鑰僅能提供良好的用戶體驗(yàn)，且安全性稍遜一些?；菊J(rèn)證方法則已經(jīng)很少被大多數(shù)現(xiàn)代化SaaS應(yīng)用所采用了。

如果您使用嵌入式iPaaS，來創(chuàng)建、部署和維護(hù)與應(yīng)用程序的原生集成，那么該平臺(tái)通常會(huì)帶有許多應(yīng)用的內(nèi)置連接器，以滿足和處理大多數(shù)身份驗(yàn)證的需求，而無需額外編寫代碼。您甚至可以通過設(shè)置，讓應(yīng)用程序來創(chuàng)建API密鑰，并在客戶激活應(yīng)用集成時(shí)，利用集成的相關(guān)配置，將該密鑰提供給客戶。

可見，無論是內(nèi)部構(gòu)建集成還是使用嵌入式集成平臺(tái)，用戶身份驗(yàn)證都是安全防護(hù)中必不可少的一個(gè)重要環(huán)節(jié)。

譯者介紹

陳峻 （Julian Chen），51CTO社區(qū)編輯，具有十多年的IT項(xiàng)目實(shí)施經(jīng)驗(yàn)，善于對(duì)內(nèi)外部資源與風(fēng)險(xiǎn)實(shí)施管控，專注傳播網(wǎng)絡(luò)與信息安全知識(shí)與經(jīng)驗(yàn)；持續(xù)以博文、專題和譯文等形式，分享前沿技術(shù)與新知；經(jīng)常以線上、線下等方式，開展信息安全類培訓(xùn)與授課。

原文標(biāo)題：??The Best Authentication Methods for B2B SaaS Integrations???，作者：Bru Woodring?