使用 Microsoft AD 的私有 API 的 OAuth 授权流程

Question

我们公司正在使用 Microsoft AD 进行用户管理和身份验证，授权也是使用 AD 组/角色完成的。在大多数第 3 方应用程序中，用户可以使用其 AD 帐户进行身份验证。 现在我们正在开发新的应用程序，它应该使用内部 API。因此，我们在 Microsoft 租户中创建了一个新的企业应用程序并定义了几个角色。 在客户端，这是正常流程 - 用户使用他们的帐户进行身份验证，客户端收到它应该发送到 API 的访问令牌。在这里，我不确定什么是实现它的最佳方式。 由于 AD 中已经存在所有用户，因此无需仅使用访问令牌来获取用户标识符并在内部数据库中创建/链接用户 - 我想使用 AD 用户并能够验证角色并“按原样”在 API 网关后面的服务中使用它们。但是这些角色没有存储在访问令牌中，所以我假设我必须单独向 Microsoft 请求它们。但我也不想每次用户向我的 API 发送请求并希望依赖客户端发送给我并且我可以验证的令牌时都请求它们。

那么实现它的最佳方式是什么？我是否应该在我们自己的身份验证服务中创建一个新的 Bearer JWT，包含我需要的所有信息，并将其提供给客户端，以便它每次都将其发送给我？客户端是否也应该使用此令牌来授权用户？但它也可以向微软请求 IDToken？我们的内部令牌会取代 IDToken 和 Access Token 吗？或者我们应该只使用 IDToken 来请求 API 吗？ 创建自己的令牌对我来说似乎是一种开销，因为我们只与 AD 用户合作，但我也不想在 API 中使用 IDToken 进行授权。

Answer 1

在 OAuth 架构中，您的应用（主要是 API）接受来自授权服务器（在您的情况下为 Azure AD）的令牌。然后，您可以使用这些令牌授权基于 Scopes 和 Claims 的数据请求。避免发行自己的代币，并始终如一地使用 AS 代币。感觉你需要处理domain specific claims，这很棘手，这些是主要问题：

选项 1：JWT 访问令牌中的自定义声明

这要求 Azure AD 在颁发令牌时联系您的内部 API。这是首选选项，但可能不受支持（或不可能），具体取决于提供商和托管基础设施。

选项 2：通过查找自定义声明

这里有一些example C# code of mine，它展示了一种在目标 API 中形成自定义声明主体的技术。首次收到访问令牌时会查找额外的声明（通常从数据库中），然后缓存以供将来使用相同访问令牌的请求。这并不理想，但由于供应商的限制，我过去不得不使用它。

机密互联网令牌

在访问令牌中包含声明时要小心，不要将敏感数据泄露给互联网客户端，例如网络或移动应用程序。尽可能使用phantom token pattern，以免泄露任何敏感数据。如果授权服务器不支持发布引用令牌，那么上面的选项 2 可能是最不坏的选项。