oauth-2.0 - 在没有用户交互的情况下长时间运行的后台应用程序中的 imap、smtp 和 pop3 的 Oauth

Question

我们销售一个 Java 应用程序，它是 Web 应用程序的扩展，使用 IMAP、POP3 和 SMTP 连接到邮箱。到目前为止，我们仅支持基本身份验证(用户名和密码)并鼓励用户使用 TLS 和应用密码。

但现在 Microsoft 将在 10 月 1 日放弃对基本身份验证的支持，转而支持 Oauth2。此外，Gmail 目前仅支持 Oauth2。这就是为什么我们需要向我们的应用添加 Oauth 支持。

这给我们带来了多重挑战，因为我们的许多客户将他们的服务器置于防火墙之后，因此传入和传出连接通常受到限制。此外，由于应用程序作为 jar 文件分发，我们无法将客户端 secret 打包到应用程序中。此外，由于用户使用不同的服务器，可访问服务器的 url 也会有所不同。

我并不是真正的 OAuth 专家，我正在为如何最好地解决这个问题而苦苦挣扎。当用户通过 web ui 进行初始配置时，我们只能访问 web 浏览器。从那里开始，应用程序必须能够每 5 分钟连接一次邮箱，而不能进行用户交互。

从表面上看，隐式流看起来是我们用例的正确选择，因为它不需要客户端密码。但是隐式流不支持刷新 token ，我需要一个刷新 token 才能在没有用户交互的情况下持续获取新的访问 token 。

所以这是我的问题:

• 哪种 OAuth 流程最适合此用例？
• 在 jar 文件中包含共享 secret /私钥是否可以接受？据我所知，唯一的缺点是网络钓鱼的可能性，这是我无论如何都无法解决的问题。
• 如何处理不同客户的不同重定向 url？
• 依靠刷新 token 来无限期地对应用进行身份验证是否安全？

更新

这就是我最终做的:

对于 Gmail，我们允许用户注册他们自己的 oAuth 客户端。这是必要的，因为 Gmail 不提供动态客户端注册，并且设备注册不允许访问 gmail 范围。

所以我们给用户一个 UI 来输入他们的客户端 ID/客户端密码和一个 tutorial关于如何创建客户端:

这需要我们的客户进行一些额外的跑腿工作，但由于他们具备这样做的技术能力，所以这是可行的。

这是我们在不破解重定向 URL 并将客户端密码包含在 JAR 中的情况下让它工作的唯一方法。

到目前为止，bugcrowd 研究人员发现没有什么可提示的。

另一方面，Microsoft Exchange 非常容易。 Microsoft 支持公共(public)客户端的设备流。所以我们只使用它。

Answer 1

Which OAuth flow would be the right fit for this use-case?

我认为你应该实现代码流。它比隐式流更安全，而且在隐式流中你不会得到刷新 token 。如果用户使用浏览器执行初始配置，那么应该可以实现代码流。您可以查看的另一个流程是设备流程。如果您的应用能够将设备代码传达给用户，那么用户可以在另一个浏览器上执行身份验证，同意相关权限，您的应用将从授权服务器中提取 token 。

Is it ever acceptable to include the shared secret/private key in the jar file? As I understand the only downside would be the possibility of phishing which is an issue I cannot solve anyway.

不是说不能接受。它更像是 — 如果您将 secret 包含在 jar 中，那么您就不能再将其视为 secret 。然后，您应该将您的客户视为公共(public)客户，并在您的代码流 (PKCE) 中实现代码交换的证明 key 。另一种可能更好的解决方案是使用动态客户端注册。当您的应用程序首次配置时，它应该将自己注册为新客户端并获得自己的客户端 ID 和密码。这样您就不必将它包含在您的 jar 中。

How can I deal with different redirect urls for different customers?

这可以通过动态客户端注册来解决。您的应用程序可以使用新的重定向 URI 注册自己，具体实例将使用该 URI。否则，您将不得不创建一个代理，拥有一个重定向 URI，并在您的代理中决定您要将响应重定向到哪里，例如基于客户端 ID、状态或其他一些数据。

Is it safe to rely on the refresh token to keep an app authenticated indefinitely?

如果您实现 DCR 并随后使用 secret 客户端，那么是的，它是安全的。请记住，刷新 token 也可能有过期时间。所以可能还是需要重新登录。

如果您需要有关此处提到的功能的更多信息，可以查看这些资源:

• 设备流:https://curity.io/resources/learn/oauth-device-flow/
• PKCE:https://curity.io/resources/learn/oauth-pkce/
• DCR:https://curity.io/resources/learn/openid-connect-understanding-dcr/