?譯者 | 陳峻

審校 | 孫淑娟

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

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

了解基本身份驗證方法

基本身份驗證方法使用的是經典的用戶名和密碼的組合。雖然它們在現代化的SaaS應用中已不再常見，但是我們仍然可以在許多歷史遺留系統中看到此類情況，包括：FTP、或基于HTTP的某些舊式應用。

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

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

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

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

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

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

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

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

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

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

了解API密鑰身份驗證方法

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

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

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

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

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

當然，API密鑰也可以作為某些API的參數被傳入，例如：

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密鑰認證方法進行集成

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

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

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

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

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

了解OAuth 2.0方法

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

OAuth 2.0的工作原理

SaaS團隊為何使用OAuth 2.0方法進行集成

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

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

此外，由于用戶不需要額外輸入任何憑據或API密鑰等數據，而只需要批準應用程序之間的授權請求，因此OAuth在用戶體驗上更為友好。

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

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

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

小結

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

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

可見，無論是內部構建集成還是使用嵌入式集成平臺，用戶身份驗證都是安全防護中必不可少的一個重要環節。

譯者介紹

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

原文標題：??The Best Authentication Methods for B2B SaaS Integrations???，作者：Bru Woodring?