JWT

什么是JWT

在介绍JWT之前，我们先来回顾一下利用token进行用户身份验证的流程：

客户端使用用户名和密码请求登录
服务端收到请求，验证用户名和密码
验证成功后，服务端会签发一个token，再把这个token返回给客户端
客户端收到token后可以把它存储起来，比如放到cookie中
客户端每次向服务端请求资源时需要携带服务端签发的token，可以在cookie或者header中携带
服务端收到请求，然后去验证客户端请求里面带着的token，如果验证成功，就向客户端返回请求数据

这种基于token的认证方式相比传统的session认证方式更节约服务器资源，并且对移动端和分布式更加友好。其优点如下：

支持跨域访问：cookie是无法跨域的，而token由于没有用到cookie(前提是将token放到请求头中)，所以跨域后不会存在信息丢失问题
无状态：token机制在服务端不需要存储session信息，因为token自身包含了所有登录用户的信息，所以可以减轻服务端压力
更适用CDN：可以通过内容分发网络请求服务端的所有资料
更适用于移动端：当客户端是非浏览器平台时，cookie是不被支持的，此时采用token认证方式会简单很多
无需考虑CSRF：由于不再依赖cookie，所以采用token认证方式不会发生CSRF，所以也就无需考虑CSRF的防御

而JWT就是上述流程当中token的一种具体实现方式，其全称是JSON Web Token，官网地址：https://jwt.io/

通俗地说，JWT的本质就是一个字符串，它是将用户信息保存到一个Json字符串中，然后进行编码后得到一个JWT token，并且这个JWT token带有签名信息，接收后可以校验是否被篡改，所以可以用于在各方之间安全地将信息作为Json对象传输。JWT的认证流程如下：

首先，前端通过Web表单将自己的用户名和密码发送到后端的接口，这个过程一般是一个POST请求。建议的方式是通过SSL加密的传输(HTTPS)，从而避免敏感信息被嗅探
后端核对用户名和密码成功后，将包含用户信息的数据作为JWT的Payload，将其与JWT Header分别进行Base64编码拼接后签名，形成一个JWT Token，形成的JWT Token就是一个如同lll.zzz.xxx的字符串
后端将JWT Token字符串作为登录成功的结果返回给前端。前端可以将返回的结果保存在浏览器中，退出登录时删除保存的JWT Token即可
前端在每次请求时将JWT Token放入HTTP请求头中的Authorization属性中(解决XSS和XSRF问题)
后端检查前端传过来的JWT Token，验证其有效性，比如检查签名是否正确、是否过期、token的接收方是否是自己等等
验证通过后，后端解析出JWT Token中包含的用户信息，进行其他逻辑操作(一般是根据用户信息得到权限等)，返回结果

为什么要用JWT

传统Session认证的弊端

我们知道HTTP本身是一种无状态的协议，这就意味着如果用户向我们的应用提供了用户名和密码来进行用户认证，认证通过后HTTP协议不会记录下认证后的状态，那么下一次请求时，用户还要再一次进行认证，因为根据HTTP协议，我们并不知道是哪个用户发出的请求，所以为了让我们的应用能识别是哪个用户发出的请求，我们只能在用户首次登录成功后，在服务器存储一份用户登录的信息，这份登录信息会在响应时传递给浏览器，告诉其保存为cookie，以便下次请求时发送给我们的应用，这样我们的应用就能识别请求来自哪个用户了，这是传统的基于session认证的过程

然而，传统的session认证有如下的问题：

每个用户的登录信息都会保存到服务器的session中，随着用户的增多，服务器开销会明显增大
由于session是存在与服务器的物理内存中，所以在分布式系统中，这种方式将会失效。虽然可以将session统一保存到Redis中，但是这样做无疑增加了系统的复杂性，对于不需要redis的应用也会白白多引入一个缓存中间件
对于非浏览器的客户端、手机移动端等不适用，因为session依赖于cookie，而移动端经常没有cookie
因为session认证本质基于cookie，所以如果cookie被截获，用户很容易收到跨站请求伪造攻击。并且如果浏览器禁用了cookie，这种方式也会失效
前后端分离系统中更加不适用，后端部署复杂，前端发送的请求往往经过多个中间件到达后端，cookie中关于session的信息会转发多次
由于基于Cookie，而cookie无法跨域，所以session的认证也无法跨域，对单点登录不适用

