B2BSaaS集成的最佳认证方式手段已经成为保证系统和数据安全的要素之一。今天，如果您正在构建从SaaS产品到其他应用程序平台的本地集成，那么最棘手的问题之一就是如何验证第三方应用程序。有时需要为自己的应用单独设置认证方式，有时需要配置集成使用对方提供的认证方式。不管在什么情况下，了解用户认证的基本工作原理，无疑会为您节省宝贵的集成或二次开发时间。在与客户合作的过程中，我的团队曾协助SaaS团队实施原生应用程序集成。下面，我将与大家一起探讨三种主流认证方式的工作原理，各自的优缺点，权限设置的难易程度，以及对原生集成过程细节的深入研究。了解基本身份验证方法基本身份验证方法使用经典的用户名和密码组合。虽然它们在现代SaaS应用中已经不常见了，但是我们仍然可以在很多历史遗留系统中看到这样的案例，包括：FTP，或者一些基于HTTP的遗留应用。在HTTP中，最简单的基本身份验证用例是将用户名和密码用:分隔，并使用base64对整体进行编码。接下来，我们使用整个base-64编码的字符串作为HTTP请求的头部（见以下代码）：curl\\--header"Authorization:BasicbXl1c2VyOm15UEBzU3cwUmQ="为了确保为了符合标准，始终使用带有基本{base64编码的用户名：密码}值的标头作为授权前缀。更简单的方法是将用户名和密码直接放在网址的开头。例如：curlhttps://myuser:myP%40sSw0rd@example.com但是，由于信任证书是在公共环境中传输的，任何人都可以读取，因此这种方法不是一种好的安全做法，不能用于安全性高的集成环境。为什么SaaS团队使用BasicAuth方法进行集成BasicAuth的基本原理简单且易于实现，您只需解码base64编码的标头并验证用户名和密码的组合是否正确。由于其简单性，当您在内部构建自定义集成而不使用API或第三方集成平台时，基本身份验证方法会派上用场。使用基本身份验证方法的集成注意事项虽然基本身份验证方法易于实现，但它有一些缺点：由于每个集成都被赋予相同的信任凭证，因此很难限制凭证的范围。也就是说，您无法通过更改绑定的凭据来实现细粒度授权，因为每个集成都可以执行凭据允许的所有操作。如果您想更改凭据，则需要为使用它们的每个集成提供新凭据。可见，这种手动设置和更新凭证的方式并不适合大规模的认证集成。了解API密钥身份验证方法API密钥是可用于识别和身份验证的单个字符串。当提到使用API（应用程序编程接口）的集成时，它通常适用。基于API密钥的身份验证在现代SaaS应用程序中非常普遍。它们通常也称为基于令牌的身份验证。为了使用API密钥身份验证方法，应用程序需要创建一个可以集成的密钥。通常，您会在应用程序中创建“设置”或“配置文件”菜单。以下代码显示了HTTP请求中的示例API密钥：curl\\--header"Authorization:BearermF_9.B5f-4.1JqM"您可能会注意到此模式与The与之前的基本认证方式使用的Authorizationheader非常相似，唯一不同的是这里使用了Bearer{token}的值。当然，APIkey也可以作为一些API的参数传入，例如：curl另外，也可以使用custom例如:curl\\--header"x-acme-api-key:mF_9.B5f-4.1JqM"为什么SaaS团队使用API??密钥认证方式进行集成，虽然API认证方式需要比基本身份验证方法更多的设置，但它们实施起来不那么复杂。通常，应用程序会将生成的API密钥（或这些密钥的哈希值）存储在一个表中，并将这些密钥与相应的用户进行匹配。使用API密钥优于基本身份验证的优势在于开发人员可以设置权限（授权）范围。您可以设置一个令牌以对特定资源进行只读访问，同时设置另一个令牌以通过API访问所有资源。这允许您为每个集成使用不同的令牌，从而确保即使用户更改了密码，API密钥仍然可以映射到该用户名。而且，如果您的集成不再需要访问API，则完全可以从应用程序中删除或禁用相应的API密钥。可以这么说，如果您使用的是嵌入式集成平台（也称为嵌入式iPaaS），API密钥非常适合与此类应用程序集成。使用API密钥身份验证方法进行集成时需要考虑的事项用户可以选择手动将API密钥从一个应用程序复制粘贴到另一个应用程序，但如果处理不当，可能会导致严重的问题。另一方面，由于APIkey通常不会过期，一旦有人截获APIkey，它就会被用来继续作恶，直到有人发现并进入源应用程序将其禁用或删除。了解OAuth2.0方法已被广泛使用。OAuth2.0的设置是：用户在应用A上点击一个按钮后，应用A向应用B发送请求，询问是否要与应用A共享一些信息内容（如电子邮件等）。如果你点击同意分享数据的按钮，那么appA就会被授予访问appB的相关权限。这个说法可能过于简单，通过下面的逻辑图让我们了解一下其背后复杂的工作原理：OAuth2.0HowworksSaaS团队为什么要使用OAuth2.0的方式进行集成OAuth2.0的强大之处在于：我们可以很容易地对特定的访问需求，如账户访问、联系人读/写等进行限制权限（授权）。也就是说，每个集成都可以使用不同的访问令牌，即使用户更改了密码，OAuth访问令牌仍然有效。同时，由于token的撤销和更新都比较简单，一旦accesstoken被某种方式拦截，可以快速设置过期或限制使用。并且用户很难生成新的访问令牌。此外，由于用户不需要输入任何额外的数据，如凭证或API密钥，而只需要批准应用程序之间的授权请求，OAuth在用户体验方面更加友好。可以说，作为一种更强大、更安全的认证方式，OAuth2.0非常适合开发者使用嵌入式集成平台（embeddediPaaS）来构建与第三方应用的集成。使用OAuth2.0方法进行集成时需要考虑的事项总体而言，构建OAuth2.0的成本高于上述基本身份验证或API密钥。您需要构建基础架构以使用OAuth2.0跟踪应用程序客户端ID和客户端机密。此外，应用程序的API还需要创建一个回调（callback）类型的URL，它将授权码（AuthorizationCode）作为输入，并用它换取访问令牌和刷新令牌（如果适用）。最后，您需要通过构建cron作业或类似AWSLambda的东西来定期刷新访问令牌。总结基于上面提到的用户体验和内置的保护机制，如果你需要在自己的应用程序和第三方应用程序之间建立自定义的内部集成，那么OAuth2.0将是非常合适的。另一方面，API密钥只能提供良好的用户体验并且安全性稍差。大多数现代SaaS应用程序很少使用基本身份验证方法。如果您使用嵌入式iPaaS来创建、部署和维护与应用程序的本地集成，该平台通常会附带许多应用程序的内置连接器，无需额外编码即可满足和处理大多数身份验证需求。您甚至可以将其设置为让应用程序创建一个API密钥，并在客户激活应用程序集成时使用集成的相关配置将该密钥提供给客户。由此可见，无论是内建集成还是嵌入式集成平台，用户认证都是安全防护中必不可少的重要环节。译者简介JulianChen，社区编辑，拥有十余年IT项目实施经验，善于把控内外部资源和风险，专注传播网络与信息安全方面的知识和经验；通过其他形式分享前沿技术和新知识；经常在线上和线下开展信息安全培训和讲座。原标题：TheBestAuthenticationMethodsforB2BSaaSIntegrations，作者：BruWoodring
