桌面应用程序的正确 oauth2 流程是什么？除了桌面应用程序，我还有一个SPA Web GUI，它确实使用隐式流。客户端是否在 3600 秒后重定向到 IdP 以颁发新的访问令牌并不重要。
但是桌面应用程序需要 24/7 全天候运行，或者可以 24/7 全天候运行。因此，它需要通过refresh_token自动刷新访问令牌。但是，由于隐式流不提供刷新令牌，因此可能是桌面应用程序的错误流，不是吗？
我想我需要身份验证代码流，它确实提供了refresh_token。但身份验证请求需要redirect_uri。假设我想使用 Google 作为我的 openid 提供商。使用谷歌，我似乎无法使用自定义 URI 方案 (https://developers.google.com/identity/protocols/OpenIDConnect( 注册客户端凭据。工作是注册例如 http://localhost:9300，理论上可以由应用程序处理。
一个
桌面应用接收refresh_token的正确 oauth2 流是什么？
乙
我能否在不使用隐式流 (Google IdP( 的情况下通过自定义 URI 方案捕获redirect_uri？侦听自定义 uri 方案比侦听本地 tcp 端口要容易得多。
C
这更像是一个普遍的问题。通常桌面应用程序是公共应用程序，所以我不应该包括client_secret对吗？因此，唯一剩下的流是隐式流。但是，如何根据规范续订访问令牌，而无需每 3600 次打扰桌面用户？ 就我而言，我可以在本地发布应用程序，以便不公开，但是公共应用程序的情况如何？
A - 授权代码授予
B - 不确定，您可以注册自定义 URI 方案
C - 提供的信息不足。 您是否正在使用 AppAuth 库？如果是这样，您应该使用 PKCE，然后不需要对刷新令牌采取额外的安全措施，前提是客户端永远不会通过安全连接与 IDP 以外的任何人发送刷新令牌。
这有帮助吗？
答：是的，使用代码授权
B：是的，使用自定义方案。在您的情况下，您应该使用客户端 ID 的反面，例如.com.googleusercontent.apps.123 是客户端 ID 的反向 DNS 表示法。 在 Google 开发者控制台中将您的客户端注册为"其他"。
C：是的，它不应包含客户端密码。这就是为什么在将代码交换为刷新令牌时，无需为本机客户端("其他"(发送密钥的原因。只需将该字段留空即可。
正如 jwilleke 所建议的，如果 AppAuth 库可用于您的用例，请使用它，因为它还可以处理一些安全问题 (PKCE(。
对于本机应用程序(桌面(，您可以遵循适用于本机应用程序的 OAuth 2.0。但这仍在审查中，您可以从提供的链接中参考最新草案。
通过此流，可以使用授权代码流获取访问令牌和刷新令牌。刷新令牌应该可以解决与 UX 相关的问题，当涉及到扩展的应用程序使用(24/7 及以后(。
根据这份工作文件，对客户端身份验证有严格的指导方针。第 8.5 节讨论它们。正如它所说，不建议使用客户端凭据
为此 原因，以及 [RFC6819] 第 5.3.1 节中所述的原因，它不是 建议授权服务器要求客户端 使用共享密钥对公共本机应用程序客户端进行身份验证
此外，正如nvnagr在他的回答中提到的，PKCE [RFC7636]是本地公共客户的必备品。