使用 Azure ACS 访问底层身份提供者的访问/刷新令牌

Question

我找不到任何明确的迹象表明 ACS 是否提供此功能。

我想利用 ACS 来完成我的大部分身份验证工作，但我也想访问发送给 ACS 的身份提供者的访问/刷新令牌。然后，我可以对身份提供者进行 API 调用，以访问用户的数据，例如日历或个人资料信息（假设我在应用程序授权步骤中请求了此访问权限）。

这可以使用 ACS 吗？似乎 ACS 将大部分底层身份提供者信息抽象出来，并且仅提供纯粹用于身份验证目的的 ACS 令牌，而不是用于直接与身份提供者对话。

Answer 1

是和不是:)

ACS 确实支持支持该功能的提供商。它没有明确记录，因为它并不特殊。 ACS 不“只是为纯粹的身份验证目的创建自己的令牌”。

如果您使用 FaceBook IdP，ACS 会为您提供 FaceBook 令牌，您可以使用它来查询 FaceBook Graph API。您将获得 API 的哪些权限取决于您的 FaceBook 应用程序需要从身份验证用户那里获得哪些权限。我不确定 FaceBook 同意框架的复杂程度，但我最后一次使用它，身份验证用户只能接受所有必需的同意，或者拒绝所有同意。在所有请求中，他无法有选择地选择哪些同意授予您的申请。

话虽如此，您不会从 Google 身份验证提供商处收到额外的令牌。至少在旧的 OpenID 2.0 实现中是这样。现在随着 OpenID 2.0 的弃用并将 Google 迁移到 OpenID Connect，您需要将 ACS 命名空间明确注册为 Google 的应用程序。那时，我假设（我的猜测）你可以声明请求的同意，就像你对 FaceBook 所做的那样。如果 Google 发送令牌，您肯定会通过 ACS 在您的应用程序中收到它。

ACS 是超级强大的服务，不会死。正如在引用的博客文章中一样，它的所有功能迟早都会转移到 Azure AD 本身。并且将提供迁移计划（希望 :)）。

另外，请注意 ACS 仅与 Yahoo、Google、Facebook、Azure AD 和任何 WS-Federation IdP 通信。并且 WS-Federation 协议并不以非常灵活和为您提供所需的灵活性而闻名。 ACS 理论上也是supports OAuth 2.0，但它的支持不包括联邦，只有本地身份管理（ACS 自身的本地身份）。

另外，请注意，许多 Microsoft 拥有的服务都在使用 ACS，例如 Visual Studio Online、Azure Service Bus 等。 ACS 既没有死，也不会让所有客户都放任自流。

您今天就可以决定使用它。或者，您可以决定使用 Azure AD 本身提供的任何功能。或者等到 ACS 完全迁移到 Azure AD。