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]是本地公共客戶必須擁有的。