B2B SaaS集成的最佳认证方法

　　在软件开发的早期，身份验证(也称认证)作为确保只有持有正确身份标识的用户，才能登录应用的基本手段，已成为了保障系统和数据安全的要素之一。如今，如果您正在构建从SaaS产品连接到其他应用平台的原生集成，那么其中最棘手的问题莫过于：如何去认证第三方应用。有时候，您需要为自己的应用单独设置身份验证的方式，而有时候您则需要通过配置集成，以使用对方提供的身份验证模式。而无论处于哪种情况，了解用户身份验证的基本工作原理，无疑能够为您节省集成或二次开发的宝贵时间。

　　在与客户合作的过程中，我的团队曾协助SaaS团队使用基本的身份验证、API密钥、Open Auth 2.0(也称为OAuth 2.0)、以及OAuth 2.0的非规范变体等，实现了原生的应用集成。下面，我将和您讨论三种主流的身份验证方法的工作原理，各自优缺点，权限设置的难易程度，并深入研究在原生集成过程中的各项细节。

　　了解基本身份验证方法

　　基本身份验证方法使用的是经典的用户名和密码的组合。虽然它们在现代化的SaaS应用中已不再常见，但是我们仍然可以在许多历史遗留系统中看到此类情况，包括：FTP、或基于HTTP的某些旧式应用。

　　在HTTP中，最简单的基本认证用例是将用户名和密码以 : 分割，并使用​​base64​​对整体进行编码。接着，我们将整个base-64编码过的字符串作为HTTP请求的头(请参见如下代码)：

　　为了确保能够符合标准，请始终使用带有Basic {base64 encoded username:password} value的头部作为Authorization前缀。

　　而更简单的方法是将用户名和密码直接放在URL的开头。例如：

　　不过，由于是在公开环境中传输信任凭证，而且任何人都可以读取到，因此该方式并非良好的安全实践，不可被用于安全性较高的集成环境中。

　　SaaS团队为何使用基本身份验证方法进行集成

　　基本身份验证的原理不但十分简单而且容易实现，您只需解码base64编码的报头，并验证用户名和密码的组合是否正确即可。由于其简单性，当您不使用API或第三方集成平台，在内部构建自定义集成时，基本身份验证方法就能及时派上用场。

　　使用基本身份验证方法在集成时需考虑的事项

　　虽然基本认证方法实现起来很简单，但是存在着一些缺点：由于每个集成都获得了相同的信任凭据，因此我们难以限制凭据的使用范围。也就是说，由于每个集成都可以执行凭证所允许的所有操作，因此您无法通过更改绑定的凭据，来实现细粒度的授权。而如果要更改凭据，则需要让使用它们的每个集成，都被赋予新的凭据。可见，这种大量手动设置和更新凭据的方法，并不适合大规模的身份验证集成。

　　了解API密钥身份验证方法

　　API密钥是一种可被用于识别与身份验证的单个字符串。它往往适用于在引用使用API(应用程序编程接口)集成的时候。基于API密钥的身份验证，在现代化SaaS应用中十分常见。它们也通常被称为基于令牌的身份验证(token-based auth)。

　　为了使用API密钥的身份验证方式，应用程序需要创建一个可供集成的密钥。通常，你可以在应用中创建一个“Settings”或“Profile”的菜单。

　　下面的代码展示了在HTTP请求中的API密钥示例：

　　您可能会注意到，该模式与前文用于基本身份验证的模式，所使用的Authorization头部非常相似，唯一区别只是在此使用的是Bearer {token}的值。

　　当然，API密钥也可以作为某些API的参数被传入，例如：

　　此外，您还可以为API密钥使用自定义的头部，例如：

　　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密钥，并在客户激活应用集成时，利用集成的相关配置，将该密钥提供给客户。

　　可见，无论是内部构建集成还是使用嵌入式集成平台，用户身份验证都是安全防护中必不可少的一个重要环节。