如果用户通过客户端上的OpenID Connect进行身份验证并触发了长时间运行的服务器端请求，那么如果操作花费的时间超过访问令牌的到期时间，服务器如何使访问令牌有效？
我们有一个应用程序套件，由几个服务器端后端应用程序（通常通过REST，HTTP和/或WebDAV访问），几个Web前端应用程序和几个客户端（即桌面）应用程序组成。我们已经支持基本和Kerberos /协商身份验证方案，并且当前正在添加对OpenID Connect的支持。
当我们的软件集成到他们的系统中时，通常由Web前端和客户端应用程序，其他服务器端后端应用程序以及第三方客户应用程序访问我们的后端应用程序。目前，我们通过Bearer方案将OpenID访问令牌传递给后端应用程序。
在典型情况下，用户（在本地客户端或Web前端上经过身份验证）会触发服务器端操作，该操作可能会运行几分钟，几小时，几天甚至几周。此操作代表用户访问其他后端，例如基于Web-DAV的服务器端文件系统，以访问其他数据。所有后端应用程序都需要用户的身份验证信息来授予访问权限，并访问其他用户详细信息以进行授权（例如，仅授予对用户自己文件的访问权限）。
显然，这意味着原始后端调用提供的访问令牌可能会在操作完成之前过期。因此，服务器需要一种无需用户干预即可刷新访问令牌的方法。如果我们的代码知道用户的刷新令牌（使用刷新令牌以及应用程序的客户端ID和用于访问OIDC令牌端点的密码），就已经可以做到这一点。
但是我们如何“正确地”将刷新令牌传递给服务器？
客户端（可能）具有完整的ID，访问和刷新令牌集。但是据我了解，承载方案期望传递的令牌是访问令牌。兼容性在这里很重要，因为我们的后端应用程序也可以被第三方客户端应用程序访问。假设将刷新令牌放入服务器应用程序是完全正确的方法，因此，我们仍然必须支持调用者只能提供访问令牌的情况（显然，在这些情况下，长时间运行的操作不会被使用）。能够代表用户访问其他后端服务。
我可以想象服务器通过Bearer接受访问令牌或刷新令牌。但是据我了解，客户端可以通过带有正确的Bearer身份验证标头的唯一“参数”是单个Base64编码的字符串，即（访问）令牌。客户端可以在此处传递访问或刷新令牌，但是据我所知，这两种令牌类型都是不透明的，我不知道服务器随后如何分辨它是哪个。
我知道最初的想法是服务器操作短暂，因此使访问令牌保持最新是客户的责任。但是可以肯定的是，我们不能成为第一个需要将OIDC与长期运行的服务器端操作结合在一起的人。是否存在将刷新令牌传递到服务器的公认方法，或者是我所缺少的完全不同的方法？