最重要的是，这个用户流程是否有意义，或者我是否遗漏了此集成中的重要内容？

流程更像是： Mozilla Firefox 示例

您了解 OpenID 客户端和 OpenID 提供商之间的 OpenID Connect 流程吗？

• 已分配配置文件（如果适用）。这可能与我之前使用的软件有关。但是，仍然可能与此有关。
• 自动发现。如果有可用的自动发现，通常它看起来像：https://myidentityProvider/.well-known/openid-configuration。您的应用程序可以从中获取，而您不必手动输入每一部分。1
• 发行者 URI：身份提供商提供的 URI。未使用自动发现时需要此 URI。
• 令牌端点： https://myidentityProvider/connect/token 。未使用自动发现时使用。
• 用户声明：您的客户端需要哪些声明才被视为有效。用户名，或者可能是返回的嵌套值。
• 用户信息端点：https：//myidentityProvider/connect/userinfo
• 范围：通常，这将与应用程序所需的 openid 配对。根据我过去的经验，有效范围是 \'openid, company.user\'。

如何确保外部提供商提供的授权码由 Okta 安全地生成、传输和验证？

您是否使用签名响应算法？我当时知道的是 ECDSA 和 RSA。我使用的是 RS256。如果您可以完成整个过程，则说明它正在运行。所有这些都应使用 TLSv1.2 或更高版本进行客户端和提供商之间的通信。如果您没有保护环境，那么它很可能无法工作或像纸牌屋一样。

一旦从外部提供商收到授权码，Okta 建议使用哪些配置来有效处理令牌交换？

不幸的是，我对此没有太多了解。客户端和提供商之间是否有许多通道，例如从源到目标再返回的跳数？如果您通过 LB，请确保它们允许的字节数足够高，即 Microsoft 字节大小约为 1024 或更多，具体取决于组织。否则，您将收到 503 HTTP 响应。