我试图了解 Windows 服务和 AWS Cognito 之间的最佳集成方式是什么。
我的 Windows 应用程序基于 Windows 服务 (C#)。这个具有最小 UI 的应用程序由客户安装，安装后它作为后台进程（Windows 服务）运行。因此，用户仅在安装过程中与应用交互。
此应用程序使用 AWS 资源：写入一个 S3 存储桶并从另一个 S3 存储桶读取。
那么，我的问题：
如何将我的服务与具有身份验证和授权功能的 AWS Cognito 集成？应用程序应将访问令牌或授权令牌等敏感数据保存在哪里？另外，也许有人可以建议我另一种解决方案，它不一定是 Cognito 的解决方案。
我看过的大多数关于我的问题的文章都是关于移动/网络应用程序的。
您的部分问题是反模式：长期存在的凭据。大多数现代框架，包括 AWS 的，都希望您半连续地交易您的身份证明以换取短期令牌。这就是为什么我认为您将难以从有关该主题的博客/AWS 文章中获得大量支持。 Cognito 是一个不错的选择，因为处理向 AWS 服务的实际移交的部分相对容易（您可以通过 IAM 对 IdP 的支持“自己”做一些这样的事情，但策略和代码 - 假设角色的 - 有点棘手顺利工作）。这里有一个 link 讨论为什么长期凭据是一个坏主意，并且在桌面和移动应用程序上同样如此：
当您编写此类应用程序时，您将向必须使用 AWS 访问密钥签名的 AWS 服务发出请求。但是，我们强烈建议您不要不要在用户下载到设备的应用程序中嵌入或分发长期 AWS 凭证，即使是在加密商店中也是如此。相反，构建您的应用程序，以便在需要时使用 Web 联合身份验证动态请求临时 AWS 安全凭证。提供的临时凭证映射到一个 AWS 角色，该角色仅具有执行移动应用所需任务所需的权限。
如果您使用 Cognito，您将循环使用临时凭证。您可以将它们存储在内存中，并在它们到期或您的客户端服务重新启动时获取新的。这个想法是它们没有那么有价值，因为它们会在短时间内过期。此外，意识到您可以设置凭据可以持续多长时间。目前，AWS 支持 60 minutes and 10 years 之间。例如，如果您只需要在启动时进行身份验证，这可能会降低您对用户的障碍，然后您可以绕过整个“需要保存凭据”项目，因为您可以将其保存在内存中。然而，定期重新验证仍然是可取的。我认为 cognito 过去默认为 30 天。
如果你真的、真的想要做长期凭证，你根本不需要认知 - 只是让用户使用他们的凭证的某种方式，这可以由你生成或取决于你的用户群有多大是。然后你需要一些存储它们的方法。要么让用户在启动时提供一些密码，然后在内存中对称地加密/解密，要么通过将它们永久存储在某个地方来牺牲更多的安全性（可能有点像带有静态非用户的“加密”文件那样晦涩难懂）密码）。但是，我强烈建议您根本不要走这条路 - 这完全是对临时凭证的一种妥协，这是此类事情的最佳做法。
这个相关的 SO 也可能对一些额外的 links 有所帮助。