jwt,accesstoken、refresh token详解
JWT(json web token)
概念
JWT定义了一种紧凑的,自包含的形式,被用作在网络中安全的传输信息
格式
例如:xxxx.yyyyyyy.zzz
根据.分割,可以得到三部分,header,payload,signature。每部分可以使用Base64解码,就是一个JSON对象。
payload中会包含当前jwt的颁发者信息,JWT有效期,用户的凭证,权限信息,和用户自定义的信息等等。由于JWT是明文信息,所以不适合将一些敏感信息保存在JWT中
流程
客户端发起请求登陆,携带用户名和密码;
服务端验证身份,根据算法,将用户标识符打包生成token
服务器返回JWT信息给游览器,JWT不包含敏感信息;
客户端发起请求获取用户资料,把刚刚拿到的token一起发送给服务器;
服务器发现数据中有token,验明正身;
服务器返回该用户的用户资料;
JWT的6个缺点
1、JWT默认不加密,但可以加密。生成原始令牌后,可以使用改令牌再次对其进行加密。
2、当JWT未加密方法是,一些私密数据无法通过JWT传输。
3、JWT不仅可用于认证,还可用于信息交换。善用JWT有助于减少服务器请求数据库的次数。
4、JWT的最大缺点是服务器不保存会话状态,所以在使用期间不可能取消令牌或更改令牌的权限。也就是说,一旦JWT签发,在有效期内将会一直有效。
5、JWT本身包含认证信息,因此一旦信息泄露,任何人都可以获得令牌的所有权限。为了减少盗用,JWT的有效期不宜设置太长。对于某些重要操作,用户在使用时应该每次都进行进行身份验证。
6、为了减少盗用和窃取,JWT不建议使用HTTP协议来传输代码,而是使用加密的HTTPS协议进行传输。
安全在哪体现
JWT的安全性,说的是自身信息是防篡改,体现在它的签名部分signature。我们可以在生成JWT的时候,使用数字证书进行签名,采用非对称加密,可以很大程度的保证JWT的安全性。JWT默认是非加密的。
但是,JWT一经颁发,将无法回收,如果发生泄漏,将无法组织,这也是众所周知的JWT最大的问题。
JWT也是客服端-服务器在用户身份信息认证使用token形式的一种体现。jwt将用户身份信息认证保存在客户端,服务端也就不用维护用户状态,大大减轻了服务器的压力。客户端每次请求中,只需要携带这个JWT信息,
服务器根据JWT信息进行身份认证即可。
OAuth2(认证)
由上述可知,JWT存在颁发不可回收问题。如果JWT信息发生泄漏,就可以凭借此信息一直访问服务器信息,
只有等到JWT自动过期,用户的信息才会失效。
那么我们怎么维护用户身份信息呢?
我们可能最先想到,使用Redis(数据库)保存JWT信息,将信息维护服务器。
如果我们真的使用这种方式,那不就又回到了最初的使用服务端保存token的方式了吗?那这个JWT还有存在的必要吗?
第二种方式,我们尽可能短的设置JWT的有效时间,那么,就算用户的JWT信息泄漏了,对系统的访问时间也就尽可能的短了。
而在OAuth2中提出了access_token和refresh_token这两个概念
access_token
用于在客户端的一般请求中,使用此JWT信息验证用户身份。它的有效期通常设置的很短。
refresh_token
用于在access_token失效时,交换新的access_token。
基本流程
客户端向从资源所有者请求授权。
客户端收到授权许可,资源所有者给客户端颁发授权许可(比如授权码code)
客户端与授权服务器进行身份认证并出示授权许可(比如授权码code)请求访问令牌。
授权服务器验证客户端身份并验证授权许可,若有效则颁发访问令牌(accept token)。
客户端从资源服务器请求受保护资源并出示访问令牌(accept token)进行身份验证。
资源服务器验证访问令牌(accept token),若有效则满足该请求。