JWT认证的优势

对比传统的session认证方式，JWT的优势是：

简洁：JWT Token数据量小，传输速度也很快
因为JWT Token是以JSON加密形式保存在客户端的，所以JWT是跨语言的，原则上任何web形式都支持
不需要在服务端保存会话信息，也就是说不依赖于cookie和session，所以没有了传统session认证的弊端，特别适用于分布式微服务
单点登录友好：使用Session进行身份认证的话，由于cookie无法跨域，难以实现单点登录。但是，使用token进行认证的话， token可以被保存在客户端的任意位置的内存中，不一定是cookie，所以不依赖cookie，不会存在这些问题
适合移动端应用：使用Session进行身份认证的话，需要保存一份信息在服务器端，而且这种方式会依赖到Cookie（需要 Cookie 保存 SessionId），所以不适合移动端

因为这些优势，目前无论单体应用还是分布式应用，都更加推荐用JWT token的方式进行用户认证

JWT结构

JWT由3部分组成：标头(Header)、有效载荷(Payload)和签名(Signature)。在传输的时候，会将JWT的3部分分别进行Base64编码后用.进行连接形成最终传输的字符串
J W T S t r i n g = B a s e 64 ( H e a d e r ) . B a s e 64 ( P a y l o a d ) . H M A C S H A 256 ( b a s e 64 U r l E n c o d e ( h e a d e r ) + “ . ” + b a s e 64 U r l E n c o d e ( p a y l o a d ) , s e c r e t ) JWTString = Base64(Header).Base64(Payload).HMACSHA256(base64UrlEncode(header) + “.” + base64UrlEncode(payload), secret) JWTString=Base64(Header).Base64(Payload).HMACSHA256(base64UrlEncode(header)+“.”+base64UrlEncode(payload),secret)

1.Header

JWT头是一个描述JWT元数据的JSON对象，alg属性表示签名使用的算法，默认为HMAC SHA256（写为HS256）；typ属性表示令牌的类型，JWT令牌统一写为JWT。最后，使用Base64 URL算法将上述JSON对象转换为字符串保存

{"alg": "HS256","typ": "JWT"
}

2.Payload

有效载荷部分，是JWT的主体内容部分，也是一个JSON对象，包含需要传递的数据。 JWT指定七个默认字段供选择

iss：发行人
exp：到期时间
sub：主题
aud：用户
nbf：在此之前不可用
iat：发布时间
jti：JWT ID用于标识该JWT

除以上默认字段外，我们还可以自定义私有字段，一般会把包含用户信息的数据放到payload中，如下例：

{"sub": "1234567890","name": "Helen","admin": true
}

请注意，默认情况下JWT是未加密的，因为只是采用base64算法，拿到JWT字符串后可以转换回原本的JSON数据，任何人都可以解读其内容，因此不要构建隐私信息字段，比如用户的密码一定不能保存到JWT中，以防止信息泄露。JWT只是适合在网络中传输一些非敏感的信息

3.Signature

签名哈希部分是对上面两部分数据签名，需要使用base64编码后的header和payload数据，通过指定的算法生成哈希，以确保数据不会被篡改。首先，需要指定一个密钥（secret）。该密码仅仅为保存在服务器中，并且不能向用户公开。然后，使用header中指定的签名算法（默认情况下为HMAC SHA256）根据以下公式生成签名
H M A C S H A 256 ( b a s e 64 U r l E n c o d e ( h e a d e r ) + “ . ” + b a s e 64 U r l E n c o d e ( p a y l o a d ) , s e c r e t ) HMACSHA256(base64UrlEncode(header) + “.” + base64UrlEncode(payload), secret) HMACSHA256(base64UrlEncode(header)+“.”+base64UrlEncode(payload),secret)
在计算出签名哈希后，JWT头，有效载荷和签名哈希的三个部分组合成一个字符串，每个部分用.分隔，就构成整个JWT对象

注意JWT每部分的作用，在服务端接收到客户端发送过来的JWT token之后：

header和payload可以直接利用base64解码出原文，从header中获取哈希签名的算法，从payload中获取有效数据

signature由于使用了不可逆的加密算法，无法解码出原文，它的作用是校验token有没有被篡改。服务端获取header中的加密算法之后，利用该算法加上secretKey对header、payload进行加密，比对加密后的数据和客户端发送过来的是否一致。注意secretKey只能保存在服务端，而且对于不同的加密算法其含义有所不同，一般对于MD5类型的摘要加密算法，secretKey实际上代表的是盐值

