B2B SaaS集成的最佳認(rèn)證方法

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

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

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

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

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

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

　　而更簡(jiǎn)單的方法是將用戶(hù)名和密碼直接放在URL的開(kāi)頭。例如：

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

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

　　基本身份驗(yàn)證的原理不但十分簡(jiǎn)單而且容易實(shí)現(xiàn)，您只需解碼base64編碼的報(bào)頭，并驗(yàn)證用戶(hù)名和密碼的組合是否正確即可。由于其簡(jiǎ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)起來(lái)很簡(jiǎn)單，但是存在著一些缺點(diǎn)：由于每個(gè)集成都獲得了相同的信任憑據(jù)，因此我們難以限制憑據(jù)的使用范圍。也就是說(shuō)，由于每個(gè)集成都可以執(zhí)行憑證所允許的所有操作，因此您無(wú)法通過(guò)更改綁定的憑據(jù)，來(lái)實(shí)現(xiàn)細(xì)粒度的授權(quán)。而如果要更改憑據(jù)，則需要讓使用它們的每個(gè)集成，都被賦予新的憑據(jù)�？梢�(jiàn)，這種大量手動(dòng)設(shè)置和更新憑據(jù)的方法，并不適合大規(guī)模的身份驗(yàn)證集成。

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

　　API密鑰是一種可被用于識(shí)別與身份驗(yàn)證的單個(gè)字符串。它往往適用于在引用使用API(應(yīng)用程序編程接口)集成的時(shí)候�；�于API密鑰的身份驗(yàn)證，在現(xiàn)代化SaaS應(yīng)用中十分常見(jiàn)。它們也通常被稱(chē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密鑰示例：

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

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

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

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

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

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

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

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

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

　　了解OAuth 2.0方法

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

　　OAuth 2.0的工作原理

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

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

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

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

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

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

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

　　小結(jié)

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

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

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