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

Question

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

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

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

一个

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

乙

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

C

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

Answer 1

A - 授权码授予

B - 不确定，您可以注册自定义URI方案

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相关问题。

根据该工作文档，客户端身份验证有严格的指导原则。 第8.5节讨论了它们。 因为它说不建议客户端凭据

出于这个原因，以及[RFC6819]的第5.3.1节中所述，授权服务器不建议使用共享密钥对公共本机应用程序客户端进行客户端身份验证

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