我对OAuth2access_token缺少一些理解，希望有人能解释或指导我缺少什么。
我使用Microsoft Azure AD作为我的应用程序的身份验证提供者，我使用成功身份验证后返回的id_token来扩展它，并使用一些额外的数据自定义到我的应用程序(以方便授权)。
我正在做这个抛出JWT。签名，我从id_token解码数据并添加数据，然后我使用保存在服务器上的密钥对其签名。
我的问题是,我可以为access_token做同样的事情吗?当我想这么做的时候，我得到了授权。我做错了什么吗?或者这是不可能的?为什么会发生这种情况，我没有发现任何向MS发出的请求来验证我的新签名access_token。
永远不要更改发出的令牌——这是不正确的做法。但是你关于使用特定领域声明的观点是完全有效的——所有现实世界的系统都需要这些来进行授权。
选项1
一些专业提供商可以在令牌发布时联系您的api，以获得要包含在令牌中的特定领域数据。请参阅security文章了解其工作原理。我不认为Azure AD支持这个。
最好避免在返回给互联网客户端的可读令牌中泄露敏感数据。如果您在ID令牌或访问令牌中包含姓名，电子邮件等，则可能会在PEN测试中标记，因为它是个人身份信息，并且透露它可能与GDPR等法规相冲突。
security建议通过不透明的引用令牌格式(通过幻影令牌模式)发布访问令牌来保护它们。
选项2
Azure AD的一个可用选项是采用以下方法:
-
当第一次收到访问令牌时，在API中查找额外的域特定声明，然后缓存具有相同访问令牌的进一步API请求的结果。请参阅我的Azure AD代码示例类，了解构建自定义claimprincipal的一些代码。请注意，API将继续对每个请求验证JWT。
-
如果UI需要额外的特定于域的声明，那么从你的API提供它们，它可以从它的claimprincipal返回OAuth User Info和特定于域的数据到UI。请参阅这个API控制器类了解其外观。就我个人而言，我总是这样做，从不在ui中读取ID令牌——它也应该永远不会读取访问令牌。
应用程序与Azure互动广告,收到ID标记后对用户进行身份验证。应用程序在与api交互时使用访问令牌和刷新令牌.
-
id_token是一个JSON Web令牌(JWT)，它具有用户配置文件属性以声明的形式。使用ID令牌应用程序，用于获取用户信息，如用户名，电子邮件。
-
访问令牌另一方面是凭据，可以应用程序用来访问API．因此，如果您需要应用程序访问api，则使用访问令牌，您可以按照Tiny Wang
提供的建议步骤进行操作。 -
与id令牌类似，访问令牌也有签名，但它们没有签名加密。根据IETF OAuth (RFC 6749)标准规范，每个访问令牌可以有不同的格式和结构而id令牌应该是JWT格式。
-
验证id_token或access_token,你的应用验证令牌的签名和声明。要验证访问令牌，你的应用还应该验证发行者、受众和用户签字标记。
-
所以在生产应用程序中，您应该通过指定获得id令牌"
id_token+code"或"id_token+token"作为response_type进行验证验证是否正确成功。意思是它使用用于身份验证的id_token和交换access_token的"代码"访问资源进行授权。 -
简而言之，id_token用于标识已通过身份验证的用户访问令牌用于证明对受保护资源的访问权限。
有关访问令牌和id令牌的信息，请参阅此。