随着互联网的不断发展,技术的迭代也非常之快。我们的用户认证也从刚开始的用户名密码转变到基于 cookie 的session认证,然而到了今天,这种认证已经不能满足与我们的业务需求了(分布式,微服务)。我们采用了另外一种认证方式:基于token的认证。
一、与cookie相比较的优势:
1、支持跨域访问,将token置于请求头中,而cookie是不支持跨域访问的;
2、无状态化,服务端无需存储token,只需要验证token信息是否正确即可,而session需要在服务端存储,一般是通过cookie中的sessionID在服务端查找对应的session;
3、无需绑定到一个特殊的身份验证方案(传统的用户名密码登陆),只需要生成的token是符合我们预期设定的即可;
4、更适用于移动端(Android,iOS,小程序等等),像这种原生平台不支持cookie,比如说微信小程序,每一次请求都是一次会话,当然我们可以每次去手动为他添加cookie,详情请查看博主另一篇博客;
5、避免 CSRF 跨站伪造攻击,还是因为不依赖cookie;
6、非常适用于RESTful API,这样可以轻易与各种后端(java,.net, python ……)相结合,去耦合
还有一些优势这里就不一一列举了。
原理
后端不在存储认证信息,而是在用户登录的时候生成一个token,然后返回给前端,前端进行存储,在需要进行验证的时候将token一并发送到后端,后端进行验证。
二、基于JWT的token认证实现
JWT:JSON Web Token,其实token就是一段字符串,由三部分组成: Header , Payload ,Signature。详细情况请自行百度,现在,上代码。
1、引入依赖,这里选用java-jwt,选择其他的依赖也可以
2、实现签名方法
设置15分钟过期也是出于安全考虑,防止token被窃取,不过一般选择基于token认证,传输方式我们都应该选择https,这样别人无法抓取到我们的请求信息。这个私钥是非常重要的,加密解密都需要用到它,要设置的足够复杂并且不能被盗取,我这里选用的是一串uuid,加密方式是HMAC256。
3、认证
此处是演示的还是以传统的用户名密码验证,验证通过生成发放token。
4、配置拦截器
实现HandlerInterceptor,重写preHandle方法,该方法是在每个请求之前触发执行,从request的头里面取出token,这里我们统一了存放token的键为token,验证通过,放行,验证不通过,返回认证失败信息。
5、设置拦截器
以注入方式注入IOC,配置拦截器,放过认证接口。
6、token解码方法
7、postman测试
- 获取token,验证用户通过后返回token
- 访问携带token,请求成功,成功获取接口信息
- 访问携带token,token失效
本文完,如果感兴趣,索要源码可以关注私聊哦!
本文完,如果感兴趣,索要源码可以关注私聊哦!
相关文章
本站已关闭游客评论,请登录或者注册后再评论吧~