如果访问令牌具有所有声明并且可以撤销，为什么还要使用 openid connect ID 令牌？
Why use openid connect ID token if the access token had all the claims and can be revoked?
我在 ASP.NET 核心 2.2 AddJwtBearer 中使用 oauth2 授权代码流。我的令牌端点 returns JWT 访问令牌包含检查用户权限所需的所有声明。
我可以将此令牌作为任何 Web API 调用的承载者发送，标准 .net 代码可以使用这些声明来检查权限，例如 [Authorize(Policy="somePolicy")]。
其中一项声明指向我们可以撤销的内部会话密钥。
所以我的问题是为什么我需要 ID 令牌甚至刷新令牌？
声明和其他详细信息都在访问令牌中，那么 ID 令牌会添加什么？
如果信息在 Auth 令牌中，必须进一步调用 userinfo 端点发送是一种浪费吗？
如果我可以撤销 Auth 令牌指向的会话，我肯定不需要刷新令牌并且可以拥有更长寿命的 Auth 令牌？
我已经阅读了很多示例和比较，但是仅 oauth2 和使用 openid connect 增强的大多数计算似乎是使用非常基本的 oauth2 而不使用 JWT 等，因此编写是为了夸大差异。
所以我不清楚两者何时使用相同的授权代码流和 JWT 令牌，在我的情况下使用 id 令牌的团队优势是什么？？
鉴于您的上下文，OpenId Connect 似乎对于您的情况而言不是必需的。当您实施单点登录 (SSO) 时，它确实会增加价值。在这种情况下，身份令牌也可以用于 SSO 注销。
在访问令牌中额外声明身份也是一种浪费。必须在每次通话时发送所有这些信息。特别是当您只需要一次信息时（Spa 可能会将信息保存在内存中）。最好让一些 api（端点）在请求时公开信息。
关于访问令牌，您无法撤销它。您可以撤销授权，但访问令牌在过期之前仍然有效。您希望在评估策略之前尽快使管道中的无效访问令牌短路。
请注意，api 可以使用内部会话密钥撤销访问权限的情况并不常见。大多数 api 是 'session-less' 并且完全依赖访问令牌。因为这就是 JWT 的目的，它是独立的，不必联系权威机构来验证令牌。
也许您可以使用长期访问令牌，因为在您的情况下，授权是在另一个级别确定的。但是您是否能够检测到令牌何时被泄露？你要在哪里检查它？在每个 api 和客户中？或者你更愿意让当局来处理它（单一责任）？
在实施安全性时，您应该查看设计、责任、在哪里做什么。让颁发令牌的机构负责身份验证和 client/resource 授权。 Api，作为实施业务规则（策略）的资源，可以处理（用户）授权。
长寿命令牌的问题在于，当它落入坏人之手时，它会允许访问直到它过期，或者在您的情况下，直到您检测到有问题为止。短期令牌总是允许短时间访问，这使得黑客几乎不值得在可以使用的时间获得令牌。
对于短期访问令牌，您将不得不使用刷新令牌。授权机构可以在每次调用时验证是否应颁发新的访问令牌。当然这里算一样的，这只适用于你实际是在验证请求的情况。代币本身并不安全。您必须添加一定程度的安全性，例如检查IP地址。但是有权处理它并使用一次性刷新令牌确实增加了安全性。
根据我使用 oidc/oauth2 的经验，访问令牌主要用于授予客户端应用程序对资源的访问权限（代表用户）。其中范围声明定义了可访问的功能，子声明标识了用户。
授权可以在不同级别上实施，不必是访问令牌的一部分。事实上，权限根本不应该是访问令牌的一部分。
所以您的设置可能没问题。但出于已经提到的原因，我不会使用长期访问令牌。另外，它们是不可管理的。当流程发生某些变化时，您无法更新访问令牌，例如添加范围时。
我在 ASP.NET 核心 2.2 AddJwtBearer 中使用 oauth2 授权代码流。我的令牌端点 returns JWT 访问令牌包含检查用户权限所需的所有声明。
我可以将此令牌作为任何 Web API 调用的承载者发送，标准 .net 代码可以使用这些声明来检查权限，例如 [Authorize(Policy="somePolicy")]。
其中一项声明指向我们可以撤销的内部会话密钥。
所以我的问题是为什么我需要 ID 令牌甚至刷新令牌？ 声明和其他详细信息都在访问令牌中，那么 ID 令牌会添加什么？ 如果信息在 Auth 令牌中，必须进一步调用 userinfo 端点发送是一种浪费吗？ 如果我可以撤销 Auth 令牌指向的会话，我肯定不需要刷新令牌并且可以拥有更长寿命的 Auth 令牌？
我已经阅读了很多示例和比较，但是仅 oauth2 和使用 openid connect 增强的大多数计算似乎是使用非常基本的 oauth2 而不使用 JWT 等，因此编写是为了夸大差异。 所以我不清楚两者何时使用相同的授权代码流和 JWT 令牌，在我的情况下使用 id 令牌的团队优势是什么？？
鉴于您的上下文，OpenId Connect 似乎对于您的情况而言不是必需的。当您实施单点登录 (SSO) 时，它确实会增加价值。在这种情况下，身份令牌也可以用于 SSO 注销。
在访问令牌中额外声明身份也是一种浪费。必须在每次通话时发送所有这些信息。特别是当您只需要一次信息时（Spa 可能会将信息保存在内存中）。最好让一些 api（端点）在请求时公开信息。
关于访问令牌，您无法撤销它。您可以撤销授权，但访问令牌在过期之前仍然有效。您希望在评估策略之前尽快使管道中的无效访问令牌短路。
请注意，api 可以使用内部会话密钥撤销访问权限的情况并不常见。大多数 api 是 'session-less' 并且完全依赖访问令牌。因为这就是 JWT 的目的，它是独立的，不必联系权威机构来验证令牌。
也许您可以使用长期访问令牌，因为在您的情况下，授权是在另一个级别确定的。但是您是否能够检测到令牌何时被泄露？你要在哪里检查它？在每个 api 和客户中？或者你更愿意让当局来处理它（单一责任）？
在实施安全性时，您应该查看设计、责任、在哪里做什么。让颁发令牌的机构负责身份验证和 client/resource 授权。 Api，作为实施业务规则（策略）的资源，可以处理（用户）授权。
长寿命令牌的问题在于，当它落入坏人之手时，它会允许访问直到它过期，或者在您的情况下，直到您检测到有问题为止。短期令牌总是允许短时间访问，这使得黑客几乎不值得在可以使用的时间获得令牌。
对于短期访问令牌，您将不得不使用刷新令牌。授权机构可以在每次调用时验证是否应颁发新的访问令牌。当然这里算一样的，这只适用于你实际是在验证请求的情况。代币本身并不安全。您必须添加一定程度的安全性，例如检查IP地址。但是有权处理它并使用一次性刷新令牌确实增加了安全性。
根据我使用 oidc/oauth2 的经验，访问令牌主要用于授予客户端应用程序对资源的访问权限（代表用户）。其中范围声明定义了可访问的功能，子声明标识了用户。
授权可以在不同级别上实施，不必是访问令牌的一部分。事实上，权限根本不应该是访问令牌的一部分。
所以您的设置可能没问题。但出于已经提到的原因，我不会使用长期访问令牌。另外，它们是不可管理的。当流程发生某些变化时，您无法更新访问令牌，例如添加范围时。