面试题库

30 天从前端工程师到 Agent 工程师

D19 跨服务 Agent 集成：用户级 JWT 铸造、JWKS 验签、inject/memory/usage 三类接口、幂等 externalId

• JWKS 验签是怎么工作的？为什么跨服务场景下它比共享密钥更合适？How does JWKS-based verification work, and why does it fit cross-service scenarios better than a shared secret?

  国内高频海外高频基础#auth#jwt#security

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

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

  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.

  答题要点

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