前后端分离的登录:token机制

   随着互联网的不断发展,技术的迭代也非常之快。我们的用户认证也从刚开始的 用户名密码 转变到 基于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 的形式。


   开写之前先捋一下整理思路:
     1、首次登录时,后端服务器判断用户账号密码正确之后,根据用户id、用户名、定义好的秘钥、过期时间 生成 token ,返回给前端

     2、前端拿到后端返回的 token ,存储在 localStroage

     3、前端每次路由跳转, 判断 localStroage 有无 token ,没有则跳转到登录页,有则请求获取用户信息,改变登录状态

     4、每次请求接口,在 请求头里携带 token

     5、后端接口 判断 请求头有无 token,没有或者 token 过期,返回401

     6、前端得到 401 状态码重定向 到登录页面

发布了54 篇原创文章 · 获赞 19 · 访问量 2万+

猜你喜欢

转载自blog.csdn.net/qq_41970025/article/details/90705849