JWKS公开端点为何需要额外防护

在很多基于微服务或第三方登录的系统里，大家经常能看到一个公开的端点，比如常见的 /.well-known/jwks.json。不少人第一反应会觉得：既然这里面放的本来就是公钥，谁都能看，那直接扔在外网不设防不就行了吗？但如果站在旁观者的角度细看很多安全翻车的场景，就会发现这个看似人畜无害的“公开公告栏”，恰恰成了攻击者撕开系统口子的突破点。

公钥本身虽然不需要保密，但公开端点面临的第一个现实问题是算法混淆攻击。很多业务系统在用非对称加密（比如 RS256）给令牌签名，校验方理应去公开端点拉取 RSA 公钥来验签。可有些后端的鉴权逻辑写得太死板，完全跟着客户端请求头里的算法参数走。攻击者只要顺手从公开端点把公钥原文拖下来，再把请求头里的算法强行改成对称加密的 HS256，用这个公开可见的公钥当成密钥来签名。如果服务端没有严格限制算法，直接拿手里的公钥去跑对称验签，两边一算正好匹配，伪造的身份直接就放行了。一个本该公开的验签依据，就这么反过来成了攻击者手里的趁手武器。

除了被拿去配合算法漏洞搞事情，这个端点还极易成为微服务架构中的性能软肋。微服务和网关在处理用户请求时，往往需要根据令牌里的密钥标识去请求端点获取最新公钥。如果对外暴露的端点缺乏访问频率限制和缓存保护，或者服务内部没有做好公钥的本地缓存，攻击者完全可以故意发送带有一堆不存在密钥标识的请求，逼迫验证端反复穿透去拉取端点数据，甚至直接把公开端点当成拒绝服务攻击的目标。一旦端点被高频请求打崩，整个系统的身份认证链条就会瞬间瘫痪。

因此，公开端点对外开放并不等于“放任不管”。服务端在消费这些公钥数据时，必须显式锁定期望的算法白名单，拒绝听信客户端动态指定的加密算法。同时，公开端点本身必须加上严格的限流和合理的缓存策略，才能在保证公共服务可达的同时，不给攻击者留下钻空子的空间。