Interview Bank

From Frontend Engineer to Agent Engineer in 30 Days

D19 Cross-Service Agent Integration: Minting a User-Level JWT, JWKS Signature Verification, the inject/memory/usage Interfaces, Idempotent externalId

• For service-to-service calls, would you use a service token or a user token? When does each apply?两个服务之间调用，你会用服务级令牌还是用户级令牌？分别适用于什么场景？

  Common in ChinaCommon overseasIntermediate#auth#security#api-design

  How to reason about it · think before answering

  1. The hinge is each. Answering user tokens are safer turns a design question into a slogan — the interviewer wants the conditions under which each one is correct, and the concrete cost of choosing wrong.
  2. Give the deciding question first: is there a specific user behind this call? If yes, it must be a user token. If not — fetching config, reporting metrics, running a reconciliation batch — a service token is the right answer, and stuffing in a user id would fabricate audit history.
  3. Then state the three reasons as costs, not virtues. A leaked service token means every user's data at once; a leaked user token means one user, and it expires in fifteen minutes. Audit logs with a service token only show that some service called, never on whose behalf. And a downstream service doing per-user authorization is forced to trust a userId in the request body, which the caller writes freely.
  4. Add the production view: it is rarely either-or. Real systems use the service credential to obtain user tokens — the caller proves who it is once, then mints a short-lived token representing one user. The service credential then appears only at the minting step, never on every business call.
  5. Expect: what if a token leaks? Answer in two layers — a short lifetime (fifteen minutes here) does most of the containment, and a jti denylist is the supplement. Do not lead with a denylist: it puts a database lookup in front of every verification and gives away the whole point of stateless verification.
  6. Expect: how fine-grained should scopes be? Offer a usable rule — split along asymmetric risk. A bad read leaks information; a bad write poisons data that keeps influencing every later turn. So read and write always split; finer than that only if a real caller genuinely needs just one half.

  分析过程 · 先想清楚再作答

  1. 题眼在「分别」。答「用户级更安全」就把一道设计题做成了口号题——面试官想看你能不能说出两者各自成立的条件，以及选错的具体代价。
  2. 先给判断依据，一句话就能拆开：这次调用**有没有一个具体的用户在背后**。有，就必须是用户级；没有（拉配置、上报指标、跑对账批处理），服务级才是对的，硬塞一个用户 id 进去反而是伪造审计记录。
  3. 然后把用户级的三条理由说成代价而不是优点：服务级令牌泄露一次等于全量用户数据泄露，用户级泄露一张只丢一个用户且十五分钟自动作废；服务级在审计日志里只能查到「某服务调了一次」，查不到替谁操作；下游做用户级权限判断时，服务级令牌逼着它去信请求体里的 userId，而那是调用方可以随便写的。
  4. 补一句生产视角：两者不是二选一，真实系统里常常是「服务级令牌用来换用户级令牌」——调用方先用自己的服务凭证证明自己是谁，再申请一张代表某个用户的短期令牌。这样服务凭证只出现在铸造这一步，不出现在每一次业务调用里。
  5. 可以预期的追问一：令牌泄露了怎么办？答案要分两层——短有效期（本课 15 分钟）是止损的主力，撤销列表按 jti 拉黑是补充；不要上来就说「用黑名单」，那等于给每次验签加一次数据库查询，把无状态验签的好处全赔进去了。
  6. 可以预期的追问二：那 scope 该切多细？给一条可操作的判据——按「读写不对称的风险」切，读错了泄露信息、写错了污染数据且会持续影响后续每一轮对话，所以 read 和 write 必须分开；再细就要看有没有真实的调用方只需要其中一半。

  Key points

  • The deciding question is whether a specific user stands behind the call: yes means user token, no (config, metrics, reconciliation) means service token
  • A leaked service token exposes every user; a leaked user token exposes one and expires on its own
  • Auditing has to reach a person — only the sub claim answers who the call was made on behalf of
  • With a service token the downstream must trust a userId in the request body, which the caller can forge
  • Common production shape: the service credential only buys short-lived per-user tokens and never appears on business calls
  • After a leak, short lifetimes do the containment and a jti denylist supplements it — do not trade away stateless verification by default

  答题要点

  • 判断依据是「这次调用背后有没有一个具体用户」：有就用用户级，没有（配置、指标、对账批处理）才用服务级
  • 服务级令牌泄露的爆炸半径是全量用户，用户级只影响一个用户且短期自动失效
  • 审计要能落到人：只有 sub 字段能回答「当时是替谁操作的」
  • 下游要做用户级权限判断时，服务级令牌逼着它去信请求体里的 userId，而那是调用方可以伪造的
  • 生产里常见组合：服务凭证只用来换取代表某个用户的短期令牌，不出现在每次业务调用里
  • 泄露后的止损顺序是短有效期优先、jti 撤销列表补充，别一上来就上黑名单换掉无状态验签