B2B SaaS集成的最佳认证方法
发布时间：2022-08-27 09:56:07 所属栏目：安全 来源：互联网
导读：在软件开发的早期，身份验证（也称认证）作为确保只有持有正确身份标识的用户，才能登录应用的基本手段，已成为了保障系统和数据安全的要素之一。如今，如果您正在构建从SaaS产品连接到其他应用平台的原生集成，那么其中最棘手的问题莫过于：如何去认证第三
|
在软件开发的早期，身份验证（也称认证）作为确保只有持有正确身份标识的用户，才能登录应用的基本手段，已成为了保障系统和数据安全的要素之一。如今，如果您正在构建从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=" 1. 2. 为了确保能够符合标准，请始终使用带有Basic {base64 encoded username:password} value的头部作为Authorization前缀。 而更简单的方法是将用户名和密码直接放在URL的开头。例如： 复制 curl https://myuser:myP%40sSw0rd@example.com 1. 不过，由于是在公开环境中传输信任凭证，而且任何人都可以读取到，因此该方式并非良好的安全实践，不可被用于安全性较高的集成环境中。 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" 1. 2. 您可能会注意到，该模式与前文用于基本身份验证的模式，所使用的Authorization头部非常相似，唯一区别只是在此使用的是Bearer {token}的值。 当然，API密钥也可以作为某些API的参数被传入，例如： 复制 curl <https://example.com?token=mF_9.B5f-4.1JqM> 1. 此外，您还可以为API密钥使用自定义的头部，例如： 复制 curl <https://example.com> --header "x-acme-api-key: mF_9.B5f-4.1JqM" 1. 2. 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等方案，来定期刷新访问令牌。 （编辑：济源站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
