我正在尝试设计一个新项目，该项目将具有多个服务（服务数据）和 Web 应用程序（服务 HTML）。我读过微服务，它们看起来很合适。
我仍然遇到的问题是如何实现 SSO。我希望用户进行一次身份验证并有权访问所有不同的服务和应用程序。
我可以想到几种方法：
添加身份服务和应用程序。任何具有受保护资源的服务都将与身份服务对话，以确保其拥有的凭据有效。如果不是，它将重定向用户进行身份验证。
使用诸如 OpenID 之类的网络标准，并让每个服务处理它自己的身份。这意味着用户必须单独授权每个服务/应用程序，但之后它将是 SSO。
我很乐意听到其他想法。如果一个特定的 PaaS（比如 Heroku）有一个专有的解决方案也是可以接受的。
在我之前的工作中实现微服务架构时，我们认为最好的方法是与 #1 保持一致，添加身份服务并通过它授权服务访问。在我们的例子中，这是通过令牌完成的。如果请求带有授权令牌，那么如果它是用户与服务会话中的第一次调用，我们可以使用身份服务验证该令牌。一旦令牌得到验证，它就会保存在会话中，因此用户会话中的后续调用不必进行额外的调用。如果需要在该会话中刷新令牌，您还可以创建计划作业。
在这种情况下，我们使用 OAuth 2.0 端点进行身份验证，并将令牌添加到 HTTP 标头以调用我们的域。所有服务都从该域路由，因此我们可以从 HTTP 标头中获取令牌。由于我们都是同一个应用程序生态系统的一部分，最初的 OAuth 2.0 授权将列出用户将为其帐户授予权限的应用程序服务。
这种方法的一个补充是身份服务将提供代理客户端库，该代理客户端库将添加到 HTTP 请求过滤器链并处理服务的授权过程。该服务将被配置为使用来自身份服务的代理客户端库。由于我们使用的是 Dropwizard，这个代理将成为一个 Dropwizard 模块，将过滤器引导到正在运行的服务进程中。这允许对身份服务进行更新，只要接口没有发生显着变化，相关服务就可以轻松地使用免费的客户端更新。
我们的部署架构分布在 AWS Virtual Private Cloud (VPC) 和我们自己公司的数据中心。OAuth 2.0 身份验证服务位于公司的数据中心，而我们所有的应用程序服务都部署到 AWS VPC。
我希望我们采取的方法对您的决定有所帮助。如果您还有其他问题，请告诉我。
Chris Sterling 解释了上面的标准身份验证实践，这绝对有意义。出于一些实际原因，我只想在这里提出另一个想法。
我们实现了身份验证服务和其他多个依赖身份验证服务器的微服务来授权资源。在某些时候，由于身份验证服务器的往返次数过多，我们遇到了性能问题，随着微服务数量的增加，我们还遇到了身份验证服务器的可扩展性问题。我们稍微改变了架构以避免过多的往返。
身份验证服务器只会与凭据联系一次，它将根据私钥生成令牌。相应的公钥将安装在每个客户端（微服务服务器）中，该客户端将能够在不联系身份验证服务器的情况下验证身份验证密钥。密钥包含生成的时间，并且安装在微服务中的客户端实用程序也将有效。尽管它不是标准实现，但我们在这个模型上取得了相当大的成功，尤其是当所有微服务都在内部托管时。