基于 RSA 非对称签名签发 JWT 的多系统单点登录实践

Fri, 12 Apr 2024 10:30:00 +0800

HMAC 差在哪

我们在某科技公司做统一认证中心时，多个业务系统（统一支付平台、数据治理服务、知识库问答服务等）各自维护登录态，用户在系统间跳转要反复登录。最初考虑过用 HMAC 对称签名签发 JWT，但那样每个下游系统都得持有同一把密钥，一处泄露，整个认证体系就崩了，轮换密钥还得挨个通知所有业务方，运维成本很高。

最后选了 RSA 非对称签名：统一认证中心持私钥签发 JWT，各业务系统只持公钥验签，私钥永远不离开认证中心。

私钥签发，公钥验签

整体流程是：用户在统一认证中心登录后，认证中心用 RSA 私钥签发 Access Token 和 Refresh Token，写进 Cookie 或通过 Authorization 头返回。业务系统在网关层用公钥本地验签，不需要每次回调统一认证中心，认证中心的压力也小。

JWT 里放了 user_id、app_id、team_id、roles、exp、iss、aud 这些声明。iss 固定为 passport，aud 是目标应用的 AppID，防止 token 被跨应用滥用。Access Token 有效期 2 小时，Refresh Token 7 天，刷新时轮转新 Token。

代码里就两个函数

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41


import (
 "crypto/rsa"
 "time"

 "github.com/golang-jwt/jwt/v5"
)

type Claims struct {
 UserID int64 `json:"user_id"`
 AppID string `json:"app_id"`
 TeamID int64 `json:"team_id"`
 Roles []string `json:"roles"`
 JTI string `json:"jti"`
 jwt.RegisteredClaims
}

func (s *Service) SignToken(c *Claims, ttl time.Duration) (string, error) {
 c.RegisteredClaims = jwt.RegisteredClaims{
 Issuer: "passport",
 Audience: jwt.ClaimStrings{c.AppID},
 ExpiresAt: jwt.NewNumericDate(time.Now().Add(ttl)),
 IssuedAt: jwt.NewNumericDate(time.Now()),
 ID: c.JTI,
 }
 tok := jwt.NewWithClaims(jwt.SigningMethodRS256, c)
 return tok.SignedString(s.privKey) // *rsa.PrivateKey
}

func ParseToken(pub *rsa.PublicKey, tokenStr string) (*Claims, error) {
 claims := &Claims{}
 tok, err := jwt.ParseWithClaims(tokenStr, claims, func(t *jwt.Token) (interface{}, error) {
 if _, ok := t.Method.(*jwt.SigningMethodRSA); !ok {
 return nil, fmt.Errorf("unexpected signing method: %v", t.Header["alg"])
 }
 return pub, nil
 })
 if err != nil || !tok.Valid {
 return nil, err
 }
 return claims, nil
}

验签逻辑放在各业务系统的 gRPC/HTTP 拦截器里，公钥通过配置中心下发。密钥轮转也支持：统一认证中心同时挂载新老两把私钥签发，公钥端点暴露 JWKS，业务系统定期拉取缓存。

alg=none 和另外两个坑

一是 alg=none 攻击。ParseWithClaims 的回调里必须校验 t.Method 是 RS256，不能信任 header 里的 alg。

二是 JWT 无法主动失效。我们用 Redis 维护黑名单，退出登录时把 jti 写进去，直到 token 自然过期才出黑名单。代价是每次请求多一次 Redis 查询，用 pipeline 加本地短缓存，压到可接受。

三是密钥轮转初期踩过坑：新私钥签发的 token，老业务系统还没拉到新公钥，验签直接失败。后来改成两把私钥灰度签发、JWKS 缓存 10 分钟、切换前先发公钥再切私钥，才算平稳。

后来

RSA 非对称签名让私钥收敛在认证中心，下游只持公钥，安全性和可扩展性都比 HMAC 好。配合短有效期 Access Token、Refresh Token 轮转和 Redis 黑名单，多业务系统的 SSO 就立住了。后续要接微信、企微、飞书登录，也只是多一种签发来源，验签侧一行不用改。

封面图：pixishared / Flickr · CC BY-SA 2.0

基于 RSA/SHA 签名的 OpenAPI 安全机制实现

Tue, 09 Jan 2024 10:30:00 +0800

为什么是 RSA，不是 HMAC

商户的服务器要调我们的下单、查询、退款接口，安全是第一道门槛。没法靠 Session，也不能让 AppSecret 在网络上裸奔。我参考了微信支付、支付宝那一套签名机制，最后定下 RSA 非对称签名加 SHA256 摘要，再用时间戳和随机串防重放。

为什么不全用 HMAC？因为 HMAC 是对称的，平台手里也捏着商户的密钥，一旦平台侧泄露，商户没法自证清白。换成 RSA 就没有这个问题：商户的私钥自己保管，平台只存公钥，谁发的、有没有被改，验签时责任边界清清楚楚。

签名串怎么拼

签名串的构造规则我们定得很死：

