oauth2 openid连接javascript（电子）桌面应用程序

Question

桌面应用程序的正确oauth2流程是什么？除了桌面应用程序，我还有一个使用Implicit流程的SPA Web GUI。如果客户端在3600s之后重定向到IdP以发布新的访问令牌，则无关紧要。

但是桌面应用程序需要全天候运行或者可以全天候运行。因此需要通过refresh_token自动刷新访问令牌。但由于隐式流程不提供刷新令牌，因此它可能是桌面应用程序的错误流程，不是吗？

我想我需要auth代码流，它确实提供了refresh_token。但身份验证请求需要redirect_uri。我们想说我想用Google作为我的openid提供商。使用谷歌看起来我无法使用自定义URI方案（https://developers.google.com/identity/protocols/OpenIDConnect）注册客户端凭据。注册例如http://localhost:9300的工作原理是什么，理论上可以由应用程序处理。

A

桌面应用程序接收refresh_token的正确oauth2流程是什么？

乙

我可以通过自定义URI方案捕获redirect_uri而不使用隐式流（Google IdP）吗？监听自定义uri方案比监听本地tcp端口更容易。

C

这是一个更普遍的问题。通常桌面应用程序是公共应用程序，所以我不应该包含client_secret吗？因此剩下的唯一流量就是隐含流量。但是如何根据规格更新访问令牌而不必每3600秒打扰桌面用户？ 在我的情况下，我可以在本地发布应用程序，所以不公开，但它是如何为公共应用程序？

Answer 1

A - 授权码授予

B - 不确定，你可以register a Custom URI Scheme

C - 提供的信息不足。 您使用的是AppAuth库吗？如果是这样，你应该使用PKCE，然后假设客户端永远不会通过安全连接向IDP以外的任何人发送刷新令牌，则不需要额外的刷新令牌安全措施。

这有帮助吗？

Answer 2

答：是的，使用代码授权

B：是的，使用自定义方案。在您的情况下，您应该使用您的客户端ID的反向。例如com.googleusercontent.apps.123是客户端ID的反向DNS表示法。在Google开发者控制台中将您的客户注册为“其他”。

C：是的，它不应包含客户机密。这就是为什么在交换刷新令牌代码时不需要为本机客户端（“其他”）发送秘密的原因。只需将该字段留空即可。

正如jwilleke所建议的，如果它可用于您的用例，请使用AppAuth库，因为它还会处理一些安全问题（PKCE）。

Answer 3

对于原生应用（桌面），您可以关注OAuth 2.0 for Native Apps。但这仍在审核中，您可以从提供的链接中查阅最新的草稿。

通过此流程，您可以使用授权代码流来获取访问令牌和刷新令牌。刷新令牌应解决与扩展应用程序使用（24/7及更高版本）相关的UX相关问题。

根据此工作文档，有严格的客户端身份验证指南。 Section 8.5讨论它们。因为它不建议使用客户端凭证

  

为此      原因，以及 [RFC6819]第5.3.1节中所述的原因，并非如此      建议授权服务器要求客户端      使用共享密钥验证公共本机应用程序客户端

正如nvnagr在他的回答中所提到的，PKCE [RFC7636]是本地公共客户必须拥有的。