flipped-aurora/gin-vue-admin · error

无效签名

Error message

无效签名

What it means

TokenSignatureInvalid is returned by ParseToken when the JWT's signature fails verification: the token was signed with a key different from JWT.SigningKey, or its payload/signature segments were altered after issuance.

Source

Thrown at server/utils/jwt.go:22

	"context"
	"errors"
	"time"

	"github.com/flipped-aurora/gin-vue-admin/server/global"
	"github.com/flipped-aurora/gin-vue-admin/server/model/system/request"
	jwt "github.com/golang-jwt/jwt/v5"
)

type JWT struct {
	SigningKey []byte
}

var (
	TokenValid            = errors.New("未知错误")
	TokenExpired          = errors.New("token已过期")
	TokenNotValidYet      = errors.New("token尚未激活")
	TokenMalformed        = errors.New("这不是一个token")
	TokenSignatureInvalid = errors.New("无效签名")
	TokenInvalid          = errors.New("无法处理此token")
)

func NewJWT() *JWT {
	return &JWT{
		[]byte(global.GVA_CONFIG.JWT.SigningKey),
	}
}

func (j *JWT) CreateClaims(baseClaims request.BaseClaims) request.CustomClaims {
	bf, _ := ParseDuration(global.GVA_CONFIG.JWT.BufferTime)
	ep, _ := ParseDuration(global.GVA_CONFIG.JWT.ExpiresTime)
	claims := request.CustomClaims{
		BaseClaims: baseClaims,
		BufferTime: int64(bf / time.Second), // 缓冲时间1天 缓冲时间内会获得新的token刷新令牌 此时一个用户会存在两个有效令牌 但是前端只留一个 另一个会丢失
		RegisteredClaims: jwt.RegisteredClaims{
			Audience:  jwt.ClaimStrings{"GVA"},                   // 受众
			NotBefore: jwt.NewNumericDate(time.Now().Add(-1000)), // 签名生效时间

View on GitHub (pinned to 3136500ef3)

Solutions

  1. Ensure every server instance uses the same JWT.SigningKey value in config.yaml (or shared secret manager).
  2. Re-login/re-issue the token after any signing-key rotation.
  3. If this is a dev/prod mix-up, use the token issued for the environment you are calling.
  4. Diff the signing key against the issuer's to confirm which mismatch exists before rotating.

Example fix

// before
# node A config.yaml
jwt:
  signing-key: 'abc'
# node B config.yaml
jwt:
  signing-key: 'xyz'   # tokens from A fail on B: 无效签名
// after
jwt:
  signing-key: 'abc'   # identical on all nodes
Defensive patterns

Strategy: validation

Validate before calling

// ops check before deploy
// grep -r 'signing-key' server/config.yaml  -> must match issuer's key
if cfg.JWT.SigningKey == "" || cfg.JWT.SigningKey != expectedKey {
    return errors.New("signing key mismatch across nodes")
}

Try / catch

claims, err := utils.ParseToken(token)
if errors.Is(err, utils.TokenSignatureInvalid) {
    // token from another environment or tampered: reject, force re-login
    return nil, ErrSignatureMismatch
}

Prevention

When it happens

Trigger: Tokens issued by an environment whose JWT.SigningKey differs from the validating server's config; manually edited tokens; key rotation on the server invalidating previously issued tokens.

Common situations: Multi-node deployments with inconsistent config.yaml signing keys; dev/prod keys mixed up (token from dev used against prod); a config change rotating the key while clients still hold old tokens.

Related errors


AI-assisted analysis of flipped-aurora/gin-vue-admin@3136500ef3 (2026-08-31). Data as JSON: /api/errors/02da42ccf6737126. Report an issue: GitHub.