对于使用数据连接组件构建应用程序的开发人员，我们建议利用新的开发人员托管服务账户 (DMSA) 功能作为简化方法，让 Procore 管理员能够在其公司账户中轻松安装和配置数据连接应用程序。DMSA 功能可允许开发人员指定其应用程序在 Procore 平台上正常运行所需的确切公司和项目级别的工具权限。公司管理员定义应用程序可以使用这些权限访问哪些项目。开发人员利用 DMSA 为传统服务账户提供更方便、更安全的替代方案。通过改进应用程序管理和更好地了解应用程序使用情况，公司管理员从 DMSA 中受益。
所有传统服务账户都将在2024 年 12 月 31 日停用。
传统服务账户已于 2021 年 12 月 9 日弃用。 从 2024 年 10 月 1 日开始，我们将不再允许创建新的传统服务账户。 现有的传统服务账户将继续运作到 2024 年 12 月 31 日。
根据此时间线，目前使用传统服务账户的数据连接应用程序的开发人员需要更新他们的应用程序以使用开发人员托管服务账户，并且客户需要在停用日期之前安装这些更新后的应用程序。 所有在停用日期前未迁移的数据连接应用程序将停止运行。 Procore App Marketplace 上列出的任何未使用受支持的Procore API访问方法的应用程序，都将在停用日期前被移除。 有关其他信息，请参阅迁移数据连接应用程序以使用 DMSA 。
与传统服务账户相比，使用 DMSA 可以获得许多优势：
简化的应用程序管理 - DMSA 由公司管理员使用公司管理员工具中的应用程序管理功能进行安装和管理。与 DMSA 关联的目录用户是在应用程序安装过程中自动创建的。如果使用传统的服务账户，公司管理员必须手动创建和管理账户及其访问权限，这需要与第三方开发人员进行额外的沟通和协调才能安装和配置应用程序。
更安全的权限管理 - 给定 DMSA 应用程序的所有必需的公司级别和项目级别工具权限都在应用程序清单中定义，该清单在安装过程中应用于你的公司账户。当应用程序包含新功能并发布更新版本时，开发人员可以通过升级过程请求新权限以供审查和批准。
改进的项目访问控制 - 在安装和配置过程中，公司管理员可以准确选择允许 DMSA 应用程序使用的项目。如果使用传统的服务账户，项目访问权限需由公司管理员手动配置和管理，这可能既耗时又费钱，而且可能不够安全，如下所述。
更好地了解应用程序使用情况 - 因为 DMSA 是使用应用程序管理安装的，公司管理员可以以应用程序指标的形式了解应用程序使用情况，例如 API 请求的数量、哪些用户安装和/或使用了应用程序、哪些项目被允许使用应用程序，等等。如果使用传统服务账户，既无法收集也无法访问此类指标。
安装和使用利用传统服务账户的应用程序会带来以下风险：
API 凭证的不安全传输 - 由于传统服务账户是由公司管理员在 Procore 中手动创建的，因此必须将生成的一组唯一的 API 凭证（client_id 和 client_secret）提供回开发人员，以便成功完成集成设置。不幸的是，这种敏感信息的传输可能会通过电子邮件、短信等不安全的方式进行，从而使公司数据可能容易受到攻击。
缺少使用数据 - 如果传统服务账户遭到入侵，则很难跟踪它的使用位置，因为该账户不会生成使用数据。
潜在的人为错误 - 手动配置和管理与传统服务账户关联的权限的要求可能容易出错并导致意外的应用程序行为。
以下是 DMSA 和传统服务账户之间的一些主要区别。
| 开发人员管理服务账户 | 传统服务账户 | |
| 账户创建 |
|
|
| 授权 |
|
|
| 权限 |
|
|
| 项目配置 |
|
|
| 应用程序管理 |
|
|
在安装过程中，可能会在代表 DMSA 的公司和/或项目目录工具中创建新的用户记录。DMSA 联系人名称需遵循不同的格式，应用程序名称转换为小写，并由破折号分隔，后跟随机生成的八个字符的 ID。例如，安装应用程序 My DMSA Test App 会在公司目录中创建用户 my-dmsa-test-app-469b1f7f。请务必不要编辑或删除 DMSA 应用程序安装创建的目录用户，因为此操作可能会导致应用程序在运行时出现问题。
强烈警告公司管理员不要将公司级别目录工具的管理员访问权限授予使用 DMSA 或传统服务账户的应用程序。具有这种最高访问级别的应用程序能够进行变更，这些变更可能会对整个项目中的所有工具或组织的整个 Procore 公司账户中的所有项目产生不利影响。虽然某些应用程序可能需要此功能才能运行，但我们建议在允许之前彻底审查集成需求并了解影响。
在 Procore 平台上构建的应用程序使用行业标准 OAuth 2.0 授权框架 通过 API 进行身份验证。Procore API 支持以下两种授权授予类型或身份验证流程：
授权编号（用户登录流程） - Web 服务器和基于浏览器的应用程序通常使用此授权类型通过 API 进行身份验证。使用授权编号授权类型，应用程序在使用 Procore API 进行身份验证时代表当前登录的用户运行。在这种情况下，应用程序假定已登录用户的权限，并且可以访问允许特定用户与之交互的任何工具、项目或数据。由于在这种授权类型下权限治理可能具有挑战性，因此不建议将其用于数据连接应用程序。有关授权编号授权类型的更多信息，请参阅 OAuth 2.0 授权编号授权流程。
无论集成使用的授权授予类型是 authorization_code（登录用户的权限）还是 client_credentials（服务账户/DMSA 权限），Procore 公司管理员最终负责管理其目录用户的权限。
作为软件即服务 (SaaS) 提供商，Procore 在平台安全方面遵循责任共担安全模型。
客户对他们安装的集成、他们批准使用这些集成的权限以及他们对与 Procore 提供的这些集成相关联的目录用户（DMSA 或传统）所做的任何更改负责。
合作伙伴/开发人员负责处理凭证、调用 API 的代码以及他们对数据的处理方式。客户将密钥提供给开发者，供开发者使用。
Procore 负责为开发人员提供一种通过 OAuth 请求客户许可的方式，并为客户提供安装和管理应用程序的功能。