假设我有一个前端应用程序想要从后端服务获取一些数据。（我愿意。）该服务将需要验证最终用户是否经过身份验证，是否有权使用该服务，并可能根据用户的权限过滤返回的数据。就我而言，前端应用程序和后端服务都依赖 Azure ACS 进行身份验证。
理想情况下，前端希望代表经过身份验证的用户采取行动，这听起来很适合使用ActAs令牌（如 WS-Trust 中所指定）。但是，事实证明ACS 目前不支持 ActAs。
一种解决方法是使用实际的不记名令牌（前端应用程序中的引导令牌）对后端服务进行身份验证。这并不难，但出于某种原因，这会是一个坏主意吗？
从您的前端应用程序中，您当然可以通过按原样发送令牌或从中发送属性来传递最终用户的身份数据。两者都有问题。对于前者，如果它也被加密，则前端和后端将不得不共享解密所需的私钥；他们还必须共享受众限制等，以便后端认为令牌对其有效。换句话说，前端和后端将是一个依赖方，而不是两个。可能不是问题，但要注意。在后一种情况下，您最终会以适当的方式发送用户数据，这可能会随着时间的推移增加集成和维护成本。在这两种情况下，您都可以使用某种其他类型的凭据（例如，在传输级别使用的证书）向后端验证前端应用程序，因此，
我建议您考虑的一件事是 OAuth 2。来自这篇博文，在我看来 ACS 支持它（尽管我没有任何第一手经验）。OAuth 2 真正美妙的地方在于它包含了委托，并且没有 WS-Trust 中的 ActAs 那样复杂。最终结果是相同的，即后端服务将拥有有关调用服务和最终用户的信息，但设置它所付出的努力是无与伦比的。令牌仍将是不记名令牌，但您可以通过使用 SSL 在一定程度上缓解这种情况。除了 SSL，您还可以采取一些额外的措施，但最好的是，IMO，如果微软在 ACS 中做了一些事情，比如谷歌已经用他们的访问令牌为服务帐户做的事情，这些服务帐户使用链接到 PKI 的非对称密钥。（顺便说一句，据我所知，微软可能已经做过类似的事情；如果是这样，你就准备好了。）
无论如何，HTH！