?譯者 | 陳峻

審校 | 孫淑娟

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

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

了解基本身份驗證方法

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

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

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

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

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

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

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

SaaS團隊為何使用基本身份驗證方法進行集成

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

使用基本身份驗證方法在集成時需考慮的事項

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

了解API密鑰身份驗證方法

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

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

下面的代碼展示了在HTTP請求中的API密鑰示例：

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

您可能會注意到，該模式與前文用于基本身份驗證的模式，所使用的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團隊為何使用API密鑰認(rèn)證方法進行集成

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

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

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

使用API密鑰身份驗證方法在集成時需考慮的事項

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

了解OAuth 2.0方法

已被廣泛使用的??OAuth 2.0??的設(shè)置是：讓用戶在點擊應(yīng)用A的某個按鈕后，由應(yīng)用A發(fā)送請求給應(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團隊為何使用OAuth 2.0方法進行集成

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

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

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

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

使用OAuth 2.0方法在集成時需考慮的事項

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

小結(jié)

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

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

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

譯者介紹

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

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