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