✅已解决 ｜ 后端如何选择使用 id_token 还是 access_token

答疑解惑 常见 FAQ
1

读过了 concepts/access-token-vs-id-token 并了解：

  • id_token 用于同自建应用的 backend 进行通信
  • access_token 用于同 resource server 进行通信

但是，如果我的 backend 和 resouce server 同一个呢？

假设我的系统有一个 frontend 和一组 backend。

  • frontend 是一个平凡的 SPA 应用
  • backend 暴露了 grpc，restful，graphql 等一系列 endpoints。所有的 endpoints 都是同时暴露给 frontend 和其他想用 API 的用户的
    • backend 中的特定 actions 是与 token sub 相关的。比如，对于不同的 token.sub，因为 read permission 的问题，他们能获取到的 entities 是不同的，某些 entities 对某些 sub 是不可访问的，需要被忽略
      • 这对 access_token 和 id_token 的 sub 都适用
  • backend 在与 frontend 交互时，应当使用 id_token，且不考虑 consent workflow；但在与通过 API 的用户交互时，应当使用 access_token 并考虑 scope（只有 scope 中的 action 可以使用，其他的 actions 会被 backend 驳回）
  • 所有 auth 相关的操作仅用标准 oidc endpoints（node-openid-client 和 oidc-client-ts 之类的），不用特定平台的特定 sdk

所以想问的是：

  • 这个设计合理吗？一个同时兼容 id_token 和 access_token 的 backend 是可行的吗？
  • 因为不想与特定平台绑定得太紧，所以我的想法是把 user 实体和 role 放在 backend，仅仅把 consent workflow 需要的 scope/permission 放在 authing。这个设计是可行的吗？
2

根据 https://github.com/IdentityServer/IdentityServer3/issues/2015#issue-110996731 到 https://github.com/IdentityServer/IdentityServer3/issues/2015#issuecomment-147933172 的讨论。对于一个前后端分离的应用来说：

  • id_token 是 auth server（如 authing）发给前端的 authT 证明，被用来证明用户已经经由 auth server 登录。
  • access_token 是前后端交互时的 Authorization Header，存有 scope 信息，用来向后端证明用户已经同意了 auth server 的 consent workflow
  • refresh_token 在 Authorization Code flow with PKCE 中应该是可用的，见 https://www.pingidentity.com/en/resources/blog/post/refresh-token-rotation-spa.html
3

没有完全明白，可以单独沟通一下不，可以把你的联系方式发送到我的邮箱 gaoyang@authing.cn

4

请问我是哪里没有描述清楚呢？在这个帖子下交流，我觉得帮助到更多有类似疑问的人。

5

可以的。Authing 只用来做认证，你可以通过 id token 找到用户 id，然后根据用户 id 在自己的服务器查询用户的角色权限

6

是的，我现在也是这么做的。之前是单纯没理解 id_token 和 access_token 该在什么场景用。现在理解了。
目前的设计是，我只需要 authing 的 scope 信息（因为签出 access_token 的时候，auth server 必须要知道 scope 相关的信息，其实即使是 scope 信息我都不想放在 auth server 上），其他的东西全放在 backend 中，最大限度减少对单一平台的依赖。