OAuth“应用服务器”的最佳实践——Square答案

【问题标题】：Best practices for the OAuth "application server" - SquareOAuth“应用服务器”的最佳实践——Square
【发布时间】：2015-06-25 17:11:59
【问题描述】：

我有一个应用程序，它使用个人访问令牌来访问 GET 项目列表。我想切换到使用 OAuth，应用程序将只使用 ITEMS_READ。

我的应用程序是在专用于该应用程序的安全 Ubuntu 服务器实例上运行的守护程序。关于“应用程序服务器”，Square 有什么建议吗？“应用程序服务器”的典型最佳实践是什么？

谢谢

【问题讨论】：

【解决方案1】：

API 文档相当广泛，包括a helpful section about OAuth。我在过去注意到 OAuth 实现的一些常见缺陷导致我提出这些问题：

如果您只是构建一次性集成供自己使用，则可能不值得使用 OAuth。
确保您了解 OAuth 的工作原理。如果您发现自己在询问用户的客户端机密或个人访问令牌，或者需要他们在 connect.squareup.com 上打开应用管理仪表板的任何其他内容，您需要重新考虑您的实施。只有开发者需要了解访问令牌和其他 API 凭据。
您通常可以要求比您需要的最低限度更多的 OAuth 范围。我建议也获得 MERCHANT_PROFILE_READ。这对于管理帐户很有用，因此您可以点击 /v1/me 获取您需要的各种 ID。
Square OAuth 访问令牌过期 as described here。它们会持续 30 天，因此这可能会蔓延到不了解它的开发人员身上。您将需要使用计划任务来更新即将到期的访问令牌，并在此之后清除您的旧令牌。像 cronjob 这样简单的东西应该没问题。

就您使用的技术堆栈而言，这完全取决于您。 Square Connect 团队很乐意在可能的情况下提供帮助并提供建议。

【讨论】：

其他商家发现我的应用程序/守护进程很有用，因此需要迁移到 OAuth。是的，我知道它们已过期 - 我还注意到使用 OAuth 仅限于 10 个商家。
太好了！很高兴听到您正在构建有用的东西。如果您想将您的应用程序作为产品提供，您可以询问是否将其添加到 Square App Marketplace。这将取消对授权商家数量的限制，并允许您通过 Square 赚取一些订阅收入。