JWT的种类

其实JWT(JSON Web Token)指的是一种规范，这种规范允许我们使用JWT在两个组织之间传递安全可靠的信息，JWT的具体实现可以分为以下几种：

nonsecure JWT：未经过签名，不安全的JWT
JWS：经过签名的JWT
JWE：payload部分经过加密的JWT

1.nonsecure JWT

未经过签名，不安全的JWT。其header部分没有指定签名算法

{"alg": "none","typ": "JWT"
}

并且也没有Signature部分

2.JWS

JWS ，也就是JWT Signature，其结构就是在之前nonsecure JWT的基础上，在头部声明签名算法，并在最后添加上签名。创建签名，是保证jwt不能被他人随意篡改。我们通常使用的JWT一般都是JWS

为了完成签名，除了用到header信息和payload信息外，还需要算法的密钥，也就是secretKey。加密的算法一般有2类：

对称加密：secretKey指加密密钥，可以生成签名与验签
非对称加密：secretKey指私钥，只用来生成签名，不能用来验签(验签用的是公钥)

JWT的密钥或者密钥对，一般统一称为JSON Web Key，也就是JWK

到目前为止，jwt的签名算法有三种：

HMAC【哈希消息验证码(对称)】：HS256/HS384/HS512
RSASSA【RSA签名算法(非对称)】（RS256/RS384/RS512）
ECDSA【椭圆曲线数据签名算法(非对称)】（ES256/ES384/ES512）

Go的运用

struct

package mainimport ("fmt""github.com/dgrijalva/jwt-go""time"
)type MyClaims struct {Username string `json:"username"`jwt.StandardClaims
}func main() {mySingingKey := []byte("wiasdsafsd")c := MyClaims{Username: "jt",StandardClaims: jwt.StandardClaims{NotBefore: time.Now().Unix() - 60,ExpiresAt: time.Now().Unix() + 5,Issuer:    "jt",},}t := jwt.NewWithClaims(jwt.SigningMethodHS256, c)fmt.Println(t)s, err := t.SignedString(mySingingKey)if err != nil {fmt.Printf("%s", err)}fmt.Println(s)//time.Sleep(6 * time.Second)tokern, err := jwt.ParseWithClaims(s, &MyClaims{}, func(token *jwt.Token) (interface{}, error) {return mySingingKey, nil})if err != nil {fmt.Println(err)}fmt.Println(tokern.Claims.(*MyClaims).Username)
}

map

package mainimport ("fmt""github.com/dgrijalva/jwt-go""time"
)type MyClaims struct {Username string `json:"username"`jwt.StandardClaims
}func main() {mySingingKey := []byte("wiasdsafsd")t := jwt.NewWithClaims(jwt.SigningMethodHS256, jwt.MapClaims{"exp":      time.Now().Unix() + 5,"iss":      "jt","nbf":      time.Now().Unix() - 5,"username": "my",})s, err := t.SignedString(mySingingKey)if err != nil {fmt.Printf("%s", err)}fmt.Println(s)//time.Sleep(6 * time.Second)tokern, err := jwt.ParseWithClaims(s, &jwt.MapClaims{}, func(token *jwt.Token) (interface{}, error) {return mySingingKey, nil})if err != nil {fmt.Println(err)}fmt.Println(tokern.Claims.(*jwt.MapClaims))
}

生成解析token

如今有很多将身份验证内置到API中的方法 -JSON Web令牌只是其中之一。JSON Web令牌（JWT）作为令牌系统而不是在每次请求时都发送用户名和密码，因此比其他方法（如基本身份验证）具有固有的优势。要了解更多信息，请直接进入jwt.io上的介绍，然后再直接学习。

以下是JWT的实际应用示例。主要有两个部分：提供用户名和密码以获取令牌；并根据请求检查该令牌。

在此示例中，我们使用了两个库，即Go中的JWT实现以及将其用作中间件的方式。

最后，在使用此代码之前，您需要将APP_KEY常量更改为机密（理想情况下，该常量将存储在代码库外部），并改进用户名/密码检查中的内容，TokenHandler以检查不仅仅是myusername/ mypassword组合。

