目录
- JWT
- 什么是JWT
- 为什么要用JWT
- 传统Session认证的弊端
- JWT认证的优势
- JWT结构
- 1.Header
- 2.Payload
- 3.Signature
- JWT的种类
- 1.nonsecure JWT
- 2.JWS
- Go的运用
- struct
- map
- 生成解析token
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编码后用.
进行连接形成最终传输的字符串
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)根据以下公式生成签名
在计算出签名哈希后,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 main
import (
"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 main
import (
"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 main
import (
"fmt"
"net/http"
"time"
"github.com/dgrijalva/jwt-go"
"github.com/gin-gonic/gin"
)
//自定义一个字符串
var jwtkey = []byte("www.topgoer.com")
var str string
type Claims struct {
UserId uint
jwt.StandardClaims
}
func main() {
r := gin.Default()
r.GET("/set", setting)
r.GET("/get", getting)
//监听端口默认为8080
r.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 = tokenString
ctx.JSON(200, gin.H{"token": tokenString})
}
//解析token
func getting(ctx *gin.Context) {
tokenString := ctx.GetHeader("Authorization")
//vcalidate token formate
if 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
}