golang实现jwt认证的核心是生成带用户身份信息的签名token并验证其有效性，首先需使用github.com/golang-jwt/jwt/v5库定义包含用户id、角色等信息并嵌入jwt.registeredclaims的自定义结构体myclaims，接着通过hs256算法和密钥生成token，再在后续请求中解析和验证token的签名、过期时间及声明，确保请求合法性，该方式无状态且适合分布式系统，实际应用中常结合中间件从authorization头提取token进行验证，并将用户信息存入上下文供后续处理使用，同时必须通过环境变量或密钥管理服务如vault、aws kms等安全管理密钥，避免硬编码，为平衡安全性与用户体验应采用短效access token配合长效refresh token机制，其中refresh token需存储于http only cookie或安全存储中并支持一次性使用和吊销，还可选用rs256等非对称算法实现服务间安全验证，扩展自定义claims时需避免敏感信息明文存储，可通过jti实现黑名单防止重放攻击，利用aud和iss字段限制token作用范围，并设置时钟偏差容忍度应对服务器时间差异，从而构建完整安全的jwt认证体系。
用Golang实现JWT认证，核心在于生成一个带有用户身份信息的签名字符串（Token），并在后续请求中验证这个签名的有效性，确保请求的合法性。这是一种非常流行的无状态认证方式，特别适合分布式系统。
在我看来，Golang处理JWT真是得心应手，主要得益于它强大的标准库和社区生态。要搞定JWT的生成和验证，我们通常会用到像
github.com/golang-jwt/jwt/v5
生成Token
立即学习“go语言免费学习笔记（深入）”；
生成Token其实就是把一些关键信息（比如用户ID、角色等）放进一个结构体里，然后用一个秘密的密钥去签名。这个过程有点像你给一份重要文件盖上自己的私章，证明这是你发出去的。
首先，我们需要定义一个包含我们自定义信息的结构体，它要嵌入
jwt.RegisteredClaims
package main
import (
"time"
"github.com/golang-jwt/jwt/v5"
)
// 定义我们自己的Claims结构，包含用户ID和角色，同时嵌入jwt.RegisteredClaims
type MyClaims struct {
UserID string `json:"user_id"`
UserRole string `json:"user_role"`
jwt.RegisteredClaims
}
// GenerateToken 用于生成JWT Token
func GenerateToken(userID, userRole, secretKey string, expireDuration time.Duration) (string, error) {
// 设置Token的过期时间
expirationTime := time.Now().Add(expireDuration)
// 创建Claims
claims := &MyClaims{
UserID: userID,
UserRole: userRole,
RegisteredClaims: jwt.RegisteredClaims{
ExpiresAt: jwt.NewNumericDate(expirationTime), // 过期时间
IssuedAt: jwt.NewNumericDate(time.Now()), // 签发时间
Issuer: "my-auth-service", // 签发者
Subject: userID, // 主题
},
}
// 使用HS256签名算法创建一个新的Token
token := jwt.NewWithClaims(jwt.SigningMethodHS256, claims)
// 签名Token
tokenString, err := token.SignedString([]byte(secretKey))
if err != nil {
return "", err
}
return tokenString, nil
}验证Token
验证Token就复杂一点了，需要解析Token字符串，然后用同样的密钥去验证签名是否正确，同时还要检查Token有没有过期，或者有没有被篡改。这个过程就像是拿到那份文件后，用你的私章去比对，看是不是真的，有没有被动过手脚。
package main
import (
"errors"
"github.com/golang-jwt/jwt/v5"
)
// ValidateToken 用于验证JWT Token的有效性
func ValidateToken(tokenString, secretKey string) (*MyClaims, error) {
// 解析Token字符串
token, err := jwt.ParseWithClaims(tokenString, &MyClaims{}, func(token *jwt.Token) (interface{}, error) {
// 验证签名方法是否是HS256
if _, ok := token.Method.(*jwt.SigningMethodHMAC); !ok {
return nil, errors.New("unexpected signing method")
}
return []byte(secretKey), nil
})
if err != nil {
// 错误处理，比如Token过期、签名无效等
var ve *jwt.ValidationError
if errors.As(err, &ve) {
if ve.Errors&jwt.ValidationErrorMalformed != 0 {
return nil, errors.New("token is malformed") // Token格式不正确
} else if ve.Errors&jwt.ValidationErrorExpired != 0 {
return nil, errors.New("token is expired") // Token已过期
} else if ve.Errors&jwt.ValidationErrorNotValidYet != 0 {
return nil, errors.New("token not active yet") // Token还未生效
} else {
return nil, errors.New("couldn't handle this token") // 其他错误
}
}
return nil, err
}
// 检查Token是否有效
if !token.Valid {
return nil, errors.New("invalid token")
}
// 提取Claims
claims, ok := token.Claims.(*MyClaims)
if !ok {
return nil, errors.New("couldn't parse claims")
}
return claims, nil
}在实际的Web应用中，我们通常会把验证Token的逻辑封装成一个中间件。比如在Gin框架里，你可以在请求到达真正的业务逻辑之前，先通过中间件验证Token，如果通过了，就把用户信息放到Context里，方便后续的Handler使用。
// 这是一个Gin框架的中间件示例，用于验证JWT
/*
func AuthMiddleware(secretKey string) gin.HandlerFunc {
return func(c *gin.Context) {
tokenString := c.GetHeader("Authorization")
if tokenString == "" {
c.AbortWithStatus(http.StatusUnauthorized)
return
}
// 假设Token格式是 "Bearer <token>"
if !strings.HasPrefix(tokenString, "Bearer ") {
c.AbortWithStatus(http.StatusUnauthorized)
return
}
tokenString = tokenString[len("Bearer "):]
claims, err := ValidateToken(tokenString, secretKey)
if err != nil {
c.AbortWithStatus(http.StatusUnauthorized)
return
}
// 将用户信息存储到Context中，方便后续Handler获取
c.Set("userID", claims.UserID)
c.Set("userRole", claims.UserRole)
c.Next() // 继续处理请求
}
}
*/这段代码我注释掉了，因为它涉及到具体的Web框架，如果直接放出来可能会让文章显得有点跑题，但它的思路是这样的：从HTTP请求头里拿到Token，然后调用我们写好的
ValidateToken
密钥管理，这绝对是JWT认证里最容易被忽视，也最关键的一环。你用再复杂的算法，如果密钥泄露了，那所有努力都白费。我见过太多项目，把密钥硬编码在代码里，或者直接放在版本控制系统里，这简直是自寻死路。
首先，密钥必须足够复杂和随机，不能是简单的字符串。其次，绝对不能硬编码在代码里。我的经验是，至少要通过环境变量来传递密钥。在部署时，通过Docker、Kubernetes等工具的环境变量注入密钥，这样代码仓库里就不会出现敏感信息。
更高级一点的做法是使用专门的密钥管理服务（KMS），比如HashiCorp Vault、AWS Secrets Manager、Azure Key Vault或者Google Cloud Secret Manager。这些服务能够安全地存储、分发和轮换密钥。你的应用程序在启动时，通过认证机制从KMS获取密钥，而不是直接从配置文件或环境变量读取。这样即便服务器被攻陷，攻击者也难以直接获取到密钥本身，因为密钥只在内存中短暂存在。
密钥的轮换策略也得考虑。比如，每隔一段时间就更新一次密钥。这需要你的系统能同时支持新旧两个密钥进行验证，直到所有旧Token都过期，或者所有服务都更新到新密钥后，再彻底禁用旧密钥。这个过程听起来有点复杂，但对于长期运行的服务，这能显著提升安全性。
JWT本身是无状态的，一旦签发就不能撤销，这既是它的优点，也是一个潜在的安全隐患。为了平衡安全性和用户体验，我们通常会引入“刷新Token”（Refresh Token）机制。
为什么需要刷新Token？
想象一下，如果你的Access Token（就是我们上面生成的那个JWT）有效期很长，比如几天甚至几周，那一旦这个Token被窃取，攻击者就能长时间冒充用户。所以，Access Token通常设计成短生命周期，比如15分钟到1小时。
但Access Token太短，用户就得频繁登录，体验很差。这时，Refresh Token就派上用场了。Refresh Token的有效期可以很长，比如几天、几周甚至几个月。当Access Token过期后，客户端可以使用Refresh Token向认证服务器请求一个新的Access Token，而无需用户重新输入密码。
刷新机制的工作流程：
安全性考量：
Refresh Token由于其长效性，安全性要求更高。
当我们深入JWT，会发现除了基本的HS256（HMAC SHA-256）这种对称加密算法，还有RS256（RSA SHA-256）或ES256（ECDSA SHA-256）等非对称加密算法。HS256用同一个密钥进行签名和验证，简单高效。但如果你的认证服务和资源服务是独立的，或者需要跨多个服务共享验证能力，RS256就更合适了。认证服务用私钥签名，资源服务用公钥验证，公钥可以公开，私钥则严格保密，这样就避免了在所有服务间共享同一个秘密密钥的风险。在Golang里，
github.com/golang-jwt/jwt/v5
自定义Claims的扩展性： 我们上面定义的
MyClaims
payload
Token黑名单/撤销： JWT的无状态性是把双刃剑。一旦签发，除非过期，否则无法“撤销”。但在某些场景下，比如用户强制登出、密码重置、或者检测到账户异常，我们可能需要立即让某个Access Token失效。这时，就得引入一个“黑名单”机制。服务器端维护一个已失效Token的列表（通常是Token的JTI，即JWT ID），每次验证Token时，除了校验签名和过期时间，还要查一下这个Token是否在黑名单里。这无疑增加了服务器的状态管理负担，但为了特定的安全需求，这是一种必要的折衷。
JTI (JWT ID) 的妙用：
jwt.RegisteredClaims
Jti
Audience (aud) 和 Issuer (iss) 的应用： 在微服务架构中，你可能希望某个Token只能被特定的服务或客户端使用。
aud
iss
时钟偏差处理：
exp
nbf
iat
jwt.ParseWithClaims
WithLeeway
以上就是如何用Golang实现JWT认证 生成和验证Token的完整流程的详细内容，更多请关注php中文网其它相关文章！
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移，垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是，许多工具可以让 Windows 保持平稳运行。
广告Copyright 2014-2025 //m.sbmmt.com/ All Rights Reserved | php.cn | 湘ICP备2023035733号
617
收藏
