基于Microsoft的私有API的OAuth授权流程
我们公司正在使用Microsoft进行用户管理和身份验证，授权也是使用AD组/角色完成的。在大多数第三方应用程序中，用户可以使用他们的AD帐户进行身份验证。现在我们正在开发新的应用程序，应该使用内部API。为此，我们在Microsoft租户中创建了一个新的企业应用程序，并定义了几个角色。在客户端，它是正常的流-用户使用他们的帐户进行身份验证，客户端接收它应该发送到API的访问令牌。在这一点上，我不知道什么是实现这一目标的最佳方式。由于AD中已经存在所有用户，因此不需要只使用访问令牌来获取用户标识符并在内部数据库中创建/链接用户--我希望使用AD用户，并能够验证角色并在API网关后面的服务中使用它们。但是这些角色并没有存储在访问令牌中，所以我假设，我必须分别从Microsoft请求它们。但是，我也不希望每次用户向我的API发送请求时都请求它们，并且希望依赖客户端发送给我的令牌，而我可以验证这个令牌。
那么，实现它的最佳方式是什么呢？我是否应该在我们自己的auth服务中创建一个新的Bearer，包含我所需要的所有信息，并提供给客户端，以便它每次都发送给我？客户端是否也应该使用此令牌来授权用户？但它也可以向微软请求IDToken吗？我们的内部令牌会取代IDToken和访问令牌吗？还是应该只对API的请求使用IDToken呢？在我看来，创建自己的令牌似乎是一种开销，因为我们只与AD用户一起工作，但我也不希望在API中使用IDToken进行授权。
回答 1
Stack Overflow用户
发布于 2022-01-25 22:10:36
在OAuth体系结构中，您的应用程序(主要是API)接受来自授权服务器(在您的例子中是Azure)的令牌。然后使用这些令牌授权基于范围和索赔的数据请求。避免发出您自己的令牌，并作为令牌使用一致。这感觉就像您需要处理domain specific claims，这是一个棘手的问题，以下是主要的问题：
选项1: JWT访问令牌中的自定义声明
这需要Azure AD在令牌发布时接触到您的内部API。这是首选选项，但它可能不受支持--或可能--取决于提供者和宿主基础设施。
选项2:通过查找进行自定义索赔
下面是一些我的示例C#代码，它展示了在目标API中形成自定义声明主体的技术。当第一次接收访问令牌时(通常从数据库中)查找额外的声明，然后缓存具有相同访问令牌的未来请求。它并不理想，但由于供应商的限制，我不得不在过去使用它。
机密互联网令牌
当在访问令牌中包含不向互联网客户透露敏感数据的声明时要小心，例如web或移动应用程序。如果可能的话，请使用幻象令牌模式，这样您就不会泄露任何敏感数据。如果授权服务器不支持发出引用令牌，那么上面的选项2可能是最不坏的选项。
https://stackoverflow.com/questions/70768172
复制相似问题
腾讯云开发者
