大多数客户拥有异构的私有应用程序组合；有些是自建的，有些是内部托管服务，有些具有可用的 SSO 集成，而有些依赖 HTML 或其他形式的身份验证。考虑到这一点，我们建议你组合搭配入组解决方案，以适应每个单独应用程序的需求。如下表所示，你可以将应用程序归类到一系列按优先级排序的类别中，这些类别优先考虑实施简易性和总体组织影响。
| 应用程序类型 | 建议 | 结果 |
|---|---|---|
| 未集成 SSO 的私有 Web 应用 | 专门在 Cloudflare 域名上呈送应用程序。 | 用户在委托给 Cloudflare 的新域名上访问应用程序，并通过 Cloudflare 集成即时应用 SSO。 |
| 带集成 SSO 的私有 Web 应用 | 如果可进行 SSO 配置： 专门在 Cloudflare 域名上呈送应用程序。 如果无法进行 SSO 配置： 在现有内部域名上呈送应用程序，并将相同的外部域名委托给 Cloudflare |
用户从 Cloudflare 访问相同或新域名上的内部 Web 服务。如果已配置，SSO 提供程序会将用户透明地从内部域名重定向到 Cloudflare 权威外部域名。 |
| 正在开发的新关键内部应用程序 | 专门在 Cloudflare 域名上呈送应用程序。 | 开发人员可以以编程方式在 Cloudflare 上生成（或被授予）新的公共主机名，以代表其应用程序在 SAML 或 OIDC 集成中的重定向。 |
| 正在开发的新微服务 | 专门在 Cloudflare 域名上呈送应用程序。 (可选)在内部应用程序中消耗 Access JWT 作为身份验证。 |
开发人员可以将 JWT 授权机制直接注入到其应用程序的代码库中，并使用 Terraform 自动为其应用程序构建 Cloudflare 主机名和策略。 |
| 内部 API 端点（包括依赖外部/内部 API 的内部应用程序） | 在 Cloudflare 域名上呈送内部 API，并构建接受服务令牌 (Service Tokens) 的 Access 策略，同时包含面向用户的策略。 | 自动化系统可以通过请求标头中的服务令牌进行身份验证，而最终用户继续通过其 IdP 登录。 |