场景1： 用户正在通过 UI 访问 service-1。对 service-1 的访问是通过登录页面进行身份验证的。现在，在调用service-1的REST API时，service-1需要调用service-2获取一些数据。这里 service-1 和 service-2 之间的 OKTA 身份验证流程应该是什么。一项要求是 service-2 需要了解当前用户，因为它实现了 RLS（行级安全性）。相同的用户信息如何从service-1流向service-2？
场景2：service-2的REST API需要通过一些Python编写的自动化脚本来调用。 OKTA 身份验证流程需要通过 Python 应用程序实现。这个Python应用程序没有任何前端，因此登录页面场景在这里不起作用。由于 service-2 是基于 RLS 的，因此连接时必须提供用户上下文。
OKTA中有很多认证流程，我需要知道在这些场景中可以使用什么。 service-2 作为一组 API，它没有基于消费者的不同 API（service-1 和 Python 应用程序）。
场景1
您需要设计如何在 API 和解决方案之间共享访问令牌，具体取决于服务 1 对服务 2 的信任程度：
您可以转发原始访问令牌，以便以可验证的方式传递用户身份和其他声明。
或者服务1可以使用令牌交换来降低令牌权限，然后再将其发送到服务2。
所有 API 都应强制执行正确的授权，例如检查其所需的范围。
场景2
解决方案取决于自动化脚本操作员应拥有的权限：
如果操作员是可以更新所有用户数据的后端进程，则可以使用客户端凭据流程，并且访问令牌将不具有用户身份。
否则，自动化脚本可以触发代码流，调用系统浏览器来登录交互式用户并获取具有用户身份的访问令牌。
访问令牌设计
在所有情况下，我建议您从访问令牌设计开始，以便 API 接收具有限制 API 客户端权限并启用正确授权的范围和声明的访问令牌。