Azure Active Directory 令牌验证

Question

我正在将 Azure Active Directory 集成到云平台中。由于我们的应用程序是多租户的并且依赖于特定于平台的声明，因此我们确定了解决此问题的最简单方法是通过我们的 SPA 获取 Azure AD 令牌，将其传递回我们的 WebApi，对其进行验证并返回到 SPA一个平台令牌，包含我们开展正常业务所需的所有声明（就好像它是一个简单的用户名/密码认证请求）。

不过，我对此的安全级别感到担忧。

一些背景
由于我们的平台是多租户的，我们要求每个客户端在其 Azure AD 门户上注册应用程序，然后向我们提供生成的应用程序（客户端 ID） 和 目录（租户）ID。我们使用这两条信息通过我们的前端 SPA 向 Azure 发出初始请求（在注册应用程序时遵循 Microsoft 的Quickstart 指南提供的node.js 示例）。现在，由于此时用户未经身份验证，我们需要某种方法来为客户端返回这两个特定的 id。我们已经使用子域进行识别。

例如acmeinc.mydomain.com 将返回与billy.mydomain.com 不同的应用程序（客户端 ID）和目录（租户）ID。这些现在显然是公开的，因为此请求来自未经身份验证的前端路由。

当我传递它时，我可以在前端和后端很好地处理令牌响应，并验证这两条信息在令牌中是正确的，但作为前端 - end 被赋予它们开始，对这些的验证是多余的。此外，验证发行者似乎与知道目录（租户）ID 的人一样多余，也可以伪造它（对吗？）

我在这里遗漏了什么吗？如果可以要求客户还包括我的平台私下生成的声明，我会感到更加轻松，这样我就可以在正常的 JWT 验证的同时验证这个声明。 Azure AD 门户似乎无法自定义声明。

我是错过了关键步骤，还是只是想多了？

Answer 1

有人不能伪造令牌中的发行者，因为令牌是经过数字签名的。 如果没有 Azure AD 的私钥，就无法生成有效的签名。 否则，对令牌的任何修改都会立即被注意到，因为签名不匹配。

如果您使用标准 JWT 验证，您的后端应该已经在验证此签名。

要求客户在他们的租户中注册应用程序是一项我不想让他们承担的工作。 您是否考虑过在 Azure AD 中让您的应用成为多租户应用？ 这样您的客户就可以登录您的应用程序，同意所需的权限，然后开始使用它。无需手动注册任何东西。 这可以在用户登录的入职流程中完成，然后他们可以决定他们想要的子域。 那时您将知道他们可以存储的租户 ID。因此，将来您在登录时始终可以使用正确的租户/目录 ID。

这种方法的缺点是管理回复 URL。 通过专门注册的应用程序，他们可以注册自己的子域版本作为回复 URL。 使用这个通用的多租户应用程序，您需要管理它们。 而且您不能添加无限数量的通配符，也不再支持通配符。 因此，您的身份验证必须使用 auth.mydomain.com 之类的通用身份验证回复 URL 进行，他们将从该 URL 重定向到其租户 URL。