按 ASCII 升序排列所有非空业务参数（不含 sign、sign_type、sign_version）；
拼接成 key1=value1&key2=value2；
末尾追加上行请求体的 SHA256 摘要（JSON 原文，不做字段排序）；
商户私钥做 SHA256WithRSA 签名，Base64 编码后放在 X-Sign Header；
同时带 X-App-Id、X-Timestamp（秒）、X-Nonce。

定这么死是故意的。签名串最怕商户各自发挥：参数排序差一点、大小写差一点，验签就永远过不去，还查不出是哪边的问题。

构造逻辑我直接写成一个纯函数，平台和 SDK 共用：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


func BuildSignString(query url.Values, body []byte) string {
 keys := make([]string, 0, len(query))
 for k := range query {
 if k == "sign" || k == "sign_type" {
 continue
 }
 if v := query.Get(k); v != "" {
 keys = append(keys, k)
 }
 }
 sort.Strings(keys)

 var buf strings.Builder
 for i, k := range keys {
 if i > 0 {
 buf.WriteByte('&')
 }
 buf.WriteString(k)
 buf.WriteByte('=')
 buf.WriteString(query.Get(k))
 }
 sum := sha256.Sum256(body)
 buf.WriteString("&body_sha256=")
 buf.WriteString(hex.EncodeToString(sum[:]))
 return buf.String()
}

验签四道关

平台校验四件事：AppId 是否存在、时间戳是否在 5 分钟窗口内、Nonce 是否在 Redis 里没出现过（防重放）、签名是否通过。

验签挂在 Gin 的 OpenAPI 路由组上，是个中间件：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46


func RSAVerifyMiddleware(appDao dao.AppDAO, rdb *redis.Client) gin.HandlerFunc {
 return func(c *gin.Context) {
 appID := c.GetHeader("X-App-Id")
 timestamp := c.GetHeader("X-Timestamp")
 nonce := c.GetHeader("X-Nonce")
 sign := c.GetHeader("X-Sign")

 if appID == "" || timestamp == "" || nonce == "" || sign == "" {
 c.AbortWithStatusJSON(401, gin.H{"code": "MISSING_AUTH_HEADERS"})
 return
 }
 ts, err := strconv.ParseInt(timestamp, 10, 64)
 if err != nil || math.Abs(float64(time.Now().Unix()-ts)) > 300 {
 c.AbortWithStatusJSON(401, gin.H{"code": "TIMESTAMP_EXPIRED"})
 return
 }
 nonceKey := "openapi:nonce:" + appID + ":" + nonce
 if ok, _ := rdb.SetNX(c, nonceKey, 1, 10*time.Minute).Result(); !ok {
 c.AbortWithStatusJSON(401, gin.H{"code": "REPLAY_DETECTED"})
 return
 }

 app, err := appDao.FindByAppID(c, appID)
 if err != nil || app.Status != "ACTIVE" {
 c.AbortWithStatusJSON(401, gin.H{"code": "APP_NOT_FOUND"})
 return
 }
 body, _ := c.GetRawData()
 c.Request.Body = io.NopCloser(bytes.NewBuffer(body)) // 回放给后续 handler
 signStr := BuildSignString(c.Request.URL.Query(), body)

 pub, err := parseRSAPublicKey(app.PublicKey)
 if err != nil {
 c.AbortWithStatusJSON(401, gin.H{"code": "INVALID_PUBKEY"})
 return
 }
 hashed := sha256.Sum256([]byte(signStr))
 sig, _ := base64.StdEncoding.DecodeString(sign)
 if err := rsa.VerifyPKCS1v15(pub, crypto.SHA256, hashed[:], sig); err != nil {
 c.AbortWithStatusJSON(401, gin.H{"code": "SIGN_INVALID"})
 return
 }
 c.Set("app", app)
 c.Next()
 }
}

GetRawData 之后记得用 io.NopCloser 把 body 放回去，否则后续 ShouldBindJSON 会读到空。这是我第一次联调踩的坑。

四个权衡

第一是 GET 请求的 body 处理。GET 没有 body，我们约定 body_sha256 字段直接填空字符串的 SHA256（即 e3b0c442...），而不是省略这个字段。签名串结构稳定，SDK 不用写两套分支。

第二是 Nonce 的存储成本。Redis 存 10 分钟窗口的 Nonce，看着有压力，实际上按 AppId 隔离之后单商户 QPS 并不高，10 分钟过期自动回收，没必要上滑动窗口或布隆过滤器。

第三是密钥轮换。App 表里留了 public_key 和 public_key_prev 两个字段，轮换时新公钥进主字段、旧公钥降到 prev，中间件两把都试。商户有 24 小时灰度窗口，不会一刀切验签失败。

第四是要不要加密 body。平台已经全链路 HTTPS，签名本身防篡改，最后没做请求体加密，只有银行卡号这类敏感字段由业务层单独做字段级加密。给所有商户平添一层对接成本，不值。

上线之后

上线至今，没出过签名层面的安全事件。回头看，这套机制立得住，靠的是规则够死、边界够清：谁发的、有没有被改、是不是重放，一趟验签全解决。商户接入文档里我配了 Java、Python、Go 三份 SDK 示例，写文档花的功夫，比后来省下的联调时间少多了。

封面图：Simon A. Eugster / Wikimedia Commons · CC BY-SA 3.0

RSA on 姚玉亮的网络日志