在过去的几周里，我读了很多关于OAuth 2.0/OpenID的文章，但有些事情仍然不清楚。我理解这些协议的目的：当OpenID发布一个ID令牌，通常是JWT，它告诉我用户是谁时，OAuth 2.0发布一个访问令牌，但这告诉用户的身份。我还读到id令牌的目的是在客户端软件中使用它，例如显示用户的姓名甚至他的个人资料图片。
我还阅读了强烈的建议，即当我实现自己的REST-API时，访问令牌应该是作为HTTP头授权的请求，而不是id令牌。
嗯，我有一个需求，也被称为API需要知道用户的身份。例如，如果用户调用创建新记录的POST操作，我也希望存储调用API的用户的电子邮件地址。
API需要知道标识的另一个原因是我们的当前设置：我们使用Azure Active Directory将组分配给用户。当我们需要检查API调用的授权时，我们会检查用户是否被分配到某个组。如果将分配的组作为访问令牌的声明提供，那就太好了，但不幸的是，这是Azure AD B2C缺乏的功能。已存在此功能请求。但是，除非这是可用的，否则我们需要调用MicrosoftGraph API来检索用户的分配组。在调用Graph API时，我们还需要知道调用API的用户的身份。
那么，您建议API授权的最佳实践是什么，尤其是在通过Azure AD/Azure AD B2C管理用户和访问权限时？
Azure AD B2C不提供在发布令牌时添加自定义声明或更具体地说(在您的情况下(用户组信息的功能。至少不是开箱即用。
但我认为您所需要的可以通过将自定义策略与相应的技术配置文件相结合来实现。
基本上，它允许您通过应用自定义行为来更改标准AD B2C用户流的行为。这样，就可以让Azure AD B2C通过技术配置文件请求用户组信息，以便在B2C用户流(例如登录(期间接收自定义声明，这些声明可以包含在已发布的令牌(id令牌或访问令牌(中。
由于您需要来自Azure AD的信息，我认为您可以将Azure Active Directory技术配置文件用于您的解决方案。
有关设置自定义策略的详细说明和教程，请参阅此处：https://mrochon.azurewebsites.net/2019/05/06/using-groups-in-azure-ad-b2c/
但在您开始使用自定义策略之前，我建议您确保Azure AD B2C提供的内置声明(属性((可以通过B2C的配置功能开箱即用地包含在已颁发的令牌中(不包括您需要的声明类型。看见https://learn.microsoft.com/en-us/azure/active-directory-b2c/user-profile-attributes
例如，您提到的用户的电子邮件地址已经作为内置属性提供。
还值得注意的是，您可以对访问令牌保密，并在首次收到新的访问令牌时在API中使用声明缓存设计来管理查找Graph用户信息。
这是一个可移植且易于扩展的解决方案，适用于任何授权服务器。我的一些资源可能会给你一些想法：
- Azure代码示例博客文章
- 一些相关的代码在有用的情况下