为什么我不应该在 IDP 上下文中使用 IdToken 作为不记名令牌？

Question

我正在使用 IDP 平台（这里是 AWS Cognito，但可能是 Auth0、OKTA 或 Keycloak），我想知道为什么我不鼓励使用它ID Token作为授权令牌。

更具体地说，我不会使用将用户授权委托给第三方应用程序的资源服务器。我的 IDP 将允许我在不同的应用程序上 SSO 所有用户。这里没有授予的范围，只有每个服务将用于授予或拒绝对资源（如电子邮件、用户 ID 或角色）的访问的身份验证声明。

我知道我可以为我的应用程序提供id token，然后为我的用户创建一些会话。id token鉴于可以在每个应用程序的后端检查其签名，为什么我不应该将其本身用作无状态会话令牌？

如果我应该使用access token-id token我可以用角色替换范围吗？或者我应该如何理解非委托上下文中的范围（“用户自己使用应用程序，而不给予许可”与“用户将所有范围给予 SPA 前端，它本身就是一个应用程序”）

顺便说一句，我正在通过前端的代码 PKCE 流恢复令牌。

Answer 1

ID 令牌仅包含有关用户以及用户如何进行身份验证的详细信息。因此它非常适合与用户创建更持久的 cookie 会话。ID 令牌的默认生命周期也很短，例如几分钟。您通常会在建立会话后丢弃 id-token。您永远不应该将 ID 令牌传递给其他服务。

访问令牌旨在让您能够访问该令牌所针对的 API。

当用户登录时，您请求访问某些范围，并且用户选择（同意）的范围，然后包含在访问令牌中（作为范围和受众声明）。

理论上，您可以将 ID 令牌传递给 API，而不是它应该如何工作。有关更多详细信息，请参阅此和此：

ID 令牌可以包含个人信息，如姓名、地址、电子邮件......（如驾驶执照/护照），但您不想将其泄露给第三方和 API，而是像在酒店一样，您会得到一个key ，旨在访问资源。您不使用您的身份来访问事物...... (2认同)
除非服务本身使用身份来授予授权，例如当您使用身份证去邮局取回包裹时。身份验证让他们授权您。就我而言，我的 API 是第一方。我的客户应该获得完整的访问权限，API 将根据用户 ID 和角色管理授权。实际上，我认为这些可以进入访问令牌 - 但不能使用 AWS Cognito，这可能是我困惑的根源 - 因为它们不完全遵循标准并鼓励 Id 令牌作为授权方法。 (2认同)
也许不是相同的上下文，但 Kubernetes 使用 id_tokens 作为授权手段：https://kubernetes.io/docs/reference/access-authn-authz/authentication/#openid-connect-tokens (2认同)