session认证机制和JWT token认证机制

目录

  • 1.web开发模式
    • (1)基于服务器渲染的传统web开发模式
    • (2)基于前后分离的web开发模式 (`目前主流的方式`)
  • 2.身份认证机制
  • 3.Session认证机制
    • 1)http的无状态性
    • 2)Cookie
      • (1)什么是cookie?
      • (2)cookie在身份认证中的作用
      • (3)cookie机制
    • 3)session的认证机制
    • 4)session的问题
  • 4.JWT token认证机制
    • 1)了解session认证的局限性
    • 2)什么是JWT
    • 3)JWT的工作原理
    • 4)JWT的组成部分
    • 5)JWT的使用

1.web开发模式

(1)基于服务器渲染的传统web开发模式

服务器发送给客户端的HTML页面,是在服务器端通过字符串的拼接,动态生成的。
因此,客户端不需要使用Ajax这样的技术额外请求页面的数据。
优点:前端耗时少;有利于SEO(Search Engine Optimization,搜索引擎优化)
缺点:占用服务器资源;不利于前后端分离,开发效率低

(2)基于前后分离的web开发模式 (目前主流的方式

前后端分离的开发模式,依赖于Ajax技术的广泛应用,简而言之,前后端分离的web开发模式,
就是后端只负责提供API接口,前端使用Ajax调用接口的模式。
优点:开发体验好;用户体验好;减轻了服务器端的渲染压力
缺点:不利于SEO。
利用Vue,React等前端框架的SSR(server sider render)技术能够很好的解决SEO问题。

2.身份认证机制

身份认证 authentication又称“身份认证”,“鉴权”,是指通过一定的手段,完成对用户身份的确定。
身份认证的目的,是为了确定当前所声称为某种身份的用户,确实是所声称的用户。
不同开发模式下的身份认证,对于服务端渲染和前后端分离这两种开发模式来说,分别有着不同的身份认证方案:

  • 服务器端渲染推荐使用Session认证机制
  • 前后端分离推荐使用JWT token认证机制

3.Session认证机制

1)http的无状态性

了解http协议的无状态性是进一步学习Session认证机制的必要前提。http协议的无状态性,指的是客户端的每次Http请求都是独立的,连续多个请求之间没有直接的关系,服务器不会主动保留每次HTTP请求的状态

2)Cookie

(1)什么是cookie?

现实生活中的会员卡身份认证方式,在web开发中的术语叫做cookie。
Cookie是存储在用户浏览器中的一段不超过4kb的字符串。它由一个名称(Name)一个值(Value)和其它几个用于控制Cookie有效期安全性使用范围的可选属性组成。
不同域名下的Cookie各自独立,每当客户端发起请求时,会自动把当前域名下所有未过期的cookie一同发送到服务器。
cookie的几大特性: 自动发送;域名独立;过期时限;4kb限制

(2)cookie在身份认证中的作用

客户端第一次请求服务器的时候,服务器通过响应头的形式,向客户端发送一个身份认证的Cookie,客户端会自动将cookie保存在浏览器中。
随后,当客户端浏览器每次请求服务器的时候,浏览器会自动将身份认证相关的Cookie,通过请求头的形式发送给服务器,服务器即可验明客户端的身份。

session认证机制和JWT token认证机制_第1张图片

(3)cookie机制

如果不在浏览器中设置过期时间,cookie被保存在内存中,声明周期随浏览器的关闭而结束,这个cookie简称会话cookie。如果在浏览器中设置了cookie的过期时间,cookie被保存在硬盘中,关闭浏览器后,cookie数据仍然存在,直到过期时间结束才消失。

3)session的认证机制

session用于保存每个用户的专门信息,变量的值保存在服务器端,通过session id来区分不同的客户。
session的认证机制,依赖于cookie,因为session id保存在cookie中。如果禁用cookie,则要使用URL重写,不安全。
session机制
当服务器收到请求,需要创建session对象时,首先会检查客户端请求中是否包含sessionid。如果有sessionid,服务器将根据sessionid返回对应session对象。如果客户端请求中没有sessionid,服务器会创建新的session对象,并把sessionid在本次响应中返回给客户端。通常使用cookie方式存储sessionid到客户端,在交互中,浏览器会默认携带cookie中的sessionid发送给服务器。
当浏览器支持cookie的时候,url不做任何处理。当浏览器不支持Cookie的时候,将会重写url将sessionid拼接到访问地址之后。

  1. 当用户第一次通过浏览器使用用户名和密码访问服务器的时候,服务器对用户名和密码进行验证
  2. 验证成功后,在服务器端生成并保存session数据,通过cookie向浏览器返回sessionid,浏览器将sessionid记录在cookie中。
  3. 当浏览器再次访问时,会默认携带cookie中的sessionid,服务器校验sessionid存在或有效,如果存在就保存会话,不需要登录,返回浏览器所需要的数据。

session认证机制和JWT token认证机制_第2张图片

4)session的问题

  • 扩展性(最大的问题):用户认证之后,服务器端做认证记录,如果认证记录被保存在内存中的话,这意味着用户下次请求还必须请求在这台服务器,这样才能拿到授权的资源。这样在分布式的应用上,相应的限制了负载均衡器的能力,也意味着限制了应用的扩展能力。
  • session的内存问题:因为session存在服务器内存(缓存,数据应该也可以存但是不好)中,用户过多时,内存开销会比较大。
  • CSRF(cross site request forgery 跨站请求伪造攻击):session基于cookie来进行用户识别的,cookie如果被截获,用户就会很容易收到跨站请求伪造攻击。

4.JWT token认证机制

1)了解session认证的局限性

session认证机制需要配合cookie才能实现。由于cookie默认不支持跨域请求访问,所以,当涉及到前端跨域请求后端接口的时候,需要做很多额外的配置,才能实现跨域session认证。

  • 当前端请求后端接口不存在跨域问题的时候,推荐使用session认证机制。
  • 当前端需要跨域请求后端接口的时候,不推荐使用session身份认证机制,推荐使用jwt认证机制。

2)什么是JWT

JWT(JSON Web Token)是目前最流行的跨域认证解决方案。它借助JSON格式数据作为web应用请求中的令牌,进行数据的自包含设计,实现各安全的信息传输,在数据传输过程中还可以对数据进行加密,签名等相关处理。

3)JWT的工作原理

session认证机制和JWT token认证机制_第3张图片
总结:用户的信息通过token字符串的形式,保存在客户端浏览器中。服务器通过还原token字符串的形式来认证用户的身份。

4)JWT的组成部分

JWT 通常由三部分组成,分别是Header(头部)Payload(有效载荷)Signature(签名)。三者之间使用英文的"."分隔,格式如下:Header.Palyload.Signature

  • 头部(header):包含token类型和加密算法信息,使用base64编码生产字符串
  • 载荷(payload):payload部分才是真正的用户信息,它是用户信息经过加密之后生成的字符串。
  • 签证(signature):防止jwt token被伪造
  • header和signature是安全性相关的部分,只是为来保证Token的安全性。

5)JWT的使用

客户端收到服务器返回的jwt之后,通常会将它存储在localStoragesessionStorage中。此后,客户端每次与服务器通信,都要带上这个jwt的字符串,从而进行身份认证。推荐的做法是把JWT放在HTTP请求头的Authorization字段中,格式如下:Authorization: Bearer

你可能感兴趣的:(前端,服务器)