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 撤销列表补充，别一上来就上黑名单换掉无状态验签
• How does JWKS-based verification work, and why does it fit cross-service scenarios better than a shared secret?JWKS 验签是怎么工作的？为什么跨服务场景下它比共享密钥更合适？

  Common in ChinaCommon overseasBasic#auth#jwt#security

  How to reason about it · think before answering

  1. This is the giveaway question of the chapter, but it still separates people: can you turn key rotation into a concrete operational sequence rather than saying it is easier to manage?
  2. Describe the mechanism in three sentences. The issuer holds the private key and signs; the public key set is published at a fixed address (/.well-known/jwks.json here); the token header carries a kid, and the verifier picks the matching public key from the set. Verification needs only public material, so the endpoint is public by design.
  3. Then give three reasons, each as an operational action: rotation needs no synchronized deploy on both sides (publish the new public key, let both coexist, drop the old one after old tokens expire); the verifier holds verification power, not signing power, so compromising it does not let anyone forge tokens; and adding a caller does not scatter another copy of a secret.
  4. Volunteer the part people forget: verifying the signature is not the whole check. A valid signature only proves the issuer signed it. You still validate iss, aud and exp — and missing aud is the most common cross-service incident, because a token the issuer signed for a different downstream is equally well signed, so skipping audience means holding the door open for someone else's API.
  5. Two engineering details worth adding: cache the key set but refetch on an unknown kid, or rotation day becomes a mass failure; and allow a small clock skew on exp, but not so large that it cancels out the point of short lifetimes.
  6. Expect: so is HS256 unusable? Answer that it is fine when one service signs and verifies its own tokens, and it is faster. The criterion is whether signer and verifier sit in the same trust domain; across domains, asymmetric is mandatory. Framing it as a trade-off shows judgment rather than memorization.

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

  1. 这是本章的送分题，但送分题也有区分度：能不能把「密钥轮换」这件事讲成一个具体的运维动作，而不是一句「更方便管理」。
  2. 先讲机制，三句话：签发方持私钥签名，公钥集合挂在一个固定地址上（本课用 /.well-known/jwks.json）；令牌头部带一个 kid，验签方按 kid 从集合里挑对应的公钥；验签只用公钥，所以这个地址是公开的，谁都能拉。
  3. 再讲为什么比共享密钥好，三条都要落到运维动作上：轮换不用两边同时发版（新旧两把公钥并存一段时间，等老令牌自然过期再摘旧的）；验签方拿到的只是验签能力而不是签名能力，被入侵也伪造不出令牌；多一个调用方不用多散一份密钥出去。
  4. 然后主动补上最容易被忽略的一段：验签不等于验完。签名合法只说明「这确实是那个签发方签的」，还必须校验 iss、aud、exp——**漏掉 aud 是跨服务集成里最常见的事故**，因为签发方给别的下游服务签的令牌，签名一样合法，不校验受众就等于替别人的接口开门。
  5. 工程细节可以再加两条：公钥集合要缓存，但遇到没见过的 kid 要能主动重拉，否则轮换那一刻会集体失败；以及时钟偏移，exp 校验要留一点容忍度，但容忍度不能大到把短有效期的意义抵消掉。
  6. 可以预期的追问：那 HS256 是不是就不能用了？答「同一个服务自己签自己验时它没问题，而且更快」——判据是签名方和验签方是不是同一个信任域，跨了域就必须非对称。这么答显得你在做权衡而不是背结论。

  Key points

  • Mechanism: private key signs, public key set sits at a fixed URL, the token header carries a kid, the verifier selects by kid
  • Rotation needs no synchronized deploy: publish the new key, let both coexist, retire the old one after old tokens expire
  • The verifier gets verification power only, never signing power, so compromising it cannot forge tokens
  • Adding callers does not scatter more secrets; the public key being public is the design intent
  • Beyond the signature you must check iss, aud and exp — skipping aud opens your API to tokens signed for someone else
  • Cache the key set but refetch on an unknown kid; HS256 is still reasonable when one service signs and verifies its own tokens

  答题要点

  • 机制：私钥签名、公钥集合挂在固定地址、令牌头部带 kid、验签方按 kid 取公钥
  • 轮换不用两边同时发版：新旧公钥并存，等老令牌自然过期再摘旧的
  • 验签方只拿到验签能力而不是签名能力，被入侵也伪造不出令牌
  • 调用方增加不需要多散一份密钥，公钥公开本来就是设计意图
  • 验签之外必须校验 iss、aud、exp，漏掉 aud 等于替别的下游服务开门
  • 缓存公钥集合但要能按未知 kid 主动重拉；HS256 在同一信任域内自签自验仍然是合理选择