下面的代码是gin框架对jwt的封装

package mainimport ("fmt""net/http""time""github.com/dgrijalva/jwt-go""github.com/gin-gonic/gin"
)//自定义一个字符串
var jwtkey = []byte("www.topgoer.com")
var str stringtype Claims struct {UserId uintjwt.StandardClaims
}func main() {r := gin.Default()r.GET("/set", setting)r.GET("/get", getting)//监听端口默认为8080r.Run(":8080")
}//颁发token
func setting(ctx *gin.Context) {expireTime := time.Now().Add(7 * 24 * time.Hour)claims := &Claims{UserId: 2,StandardClaims: jwt.StandardClaims{ExpiresAt: expireTime.Unix(), //过期时间IssuedAt:  time.Now().Unix(),Issuer:    "127.0.0.1",  // 签名颁发者Subject:   "user token", //签名主题},}token := jwt.NewWithClaims(jwt.SigningMethodHS256, claims)// fmt.Println(token)tokenString, err := token.SignedString(jwtkey)if err != nil {fmt.Println(err)}str = tokenStringctx.JSON(200, gin.H{"token": tokenString})
}//解析token
func getting(ctx *gin.Context) {tokenString := ctx.GetHeader("Authorization")//vcalidate token formateif tokenString == "" {ctx.JSON(http.StatusUnauthorized, gin.H{"code": 401, "msg": "权限不足"})ctx.Abort()return}token, claims, err := ParseToken(tokenString)if err != nil || !token.Valid {ctx.JSON(http.StatusUnauthorized, gin.H{"code": 401, "msg": "权限不足"})ctx.Abort()return}fmt.Println(111)fmt.Println(claims.UserId)
}func ParseToken(tokenString string) (*jwt.Token, *Claims, error) {Claims := &Claims{}token, err := jwt.ParseWithClaims(tokenString, Claims, func(token *jwt.Token) (i interface{}, err error) {return jwtkey, nil})return token, Claims, err
}

JWT(Golang)相关推荐

Json web token (JWT) golang实现
Json web token (JWT) eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG ...
golang中的jwt
最近项目中需要用到鉴权机制,golang中jwt可以用.下面分享两个jwt demo,一个用gin实现,一个用golang中的原生http实现. https://www.cnblogs.com/jiu ...
Golang jwt跨域鉴权
Golang jwt跨域鉴权 JWT全称JSON Web Token是一种跨域认证解决方案,属于一个开放的标准,它规定了一种Token实现方式,目前多用于前后端分离项目和OAuth2.0 安装jwt ...
[Golang梦工厂]一个小项目带你学会GIN框架、JWT鉴权、swagger生成接口文档，看这一篇就够了
前言哈喽,大家好,我是asong,这是我的第八篇原创文章.听说你们还不会jwt.swagger,所以我带来一个入门级别的小项目.实现用户登陆.修改密码的操作.使用GIN(后台回复Golang梦工厂: ...
Go实战--golang中使用echo框架、MongoDB、JWT搭建REST API(labstack/echo、gopkg.in/mgo.v2、dgrijalva/jwt-go)
生命不止,继续go go go !!! 之前介绍过golang中restful api的博客,是使用redis作为持久化,httprouter作为框架: Go实战–通过httprouter和redis ...
golang jwt设置过期_听说你的JWT库用起来特别扭，推荐这款贼好用的！
以前一直使用的是jjwt这个JWT库,虽然小巧够用, 但对JWT的一些细节封装的不是很好.最近发现了一个更好用的JWT库nimbus-jose-jwt,简单易用,API非常易于理解,对称加密和非对称加 ...
Go实战--golang中使用JWT(JSON Web Token)
生命不止,继续 go go go !!! 之前写过关于golang中如何使用cookie的博客: 实战–go中使用cookie 今天就来跟大家简单介绍一下golang中如何使用token,当然是要依赖 ...
Golang微服务开发实践
github: github.com/yun-mu/Micr- 微服务概念学习:可参考 Nginx 的微服务文章微服务最佳实践:可参考微服务最佳实践 demo 简介服务: consignment ...
golang web 框架 gin beego iris 对比
1.1 框架排名 Gin 31k [Lite] Beego 22k Iris 16k Echo 15k [Lite] Revel 11k Martini 10k [×] buffalo 5k [Lit ...

JWT(Golang)

目录

JWT