社区的库 https://jwt.io/ 上列出了10个支持JWT的Golang库。 名称 地址 star 支持的registered字段 支持的签名算法 jwt-go github.com/dgrijalva/jwt-go 7571 exp、nbf 大部分 jose2go github.com/dvsekhvalnov/jose2go 135 无 除了EdDSA jose github.com/SermoDigital/jose 838 全部 除了EdDSA jwt github.com/robbert229/jwt 79 exp、nbf、iat HS256、HS512 go-jose github.com/square/go-jose 1530 无 除了EdDSA jwx github.com/lestrrat-go/jwx 275 全部 除了EdDSA jwt-auth github.com/adam-hanna/jwt-auth 179 exp、nbf、jti 大部分 gojwt github.com/nickvellios/gojwt 5 exp HS256 jwt/v3 github.com/gbrlsnchs/jwt/v3 332 全部 除了EdDSA jwt github.com/pascaldekloe/jwt 179 全部 全部 jwt gitlab.com/rucuriousyet/jwt 2 无 HS256、HS512 sjwt github.com/brianvoe/sjwt 65 全部 HS256 jwt github.com/cristalhq/jwt 57 全部 全部 payload中registered预定义的字段介绍： iss（issuer）：发起者 exp（expiration time）：过期时间 sub（subject）：主题 aud（audience）：受众 nbf（Not Before）：生效时间 iat（Issued At）：签发时间 jti（JWT ID）：编号 jwt-go使用指南 jwt-go在Go官方新的包管理站点的地址。 Medium原文链接。 原文使用mux本文使用gin，同时将jwt升级为v4版本，使用经典的MVC架构来实现，Github仓库点击这里。 JSON Web令牌（JWT）是一种更现代的身份验证方法。随着Web向客户端和服务器之间的更大距离转移，JWT提供了一种很好的替代传统基于cookie的身份验证模型的方法。 JWT为客户端提供了一种对每个请求进行身份验证的方法，而无需维护会话或将登录凭据重复传递给服务器。 使用基于令牌的方法的好处 跨域/CORS：Cookie + CORS在不同的域中不能很好地发挥作用。基于令牌的方法允许对任何域上的任何服务器进行AJAX调用，因为使用 HTTP Header 来传输用户信息。 无状态的：无需保留会话存储，令牌是一个独立的实体，可以传达所有用户信息。 CDN：可以通过CDN提供应用的所有资产（例如javascript，HTML，图像等），而服务器端只是API。 解耦：不受特定认证方案的束缚。令牌可以在任何地方生成，因此，只需要使用这一种验证方式，就可以从任何地方调用服务端的API。 面向移动设备：当开始在原声平台（iOS，Android，Windows 等）上工作时，cookie并不是使用安全API（必须处理cookie容器）的理想选择。采用基于令牌的方法可以大大简化这一过程。 CRSF（Cross-site request forgery）：由于不依赖Cookie，因此无需防御跨站点请求伪造。 样例代码 主要步骤： 创建Token对象 填充Token中Header和Payload 生成Token中的Signature 从HTTP请求中获取并验证Token import jwtv4 "github.com/dgrijalva/jwt-go/v4" // example-1 token := jwtv4.New(jwtv4.SigningMethodRS512) token.Claims = jwtv4.MapClaims{ "exp": time.Now().Add(time.Hour * time.Duration(settings.Get().JWTExpirationDelta)).Unix(), "iat": time.Now().Unix(), "sub": userUUID, } // example-2 token := jwtv4.NewWithClaims(jwtv4.SigningMethodRS512,jwtv4.MapClaims{ "exp": time.Now().Add(time.Hour * time.Duration(settings.Get().JWTExpirationDelta)).Unix(), "iat": time.Now().Unix(), "sub": userUUID, }) tokenString, err := token.SignedString(j.privateKey) 解析： Token是一个结构体，如下： type Token struct { Raw string // 原始令牌，解析令牌时填充 Method SigningMethod // 使用或将要使用的签名方法 Header map[string]interface{} // 令牌的第一段 Claims Claims // 令牌的第二段 Signature string // 令牌的第三段，解析令牌时填充 Valid bool // 判断令牌是否有效，解析/验证令牌时填充 } 创建Token对象使用New函数： func New(method SigningMethod) *Token // 其实New函数是对NewWithClaims函数的封装 func New(method SigningMethod) *Token { return NewWithClaims(method, MapClaims{}) } New函数需要一个SigingMethod类型的形参。 SigingMethod是一个接口类型： type SigningMethod interface { Verify(signingString, signature string, key interface{}) error // 如果签名有效，则返回nil Sign(signingString string, key interface{}) (string, error) // 返回编码后的签名或错误 Alg() string // 返回此方法的alg标识符（例如：“HS256”） } 根据Go语言的隐式接口规则，只要实现了上述三个方法的类型都可以作为New函数的形参。 jwt-go包中实现了ECDSA、HMAC、RSA三大类算法。 // ECDSA var ( SigningMethodES256 *SigningMethodECDSA SigningMethodES384 *SigningMethodECDSA SigningMethodES512 *SigningMethodECDSA ) // HMAC var ( SigningMethodHS256 *SigningMethodHMAC SigningMethodHS384 *SigningMethodHMAC SigningMethodHS512 *SigningMethodHMAC ) // RSA var ( SigningMethodRS256 *SigningMethodRSA SigningMethodRS384 *SigningMethodRSA SigningMethodRS512 *SigningMethodRSA ) payload部分可以使用预定义的，也可以使用自定义的。 JWT官方定义中，生成签名的算法是HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)这里需要一个secret字段。我们使用SignedString方法，这是整个过程中最消耗资源的地方。 func (t *Token) SignedString(key interface{}) (string, error) // 这里的key，可以用非对称加密算法生成的私钥 // 使用openssl工具生成公私钥对 openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout ${KEY_FILE} -out ${CERT_FILE} -subj "/CN=${HOST}/O=${HOST}" 到这里JWT制作完成，下面开始从HTTP请求中验证Token。 import ( jwtv4 "github.com/dgrijalva/jwt-go/v4" "github.com/dgrijalva/jwt-go/v4/request" ) token, err := request.ParseFromRequest(ctx.Request, request.OAuth2Extractor, func(token *jwtv4.Token) (interface{}, error) { if _, ok := token.Method.(*jwtv4.SigningMethodRSA); !ok { return nil, fmt.Errorf("unexpected signing method: %v", token.Header["alg"]) } else { return authBackend.PublicKey, nil } }) jwt的request子模块中有相应的函数ParseFromRequest和ParseFromRequestWithClaims。 func ParseFromRequest(req *http.Request, extractor Extractor, keyFunc jwt.Keyfunc, options ...ParseFromRequestOption) (token *jwt.Token, err error) func ParseFromRequestWithClaims(req *http.Request, extractor Extractor, claims jwt.Claims, keyFunc jwt.Keyfunc) (token *jwt.Token, err error) 从HTTP请求中提取并解析JWT令牌。它的行为与Parse相同，但是接受Request和Extractor而不是令牌字符串。Extractor接口允许自定义提取令牌的逻辑。库中提供了几种有用的实现，如下所示，同时可以通过ParseFromRequestOption来修改解析行为。 // OAuth2访问令牌的提取器。在“Authorization” Header 的“access_token”参数中查找令牌 var OAuth2Extractor = &MultiExtractor{ AuthorizationHeaderExtractor, ArgumentExtractor{"access_token"}, } 其中keyFunc是func(*Token) (interface{}, error)函数类型，解析方法使用此回调函数提供验证密钥。该函数接收已解析但未验证的令牌。这使你可以使用令牌头中的属性（例如“kid”）来标识要使用的密钥。
新闻：免费获取JWT手册并深入学习JWT！ 什么是JWT JSON Web Token（JWT）是一个开放标准（RFC 7519），它定义了一种紧凑且自包含的方式，用于在各方之间以JSON对象安全地传输信息。由于此信息是经过数字签名的，因此可以被验证和信任。可以使用secret（使用HMAC算法）或使用RSA/ECDSA的公私密钥对对JWT进行签名。 尽管可以对JWT进行加密以在双方之间提供保密性，但我们将重点放在已签名的令牌。签名的令牌可以验证其中包含的声明的完整性，而加密的令牌则将这些声明信息隐藏了起来。当使用公/私密钥对对令牌进行签名时，签名可以证明只有持有私钥的一方才是对其进行签名的一方。 何时使用JWT 以下是JSON Web令牌常用的场景： 授权：这是使用JWT的最常见方案。一旦用户登录，每个后续请求将包括JWT，从而允许用户访问该令牌允许的路由，服务和资源。单点登录是当今广泛使用JWT的一项功能，因为它的开销很小并且可以在不同的域中轻松使用。（解决跨域认证的另一种方式，session持久化）。 信息交换：JWT是在各方之间安全地传输信息的一种好方法。因为可以对JWT进行签名（例如，使用公/私密钥对），所以可以确定信息发送者的身份。另外，由于签名是使用header和payload计算的，因此还可以验证内容是否被篡改。 JWT的结构 JWT以紧凑的形式由三部分组成，这些部分由点（.）分隔，分别是： Header Payload Signature 因此，JWT通常如下所示，xxxxx.yyyyy.zzzzz。 让我们分解不同的部分。 Header Header通常由两部分组成：令牌的类型（在这里只能是JWT）和所使用的签名算法，例如HMAC、SHA256或RSA。例如： { "alg": "HS256", "typ": "JWT" } 然后，此JSON被Base64Url编码以形成JWT的第一部分。 上面代码中： alg属性表示签名的算法（algorithm），默认是 HMAC SHA256（写成 HS256）； typ属性表示这个令牌（token）的类型（type），JWT 令牌统一写为JWT。 Payload 令牌的第二部分是payload，其中包含声明。声明是有关实体（通常是用户）和其他数据的语句。共有三种类型的声明： registered public private registered 这是一组预定义的字段，不是强制性的，而是建议使用的，以提供一组有用的可互操作的声明。官方定义了7个字段： iss（issuer）：发起者 exp（expiration time）：过期时间 sub（subject）：主题 aud（audience）：受众 nbf（Not Before）：生效时间 iat（Issued At）：签发时间 jti（JWT ID）：编号 请注意，声明名称时仅使用三个字符代表，因为JWT是紧凑的。 public 这些可以由使用JWT的人员随意定义。但是为避免冲突，应在IANA JSON Web Token注册表中定义它们，或将其定义为包含抗冲突命名空间的URI。 private 这些是自定义声明，目的是在同意使用它们的各方之间共享信息，既不是注册声明也不是公共声明。 一个payload示例如下： { "sub": "1234567890", "name": "John Doe", "admin": true } 然后，对payload进行Base64Url编码，以形成JWT的第二部分。 请注意，对于已签名的令牌，此信息尽管可以防止篡改，但任何人都可以读取。除非将其加密，否则请勿将机密信息放入JWT的有效负载或报头元素中。 Signature 要创建签名部分，必须获取编码后的Header、编码后的payload，一个secret，Header中指定的算法，然后就可以对JWT进行签名。 例如，如果要使用HMAC SHA256算法，则将通过以下方式创建签名： # 生产的内容就是JWT的第三部分 HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret) 签名用于验证消息在此过程中是否被篡改，并且对于使用私钥进行签名的令牌，它还可以验证JWT的发送者的真实身份。 结果 最后生成的结果是由点分隔的被Base64-URL编码的三个字符串，可以在HTML和HTTP环境中轻松传递这些字符串，与基于XML的标准（例如SAML）相比，它更紧凑。 下图显示了一个JWT，它已对header和payload进行了编码，并用一个secret进行了签名。 如果想使用JWT，可以使用jwt.io Debugger解码，验证和生成JWT。 Base64URL 前面提到，Header 和 Payload 串型化的算法是 Base64URL。这个算法跟 Base64 算法基本类似，但有一些小的不同。 JWT 作为一个令牌（token），有些场合可能会放到 URL（比如 api.example.com/?token=xxx）。Base64 有三个字符+、/和=，在 URL 里面有特殊含义，所以要被替换掉： =被省略 +替换成- /替换成_ 这就是 Base64URL 算法。 JWT工作原理 授权 在认证登录中，当用户使用其凭据成功登录时，将返回JWT。由于令牌是凭据，因此必须格外小心以防止安全问题。通常，令牌的保留时间不应超过要求的时间。 由于缺乏安全性，也不应该将敏感的会话数据存储在浏览器存储中。 每当用户想要访问受保护的路由或资源时，用户代理（一般是浏览器）应该发送JWT，通常的做法是在Authorization请求头中使用Bearer schema。请求头的内容应如下所示：Authorization: Bearer <token>。 在某些情况下，这是一种无状态的授权机制。服务器的受保护路由将在Authorization请求头中检查有效的JWT，如果存在，则将允许用户访问受保护的资源。如果JWT包含必要的数据，则可以减少查询数据库中某些操作的需求，尽管这种情况并非总是如此。 如果在Authirization请求头中发送令牌，则跨域资源共享（CORS）不会成为问题，因为它不使用cookie。 另一种做法是，跨域的时候，JWT 就放在 POST 请求的数据体里面。 下图显示了如何获取JWT并将其用于访问API或资源： 应用程序或客户端向授权服务器请求授权。这是一种不同的授权流程执行。例如，典型的符合OpenID Connect规范的Web应用程序将使用授权代码流程访问/oauth/authorize端点。 授予授权后，授权服务器将访问令牌返回给应用程序。 应用程序使用访问令牌来访问受保护的资源（例如API）。 请注意，在使用签名令牌时，令牌或令牌中包含的所有信息都会暴露给用户或其他方，虽然他们无法更改它，因此不应将机密信息放入令牌中。 为何使用JWT 让我们谈谈与Simple Web Tokens（SWT）和Security Assertion Markup Language Tokens（SAML）相比，JSON Web Tokens（JWT）的好处。 JSON没有XML冗长，因此在编码时JSON会更小一些，从而使JWT比SAML更紧凑。这使得JWT是在HTML和HTTP环境中传递的不错的选择。 在安全方面，SWT只能通过HMAC算法使用共享密码进行对称签名。但是，JWT和SAML令牌可以使用X.509证书形式的公用/专用密钥对进行签名。与签名JSON的简单性相比，使用XML Digital Signature签名XML而不引入模糊的安全漏洞是非常困难的。 JSON解析器在大多数编程语言中都很常见，因为它们直接映射到对象。相反，XML中没有很自然的文档-对象映射。因此使用JWT比SMAL断言更容易。 在用法方面，JWT是在互联网上广泛使用的，这说明在多平台（有其实移动平台）场景下，客户端侧对JWT进行处理是很容易的。 如果想了解有关JWT的更多信息，或者在应用程序中使用它进行身份验证，请查看Auth0上的JWT登录页面。 JWT特点 JWT 默认是不加密，但也是可以加密的。生成原始 Token 以后，可以用密钥再加密一次。 JWT 不加密的情况下，不能将秘密数据写入 JWT。 JWT 不仅可以用于认证，也可以用于交换信息。有效使用 JWT，可以降低服务器查询数据库的次数。 JWT 的最大缺点是，由于服务器不保存 session 状态，因此无法在使用过程中废止某个 token，或者更改 token 的权限。也就是说，一旦 JWT 签发了，在到期之前就会始终有效，除非服务器部署额外的逻辑。 JWT 本身包含了认证信息，一旦泄露，任何人都可以获得该令牌的所有权限。为了减少盗用，JWT 的有效期应该设置得比较短。对于一些比较重要的权限，使用时应该再次对用户进行认证。 为了减少盗用，JWT 不应该使用 HTTP 协议明码传输，要使用 HTTPS 协议传输。